[whatwg] Including

[Mark Nottingham]

Hi WHATWG,

I've maintained a little library for a while that does inclusion:
  https://github.com/mnot/hinclude
  http://mnot.github.com/hinclude/

It's used in a few different places, and is now part of Symfony 
, apparently. 

Besides the obvious issue of "should HTML5 have an inclusion tag?", something 
else has come up.

Right now, hinclude uses an XML namespace (hx:) to introduce a new tag. This 
was pretty widely tested to be interoperable way back, but AIUI that option is 
going away (whatever that means) in HTML5.

It's been suggested  that a data-* 
attribute on div could be used here, but reading the description there, I'm not 
so sure:

"[T]hese attributes are intended for use by the site's own scripts, and are not 
a generic extension mechanism for publicly-usable metadata."



hinclude is intended to be visible to software beyond the site's own scripts. 
So, what's the appropriate thing to do here? Keep on using hx:include (after 
all, it works)? use data-include or similar? Or?

Thanks,



--
Mark Nottingham   http://www.mnot.net/

Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality

[Boris Zbarsky]

On 11/12/12 4:17 PM, Boris Zbarsky wrote:

Still looking into what IE does in terms of which onerror handler is called.


Looks like IE, in all the modes I can test, does what the spec says 
right now.


I'll be changing Gecko to align with IE and the spec (and, arguably, 
sanity) here.


-Boris

Re: [whatwg] A plea to Hixie to adopt

[Silvia Pfeiffer]

On Tue, Nov 13, 2012 at 5:26 AM, Jens O. Meiert  wrote:

> Should  be optional or required?
>

> I’d deem an optional  to be nonsense because it suggests
> documents are inherently without goal, or focus.
>
> I’d deem a required  to be nonsense because we already have an
> (implied)  element, and because element proliferation doesn’t
> work in anyone’s favor.
>

I can imagine it to become "required", if we mean by that that the browsers
will need to parse a page and either find a  element or determine
heuristically with the Scooby-Doo algorithm which part of the page is
actually the main part and then add that to its DOM. Since we have the
Scooby-Doo algorithm, we have a means to stay backwards compatible.


That  essentially means  always seemed reasonable to me.
> There are plenty of options for authors to add styling hooks if they
> need any, including .


You are correct - there is no need for this for styling. However,  is
actually not for styling, but to provide a direct markup of the
*semantically* main piece of content on the page. A Scooby-Doo algorithm
can only heuristically determine what that is - with  the Web Dev
gets an actual vehicle to point their finger explicitly rather than
implicitly saying in a hand-wavy manner that it's what remains if you take
away all this other stuff (that is: if we're lucky and that "other stuff"
has actually been marked up).

Silvia.

Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality

[Boris Zbarsky]

On 11/12/12 11:48 AM, Boris Zbarsky wrote:

So I did a bit more experimenting, and at first glance when the function
runs, even though the function's global is actually window A the "this"
object seems to be set to window B... _That_'s not specced anywhere
either, afaict.


And in fact what the spec said was both ambiguous and not matching reality.

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=19947 about the 
"this" issue.  Still looking into what IE does in terms of which onerror 
handler is called.


-Boris

Re: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard

[Ian Hickson]

On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
> On Mon, Nov 12, 2012 at 6:08 PM, Ian Hickson  wrote:
> > On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
> >> But if everyone vows to just wait for 512 bytes (or EOF), then that's 
> >> fine with me.
> >
> > I don't think we should require tools to wait for 512 bytes. This is 
> > an area where if we have the requirement, some user agents are just 
> > going to have a timeout anyway and ignore the spec; we gain nothing by 
> > making it non-conforming to have a timeout.
> 
> I'm inclined to agree with you, but I'm curious what other implementers 
> have to say on the issue.
> 
> >> > What are the use cases for ‘Sniffing archives specifically’?
> >>
> >> No idea. I only included it for completeness.
> >
> > Please don't spec things for completeness without use cases. :-)
> 
> In that case, I need to know which you think you might want for HTML and 
> which you know you won't. (I don't know of any other specs reliant on 
> mimesniff.)

