date:20090713

On Tue, 23 Jun 2009, Simon Pieters wrote:
> > +
> > +  Classes from the class attribute
> > +  of HTML elements in documents that are in quirks
> > +  mode must be treated as case-insensitive.
> 
> This is the case for SVG classes, too, but maybe it's up to the SVG spec 
> to define that.

Yeah, I'd rather not poke any more fingers into SVG than I already have...


> > +  Attribute selectors on an HTML
> > +  element in an HTML
> > +  document must treat the values of attributes with
> > +  the following names as case-insensitive:
> 
> Why are values case-insensitive only in HTML documents? The values are
> case-insensitive in XHTML, too.

Do we really want to have anything case-insensitive in XML docs?


> This list is missing charset and ismap

As far as I can tell, those are not case-insensitive in Selectors in 
either Gecko or WebKit.


> and presumably the new attributes in HTML5: [...]

Why would we want to add anything to this list?


I'd rather keep this list as small as possible.

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

Re: [whatwg] drawImage() - image argument description for animation

On Mon, 22 Jun 2009, OmegaJunior wrote:
>
> Currently the drawImage() function defines the following behaviour for
> its image argument if that happens to represent an animation:
> 
> "When the drawImage() method is passed, as its image argument, an
> HTMLImageElement representing an animated image, the poster frame of
> the animation, or the first frame of the animation if there is no
> poster frame, must be used."
> 
> This seems grammatically incorrect (but isn't). However, I found it a
> bit convoluted, and had to read it several times before understanding
> what was intended.

Fixed. Thanks.

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

Re: [whatwg] hasFeature() When Only 1 Syntax is Supported

On Sat, 20 Jun 2009, Smylers wrote:
>
> The current text suggests that a user-agent may choose to support only 
> the HTML syntax (not XHTML) but should still return true for 
> hasFeature("XHTML", "5.0").
> 
> If that isn't intended then the requirements for hasFeature() should be
> changed to depend on the syntaxes chosen to be implemented.  If it _is_
> intended (and given various things browsers have to do for web
> compatibility, it wouldn't surprise me) then perhaps it would be better
> to spell this out explicitly, since it's counter-intuitive.
> 
> hasFeature() currently has the implementation requirements:
> 
>   User agents should respond with a true value when the hasFeature
>   method is queried with these values.
> 
> -- http://www.whatwg.org/html5#dom-feature-strings:
> 
> Where "these values" are ("HTML", "5.0") and ("XHTML", "5.0").
> 
> However while supporting both HTML and XHTML is "encouraged",
> user-agents "may" choose to support only one of them:
> 
>   http://www.whatwg.org/html5#conformance-requirements

On Mon, 22 Jun 2009, Simon Pieters wrote:
> 
> Maybe the spec should remove these feature strings altogether and 
> encourage authors to use more accurate methods of detecting support.

On Wed, 24 Jun 2009, Simon Pieters wrote:
> 
> The spec is now gaining all the remaining stuff from DOM2 HTML, so this 
> note is incorrect:
> 
> "Note: The interfaces defined in this specification are not always 
> supersets of the interfaces defined in DOM2 HTML; some features that 
> were formerly deprecated, poorly supported, rarely used or considered 
> unnecessary have been removed. Therefore it is not guaranteed that an 
> implementation that supports "HTML" "5.0" also supports "HTML" "2.0"."
> 
> I'm thinking that the spec should maybe just use "2.0" instead of "5.0", 
> since it's what browsers do and there might be pages that check for 
> this.
> 
> Meanwhile it seems useful to return false as appropriate if the UA only 
> allows one of the syntaxes, as Smylers points out.

I've removed everything but HTML/2.0.

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

Re: [whatwg] Date or Time String with Just a Time

On Fri, 19 Jun 2009, Smylers wrote:
>
> A valid time string, such as "10:55", is one of the possible values for 
> a valid date or time string:
> 
>   http://www.whatwg.org/html5#vaguer-moments-in-time
> 
> But step 10 of the parsing rules says:
> 
>   If the 'time present' flag is true, but 'position' is beyond the end
>   of 'input', then fail.
> 
> That would appear to fail on "10:55".  I think making step 10 begin "If
> the 'date present' and 'time present' flags are both true" (as step 11
> already does) fixes this.

Um, yes. Good call. Fixed.

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

Re: [whatwg] Week Strings

On Fri, 19 Jun 2009, 'Smylers' wrote:
>
> And even states the blindingly obvious:
> 
>   The 'week number of the last day' of a week-year with 53 weeks is 53;
>   the 'week number of the last day' of a week-year with 52 weeks is 52.

I use the term "week number of the last day" as a kind of function in the 
spec, so while it may be obvious, it has to be listed explicitly otherwise 
one could argue that it isn't defined. (I could probably just stop using 
it as a function and just assume that people will apply common sense, but 
sometimes that doesn't work so well...)

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

Re: [whatwg] Week Strings

On Fri, 19 Jun 2009, Smylers wrote:
>
> For  elements the spec requires:
> 
>   The value attribute, if specified, must have a value that is a valid
>   week string.
> 
> -- http://www.whatwg.org/html5#week-state
> 
> But the spec's HTML source contains this comment immediately afterwards:
> 
>   
>
> Does that comment mean that the above requirement will be changed to
> something along the lines of "must have a value that is a syntactically
> valid week string but may represent a week that doesn't actually exist"?

No, it just means that there's no requirement that the value="" be within 
the range given by min="" and max="". It's a reminder to myself in case I 
notice there's no such requirement one day and go and add one thinking it 
was a mistake.


> That is, the author can seed a browser's week-picker control to a value 
> which the browser must not submit back to the server?

So long as it is a valid week string, yes.


> In general determining that something is a valid week string requires 
> knowing which day of the week the year in question begins on.  For 
> example "2009-W53" is a valid week string (because 2009 began on a 
> Thursday) but "2010-W53" isn't (because 2010 will begin on a Friday). 
> Browsers will need to do this to know whether they can submit a week 
> value.

Yup.


> The spec doesn't appear to provide an algorithm for determining which 
> day of the week a year begins on (however I am not a browser developer; 
> possibly this is sufficiently straightforward that those who are don't 
> need it spelling out).

As far as I can tell, it is well-defined in the spec.


> Currently Validator.nu accepts this:
> 
>   
> 
> but not this:
> 
>   
> 
> If out-of-range week values are to be permitted in  elements then 
> a validator should permit both of them.  Conversely if they aren't 
> permitted then it should accept neither of them (and therefore have to 
> implement a 'which day is January 1st' algorithm, which I'm guessing it 
> currently doesn't).

Please report such bugs straight to Henri. :-)

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

Re: [whatwg] External document subset support

On Fri, 19 Jun 2009, Brett Zamir wrote:
> 
> 1) Firefox and Webkit, should not give a single point of failure for a 
> missing entity as they do now, (unless they switch to a validating 
> parser which finds no declaration in the external file and the user is 
> in validation mode), since such failures in a document with an external 
> DTD are NOT well-formedness errors unless the document deliberately 
> declares standalone=yes.
> 2) Explorer, which no longer seems to require in IE8 that the document 
> be completely described by the DTD as I believe it had earlier (though 
> it will report errors if the document violates rules which are 
> specified), should, per the spec, really only report validation errors 
> upon user option (ideally, I would say, off by default, and activatable 
> on a case-by-case as well as preference-based basis). This will possibly 
> speed things up if the option could be disabled as well as let their 
> browser work with documents which violate validation. But this issue is 
> not as serious as #1, since #1 prevents even valid documents from being 
> interoperably viewed on the web.
> [...]

These issues seem out of scope for HTML5. I recommend bringing them up 
with the respective vendors directly.

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

Re: [whatwg] Charset override table should match case of IANA registry

On Thu, 18 Jun 2009, Geoffrey Sneddon wrote:
>
> Although charsets are case insensitive, it'd probably be best to be 
> consistent with the IANA registry. The only change this means makes is 
> changing "Windows-*" to "windows-*".

Fixed.

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

Re: [whatwg] Plus Signs in Signed Integers

On Thu, 18 Jun 2009, Smylers wrote:
>
> The algorithm for parsing signed integers does not allow an optional
> plus sign before positive integers; that is, parsing "+4" will return an
> error at step 8 of this algorithm:
> 
>   http://www.whatwg.org/html5#rules-for-parsing-integers
> 
> That is inconsistent with the algorithm for non-negative integers, which
> tolerates (and ignores) a leading plus sign (step 6):
> 
>   http://www.whatwg.org/html5#rules-for-parsing-non-negative-integers

I've made + be tolerated by the signed parser also.

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

[whatwg] Adding "canonical" to the list of allowed link types

2009-07-13 Thread James Ide

