Re: [whatwg] microdata: itemprop in tag

[Tab Atkins Jr.]

On Sun, Oct 16, 2011 at 7:47 PM, David Karger  wrote:
> One natural way to represent a collection of structured items is in an html
> table.  this can coexist with microdata, by using  and  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  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 
> associated with a  should inherit the itemprop associated with that
>  .

Just put an @itemref on each , pointing to the s that are
part of that column.  It's more verbose, but it doesn't rely on
special HTML-only rules.

> It would yield even cleaner markup if there were a way to indicate that
> every  was a distinct itemscope (the common case).  For example, to use
>  to indicate that each row of the table scopes an item
> of type bar.    Or perhaps  could be interpreted as
> asserting a distinct itemscope for each row without specifying a type.

I'm not sure I understand.  Are you trying to mark up one item per
row, and just trying to save putting an @itemscope attribute on the
rows?  That's a fairly insignificant amount of savings for the
confusion it can cause (because now the itemscopes aren't obvious).

~TJ

[whatwg] microdata: itemprop in tag

[David Karger]

One natural way to represent a collection of structured items is in an 
html table.  this can coexist with microdata, by using  
and  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 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  
associated with a  should inherit the itemprop associated with that 
 .


It would yield even cleaner markup if there were a way to indicate that 
every  was a distinct itemscope (the common case).  For example, to 
use  to indicate that each row of the table scopes 
an item of type bar.Or perhaps  could be 
interpreted as asserting a distinct itemscope for each row without 
specifying a type.


But even using just the  inheritance rule, while still placing 
itemscope in  tags, would save a quadratic quantity of markup.

Re: [whatwg] Fullscreen

[Chris Pearce]

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.

Re: [whatwg] Fullscreen

[Chris Pearce]

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

[Chris Pearce]

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 

Re: [whatwg] DOCTYPE declaration

[Glenn Maynard]

On Sun, Oct 16, 2011 at 6:06 PM, Ashley Sheridan
wrote:

> Surely the  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] DOCTYPE declaration

[Ashley Sheridan]

On Sun, 2011-10-16 at 23:10 +0200, Nils Dagsson Moskopp wrote:

> Boris Zbarsky  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 includingdeclarations
> > 
> > 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  tag would do that? :p

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] DOCTYPE declaration

[Nils Dagsson Moskopp]

Boris Zbarsky  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 includingdeclarations
> 
> 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

Re: [whatwg] DOCTYPE declaration

[Boris Zbarsky]

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 includingdeclarations


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

[whatwg] CACHE MANIFEST

[Francis Boumphrey]

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

[Francis Boumphrey]

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 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

Doctypes in HTML have never, in practice, actually done anything
useful. 

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. wrote:

> On Sun, Oct 16, 2011 at 10:30 AM, Francis Boumphrey
>  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, 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.  "" is
> the minimal string that still triggers Standards Mode in every major
> browser.
>
> ~TJ
>

Re: [whatwg] How should overflow be handled when parsing integers?

[Mounir Lamouri]

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 
both  
and  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] How to render typographic puns in HTML5 -- aside, legend, alt, other?

[Jukka K. Korpela]

16.10.2011 2:26, Tab Atkins Jr. wrote:


On Sat, Oct 15, 2011 at 2:26 PM, David Dailey  wrote:

I know that there are a variety of accessibility things in HTML5. Take a
look at this small collection of simple typographic puns, currently rendered
in SVG:

http://cs.sru.edu/~ddailey/svg/2011/simplePuns.svg

I've added   and   to these in a way to explain the sometimes
visual effects to audiences that might not be reached by ordinary assistive
technology. The use of the mouse or examination of the source should reveal
what I'm up to.


In HTML as currently implemented in browsers, one could use  with 
title="...". This is far from ideal but would at least imply the 
mouseover behavior (on most browsers) and might give access to the 
explanatory information via assistive software, too.


By the way, I would not call these puns typographic, as they mostly do 
not depend on any particular visual appearance, as per fonts and other 
typographic measures, but orthographic - or just "puns of writing".



Question: how would you folks advise doing this in HTML5. Legend was the
thing that came to mind, but it looks as though it's not usable everywhere.
Aside seems to have slightly different semantics, since it is not so much an
aside as an explanation.  Maybe this is where a micro-format is appropriate?


 and   are likely the semantic you're looking for.


The  element has been defined rather liberally (or vaguely, if 
you want to put it that way), so that in addition to the obvious case of 
images, it may also include diagrams (perhaps Ascii graphics?), code 
listings, parts of poems, and videos - on the basis of explanations and 
examples in the HMTML5 draft. Along such lines, a pun of writing, where 
the written (and often intentionally mis-written) form of a word is 
essential, could be marked up as  and the explanation as 
.


However, one might ask what's the point of a  element when it 
has been defined so broadly. What could browsers, assistive software, 
indexing robots, and other relevant software do with it? Surely they 
could know that the  element, if present, is supposed to 
provide a caption for the , but is this really that different 
from the title attribute that we have now (and actually supported by 
software to some extent)?


Let's get back (well, not really back) to the basic _definition_ of 
: "The figure element represents some flow content, optionally 
with a caption, that is self-contained and is typically referenced as a 
single unit from the main flow of the document."


The string UNNNECESSARY is in some sense "self-contained" as a pun (and 
a funny one at that), and technically it's flow content and may have a 
caption, but it is hardly "referenced as a single unit from the main 
flow of the document". Rather, it's a standalone pun, and referencing it 
would be... well, naïve.


If we think that "typically referenced as a single unit from the main 
flow" is non-essential, what's left in the definition? Just the 
"self-contained" part. Almost anything would quality as a , 
given that "self-contained" is a very relative concept (most figures, 
for example, aren't really that self-contained but require both context 
and explanations).


And if you use  to explain a pun, that's like putting a joke 
in  and its explanation in a . Not that funny, is 
it? But I would expect browsers to render  contents by default.


The bottom line is that I would use . It has 
the advantage of being usable right now, and HTML5 doesn't seem to offer 
anything more suitable. Of course, I'm a Purist of a sort: it is better 
to use semantically empty markup (like ) than semantically wrong 
or even semantically questionable markup.


--
Yucca, http://www.cs.tut.fi/~jkorpela/

Re: [whatwg] DOCTYPE declaration

[Tab Atkins Jr.]

On Sun, Oct 16, 2011 at 10:30 AM, Francis Boumphrey
 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, 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.  "" is
the minimal string that still triggers Standards Mode in every major
browser.

~TJ

[whatwg] DOCTYPE declaration

[Francis Boumphrey]

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?
Frank

Re: [whatwg] Fullscreen

[João Eiras]

On Sat, 15 Oct 2011 05:27:21 +0100, Anne van Kesteren   
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.

[whatwg] How should overflow be handled when parsing integers?

[Daniel Bates]

(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 
 and 
 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