We definitely need (and are using) the generic sniffer, sniffing for 
images specifically, and the rules for text vs binary.

We may one day need a set of rules to sniff for a media resource (e.g. 
audio/wave vs video/webm), but whether we'll need this is as yet unclear 
(some browser vendors want to sniff, others don't).

CSS might need a font sniffer for @font-face, I don't know.

That's it, as far as I know.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard

[Gordon P. Hemsley]

On Mon, Nov 12, 2012 at 6:08 PM, Ian Hickson  wrote:
> On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
>> But if everyone vows to just wait for 512 bytes (or EOF), then that's
>> fine with me.
>
> I don't think we should require tools to wait for 512 bytes. This is an
> area where if we have the requirement, some user agents are just going to
> have a timeout anyway and ignore the spec; we gain nothing by making it
> non-conforming to have a timeout.

I'm inclined to agree with you, but I'm curious what other
implementers have to say on the issue.

>> > What are the use cases for ‘Sniffing archives specifically’?
>>
>> No idea. I only included it for completeness.
>
> Please don't spec things for completeness without use cases. :-)

In that case, I need to know which you think you might want for HTML
and which you know you won't. (I don't know of any other specs reliant
on mimesniff.)

-- 
Gordon P. Hemsley
m...@gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/

Re: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard

[Ian Hickson]

On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
> 
> But if everyone vows to just wait for 512 bytes (or EOF), then that's 
> fine with me.

I don't think we should require tools to wait for 512 bytes. This is an 
area where if we have the requirement, some user agents are just going to 
have a timeout anyway and ignore the spec; we gain nothing by making it 
non-conforming to have a timeout.

> > What are the use cases for ‘Sniffing archives specifically’?
> 
> No idea. I only included it for completeness.

Please don't spec things for completeness without use cases. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Enabling LCD Text in 2D canvases.

[Justin Novosad]

Greetings,

Looking at the discussion archives, I saw that there have been proposals in
the past for exposing anti-aliasing related features to the 2D canvas
rendering context.  I realize these proposals met significant opposition
each time. Nonetheless, I would like to quickly re-open the discussion
because I feel there is a lot at stake for the web platform.  How about a
2d canvas rendering context attribute for controlling text anti-aliasing,
which could be used to enable LCD text filtering?

The main motivation is to make web apps better.  For many types of apps,
DOM-based rendering is uncompetitively slow (e.g. rendering a large number
of independently positioned text labels). On the other hand, 2D canvas can
deliver significantly better performance in many cases, but there is a
degradation in visual quality due to the lack of LCD text filtering.
 Current browsers don't enable LCD text in 2D canvas to prevent rendering
artifacts.  If LCD text were enable-able, authors would have to be mindful
of a number of caveats in order to avoid rendering artifacts. For example,
artifacts could result from certain use cases of canvas compositing,
transforms on the canvas element, canvas-to-canvas copying with drawImage
with a transform applied.  These are the same caveats native app developers
must face when using LCD text filtering.

Any thoughts?

Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality

[Olli Pettay]

On 11/12/2012 11:55 AM, Boris Zbarsky wrote:

Consider the attached testcase, which calls setTimeout on a window and passes 
in a function from a different window.

When this function is then called, it throws.

Gecko, WebKit, and Presto all seem to trigger the onerror handler of the window 
setTimeout was called on in this case.

Per spec, section 7.1.3.5.1, we have:

   Whenever an uncaught runtime script error occurs in one of the
   scripts associated with a Document, the user agent must report
   the error at the URL of the resource containing the script (as
   established when the script was created), with the problematic
   position (line number and column number) in that resource, in
   the script's origin, using the onerror event handler of the
   script's global object.