Currently rel="canonical" (
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html)
is not in the allowed set of link types listed at
http://www.whatwg.org/specs/web-apps/current-work/#linkTypes . Looking back
through archived posts, it seems that it was once briefly mentioned in
passing but there was no discussion regarding its addition to the spec.
Considering its usefulness, are there plans to add "canonical" to the
official list of accepted values?

Regards,
James

Re: [whatwg] "HTML 5" and "HTML4"

On Thu, 18 Jun 2009, Smylers wrote:
>
> The 'History' section starts:
> 
>   Work on HTML 5 originally started in late 2003, as a proof of concept
>   to show that it was possible to extend HTML4's forms ...
> 
> -- http://www.whatwg.org/html5#history-0
> 
> Having "HTML 5" (with a space) and "HTML4" (no space) seems oddly 
> inconsistent.  Could we have them matching?

If this is the biggest problem you can find, we're doing well. :-)

Fixed.

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

Re: [whatwg] Dom as Audience Prereq

On Thu, 18 Jun 2009, Smylers wrote:
>
> The audience section states familiarity with Dom Core and Dom Events as 
> prereqs for reading the HTML 5 spec:
> 
>   http://www.whatwg.org/html5#audience
> 
> As somebody without this Dom background there are certainly many parts 
> of the spec which I've found both understandable and useful (to a web 
> author).
> 
> There may be parts which do require Dom knowledge, but as written it 
> sounds like a prereq for understanding any part of the spec, and as such 
> may unnecessarily put people off.

Fixed.

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

Re: [whatwg] Tool Implementor Audience

On Thu, 18 Jun 2009, Smylers wrote:
>
> One of the audiences for HTML is stated as "implementors of tools that 
> are intended to conform to this specification":
> 
>   http://www.whatwg.org/html5#audience
> 
> That seems circular, verging on tautologous: a tool author wondering 
> whether this spec is relevant to her (and therefore whether her tool 
> should aim to conform with it) isn't any better informed having read the 
> above.

Fixed.

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

Re: [whatwg] Lede Example

On Thu, 18 Jun 2009, Smylers wrote:
>
> One of the examples of  is marking up a lede paragraph:
> 
>   http://www.whatwg.org/html5#the-b-element
> 
> Is a lede semantically relevant to the document such that it needs to be
> in the mark-up?

Sure, why not?

> Emboldening the first paragraph of an article seems like a matter of
> style to me, similar to using a drop cap for the first letter.

It's not always just the first paragraph. Sometimes it's the first 
sentence, or the first two paragraphs, or the first phrase, it varies 
based on the conventions of the publication and on the content.

> For example, if an article were syndicated to multiple news sites it's 
> conceivable that some would style the lede differently from other 
> paragraphs and some wouldn't -- and doing so or not wouldn't affect the 
> meaning of the article or its interpretation by readers.

Indeed, some would remove the styling of the , some would not. It shows 
that  is not presentational in this case.

> So using CSS (I think article > h2 + p would do it) would seem more 
> appropriate than any mark-up here.  Especially since  is labelled as 
> "a last resort".

I don't see how the CSS can always know what the lede is.

> Highlighting specifically just the first sentence (even if the first 
> paragraph has multiple sentences) is more awkward, in that I don't think 
> it's currently possible with CSS.  But that it exists as a plausible 
> choice for presenting an article demonstrates how much a matter of 
> styling, rather than content, this area is.  And a limit of CSS should 
> be fixed in CSS, not HTML.  ( can always be used as a 
> work-around.)

I think it would be wrong to depend on CSS here, because even though the 
lede's desired presentation might vary from publication to publication, if 
the author wants a lede, then it should render, whether or not the user 
supports CSS.

In any case, this is just an example. Do you have any suggestions of 
another example to replace it?

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

Re: [whatwg] DOMTokenList is unordered but yet requires sorting

2009-07-13 Thread Jonas Sicking

On Mon, Jul 13, 2009 at 6:24 AM, news.gmane.org wrote:
> On 7/13/2009 7:26 AM, Jonas Sicking wrote:
>>
>> On Sun, Jul 12, 2009 at 9:00 PM, Ian Hickson  wrote:
>>>
>>> If we don't remove duplicates, then things like the .toggle() method
>>> could
>>> have some quite weird effects.
>>
>> Such as? The only one I can think of is that calling .toggle() would
>> remove multiple items. I don't see that as a problem?
>
> I think Ian is referring to duplicates here as "duplicates of the token
> being removed", not as "duplicates of any token in the underlying
> attribute". In the current spec algorithm, removing or toggling a token
> won't remove duplicates in other tokens.

That's what I was referring to too. For example if a DOMTokenList were
to contain two "hello" tokens, and the user called .toggle(), that
would remove two tokens from the list (both with the value "hello").

>> Define .remove() as removing all tokens with the given value, and
>> .toggle() as:
>>
>> function toggle(token) {
>>   if (this.contains(token))
>>     this.remove(token);
>>   else
>>     this.add(token);
>> }
>
> That's what toggle() does right now. (With the small difference that it also
> returns a boolean to indicate if the token was removed or added).

Yup, so I don't really see a problem with allowing multiple tokens of
the same value.

> This is a bit unrelated, but when looking at the DOMTokenList
> implementation, I had an idea about an alternative algorithm that could be
> easier to implement and could also be described more simply in the spec. The
> disadvantage is that the DOMTokenList methods mutating the underlying string
> wouldn't preserve existing whitespace (which the current algorithms try hard
> to do).
>
> The idea is that any DOMTokenList method that mutates the underlying string
> would do:
>  - split the attribute in unique tokens (preserving order).
>  - add or remove the token according to the method called.
>  - rebuild the attribute string by concatenating tokens together (with a
> single space).
>
> At first, this may look like inefficient (if implemented naively).
> But I guess that implementations will usually keep both the attribute string
> and a list of tokens in memory, so they wouldn't have to tokenize the string
> on every mutation. There is a small performance hit during attribute
> tokenization: the list of tokens would need to keep only unique tokens. But
> after that, the DOMTokenList methods are very simple: length/item() don't
> need to take care of duplicates, add/remove/toggle are simple list
> manipulation (the attribute string could be lazily generated from the token
> list when needed).
>
> To summarize:
> pros: simpler spec algorithms, simpler implementation
> cons: less whitespace preservation, small perf hit during tokenization
>
> I don't know if I'm missing something. Does this sound reasonable?

I do agree that the spec seems to go extraordinary far to not touch
whitespace. Normalizing whitespace when parsing is a bad idea, but
once the user modifies the DOMTokenList, I don't see a lot of value in
maintaining whitespace exactly as it was.

Ian: What is the reason for the fairly complicated code to deal with
removals? At least in Gecko it would be much simpler to just
regenerate the string completely. That way generating the string-value
could just be dropped on modifications, and regenerated lazily when
requested.

/ Jonas

Re: [whatwg] HTML 5 video tag questions

On Mon, Jul 13, 2009 at 4:28 PM, Jonas Sicking wrote:
> This way even incremental rendering of the fallback contents would
> work fine. The only case that's weird is markup like:
>
> 
>  lots and lots of fallback here
>  
> 
>
> There is a risk that content would be displayed, and then switch to
> displaying video. This doesn't seem like a big problem as it seems
> more likely that people will put the  first. And if someone
> doesn't the effects aren't very bad.

That's against spec anyway ( elements, if present, should be
the first children of , and are then followed by fallback
content if present), so it's not a big deal if it displays badly.

Re: [whatwg] HTML 5 video tag questions

On Mon, Jul 13, 2009 at 4:01 PM, Philip Jägenstedt wrote:
> I thought you meant
>
> 
>  
>    fallback content here
>  
> 
>
> I would prefer if fallback content and source elements weren't mixed on the
> same level, but maybe that's just me.

Eh, fallback content for non- browsers is already there, so
it's nothing new.

>> (You could also just put @fallback on the second  and drop the
>> third  entirely for the same effect.)
>
> Once the source element is iterated by the resource selection algorithm and
> starts loading, the fallback attribute or the whole source element might be
> removed. You would have to set a flag at some point to remember the fallback
> state and unset it... when? What is the effect of
>
> 
> 
> 
> fallback here
> 
>
> ?

It would hit the first , note that there's no @src, see that
there is @fallback, and immediately drop to showing fallback content.

> Is fallback irrevocable or could the same video element go back to showing
> video under some circumstances?

It should be revocable in the exact same circumstances that a 
element might start playing from one , and then switch to
another.  From my reading of the algorithm I don't think this is
possible, so fallback would be irrevocable.

> Does audio also have fallback content?

It uses  and the same source-selection algorithm (and the same
fallback situation in the case of non- browsers), so yes.

