[whatwg] How should overflow be handled when parsing integers?
(Please disregard this email if you already received a copy of it) How should overflow be handled when parsing integers? Step 8 of the parsing algorithm in both http://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers and http://dev.w3.org/html5/spec/Overview.html#non-negative-integers doesn't mention how to handle integer overflow when interpreting the result of a sequence of base-ten integers. Currently in WebKit we consider such overflow a parsing error. Is there any reason not to consider overflow a parsing error? Regardless, I suggest codifying the handling of overflow in the aforementioned sections. This issue came up recently in WebKit with respect to the parsing of the maxlength attribute (https://bugs.webkit.org/show_bug.cgi?id=68981). Dan
Re: [whatwg] Fullscreen
On Sat, 15 Oct 2011 05:27:21 +0100, Anne van Kesteren ann...@opera.com
wrote:
I wrote up a draft:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
(...)
a)
The fullscreen media query is missing (I seriously suggest supporting it)
# @media all and (full-screen) { /* ... */ }
Does it make sense to have on/off as in the Mozilla proposal ? e.g. and
(full-screen:on/ff) ?
b)
I think that :fullscreen should not apply if there is no fullscreen
element. It would make the CSS snippet simpler, and the media query would
still allow fullscreen styles to be applied. It also allows the user agent
from optimize a bit to skip that fullscreen CSS snippet if there is no
fullscreen element bound. And the CSS snippet as mentioned applies only to
HTML, so another use case to have a media query.
c)
There should be a security note for request/cancel/enter/exitFullscreen
that the user agent might choose to dishonor the calls to these methods,
like if fullscreeen is not supported, or the browsing context is child of
another one that does not allow fullscreen, or the call to these methods
is not from a user initiated action. I would remark that user agents
should ignore calls to those methods if not coming from a user initiated
action (kind like the way pop ups are handled). So, the click to go
fullscreen button use case works, but a webpage going fullscren during
load and then spoof the browser UI would not. It would also make the use
case for requestFullScreenWithKeys API less interesting.
d)
Perhaps a non normative note just to explain that the flags do would be
nice for authors. fullscreen tells if the document is being rendered
fullscreen (a shortcut to check if the media query applies), and
fullscreenEnabled tells if the document is allowed to go fullscreen using
the enter/requestFullscreen API.
e)
Given their use cases, the flag fullscreenEnabled would be better called
fullscreenAllowed, and the fullscreen flag would be better called
fullscreenEnabled.
So far, nice work.
Re: [whatwg] How should overflow be handled when parsing integers?
On 10/16/2011 02:17 PM, Daniel Bates wrote: How should overflow be handled when parsing integers? Step 8 of the parsing algorithm in bothhttp://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers andhttp://dev.w3.org/html5/spec/Overview.html#non-negative-integers doesn't mention how to handle integer overflow when interpreting the result of a sequence of base-ten integers. Currently in WebKit we consider such overflow a parsing error. Is there any reason not to consider overflow a parsing error? Regardless, I suggest codifying the handling of overflow in the aforementioned sections. Gecko also considers that an overflow is a parsing error. Presto and IE6 doesn't seem to. The specs should probably mention this by whether consider it as a parsing error or request the UA to default to the highest value (which Presto and IE6 seem to do but not using the same value). This issue came up recently in WebKit with respect to the parsing of the maxlength attribute (https://bugs.webkit.org/show_bug.cgi?id=68981). Actually, this problem wouldn't have been that annoying if Webkit was following the specs regarding maxlength attribute: if the content attribute value isn't a valid non-negative integer, the element has no maximum allowed value length. -- Mounir
Re: [whatwg] DOCTYPE declaration
Thanks Tab, I guess I could have stated myself a little clearer. The spec says: DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications. My point is, as the only possible use for a DOCTYPE declaration in HTML (any version) is for including !ENTITY declarations, and no browser to my knowledge does, not even the niche browsers, why bother with an DOCTYPE declaration at all. As you point out tabDoctypes in HTML have never, in practice, actually done anything useful. /tab Surely the Living HTML Spec could be cutting out some dead-wood here. (Perhaps it's here just as some 'sacred cow' talisman and to prevent some 'hurt feelings' :) Frank On Sun, Oct 16, 2011 at 1:34 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 16, 2011 at 10:30 AM, Francis Boumphrey boumphre...@gmail.com wrote: I'm not sure if this is the right place to ask this. What, if any DOCTYPE declaration should be used on HTML5 documents. As these usually refer to a DTD, and living HTML does not have a DTD is it even appropriate to use one? You use the !DOCTYPE HTML doctype, as explained in the spec. Doctypes in HTML have never, in practice, actually done anything useful. The DTD reference hasn't been followed by any major browser (the W3C website has had to go to great lengths to protect itself from being DDOSed by the few editors and niche browsers that *do* follow DTD references), and essentially acts solely as a talisman that switches between Quirks Mode and Standards Mode. !DOCTYPE HTML is the minimal string that still triggers Standards Mode in every major browser. ~TJ
[whatwg] CACHE MANIFEST
This is a great new addition. However none of the current versions of Browsers provide an easy way to view cached files when the user is off line. Earlier IE's would give you an option, but this seems to have been done away with i later versions. Should not The spec require that compliant browsers provide an easy way to view cached files when the user is off line? Frank
Re: [whatwg] DOCTYPE declaration
On 10/16/11 2:15 PM, Francis Boumphrey wrote: My point is, as the only possible use for a DOCTYPE declaration in HTML (any version) is for including!ENTITYdeclarations And triggering browsers' standards mode, most importantly. why bother with an DOCTYPE declaration at all. To trigger standards mode. (Perhaps it's here just as some 'sacred cow' talisman and to prevent some 'hurt feelings' :) It's there to trigger standards mode in browsers. -Boris
Re: [whatwg] DOCTYPE declaration
Boris Zbarsky bzbar...@mit.edu schrieb am Sun, 16 Oct 2011 15:43:26 -0400: On 10/16/11 2:15 PM, Francis Boumphrey wrote: My point is, as the only possible use for a DOCTYPE declaration in HTML (any version) is for including!ENTITYdeclarations And triggering browsers' standards mode, most importantly. why bother with an DOCTYPE declaration at all. To trigger standards mode. It is also a nice „magic string“ to figure out if a file is a HTML file. Cheers, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] DOCTYPE declaration
On Sun, 2011-10-16 at 23:10 +0200, Nils Dagsson Moskopp wrote: Boris Zbarsky bzbar...@mit.edu schrieb am Sun, 16 Oct 2011 15:43:26 -0400: On 10/16/11 2:15 PM, Francis Boumphrey wrote: My point is, as the only possible use for a DOCTYPE declaration in HTML (any version) is for including!ENTITYdeclarations And triggering browsers' standards mode, most importantly. why bother with an DOCTYPE declaration at all. To trigger standards mode. It is also a nice „magic string“ to figure out if a file is a HTML file. Cheers, Surely the html tag would do that? :p -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] DOCTYPE declaration
On Sun, Oct 16, 2011 at 6:06 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: Surely the html tag would do that? :p It's optional. http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#optional-tags -- Glenn Maynard
Re: [whatwg] Fullscreen
On 15/10/2011 5:27 p.m., Anne van Kesteren wrote: I wrote up a draft: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Thanks for writing this up. Comments: 1. We should define what happens when the full-screen element is removed from a document. Roc and I thought it would be best to *not* reset the full-screen elements, :fullscreen, and :fullscreen-ancestor styles in ancestor documents, so that the current document's frame remains in full-screen mode. i.e. removing the full-screen element should result in the same state as if you requested full-screen on said element when it was not in a document. The fullscreen state needs to be reset in descendent documents though. 2. We should define what happens when the full-screen element is removed from a document and inserted into another document. I think we should reset the fullscreen element in the old fullscreen element's owner's doc, and reset all fullscreen state (flag and pseudo classes) in all the old owner document's descendent documents, but not in its ancestor documents. So this should be equivalent to requesting full-screen on an element, and releasing all references to that element (though arguably Document.fullscreenElement would keep that element alive in that case...). 3. Step 3.6 of the transition to fullscreen algorithm fires a fullscreenchange event to the document which requests fullscreen, regardless of whether it was already in fullscreen mode or not, and regardless of whether the fullscreen element changed. If a doc is already in fullscreen state, requesting fullscreen again may change the fullscreen element, but won't change the document.fullscreen flag. My thoughts are we should dispatch fullscreenchange in any document in the doc tree whenever document.fullscreen changes, or whenever the document.fullscreenElement changes (so that script knows if the request to change the fullscreen element was granted). 4. The transition to fullscreen algorithm needs to reset the full-screen state on all documents in the doctree, otherwise requesting full-screen on a node in a sibling/cousin document to the current fullscreen element's document will end up with inconsistent state. Also if a request for full-screen originates in a sibling/cousin document to the current full-screen element's document, resetting the fullscreen state in the documents in the sibling/cousin branch should cause fullscreenchange events to be dispatched to those documents. The order in which fullscreenchange events are dispatched should be defined (i.e. do the fullscreenchange events for documents exiting fullscreen run before or after the fullscreenchange events for documents entering fullscreen?). 5. The transition from fullscreen algorithm only fires the fullscreenchange event at the document which requests the fullscreen exit, not all the documents whose fullscreen state changes upon the exit of fullscreen (ancestor and descendent documents). 6. We should dispatch a fullscreendenied event if the request for fullscreen is denied. Feedback from authors is that it is critical to know whether a request for fullscreen has been denied, so that they can fallback to other mechanisms. Mozilla's original proposal intentionally didn't include this because we thought we'd require permission to enter fullscreen. We've since changed to an ask forgiveness model, where the request to go fullscreen can be made synchronously, so the previous criticisms against this event don't apply. Without this event, if there is an animation for enter full screen, there's no way to distinguish between entered full-screen but running animation and the fullscreen denied case, other than by setting a timeout of appropriate length, which is hacky. 7. I prefer requestFullScreen() for the same reason Olli gave. Especially if we make Element.requestFullScreen() asynchronous; enterFullScreen() really does imply synchronous action. I prefer exitFullscreen() to cancelFullScreen(). Regards, Chris Pearce. Defining when exactly the fullscreen enabled flag is set for Document objects I will leave up to HTML. As well as defining the allowfullscreen attribute. Presumably it should be set for Document objects associated with the top-level browsing context and descendant browsing context as long as their browsing context container has the aforementioned attribute set. If we want to transition from fullscreen when navigating, HTML can define that as well, neatly integrated in the navigation section. The Model section of the Fullscreen specification has an appropriate hook. I have not added the key restrictions given earlier emails. Unfortunately there was not that much feedback on them, but maybe this draft will help on that front! I went with fullscreen rather than full screen as that seemed cleaner and easier to type. I
Re: [whatwg] Fullscreen
On 15/10/2011 5:27 p.m., Anne van Kesteren wrote: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Defining when exactly the fullscreen enabled flag is set for Document objects I will leave up to HTML. As well as defining the allowfullscreen attribute. Presumably it should be set for Document objects associated with the top-level browsing context and descendant browsing context as long as their browsing context container has the aforementioned attribute set. By this do you mean the fullscreen enabled flag should be defined elsewhere in the HTML spec? Can we at least link to is to that it's easy for implementors to find? Ditto for allowfullscreen. Both of these things are important, we should have references to them at least. Or include them in this spec, with a note to move them into their new homes once we agree on the spec. Regards, Chris Pearce.
Re: [whatwg] Fullscreen
On 17/10/2011 5:31 a.m., João Eiras wrote:
a)
The fullscreen media query is missing (I seriously suggest supporting it)
# @media all and (full-screen) { /* ... */ }
Does it make sense to have on/off as in the Mozilla proposal ? e.g.
and (full-screen:on/ff) ?
We removed this from our proposal, since the view-mode media query has a
fullscreen mode. However the view-mode media query does not distinguish
between browser fullscreen mode (pressing F11 in Firefox and the same in
Opera) and DOM full-screen mode, where a particular element is
fullscreen. You need Document.fullscreen for that. Perhaps this is
indeed an argument for including a separate media query for the
fullscreen API's fullscreen mode.
b)
I think that :fullscreen should not apply if there is no fullscreen
element.
When is there no fullscreen element? When the fullscreen element isn't
in the document? Without the :fullscreen rule, containing frames won't
have the styles applied that enables iframe contents to appear fullscreen.
c)
There should be a security note for
request/cancel/enter/exitFullscreen that the user agent might choose
to dishonor the calls to these methods, like if fullscreeen is not
supported, or the browsing context is child of another one that does
not allow fullscreen, or the call to these methods is not from a user
initiated action.
This is implied by aborting when any ancestor browsing context's
document doesn't have the fullscreen enabled flag set.
I would remark that user agents should ignore calls to those methods
if not coming from a user initiated action (kind like the way pop ups
are handled). So, the click to go fullscreen button use case works,
but a webpage going fullscren during load and then spoof the browser
UI would not.
I agree, in fact we're doing this already in our implementation. Do we
need to add this to the spec as a recommendation?
d)
Perhaps a non normative note just to explain that the flags do would
be nice for authors.
I agree, this would make the spec more approachable.
e)
Given their use cases, the flag fullscreenEnabled would be better
called fullscreenAllowed, and the fullscreen flag would be better
called fullscreenEnabled.
fullscreenEnabled is better, as fullscreenAllowed implies that the
request is going to be granted, whereas fullscreenEnabled doesn't imply
that. For example, requests for fullscreen would still be denied if not
coming from a user-generated event handler even if
document.fullscreenEnabled returned true.
Regards,
Chris Pearce.
[whatwg] microdata: itemprop in col tag
One natural way to represent a collection of structured items is in an html table. this can coexist with microdata, by using tr itemscope and td itemprop tags. But by ignoring the structure of the table, this creates a lot of redundant attribute specification. It would yield cleaner markup if it were possible to use col itemprop=foo to indicate an item property that should be inherited by all cells in the given column. In other words, to assert that any td associated with a col should inherit the itemprop associated with that col . It would yield even cleaner markup if there were a way to indicate that every tr was a distinct itemscope (the common case). For example, to use table itemtype=bar to indicate that each row of the table scopes an item of type bar.Or perhaps table itemscope could be interpreted as asserting a distinct itemscope for each row without specifying a type. But even using just the col inheritance rule, while still placing itemscope in tr tags, would save a quadratic quantity of markup.