But the global object is the window the function came from.  So the spec 
doesn't seem to match any of the above three rendering engines.  Does it
match Trident?

I ask because I'm worried about web compat here.  While I agree that what the 
spec says to do is the sensible thing (and in fact, I had accidentally
switched Gecko to doing what the spec says here as part of working on something 
else entirely), if none of the UAs do it then there may be web content
that relies on it not happening.  There are certainly tests in Mozilla's 
regression test suite that inadvertently rely on Gecko's current behavior...



First I thought the spec behavior would make more sense, but if the error is 
about executing something bound to
window A it would be quite surprising to get error event on window B.
But I don't feel strongly about this.


-Olli



-Boris

[whatwg] 'datetime-local' and 'datetime' comments

[Mounir Lamouri]

Hi,

We've been working on implementing date and time input types attributes
at Mozilla this summer and we found out that 'datetime-local' and
'datetime' have a quite odd behaviour.

'date' and 'time' are both timezone agnostic types: you just set a time
and date and we assume that it is relative to something. So, it seems
somewhat natural to assume that 'datetime' would be simply those types
added to each other. Instead of that, 'datetime' has a notion of
timezone and 'datetime-local' is the timezone agnostic type.

In addition of being more intuitive, it seems that a huge majority of
date/time usage are timezone agnostics because, usually, the timezone is
implicit. For example, booking flight/train tickets.
There is however some use cases I can think of, like scheduling a
meeting, where, sometimes, you might want to mess with timezones. But
those are quite rare.

Furthermore, there are currently two implementations for 'datetime' and
'datetime-local' I can think of:
- Opera: 'datetime' is like 'datetime-local' except that there is a
greyed 'UTC' text next to the datetime picker;
- Chrome Android: 'datetime' is exactly like 'datetime-local'.
I haven't checked what is actually sent when the form is submitted by
those implementations.

Last but not least, I have never seen any [good and simple] UI allowing
me to pick a date and time in a specific time zone. As far as I know,
there are no native UI for those things even on mobile where there are
UI for date and time pickers.

As a conclusion, given the lack of good UI and good implementations, I
think we should change the behaviour of 'datetime' to match the
behaviour of 'datetime-local' so developers don't use the former and
falsely expect the behaviour of the later.
Also, I would suggest that we remove 'datetime-local' from the
specifications. If later if find out that we really need a date-time
picker that is not timezone agnostic, we could add something. For the
moment, given the state of the implementations and the very tiny use
cases that could solve, I think having this type would hurt more than help.

Thanks,
--
Mounir

Re: [whatwg] A plea to Hixie to adopt

[Jens O. Meiert]

Should  be optional or required?

I’d deem an optional  to be nonsense because it suggests
documents are inherently without goal, or focus.

I’d deem a required  to be nonsense because we already have an
(implied)  element, and because element proliferation doesn’t
work in anyone’s favor.

That  essentially means  always seemed reasonable to me.
There are plenty of options for authors to add styling hooks if they
need any, including .

-- 
Jens O. Meiert
http://meiert.com/en/

Re: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard

[Henri Sivonen]

Thanks for pursuing this.

Resending feedback previously written at
https://bugzilla.mozilla.org/show_bug.cgi?id=808593#c10 :

I think the bits ‘type is equal to "font" or’ and ‘type is equal to
"archive" or’ are highly questionable. The most popular font types are
in the process of getting application/ types and the most popular
archives already have application/ types.

I suspect the ‘a reasonable amount of time has elapsed, as determined
by the user agent.’ is unnecessary. The HTML spec has the same
provision for the  prescan. Firefox didn’t implement it, a
couple of people complained, then fixed their code, and the sky didn’t
fall.

What are the use cases for ‘Sniffing archives specifically’? It
appears that it sniffs ODF-style files
(http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html#__RefHeading__752809_826425813
; EPUB, ODF, InDesign, etc.) and Open Packaging Conventions-based
files (https://en.wikipedia.org/wiki/Open_Packaging_Conventions ;
OOXML, XPS, etc.) files as zip archives. Is that intended and a
desirable outcome in the light of use cases? (In general, it would be
easier to review if the spec makes sense if the use cases and callers
of various sniffing functions were known.)