>>> This is why I suggested >>
>>> src="cant.play.ogg">Ooops!
>>>
>>> I still think the use of this is questionable though.
>>
>> I'm not sure why you think the usecase is questionable.  It seems
>> pretty clear - it'd be nice to have a non-script way of showing
>> content (specifically, alternate video players) when the browser
>> supports  but can't play any of the provided sources.
>
> Yes, handling the (minor) use case video support + no supported source + no
> script would be nice, but only if it doesn't make an even bigger mess of the
> resource selection algorithm and doesn't allow switching back and forth
> between video and fallback.

>From what I can tell of the resource selection algorithm, fallback
should be irrevocable, just like a successful  load is.

The resource selection algorithm appears to need fairly trivial
changes to accommodate this.  Step 4, when parsing @src from ,
insert a new substep between substeps 2 and 3.  Pull the first
sentence from the current substep 3 into this new substep, and say
something like "If the element has a fallback attribute, abort this
algorithm immediately and display the fallback content."  When parsing
 elements, change step 3 so that whenever any of those
conditions are met, if the  has @fallback the algorithm aborts
immediately and shows the fallback content, otherwise it fires the
error event and jumps to the "search loop" step as normal.

Alternately, we could just put @fallback always on the  element
directly, rather than on .  That would preserve the first part
of what I said, but now we have a step between substeps 9 and 10 that
checks for @fallback on the .  If it finds it, it immediately
aborts and shows the fallback content, otherwise substep 10 proceeds
normally (waiting forever).

~TJ

Re: [whatwg] HTML 5 video tag questions

2009-07-13 Thread Jonas Sicking

On Mon, Jul 13, 2009 at 5:01 AM, Philip Jägenstedt wrote:
>>> The design you describe is what  tried to do, and it proved to be
>>> extremely problematic in practice -- and that was without another
>>> built-in
>>> fallback mechanism to complicate matters.
>>
>> While  has had a very poor implementation story, I don't think
>> this was a big reason for that.
>>
>> Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
>> answer this better, but at least in gecko I don't think this part of
>> object was particularly hard to implement correctly once we actually
>> tried.
>>
>> Has any browser vendor argued against displaying the fallback due to
>> high implementation burden?
>
> Implementation probably isn't the biggest burden here, specifying sane
> behavior is. For example:
>
> If fallback content is displayed after the last source element has failed,
> what should happen when a new source element is inserted? Switching back to
> "video mode" would make it even more special than object fallback and if you
> don't you'll just get stuck with fallback and have effectively broken the
> possibility of inserting source elements via scripts.
>
> Something like  src="cant.play.ogg">Ooops!
> is what you'd need to make the resource selection algorithm deal with
> fallback in a sane way when scripts are disabled, but this is too much of a
> corner case to justify the complexity in my opinion.

I think fallback contents is simply defined as the contents of the
, minus any  elements (which wouldn't render anyway).
No need for .

The simplest solution would be to display the fallback when there
aren't any  (or @src) elements being either displayed or
waiting to load. I think spec-wise the simplest thing would be to
display fallback when

The networkState of the element is NETWORK_NO_SOURCE.

This way even incremental rendering of the fallback contents would
work fine. The only case that's weird is markup like:

  lots and lots of fallback here

There is a risk that content would be displayed, and then switch to
displaying video. This doesn't seem like a big problem as it seems
more likely that people will put the  first. And if someone
doesn't the effects aren't very bad.

Alternatively we could use the following rules:
1. The networkState of the element is NETWORK_NO_SOURCE.
*and*
2. The  element is fully parsed. I.e. it has been removed from
the stack of open elements.

This would mean that incremental rendering doesn't work. This doesn't
seem any worse than what we have now when fallback is never displayed.

Though I think it'd work fine always display fallback whenever the
networkState is NETWORK_NO_SOURCE.

/ Jonas

Re: [whatwg] HTML 5 video tag questions

2009-07-13 Thread Michael A. Puls II

On Mon, 13 Jul 2009 17:01:26 -0400, Philip Jägenstedt   
wrote:



Does audio also have fallback content?


With , you can set its display to 'none' and the audio will still  
play. However, if its display is set to 'none' and the element were to  
fall back to a child object element that loads a plug-in, things wouldn't  
work because plug-ins don't work with a display of 'none'.


You would then have to detect that  fell back so you could set its  
display to "inline-block" for example so the fallback plug-in would  
actually load. Or, there'd have to be a new css selector to handle this  
like audio::fallback_state { display: inline-block} or a parent selector  
on the child object element that was only applied when  fell back  
to it. Or, the browser would have to make plug-in objects that are  
descendants of an  element work with a display of 'none'.


The same applies to  if you want to set its display to 'none' and  
just hear the audio.


--
Michael

Re: [whatwg] HTML 5 video tag questions

On Mon, 13 Jul 2009 21:28:45 +0200, Tab Atkins Jr.
wrote:

On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedt
wrote:
On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr.

wrote:

On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarsky wrote:

Philip Jägenstedt wrote:

It would have to be part of the resource selection algorithm. Since
that

waits for new source elements indefinitely, when exactly would you
decide to
switch to fallback content? Bad solutions include special-casing
static

markup and/or (falsely) assuming that scripts will not insert more
source
elements at some point. If fallback content is defined simply as the
content
of the video element I also can't figure out any other solutions.

A that says "use the content"?

-Boris

Ie inserting or . If both @src and
@fallback are specified on a , it is treated like a ; that is, it first tries the @src attribute, and
if that doesn't work, then it goes to the fallback content.

That would require the parser to inspect an attribute to determine if
the

element is a void element (one that does not have a closing tag) or not,
which I've been told is not very nice. Are there any other such cases?

Hm? I'm not sure what you mean here. It would work like this:

I'm some fallback content!

You'll see the if the browser doesn't support , or if the
resource selection algorithm hits that third source and hasn't found
anything it can play yet. It wouldn't change whether the is
a void element or not.

I thought you meant

fallback content here

I would prefer if fallback content and source elements weren't mixed on
the same level, but maybe that's just me.

(You could also just put @fallback on the second and drop the
third entirely for the same effect.)

Once the source element is iterated by the resource selection algorithm
and starts loading, the fallback attribute or the whole source element
might be removed. You would have to set a flag at some point to remember
the fallback state and unset it... when? What is the effect of

fallback here

Is fallback irrevocable or could the same video element go back to showing
video under some circumstances? Does audio also have fallback content?

This is why I suggested Ooops!

I still think the use of this is questionable though.

I'm not sure why you think the usecase is questionable. It seems
pretty clear - it'd be nice to have a non-script way of showing
content (specifically, alternate video players) when the browser
supports but can't play any of the provided sources.

Yes, handling the (minor) use case video support + no supported source +
no script would be nice, but only if it doesn't make an even bigger mess
of the resource selection algorithm and doesn't allow switching back and
forth between video and fallback.

The browsers that have already shipped with video don't support fallback
but they are the ones that are the most likely to need it (assuming that
format support will get better over time). It would be nice to hear what
they think about all of this.

--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] Browser Bundled Javascript Repository

2009-07-13 Thread And Clover

I honestly can't see the benefit of bundling common libraries at all. It 
requires a bunch of infrastructure to manage it and quickly becomes out 
of date. Not worth it to save a few tens of K as a one-time download - 
not a significant amount at all in today's terms.


What would help is if more people could link a script from a common 
location so that it was already cached by the standard browser 
mechanisms. This is already happening to some extent.


But linking external scripts does have a problem in that you have to 
trust the site you're linking not to change the script (or get 
compromised) to add malicious features. A cryptographic hash of the file 
you expect could be used to mitigate this issue, perhaps for other types 
of file too. And such a feature could fall within HTML5's purview.


For example:

Re: [whatwg] Browser Bundled Javascript Repository

On Mon, Jul 13, 2009 at 3:20 PM, Aryeh Gregor wrote:
> On Mon, Jul 13, 2009 at 3:21 PM, Tab Atkins Jr. wrote:
>> Yes there are.  jQuery doesn't put out very many updates, and I don't
>> think most people alter their jQuery file.
>
> It's only one file, not multiple?

Yes.

> And people don't inadvertently
> change newline style, or minify it using different incompatible
> minifiers,

As jQuery serves a minified version directly, probably not.  I suspect
that most of us just download the file and pop it straight onto the
server.

> or combine it with their other files so that they only
> serve a single JS file?

This is a possibility, but I don't know how often this happens in practice.

> And you're taking into account that certainly
> the majority of sites don't use jQuery at all?

Was that ever in question?  The point is that jQuery (and other
libraries) are used *often enough* that caching across websites can be
useful.  This is the whole reason that the Google-hosted version is
useful.  Automatic caching from the browser just allows smaller-use
libraries (and plugins for those libraries) to benefit without having
to convince a central authority to host them and donate bandwidth.

> And that you'd have to
> remove it when the user cleared their cache?

I'm not certain what this has to do with the proposal.

> Does anyone have statistics on how useful this would be in real life?
> I suspect only marginally.

For starters, anyone know the usage statistics on the Google-hosted versions?

>> That'd only address the things that the various vendors can agree are
>> 'standard' enough to push into a common API.
>
> That would be enough for most people.

The issue is getting everyone to agree on enough.  I use quite a lot
of jQuery's tools, for example.  Even if a lot of it was pushed into
the browsers, I'd still probably have to use jQuery for some of the
functionality that wasn't included.  Of course, at that point jQuery
could potentially be much smaller.

And what if the API ended up resembling Prototype?  I *greatly* prefer
jQuery over all the other frameworks, and would have a much more
difficult time using anything else.

>> It would also mean that
>> legacy browsers break completely, as you're depending on the browser's
>> built-in libraries that don't exist in older versions.
>
> No, because you could have compatibility libraries that you just
> wouldn't load if the browser already supported the features.

Yes, so now I have to feature-test those things before trying to use
them.  Dealing with legacy javascript support is annoying enough right
now - I'd prefer that these things gradually migrate into the core and
the library I use still just wrap around it.

The fact that standardized javascript features tend to end up being
clunky due to their requirement of language independence makes me not
really want this either.  I much prefer a library that presents a
good, clean language to me, and handles the clunky aspects in the
background.  I doubt we'll ever have a standardized AJAX function as
clean and easy to use to use as $.get(), frex.

~TJ

Re: [whatwg] Browser Bundled Javascript Repository

2009-07-13 Thread Aryeh Gregor

On Mon, Jul 13, 2009 at 3:21 PM, Tab Atkins Jr. wrote:
> Yes there are.  jQuery doesn't put out very many updates, and I don't
> think most people alter their jQuery file.

It's only one file, not multiple?  And people don't inadvertently
change newline style, or minify it using different incompatible
minifiers, or combine it with their other files so that they only
serve a single JS file?  And you're taking into account that certainly
the majority of sites don't use jQuery at all?  And that you'd have to
remove it when the user cleared their cache?

Does anyone have statistics on how useful this would be in real life?
I suspect only marginally.

> That'd only address the things that the various vendors can agree are
> 'standard' enough to push into a common API.

That would be enough for most people.

> It would also mean that
> legacy browsers break completely, as you're depending on the browser's
> built-in libraries that don't exist in older versions.

No, because you could have compatibility libraries that you just
wouldn't load if the browser already supported the features.

Re: [whatwg] HTML 5 video tag questions

On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedt wrote:
> On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr. 
> wrote:
>
>> On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarsky wrote:
>>>
>>> Philip Jägenstedt wrote:

 It would have to be part of the resource selection algorithm. Since that
 waits for new source elements indefinitely, when exactly would you
 decide to
 switch to fallback content? Bad solutions include special-casing static
 markup and/or (falsely) assuming that scripts will not insert more
 source
 elements at some point. If fallback content is defined simply as the
 content
 of the video element I also can't figure out any other solutions.
>>>
>>> A  that says "use the content"?
>>>
>>> -Boris
>>>
>>
>> Ie inserting  or .  If both @src and
>> @fallback are specified on a , it is treated like a > src>; that is, it first tries the @src attribute, and
>> if that doesn't work, then it goes to the fallback content.
>
> That would require the parser to inspect an attribute to determine if the
> element is a void element (one that does not have a closing tag) or not,
> which I've been told is not very nice. Are there any other such cases?

Hm?  I'm not sure what you mean here.  It would work like this:


  
  
  
  I'm some fallback content!


You'll see the  if the browser doesn't support , or if the
resource selection algorithm hits that third source and hasn't found
anything it can play yet.  It wouldn't change whether the  is
a void element or not.

(You could also just put @fallback on the second  and drop the
third  entirely for the same effect.)

> This is why I suggested  src="cant.play.ogg">Ooops!
>
> I still think the use of this is questionable though.

I'm not sure why you think the usecase is questionable.  It seems
pretty clear - it'd be nice to have a non-script way of showing
content (specifically, alternate video players) when the browser
supports  but can't play any of the provided sources.

~TJ

Re: [whatwg] Browser Bundled Javascript Repository

On Mon, Jul 13, 2009 at 2:01 PM, Aryeh Gregor wrote:
> I'm not sure how useful this would actually be, though.  Are there
> really *so* many sites using the *exact* same version of jQuery or any
> other single library?

Yes there are.  jQuery doesn't put out very many updates, and I don't
think most people alter their jQuery file.

Remember that this would also help with, frex, plugins for jQuery.
Some of them (especially the jQuery UI plugins) are really fat, and
being able to cache them across many sites could be useful.

> It seems like a better idea would be to get all
> the valuable user-created APIs standardized and implemented in some
> form cross-browser, as a few (e.g., getElementsByClassName) have been.
>  Then the common uses of jQuery or whatever would just be
> compatibility layers for legacy browsers.  Kind of like how a bunch of
> Boost is getting added to standard C++.  Of course, this requires more
> effort, but it's more likely to actually work, in the long term.

That'd only address the things that the various vendors can agree are
'standard' enough to push into a common API.  It would also mean that
legacy browsers break completely, as you're depending on the browser's
built-in libraries that don't exist in older versions.  It's much
better to lean on existing files so that older browsers download them
like normal, and newer browsers download them once and then cache them
across the web.

>> I believe all these problems are solvable, but they do need to be
>> solved before considering inclusion in any spec. I'm also not
>> convinced this needs to be included in the HTML5 spec, but that might
>> depend on what the ultimate solution looks like.
>
> The most obvious place to solve this seems to be HTTP, not HTML.  HTTP
> is closer to the resource itself.  If you do something with HTML, like
> an extra  attribute, then you're going to get authors updating
> the HTML but not the thing it points to or vice versa.  An ETag-like
> solution would be implemented either in the web server or whatever
> script is serving the content, and those should always know whether
> the file has changed.  (Modulo pathological behavior like something
> changing the file and then forging the mtime/ctime.)
>
> So yeah, doesn't seem like something for HTML 5.

Agreed, and your approach seems workable to me.

~TJ

Re: [whatwg] HTML 5 video tag questions

On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr.   
wrote:



On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarsky wrote:

Philip Jägenstedt wrote:


It would have to be part of the resource selection algorithm. Since  
that
waits for new source elements indefinitely, when exactly would you  
decide to

switch to fallback content? Bad solutions include special-casing static
markup and/or (falsely) assuming that scripts will not insert more  
source
elements at some point. If fallback content is defined simply as the  
content

of the video element I also can't figure out any other solutions.


A  that says "use the content"?

-Boris



Ie inserting  or .  If both @src and
@fallback are specified on a , it is treated like a ; that is, it first tries the @src attribute, and
if that doesn't work, then it goes to the fallback content.


That would require the parser to inspect an attribute to determine if the  
element is a void element (one that does not have a closing tag) or not,  
which I've been told is not very nice. Are there any other such cases?


This is why I suggested src="cant.play.ogg">Ooops!


I still think the use of this is questionable though.

--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] Nested list

2009-07-13 Thread Erik Vorhes

On Mon, Jul 13, 2009 at 11:34 AM, Ryosuke Niwa wrote:
>
> We can define it in this way.  When a list A appears within anther list B
> (without being enclosed by li), then the list A is a sublist of B and that
> lists A and B constitutes a tree structure.  When a list C appears within a
> list item of the list B, then list C is a list appears in a paragraph of a
> list item of B.  i.e. C ad B does not constitute a tree structure.
>
> This can be seen from the way those two constructs are rendered in major
> UAs.  Namely, when lists A and B are nested, you don't see a bullet before
> A.  Because A and B together constitutes a tree-structure, this rendering is
> semantically correct.  On the other hand, UAs render a bullet before C.  B
> has a list item that happens to contain a list, but that doesn't prevent B
> from having a bullet for that particular list item.
>

While I think I understand your description, I'm a little concerned
for a few reasons.

1. Depending on context, lists within lists don't render differently
than lists within list items do.

2. How does the User Agent determine if a list within a list is part
of the preceding  if that  isn't closed? Is it part of the
 or something on its own?

3. Why should  and  provide different semantic meaning
depending on context? Won't that lead to confusion?

4. If two lists aren't actually supposed to be items in the same list,
why would you group them as a list? Shouldn't they be separate
entities entirely?

I've cobbled together a demonstration page to address some of these
issues (more clearly, I hope): http://textivism.com/list-items/

Erik Vorhes

Re: [whatwg] Browser Bundled Javascript Repository

2009-07-13 Thread Aryeh Gregor

On Mon, Jul 13, 2009 at 12:49 AM, Jonas Sicking wrote:
> 2. How do we deal with identifying libraries.
> As Aaron Boodman pointed out, SHA hashes means that you can't make
> upgrades for security problems etc.