Otherwise, looks good to me.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard

[Gordon P. Hemsley]

On Mon, Nov 12, 2012 at 10:06 AM, Henri Sivonen  wrote:
> Resending feedback previously written at
> https://bugzilla.mozilla.org/show_bug.cgi?id=808593#c10 :
>
> I think the bits ‘type is equal to "font" or’ and ‘type is equal to
> "archive" or’ are highly questionable. The most popular font types are
> in the process of getting application/ types and the most popular
> archives already have application/ types.

Buzzkill. ;(

> I suspect the ‘a reasonable amount of time has elapsed, as determined
> by the user agent.’ is unnecessary. The HTML spec has the same
> provision for the  prescan. Firefox didn’t implement it, a
> couple of people complained, then fixed their code, and the sky didn’t
> fall.

This line was present in a previous draft of the spec, as was the
seeming allowance to begin matching the resource header before it had
finished loading. For simplicity in the algorithm, I removed the
latter, so I left the former in as an escape hatch for those who
wanted to emulate that behavior.

But if everyone vows to just wait for 512 bytes (or EOF), then that's
fine with me.

> What are the use cases for ‘Sniffing archives specifically’?

No idea. I only included it for completeness.

The 'rules for sniffing * specifically' are intended as hooks for
other specs to tie into. If no spec requires you to implement it, then
you have no need to implement it. HTML uses 'rules for sniffing images
specifically' (and 'rules for distinguishing if a resource is text or
binary'), and I imagine it could also find uses for 'rules for
sniffing audio specifically' and 'rules for sniffing video
specifically' (and maybe even 'rules for sniffing fonts
specifically').

> It
> appears that it sniffs ODF-style files
> (http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html#__RefHeading__752809_826425813
> ; EPUB, ODF, InDesign, etc.) and Open Packaging Conventions-based
> files (https://en.wikipedia.org/wiki/Open_Packaging_Conventions ;
> OOXML, XPS, etc.) files as zip archives. Is that intended and a
> desirable outcome in the light of use cases? (In general, it would be
> easier to review if the spec makes sense if the use cases and callers
> of various sniffing functions were known.)

I don't think that's intended, but I don't know. The selection of
which bytes to sniff predates me, and I don't know what the use cases
are.

> Otherwise, looks good to me.

Thanks for the review!

-- 
Gordon P. Hemsley
m...@gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/

[whatwg] Request for network diagnostic API

[张立理]

Hi all:
Recently we are digging into some performance issue related to our users' 
network, then we found we lack some methods to get required information about 
their network stats.
After some researches, we found a list of most frequently encountered issues:
1. User's IP, when mapped to our IP->ISP library, got a wrong result, so we 
respond the user with a wrong server, which dramatically slows down the 
transfer speed.2. User has his own network broken, but didn't know where the 
issue is.3. User couldn't even give us a simple network connectivity 
information so we were unable to confirm the problem.
As of above 3 issues, we think we should request some network diagnostic 
methods to help identify theses issues, including:
1. A `nslookup` method which gives the DNS lookup result, so we could help 
dianose whether our user connects the fastest server.2. A `traceroute` method 
which help us discover which section was out of work we we could, for example, 
contact out ISP to quickly fix it.3. A `ping` method which simply shows the 
connectivity between user's device and our server, and speed sometimes.
With these API we are quite sure we could identify most network issues quickly 
and easily, but without them, we have to send user a client application which 
collects all these information and then send to our server, however this is not 
a best choice, since user may suspect that we were giving some malware (e.g. 
keyboard monitoring app).
And also, with these API, if users could allow us to collect network 
informations, we could continuously research these data, finding where / when 
we do not give a best connectivity, and then improve to render a better service 
to our users.
We know these API are very privacy-sensitive, so it should **display a confirm 
panel** to user first just like the Geolocation API, telling user which website 
it willl be testing.

Gray 
Zhang---otakustay@live.comhttp://www.otakustay.com
 (Broken)  

Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality

[Simon Pieters]

On Mon, 12 Nov 2012 10:55:36 +0100, Boris Zbarsky  wrote:


Consider the attached testcase, which calls setTimeout on a window and
passes in a function from a different window.

When this function is then called, it throws.

Gecko, WebKit, and Presto all seem to trigger the onerror handler of the
window setTimeout was called on in this case.

Per spec, section 7.1.3.5.1, we have:

   Whenever an uncaught runtime script error occurs in one of the
   scripts associated with a Document, the user agent must report
   the error at the URL of the resource containing the script (as
   established when the script was created), with the problematic
   position (line number and column number) in that resource, in
   the script's origin, using the onerror event handler of the
   script's global object.

But the global object is the window the function came from.  So the spec
doesn't seem to match any of the above three rendering engines.  Does it
match Trident?

I ask because I'm worried about web compat here.  While I agree that
what the spec says to do is the sensible thing (and in fact, I had
accidentally switched Gecko to doing what the spec says here as part of
working on something else entirely), if none of the UAs do it then there
may be web content that relies on it not happening.  There are certainly
tests in Mozilla's regression test suite that inadvertently rely on
Gecko's current behavior...

-Boris


I don't see any attachment. Maybe the whatwg list prunes them? Can you  
send it to www-archive?


Do browsers use the script's origin per spec, or do they use the  
function's global object's document's origin (for the purpose of tainting  
the arguments)?