I think a hash would be fine.  You don't want to load a different
version of the library than the author intended, even if it may
supposedly have bug fixes.  Perhaps the author is relying on the bugs
that were fixed.  This should be transparent, so that the same script
will always be used whether browsers support this feature or not.

> 3. Compat when the browser doesn't have a library cached.
> A solution that includes using a different uri for browsers that do
> support caching than browsers that don't is scary since there is a big
> risk that the author will forget to update one but not the other.

How about you have an extra HTTP header like "X-Content-Hash"?  This
could provide a SHA256 hash (or something else that looks safe for
now, progressively upgradeable) of the content.  The browser can keep
its cached copies of these files indexed by hash.  If it tries
downloading a file, and notices that the hash is the same as a file
already downloaded, it can terminate the HTTP connection and use the
existing file (even if it's from a different site).  It will then
proceed as though it had actually downloaded the file: e.g., it will
respect the Expires headers separately (two sites might serve the same
file but have different expectations about how likely it is to
change).

Of course, when the file is downloaded, it would be indexed based on
actual SHA256, not the reported SHA256.  This way you can't poison the
cache.  If an incorrect hash is provided, that will potentially result
in the wrong script being used, of course, but you can't generate a
preimage of the bad hash (hopefully!), so attackers can't exploit it.
Unless they can inject HTTP headers, but then you're screwed anyway.

So this would basically be like ETag, but with the tag unique across
all sites.  In fact, maybe piggybacking it on ETag would be a better
idea, so you don't have to do stuff like terminate the TCP connection
unexpectedly.  (Which I don't *think* would be harmful? but is
certainly suboptimal.)  Just define a magic ETag format that nobody's
currently using.

I'm not sure how useful this would actually be, though.  Are there
really *so* many sites using the *exact* same version of jQuery or any
other single library?  It seems like a better idea would be to get all
the valuable user-created APIs standardized and implemented in some
form cross-browser, as a few (e.g., getElementsByClassName) have been.
 Then the common uses of jQuery or whatever would just be
compatibility layers for legacy browsers.  Kind of like how a bunch of
Boost is getting added to standard C++.  Of course, this requires more
effort, but it's more likely to actually work, in the long term.

> I believe all these problems are solvable, but they do need to be
> solved before considering inclusion in any spec. I'm also not
> convinced this needs to be included in the HTML5 spec, but that might
> depend on what the ultimate solution looks like.

The most obvious place to solve this seems to be HTTP, not HTML.  HTTP
is closer to the resource itself.  If you do something with HTML, like
an extra  attribute, then you're going to get authors updating
the HTML but not the thing it points to or vice versa.  An ETag-like
solution would be implemented either in the web server or whatever
script is serving the content, and those should always know whether
the file has changed.  (Modulo pathological behavior like something
changing the file and then forging the mtime/ctime.)

So yeah, doesn't seem like something for HTML 5.

Re: [whatwg] HTML 5 video tag questions

On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarsky wrote:
> Philip Jägenstedt wrote:
>>
>> It would have to be part of the resource selection algorithm. Since that
>> waits for new source elements indefinitely, when exactly would you decide to
>> switch to fallback content? Bad solutions include special-casing static
>> markup and/or (falsely) assuming that scripts will not insert more source
>> elements at some point. If fallback content is defined simply as the content
>> of the video element I also can't figure out any other solutions.
>
> A  that says "use the content"?
>
> -Boris
>

Ie inserting  or .  If both @src and
@fallback are specified on a , it is treated like a ; that is, it first tries the @src attribute, and
if that doesn't work, then it goes to the fallback content.

~TJ

Re: [whatwg] HTML 5 video tag questions

2009-07-13 Thread Boris Zbarsky


Philip Jägenstedt wrote:
It would have to be part of the resource selection algorithm. Since that 
waits for new source elements indefinitely, when exactly would you 
decide to switch to fallback content? Bad solutions include 
special-casing static markup and/or (falsely) assuming that scripts will 
not insert more source elements at some point. If fallback content is 
defined simply as the content of the video element I also can't figure 
out any other solutions.


A  that says "use the content"?

-Boris

Re: [whatwg] Serializing HTML fragments (9.4)

2009-07-13 Thread Boris Zbarsky


Simon Pieters wrote:
It's actually rather purposeful, at least in terms of the code.  It'd 
be pretty easy to change to returning the textContent instead (so 
walking into kids).


textContent wouldn't emit the tags.


Yes, true.  I thought that's what you were asking for...


I think the spec currently matches what IE does.


Does IE even support adding a child element to a

[whatwg] HTML5+RDFa first Editors Draft published

2009-07-13 Thread Manu Sporny

The first public Editors Draft of RDFa for HTML5 was published earlier
today. You can view the draft in two forms:

 * [1] HTML5+RDFa Section (small 34K HTML document)
 * [2] Complete HTML5+RDFa Specification (very large 4MB HTML document)

This blog post explains how this draft came to be, how it was published
via the World Wide Web Consortium, and what it means for the future of
RDFa and HTML5:

http://blog.digitalbazaar.com/2009/07/13/html5rdfa/

-- manu

[1]http://dev.w3.org/html5/rdfa/rdfa-module.html
[2]http://dev.w3.org/html5/rdfa/Overview.html#rdfa

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Re: [whatwg] Serving up Theora in the real world

2009-07-13 Thread Peter Kasting

On Mon, Jul 13, 2009 at 1:43 AM, Philip Jägenstedt wrote:

> Also, I've reported bugs on Safari and Chrome (I think, neither give
> confirmation that the report has been sent successfully!)
>

That's odd.  Both bugs.webkit.org and crbug.com tell me when I've filed a
bug, and give me the bug number for reference.  How did you file your
issues?  (Feel free to respond privately if you want, in order to avoid
spamming the list)

PK

Re: [whatwg] hash sum tags of binary files and code blocks?

On Mon, Jul 13, 2009 at 11:41 AM, Aron Spohr wrote:
> Hi Christian,
>
> have you ever considered just making the md5 (or maybe just a shorter CRC) 
> part of the filename of the file you want to cache? Then you can send Expiry 
> headers for 6 months or a years time for those files and you'll get the same 
> behaviour.

FWIW, I do this.  I set far-future expiry headers on my CSS and
images.  If I need to make a change after it's gone live, I append a
query parameter with a current timestamp.  There isn't anything on the
other end which responds to the query param, but it does indicate that
it's a new resource to the browser's caching algorithm, which is
precisely what I want.  The new version will then stay cached until I
change the query param again.  Using a hash or version number instead
of a timestamp is equivalent.

(I could, of course, actually hook up a script on the server-side
which remembers the previous versions of the resource and will serve
them up as requested, but that hasn't ever been necessary so far.)

~TJ

Re: [whatwg] hash sum tags of binary files and code blocks?

2009-07-13 Thread Aron Spohr

Hi Christian,

have you ever considered just making the md5 (or maybe just a shorter CRC) part 
of the filename of the file you want to cache? Then you can send Expiry headers 
for 6 months or a years time for those files and you'll get the same behaviour.

Aron

Re: [whatwg] hash sum tags of binary files and code blocks?

2009-07-13 Thread David Wilson

2009/7/13 Christian Nygaard :
> What if one included hash sums of every binary file in html tags, plus
> embedded hash sums in streaming file blocks, then the client would never
> need to look at time stamps/expire headers to determine if it could cache
> the objects. That would make caching very easy on mobile devices with slow
> datalinks, make it possible for service providers to cache objects globally
> for their customer base. One could also augment whole code blocks with hash
> sums for example css this could possibly be more efficient than time expire.
>
> 
>

How would this interact with HTTP Accept header? It seems each
resource would be required to have only a single presentation, and
that the HTML was intimately aware of the details of that
presentation, or alternatively intimately aware of what presentation
the user agent would request.

> 
> 
> 
> 
> 
>
>  md5="dee0b8572297fe4e3b004cfe188ecad3"/>
> no need to load that style sheet ever again if it's contents has not
> changed.

This scheme doesn't really fit HTTP at all. However that's not to say
it's interesting. In fact swathes of research have been devoted to
designing access layers like this (they're often called content
addressable networks). Introducing little bits of it into HTML seems
like the wrong layer to be working on.


David

-- 
Reality is that which, when you stop believing in it, doesn't go away.
  — Philip K. Dick

[whatwg] hash sum tags of binary files and code blocks?

2009-07-13 Thread Christian Nygaard

What if one included hash sums of every binary file in html tags, plus
embedded hash sums in streaming file blocks, then the client would never
need to look at time stamps/expire headers to determine if it could cache
the objects. That would make caching very easy on mobile devices with slow
datalinks, make it possible for service providers to cache objects globally
for their customer base. One could also augment whole code blocks with hash
sums for example css this could possibly be more efficient than time expire.










no need to load that style sheet ever again if it's contents has not
changed.

//Christian Nygaard

Re: [whatwg] Nested list

2009-07-13 Thread Adrian Sutton

On 13/07/2009 16:45, "Erik Vorhes"  wrote:
> Part of the reason that browsers handle this--
> 
> 
> 
> 
> 
> -- pretty well is because, in HTML 4.01 (and earlier HTML specs), 
> was not required to be explicitly closed, so it would implicitly
> handle that  as a child of the preceding . (Inconsistencies in
> rendering most likely arise because the browser havs already found the
> explicit close to a list item before getting to the nested list.)

Actually, at least Safari and FireFox treat the invalidly nested OL as a
completely separate item - ie: they don't treat it as a child of the
previous LI.

You can see this quite clearly if you apply a style to the LI (or just look
at the resulting DOM):

Item 1
  Nested

Item 1
Nested

The first list is entirely bold, the second on "Nested" is not bold which
matches the DOM structure that Safari shows.

> Do you have use case for when a child list is *not* an item in the
> parent list? Otherwise, it doesn't make sense *not* to wrap the child
> list in the  element.

This is the real crux of why I think browser behavior is wrong - in every
case I've seen, the author intends the indent to mean a sub-point, not a new
point which for some reason is indented further. Given the rendering readers
would expect an indented list item to be a sub-point as well.

I don't see that HTML 5 has any choice but to define the current browser
rendering and DOM structure as the way things are - changing the resulting
DOM structure would break backwards compatibility. However, I'd really like
to see browsers change to create correctly nested lists so the list
structure actual matches the author intent. I'm somewhat doubtful browser
vendors would want to change though and I must admit it does potentially
create compatibility problems for existing JavaScript editors which would
have to be explored more.

Regards,

Adrian Sutton. 
__
Adrian Sutton, CTO
UK: +44 1 628 200 182 x481  US: +1 (650) 292 9659 x717
Ephox 
Ephox Blogs , Personal Blog

Re: [whatwg] Nested list

2009-07-13 Thread Adrian Sutton

On 13/07/2009 16:45, "Erik Vorhes"  wrote:
> Part of the reason that browsers handle this--
> 
> 
> 
> 
> 
> -- pretty well is because, in HTML 4.01 (and earlier HTML specs), 
> was not required to be explicitly closed, so it would implicitly
> handle that  as a child of the preceding . (Inconsistencies in
> rendering most likely arise because the browser havs already found the
> explicit close to a list item before getting to the nested list.)

Actually, at least Safari and FireFox treat the invalidly nested OL as a
completely separate item - ie: they don't treat it as a child of the
previous LI.

You can see this quite clearly if you apply a style to the LI (or just look
at the resulting DOM):

Item 1
  Nested

Item 1
Nested

The first list is entirely bold, the second on "Nested" is not bold which
matches the DOM structure that Safari shows.

> Do you have use case for when a child list is *not* an item in the
> parent list? Otherwise, it doesn't make sense *not* to wrap the child
> list in the  element.

This is the real crux of why I think browser behavior is wrong - in every
case I've seen, the author intends the indent to mean a sub-point, not a new
point which for some reason is indented further. Given the rendering readers
would expect an indented list item to be a sub-point as well.

I don't see that HTML 5 has any choice but to define the current browser
rendering and DOM structure as the way things are - changing the resulting
DOM structure would break backwards compatibility. However, I'd really like
to see browsers change to create correctly nested lists so the list
structure actual matches the author intent. I'm somewhat doubtful browser
vendors would want to change though and I must admit it does potentially
create compatibility problems for existing JavaScript editors which would
have to be explored more.

Regards,

Adrian Sutton. 
__
Adrian Sutton, CTO
UK: +44 1 628 200 182 x481  US: +1 (650) 292 9659 x717
Ephox 
Ephox Blogs , Personal Blog

Re: [whatwg] Nested list

2009-07-13 Thread Erik Vorhes

On Mon, Jul 13, 2009 at 10:22 AM, Ryosuke Niwa wrote:
>
> Does anyone see a serious compatibility issue with adding ol / ul as child
> nodes of ol / ul?  I feel like not allowing them is more problematic given
> the situation.
>

Part of the reason that browsers handle this--





-- pretty well is because, in HTML 4.01 (and earlier HTML specs), 
was not required to be explicitly closed, so it would implicitly
handle that  as a child of the preceding . (Inconsistencies in
rendering most likely arise because the browser havs already found the
explicit close to a list item before getting to the nested list.)

Do you have use case for when a child list is *not* an item in the
parent list? Otherwise, it doesn't make sense *not* to wrap the child
list in the  element.

Erik

Re: [whatwg] Nested list

2009-07-13 Thread Ryosuke Niwa

On Mon, Jul 13, 2009 at 4:01 AM, Simon Pieters  wrote:
>
>
> I think this is a bug in execCommand('indent') and should be fixed in
> browsers.
>
> The spec doesn't seem to list 'indent' at all. It would be helpful if it
> was specified.
>

Yes, we need to specify how execCommand('indent' / 'insertorderedlist' /
'insertunorderedlist') works.  But given that major UAs(Firefox, Internet
Explorer, & WebKit) directly inserts ol / ul element without enclosing it
with li element, I think we should allow that construct in HTML5.

On Mon, Jul 13, 2009 at 4:07 AM, Adrian Sutton 
 wrote:
>
>
> It does introduce complexities when you try to indent list items more than
> one level deeper than it's parent, but semantically that really doesn't
> make
> sense anyway. You can make it work by adding a new list item but with
> list-style-type: none specified.

You still need to deal with margin / padding so you may specify them as
well.  As you said, it's very hard to make UA-generated HTML correct.  But
since major UAs produce the same DOM (ul / ol immediately inside another ul
/ ol), I don't see why we can't add that to HTML5 spec.  After all, all we
need to do is to allow li / ul / ol elements inside ul / ol instead of just
li.

Does anyone see a serious compatibility issue with adding ol / ul as child
nodes of ol / ul?  I feel like not allowing them is more problematic given
the situation.

Ryosuke

Re: [whatwg] Storage Events for a Specific Storage Area

2009-07-13 Thread Joseph Pecoraro

We could make Storage into an EventTarget and also fire events on  
there,

sure. As Jeremy said, this is something that might best be done in the
next version; we're still trying to get the current features  
implemented

in a stable and consistent fashion as it is.


Sounds great.  Although wouldn't now be the best time to introduce  
something new?  Its not a breaking change (theoretically), its an  
additional feature.  Its my understanding that most of Web Storage is  
undergoing changes (B-trees and SQL orthogonally), but the Storage  
interface is not going to change much?  Is that because of current  
browser support?



In general, though, I don't think it's critical, since you can  
easily work

around it by checking which was changed based on the event data


Fair enough. =)



(I agree that your proposal would have made more sense. I'm sorry my
learning experiences have such a detrimental effect on the Web! :-) )


We're all learning. =P


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


- Joe

Re: [whatwg] DOMTokenList is unordered but yet requires sorting

2009-07-13 Thread news.gmane.org


On 7/13/2009 7:26 AM, Jonas Sicking wrote:

On Sun, Jul 12, 2009 at 9:00 PM, Ian Hickson  wrote:

If we don't remove duplicates, then things like the .toggle() method could
have some quite weird effects.


Such as? The only one I can think of is that calling .toggle() would
remove multiple items. I don't see that as a problem?


I think Ian is referring to duplicates here as "duplicates of the token 
being removed", not as "duplicates of any token in the underlying 
attribute". In the current spec algorithm, removing or toggling a token 
won't remove duplicates in other tokens.



Define .remove() as removing all tokens with the given value, and .toggle() as:

function toggle(token) {
   if (this.contains(token))
 this.remove(token);
   else
 this.add(token);
}


That's what toggle() does right now. (With the small difference that it 
also returns a boolean to indicate if the token was removed or added).



I definitely think it'd be worth avoiding the code complexity and perf
hit of having the implementation remove duplicates if they appear in
the class attribute given how extremely rare duplicates are.



This is a bit unrelated, but when looking at the DOMTokenList 
implementation, I had an idea about an alternative algorithm that could 
be easier to implement and could also be described more simply in the 
spec. The disadvantage is that the DOMTokenList methods mutating the 
underlying string wouldn't preserve existing whitespace (which the 
current algorithms try hard to do).


The idea is that any DOMTokenList method that mutates the underlying 
string would do:

 - split the attribute in unique tokens (preserving order).
 - add or remove the token according to the method called.
 - rebuild the attribute string by concatenating tokens together (with 
a single space).