--
Simon Pieters
Opera Software

[whatwg] main spec updated with suggested changes to parser behaviour and rendering

[Steve Faulkner]

Hi all,

have updated the main spec with suggested changes to parser behaviour [1]
and rendering [2]

https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

feedback welcome!



[1]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0045.html
[2]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0054.html



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

[whatwg] Spec for handling runtime script errors doesn't seem to match reality

[Boris Zbarsky]

Consider the attached testcase, which calls setTimeout on a window and 
passes in a function from a different window.


When this function is then called, it throws.

Gecko, WebKit, and Presto all seem to trigger the onerror handler of the 
window setTimeout was called on in this case.


Per spec, section 7.1.3.5.1, we have:

  Whenever an uncaught runtime script error occurs in one of the
  scripts associated with a Document, the user agent must report
  the error at the URL of the resource containing the script (as
  established when the script was created), with the problematic
  position (line number and column number) in that resource, in
  the script's origin, using the onerror event handler of the
  script's global object.

But the global object is the window the function came from.  So the spec 
doesn't seem to match any of the above three rendering engines.  Does it 
match Trident?


I ask because I'm worried about web compat here.  While I agree that 
what the spec says to do is the sensible thing (and in fact, I had 
accidentally switched Gecko to doing what the spec says here as part of 
working on something else entirely), if none of the UAs do it then there 
may be web content that relies on it not happening.  There are certainly 
tests in Mozilla's regression test suite that inadvertently rely on 
Gecko's current behavior...


-Boris

Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality

[Boris Zbarsky]

On 11/12/12 2:00 AM, Boris Zbarsky wrote:

On 11/12/12 1:55 AM, Boris Zbarsky wrote:

Consider the attached testcase, which calls setTimeout on a window and
passes in a function from a different window.


Note that I observe the same behavior if I set onclick on another window
too...


And with addEventListener, likewise.

-Boris

Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality

[Boris Zbarsky]

On 11/12/12 1:55 AM, Boris Zbarsky wrote:

Consider the attached testcase, which calls setTimeout on a window and
passes in a function from a different window.


Note that I observe the same behavior if I set onclick on another window 
too...  It seems just as bizarre there.  :(


-Boris