At first, this may look like inefficient (if implemented naively).
But I guess that implementations will usually keep both the attribute 
string and a list of tokens in memory, so they wouldn't have to tokenize 
the string on every mutation. There is a small performance hit during 
attribute tokenization: the list of tokens would need to keep only 
unique tokens. But after that, the DOMTokenList methods are very simple: 
length/item() don't need to take care of duplicates, add/remove/toggle 
are simple list manipulation (the attribute string could be lazily 
generated from the token list when needed).


To summarize:
pros: simpler spec algorithms, simpler implementation
cons: less whitespace preservation, small perf hit during tokenization

I don't know if I'm missing something. Does this sound reasonable?

Sylvain

[whatwg] To post to this list, send your email to:

2009-07-13 Thread Mykal Luttrell

netarchit...@randasolutions.com

 

M. A. Luttrell Sr.

Sr. Web Applications Architect

 

 

 

Randa Solutions Inc.

722 Rundle Ave.

Nashville, Tennessee 37027

(615) 424-9988

 

This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any
review, use, distribution, or disclosure by others is strictly
prohibited and could be subject to and be punishable by law. If you are
not the intended recipient (or authorized to receive information for the
intended recipient), please contact the sender by reply e-mail and
delete all copies of this message.

 

 

<>

Re: [whatwg] HTML 5 video tag questions

2009-07-13 Thread David Gerard

2009/7/13 Jeff Walden :
> On 12.7.09 23:20, Ian Hickson wrote:

>> If people really want to push
>> Apple into supporting Theora, the best way to do it would be to just keep
>> using it as if it was the common codec, and _not_ provide another fallback
>> for-supporting UAs -- then things would work fine it non--
>> supporting UAs like IE (through fallback flash support inside),
>> and would work fine in Theora-supporting UAs, but Safari would be left in
>> the cold.

> I'm fine doing this for myself: partly because it's pressure on Apple;
> perhaps mostly because I choose to make embedding videos that I can watch
> in-browser easy for myself, and because I don't particularly care if some
> portions of my audience are unable to see such videos and also choose not to
> download a browser that will display them ("fallback" content provides a
> download link -- I haven't made the effort to handle Safari4-sans-XiphQT
> yet, see supra).  That said, my position will be uncommon, and I'm not
> particularly interested in making use of  right now harder for those
> who don't share it -- even if it comes at the expense of added pressure on
> Apple.

In Wikimedia's case, we do care about the user experience, *but* will
only be using Theora for the foreseeable future - H.264 is not an
option.

So browsers with Theora in  should Just Work, browsers without
 will get the Java player or an in-browser plugin (and a note
suggesting a browser that does Theora in ) and Safari is a
nuisance because it's the exception and it *might* work but it *might*
not and we have to reliably detect whether it does.

(Presumably Apple would be happier with us suggesting XiphQT rather
than suggesting Firefox!)

iPhone Safari users (does iPhone Safari support  yet?) are,
unfortunately, out in the cold until someone writes a Wikimedia client
app that does Theora for them. That won't be us unless a volunteer
steps up. Other phone users are likely out in the cold too (I don't
know of any phones that support arbitrary Java applets in the
browser).

- d.

Re: [whatwg] Serializing HTML fragments (9.4)

2009-07-13 Thread Simon Pieters


On Thu, 09 Jul 2009 19:38:58 +0200, Boris Zbarsky  wrote:


Kartikaya Gupta wrote:
Opera and Chrome will alert "some>stuffmore(escaping the angle bracket inside the child element) and Firefox just  
outputs "more

It's actually rather purposeful, at least in terms of the code.  It'd be  
pretty easy to change to returning the textContent instead (so walking  
into kids).


textContent wouldn't emit the tags.

I think the spec currently matches what IE does.


See https://bugzilla.mozilla.org/show_bug.cgi?id=125746 for the history  
here (the code has just been carried along since).


I tried a couple of the other special elements (script and xmp) and  
they worked the same way. I think for compatibility the spec should say  
"If the parent of the current node is a" instead of "If one of the  
ancestors of current node is a" for the Text/CDATASection handling.


No opinion on this, honestly.


--
Simon Pieters
Opera Software

Re: [whatwg] HTML 5 video tag questions

2009-07-13 Thread Lino Mastrodomenico

2009/7/13 Ian Hickson :
> On Fri, 10 Jul 2009, Jeff Walden wrote:
>> And if a site wants to publish H.264-only with Flash or QuickTime as the
>> fallback, they have to use scripting to make it work in Firefox.
>
> We presumably don't want to make the use of uncumbered codecs easier.

I agree. Moreover there are already two stable and widely used
browsers that implement the current spec and websites are starting to
use it. Since this fallback would be an incompatible change, please
don't do it unless there's a *really* good reason for it.

-- 
Lino Mastrodomenico

Re: [whatwg] HTML 5 video tag questions

On Mon, 13 Jul 2009 11:14:21 +0200, Jonas Sicking  wrote:

On Sun, Jul 12, 2009 at 11:20 PM, Ian Hickson wrote:

On Fri, 10 Jul 2009, Jonas Sicking wrote:

>>
>> Hmm.. is that good? What if you want to use an  (to use  
flash

>> or java) or a  as fallback?
>
> Then you do it with script.
>
> The design is based around the assumption that we will eventually  
find

> a common codec so that fallback won't ever be needed in supporting
> UAs.

I agree that the current design makes sense once there is a common  
codec

supported across all browsers. However currently it seems like we might
not reach that point until after all major browsers support .

What would be the downside of displaying the fallback contents if none
of the videos can be displayed due to unsupported codecs?

When would you fall back? For example, while parsing, would you fall  
back
in between the  element being parsed and the first   
element

being parsed?

You could display the fallback once you've reached the  and
not found an acceptable . Technically it'd be when you pop the
video element off the stack of open elements. I don't even think it'd
be hard to pull down all s and check that none of them are
supported before displaying the fallback if types aren't specified on
the  element.

It would have to be part of the resource selection algorithm. Since that  
waits for new source elements indefinitely, when exactly would you decide  
to switch to fallback content? Bad solutions include special-casing static  
markup and/or (falsely) assuming that scripts will not insert more source  
elements at some point. If fallback content is defined simply as the  
content of the video element I also can't figure out any other solutions.

The design you describe is what  tried to do, and it proved to  
be
extremely problematic in practice -- and that was without another  
built-in

fallback mechanism to complicate matters.

While  has had a very poor implementation story, I don't think
this was a big reason for that.

Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
answer this better, but at least in gecko I don't think this part of
object was particularly hard to implement correctly once we actually
tried.

Has any browser vendor argued against displaying the fallback due to
high implementation burden?

Implementation probably isn't the biggest burden here, specifying sane  
behavior is. For example:

If fallback content is displayed after the last source element has failed,  
what should happen when a new source element is inserted? Switching back  
to "video mode" would make it even more special than object fallback and  
if you don't you'll just get stuck with fallback and have effectively  
broken the possibility of inserting source elements via scripts.

Something like src="cant.play.ogg">Ooops!  
is what you'd need to make the resource selection algorithm deal with  
fallback in a sane way when scripts are disabled, but this is too much of  
a corner case to justify the complexity in my opinion.

--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] Using for Meta-Content

On Thu, 18 Jun 2009, Smylers wrote:
>
> HTML 5 currently defines  as being for "stress emphasis of its 
> contents", noting that:
> 
>   The placement of emphasis changes the meaning of the sentence.  The
>   element thus forms an integral part of the content.
> 
> -- http://www.whatwg.org/html5#the-em-element
> 
> I'm not sure this definition is wide enough to encompass the use that 
> HTML 5 itself puts  to, using it for the "This section is 
> non-normative" bits at the start of sections, such as:
> 
>   http://www.whatwg.org/html5#introduction

That shouldn't be . I've changed those to  in the spec.


> This meta-content use seems similar to an article by a guest author 
> being prefaced by an italicized paragraph from a regular author 
> introducing the guest.  Or editoral comments inserted into somebody 
> else's work, which are often in square brackets and italics as well as 
> having "- Ed" at the end.  Mainly it's just indicating some kind of 
> separation from the main text.

Yup.  is appropriate for those -- it's a different voice.


On Fri, 19 Jun 2009, Nils Dagsson Moskopp wrote:
> > 
> > I suggest that either the definition of  is broadened to include 
> > this sense, or these normativity designators are instead marked up 
> > with something like  or .
> 
> I suggest broadening the  element, mainly because it is already 
> spec'd to contain some kind of meta-information (legal text).

 is more for side comments than a different voice.


> Editorial comments can be marked up using the  element, as I 
> understand it.

 would be for the actual change, rather than a note about the change.

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

Re: [whatwg] Nested list

2009-07-13 Thread Adrian Sutton

On 13/07/2009 12:01, "Simon Pieters"  wrote:
> I think this is a bug in execCommand('indent') and should be fixed in
> browsers.

As someone who has gone to a great deal of effort to get HTML lists working
in an editor really well, I'd definitely agree. However, almost no editors
get this right for some reason. It's been quite a while since I tested but I
believe even Frontpage and Dreamweaver got it wrong at the time.

It does introduce complexities when you try to indent list items more than
one level deeper than it's parent, but semantically that really doesn't make
sense anyway. You can make it work by adding a new list item but with
list-style-type: none specified.

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 200 182 x481  US: +1 (650) 292 9659 x717
Ephox 
Ephox Blogs , Personal Blog

Re: [whatwg] Nested list

2009-07-13 Thread Simon Pieters


On Fri, 03 Jul 2009 00:05:09 +0200, Ryosuke Niwa  wrote:


Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
nested OL or UL without LI.  See
http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.2  In fact, the
nested list example is marked deprecated.  But in practice, all major
user agents produce nested list when execCommand("Indent"...) is
executed.


I think this is a bug in execCommand('indent') and should be fixed in  
browsers.


The spec doesn't seem to list 'indent' at all. It would be helpful if it  
was specified.




Is there any chance we can standardize nested lists, and in
particular, what UA produce?

For example, all major browsers (Firefox, IE, & WebKit) produce
slightly different versions of HTML when indenting "item 2" in the
following HTML (assume it's content-editable):

item 1
item 2
item 3


In particular, many UA remove arbitrary id attributes.

Best regards,
Ryosuke Niwa
rn...@google.com


--
Simon Pieters
Opera Software

Re: [whatwg] input type="url" allow URLs without http:// prefix

2009-07-13 Thread Kornel


On 13 Jul 2009, at 08:52, Bruce Lawson wrote:


I'd like to suggest that input
type="url" allows the http:// prefix to be optional on input and,  
if ommitted, be assumed when parsing.


The spec explicitly allows that actual value seen and edited by the  
user in the interface is different from DOM value of the input, so  
browsers are free to prepend http:// automatically (and IMHO should  
– DSK-253195).


Excellent. And, while I don't doubt you at all, I'm abashed that I  
missed that nuance, especially as it'#s explicitly allowed?  Where  
would I find that in the spec?


The "URL state" section says that value in DOM may be different from  
value in the user interface:


http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#url-state

The example difference given in the spec is URL-escaping, but in my  
understanding, it should allow to prepending of protocol as well (I  
admit that last bit is not stated explicitly).


--
regards, Kornel

Re: [whatwg] editorial ambiguity in definition of ?

On Thu, 18 Jun 2009, Bruce Lawson wrote:
>
> Spec says
> 
> "The nav element represents a section of a page that links to other pages or
> to parts within the page: a section with navigation links. Not all groups of
> links on a page need to be in a nav element — only sections that consist of
> primary navigation blocks are appropriate for the nav element."
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-nav-element
> 
> "Primary navigation blocks" is ambiguous, imo. A page may have two nav blocks;
> the first is site-wide naviagtion ("primary navigation") and within-page
> links, eg a table of contents which many would term "secondary nav".
> 
> Because of the use of the phrase "primary navigation block" in the spec, a
> developer may think that her secondary nav should not use a  element.
> 
> Suggest rewording along the lines of "only sections that consist of blocks
> whose primary purpose is navigation around the page or within the site are
> appropriate for the nav element, so - for example - lists of links to
> sponsors/ advertisers would not be marked up as nav elements."

I fixed this by just changing "primary" to "major".

I've also added an example of secondary navigation using .

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

Re: [whatwg] Storage Events for a Specific Storage Area

On Wed, 17 Jun 2009, Joseph Pecoraro wrote:
>
> The "storage" event [1] fires for both sessionStorage and localStorage.  
> To me, this means if you only want to interact with localStorage you 
> will have to manually ensure that it is the storage area being modified:
> 
>   window.addEventListener('storage', function(e) {
> if ( e.storageArea === localStorage ) {
>   // ...
> }
>   }
> 
> Was there any discussion about creating events specific to the storage 
> object, or should that already be possible?  I've been playing around 
> with WebKit's Storage implementation, and the following (understandably) 
> is not possible:
> 
>   > localStorage.addEventListener
>   undefined
> 
> Is there any way to listen to events for a single specific storage area 
> or is the previously mentioned approach preferred?

We could make Storage into an EventTarget and also fire events on there, 
sure. As Jeremy said, this is something that might best be done in the 
next version; we're still trying to get the current features implemented 
in a stable and consistent fashion as it is.

In general, though, I don't think it's critical, since you can easily work 
around it by checking which was changed based on the event data.

(I agree that your proposal would have made more sense. I'm sorry my 
learning experiences have such a detrimental effect on the Web! :-) )

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

Re: [whatwg] "Fullscreenable" attribute.

2009-07-13 Thread Dan Brickley


On 13/7/09 11:06, Ian Hickson wrote:

On Tue, 16 Jun 2009, Alpha Omega wrote:

I think it would be useful to add "fullscreenable" (or more refined
name) attribute to arbitrary element, so users could be able to
full-screen DOM subtrees, that document author marked as
"fullscreenable".

Usage: User choses area that he wants to fullscreen, peforms UA-specific
action there("go to fullscreen" in context menu in desktop browsers, or
gesture on mobile devices for example), UA goes up in DOM tree until it
founds "fullscreenable" attribute, and then "fullscreens" this subtree.
If "fullscreenable" attribute is not found, then it is UA authors
decision what to do - for example fullscreen entire page.


Should UAs always put users in control of this?

ie. everything in principle is "fullscreenable", but this indicator 
would be a strong hint that this chunk of content makes special sense to 
be treated in this manner.



Use case: Not only solves problem with  tag, but also useful for
mobile UAs (users could use it to "zoom" to author defined parts, on
pages with complex layouts.), and for interactive webapps in general
IMHO.


I think this would be an interesting idea. I haven't any idea what the UI
would look like though. I recommend approaching vendors directly and
getting their input and experimental implementations, as described here:


http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F


I like the idea of being able to go full-screen. I'd encourage talking 
to Web accessibility folk before going to far with a proposal / 
implementation...


cheers,

Dan

Re: [whatwg] HTML 5 video tag questions

2009-07-13 Thread Jonas Sicking

On Sun, Jul 12, 2009 at 11:20 PM, Ian Hickson wrote:
> On Fri, 10 Jul 2009, Jonas Sicking wrote:
>> >>
>> >> Hmm.. is that good? What if you want to use an  (to use flash
>> >> or java) or a  as fallback?
>> >
>> > Then you do it with script.
>> >
>> > The design is based around the assumption that we will eventually find
>> > a common codec so that fallback won't ever be needed in supporting
>> > UAs.
>>
>> I agree that the current design makes sense once there is a common codec
>> supported across all browsers. However currently it seems like we might
>> not reach that point until after all major browsers support .
>>
>> What would be the downside of displaying the fallback contents if none
>> of the videos can be displayed due to unsupported codecs?
>
> When would you fall back? For example, while parsing, would you fall back
> in between the  element being parsed and the first  element
> being parsed?

You could display the fallback once you've reached the  and
not found an acceptable . Technically it'd be when you pop the
video element off the stack of open elements. I don't even think it'd
be hard to pull down all s and check that none of them are
supported before displaying the fallback if types aren't specified on
the  element.

> The design you describe is what  tried to do, and it proved to be
> extremely problematic in practice -- and that was without another built-in
> fallback mechanism to complicate matters.

While  has had a very poor implementation story, I don't think
this was a big reason for that.

Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
answer this better, but at least in gecko I don't think this part of
object was particularly hard to implement correctly once we actually
tried.

Has any browser vendor argued against displaying the fallback due to
high implementation burden?

/ Jonas

Re: [whatwg] "Fullscreenable" attribute.

On Tue, 16 Jun 2009, Alpha Omega wrote:
>
> I think it would be useful to add "fullscreenable" (or more refined 
> name) attribute to arbitrary element, so users could be able to 
> full-screen DOM subtrees, that document author marked as 
> "fullscreenable".
> 
> Usage: User choses area that he wants to fullscreen, peforms UA-specific 
> action there("go to fullscreen" in context menu in desktop browsers, or 
> gesture on mobile devices for example), UA goes up in DOM tree until it 
> founds "fullscreenable" attribute, and then "fullscreens" this subtree. 
> If "fullscreenable" attribute is not found, then it is UA authors 
> decision what to do - for example fullscreen entire page.
> 
> Use case: Not only solves problem with  tag, but also useful for 
> mobile UAs (users could use it to "zoom" to author defined parts, on 
> pages with complex layouts.), and for interactive webapps in general 
> IMHO.

I think this would be an interesting idea. I haven't any idea what the UI 
would look like though. I recommend approaching vendors directly and 
getting their input and experimental implementations, as described here:

   
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F

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

Re: [whatwg] Serving up Theora in the real world