Nabble - w3.org - public-html-comments

RE: Widget tag

2009-11-23T00:54:11Z

Hi Luigi,

Please could expand on what it is that the “widget” element will do, and how search engines will make use of them? My understanding is that the “code” element can already be used to mark up sections of example code, and that the “script” element can be used to mark up sections of client executed script code. What is it that you envisage the “widget” element doing different to these?

Thanks,

-Jason

From: public-html-comments-request@... [mailto:public-html-comments-request@...] On Behalf Of Luis Vega
Sent: 22 November 2009 06:12
To: public-html-comments@...
Subject: Widget tag

Hi, great job

I think a "widget" tab will be very useful for search engines to know about thos little pieces of code.

Thanks

--
Luigi

Scanned by iCritical.

Widget tag

2009-11-21T22:12:10Z

Hi, great job

I think a "widget" tab will be very useful for search engines to know about thos little pieces of code.

Thanks

--
Luigi

RE: Asset bundles for faster page fetching (fewer requests to the server)

2009-11-09T02:44:23Z

What a fantastic idea Jxtps!

I'd like to suggest a way for the user-agent to keep track of assets within the bundle vs. individual files. For example on an image link:

<img src="/folder/imagefile.jpg" asset="/bundle.zip/imagefile.jpg" alt="title" />

If the user-agent recognises bundles, then it will extract the imagefile.jpg from the bundle.zip archive, but if the user-agent doesn't recognise bundles, it requests the imagefile.jpg individually from the web server from the /folder/.

The user-agent would keep track of the fact that:

/folder/imagefile.jpg

... is exactly the same as:

/folder/bundle.zip/imagefile.jpg

... so that if it comes across another instance of /folder/imagefile.jpg in the same web-page or another web-page, it can extract it from the cached bundle.zip archive instead of making another HTTP request.

Likewise:

<link type="text/css" rel="StyleSheet" href="/folder/stylesheetfile.css" asset="/bundle.zip/stylesheetfile.css" />

<script type="text/javascript" src="/folder/javascriptfile.js" asset="/bundle.zip/javascriptfile.js"><script>

I hope this makes sense.

Regards,

--
David Bailey,
Bath Spa University - Web Manager.

[As long as you don't print this email, no trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.]

From: public-html-comments-request@... [mailto:public-html-comments-request@...] On Behalf Of jxtps435
Sent: 08 November 2009 19:58
To: public-html-comments@...
Subject: Asset bundles for faster page fetching (fewer requests to the server)

Hi all,

It would be great if it were possible for a web page author to specify an "asset bundle" to use for the web page authored. This asset bundle could be e.g. a zip file containing parts/all of the css, javascript and image content needed by the page. A user agent could then fetch the asset bundle (one request) and in it find most/all of the assets needed to render the page, without the need to make additional requests to the server (with all the attendant latency etc issues).

User agents that are not aware of the asset bundle concept would simply ignore the asset bundle reference and fetch the assets in the way it's already done today, thereby ensuring full backwards compatibility.

Assets required for page rendering but not found in the asset bundle would be fetched the way it's already done today (so you can optimize what you put in the asset bundle).

Benefits:

- Lower the impact of latency on page loading for web pages with multiple assets (almost all modern web pages).

- Many web page authors do not have fine-grained control over the ETAGs generated for their css/javascript/image assets, which then requires the user agent to issue refresh requests for all those assets. With an asset bundle the number of such requests could be drastically reduced.

- Even in the case where web page authors do have fine-grained control over the ETAGs, it can be difficult to take advantage of this since you may not know when content will need to be refreshed. If you set the ETAG to ~infinity, then it requires significant labor to update the file names of content that has changed to make sure it is refreshed. With an asset bundle you would only need to update a single filename.

- Many web servers are poorly configured and do not compress e.g. css and javascript content they serve. An asset bundle would be compressed by virtue of construction.

- Fully backwards compatible with opt-in for web page authors and user agents.

The asset bundle itself could be easily generated either manually by the web page author (zip the contents of the directory containing the assets for simple cases), or automated by a tool in e.g. the web framework used (if any). This would allow for single-point-of-update with an ETAG set to ~infinity - just change the name of the asset file, rather than the name of each individual asset. Note that this could easily be fully automated in any of the popular web frameworks in use today.

The asset bundle could be referenced in the web page by e.g. something like <link rel="assetbundle" src="/assetbundle.zip" ... >.

Tools used to create the asset bundle could be made sufficiently smart so as to only include "small" assets (e.g. the 50+ <4kb images), but not "big" assets (e.g. the 2mb video).

Mapping the directory structure inside the asset bundle to the path structure of the assets used in the web page/css/javascript should be straightforward, even for complex cloud-fronted/akamai-ed configurations, with the use of a few optional path mapping attributes in the tag used to reference the asset bundle.

Since it would be completely optional to use an asset bundle, the user agent should assume that the asset bundle is an authoritative source for the most recent version of any assets found inside of it, thereby allowing the user agent to skip additional refresh requests for those assets.

If multiple asset bundles are referenced by a web page, the most recent one specified that contains a given asset would be used for that asset (i.e. order-in-web-page decides priority, just like for css).

Use of streaming compression standards would allow for the unpacking of received bundle contents before the full file has been fetched. This would allow conscientious web page authors and their tools to optimize the storage order inside the asset bundle.

In a low-latency situation a user agent may be able to fetch the assets faster if the requests are made in parallel, rather than through the by construction serialized fetching of an asset bundle. User agents can be optimized to detect and take advantage of this (i.e. the asset bundle is a "hint" or "suggestion" not a requirement).

I read somewhere that the typical website visitor views on the order of 5 pages. With say 50 assets for each page (including the page itself), a user agent that aggressively checks for refreshed content may find itself making 5*50=250 requests to the website. With an asset bundle this would be 5*2=10 requests, and if the asset bundle's ETAG is properly configured, it would be 6 requests (vs 54 for a fully ETAGged non-asset-bundle site).

Thank you for reading this.
Jxtps

Asset bundles for faster page fetching (fewer requests to the server)

2009-11-08T11:58:01Z

Hi all,

It would be great if it were possible for a web page author to specify an "asset bundle" to use for the web page authored. This asset bundle could be e.g. a zip file containing parts/all of the css, javascript and image content needed by the page. A user agent could then fetch the asset bundle (one request) and in it find most/all of the assets needed to render the page, without the need to make additional requests to the server (with all the attendant latency etc issues).

User agents that are not aware of the asset bundle concept would simply ignore the asset bundle reference and fetch the assets in the way it's already done today, thereby ensuring full backwards compatibility.

Assets required for page rendering but not found in the asset bundle would be fetched the way it's already done today (so you can optimize what you put in the asset bundle).

Benefits:

- Lower the impact of latency on page loading for web pages with multiple assets (almost all modern web pages).

- Many web page authors do not have fine-grained control over the ETAGs generated for their css/javascript/image assets, which then requires the user agent to issue refresh requests for all those assets. With an asset bundle the number of such requests could be drastically reduced.

- Even in the case where web page authors do have fine-grained control over the ETAGs, it can be difficult to take advantage of this since you may not know when content will need to be refreshed. If you set the ETAG to ~infinity, then it requires significant labor to update the file names of content that has changed to make sure it is refreshed. With an asset bundle you would only need to update a single filename.

- Many web servers are poorly configured and do not compress e.g. css and javascript content they serve. An asset bundle would be compressed by virtue of construction.

- Fully backwards compatible with opt-in for web page authors and user agents.

The asset bundle itself could be easily generated either manually by the web page author (zip the contents of the directory containing the assets for simple cases), or automated by a tool in e.g. the web framework used (if any). This would allow for single-point-of-update with an ETAG set to ~infinity - just change the name of the asset file, rather than the name of each individual asset. Note that this could easily be fully automated in any of the popular web frameworks in use today.

The asset bundle could be referenced in the web page by e.g. something like <link rel="assetbundle" src="/assetbundle.zip" ... >.

Tools used to create the asset bundle could be made sufficiently smart so as to only include "small" assets (e.g. the 50+ <4kb images), but not "big" assets (e.g. the 2mb video).

Mapping the directory structure inside the asset bundle to the path structure of the assets used in the web page/css/javascript should be straightforward, even for complex cloud-fronted/akamai-ed configurations, with the use of a few optional path mapping attributes in the tag used to reference the asset bundle.

Since it would be completely optional to use an asset bundle, the user agent should assume that the asset bundle is an authoritative source for the most recent version of any assets found inside of it, thereby allowing the user agent to skip additional refresh requests for those assets.

If multiple asset bundles are referenced by a web page, the most recent one specified that contains a given asset would be used for that asset (i.e. order-in-web-page decides priority, just like for css).

Use of streaming compression standards would allow for the unpacking of received bundle contents before the full file has been fetched. This would allow conscientious web page authors and their tools to optimize the storage order inside the asset bundle.

In a low-latency situation a user agent may be able to fetch the assets faster if the requests are made in parallel, rather than through the by construction serialized fetching of an asset bundle. User agents can be optimized to detect and take advantage of this (i.e. the asset bundle is a "hint" or "suggestion" not a requirement).

I read somewhere that the typical website visitor views on the order of 5 pages. With say 50 assets for each page (including the page itself), a user agent that aggressively checks for refreshed content may find itself making 5*50=250 requests to the website. With an asset bundle this would be 5*2=10 requests, and if the asset bundle's ETAG is properly configured, it would be 6 requests (vs 54 for a fully ETAGged non-asset-bundle site).

Thank you for reading this.

Jxtps

Re: Value of should list all files

2009-11-03T07:42:43Z

On Sun, 01 Nov 2009 15:33:15 -0800, Geoff Lankow <geoff@...>
wrote:

> the filename of the first file in the list of selected files
> <http://www.w3.org/TR/html5/forms.html#concept-input-type-file-selected>,
> if any, or the empty string if the list is empty. On setting, it must
> throw an |INVALID_ACCESS_ERR
> <http://www.w3.org/TR/html5/infrastructure.html#invalid_access_err>|
> exception.
>
> Why only the first file in the list? It can't be for
> backwards-compatibility, as the multiple attribute never existed before
> this spec. Doesn't it make sense to list all the files?

You can get the file names through <input>.files. Making <input>.value
more complex as well did not seem worth it.

--
Anne van Kesteren
http://annevankesteren.nl/

scrollIntoView scrolls what

2009-11-02T16:39:51Z

It may be too late for this, but I think the spec would benefit from more clarity and/or control of what element.scrollIntoView does. In particular, I'm thinking of the case where the element is contained in multiple structures that can scroll (e.g. both the div and whole page, or one scrolling div nested inside another).

As it is, the spec is unclear about which elements should be scrolled, and there are scenarios in which there would be more than one way to scroll the content into view. I would suggest at least standardizing this; I propose that when two possible solutions are available, the one that uses only deeper elements of the DOM be used.

For even more control, another optional argument could be added that allows the caller to specify which containers should be scrolled.

Cheers,

Mike

Addendum: Here's a bit of evidence that I'm not the only person who wants this:

http://codingforums.com/showthread.php?t=169209

http://www.experts-exchange.com/Programming/Languages/Scripting/JavaScript/Q_22725518.html

Value of should list all files

2009-11-01T15:33:15Z

the filename of the first file in the list of selected files
<http://www.w3.org/TR/html5/forms.html#concept-input-type-file-selected>, if
any, or the empty string if the list is empty. On setting, it must throw
an |INVALID_ACCESS_ERR
<http://www.w3.org/TR/html5/infrastructure.html#invalid_access_err>|
exception.

Why only the first file in the list? It can't be for
backwards-compatibility, as the multiple attribute never existed before
this spec. Doesn't it make sense to list all the files?

-Geoff

Re: Video DOM API

2009-10-14T19:54:05Z

On Wed, 14 Oct 2009 06:50:49 -0400, Simon Pieters <simonp@...> wrote:

> On Wed, 14 Oct 2009 12:11:27 +0200, Michael A. Puls II
> <shadow2531@...> wrote:
>
>>> What behavior do you expect when using <source>s instead of src?
>>>
>>
>> Well, you can insert, replace and remove a <source> element. You can
>> change @src and @type on each <source> that's present.
>
> Also keep in mind that the parser inserts <source> elements.

O.K.

>> One easy way (thought-wise) to handle that is that whenever any of that
>> happens, the UA should stop, unload, reset states and figure out what
>> <source> to play.
>
> The resource selection algorithm tries each <source> in turn. It seems
> bad to start over several times during parsing.

O.K.

>> On the other hand, you might want to change @src for multiple <source>s
>> without triggering a reevalutation until you explicitly call for one.
>
> Indeed.
>
>
>> Or, you might want a mix of the two that depends on whether there's
>> just one <source> or where you're inserting a <source> (before the one
>> that's currently being used for example) or which <source> you're
>> removing (the one being used or not).
>>
>> So, I mostly expect the first way. However, the second seems simpler
>> and would just cover everything.
>>
>> But, note that I haven't really dealt with the multiple type fallback
>> stuff yet, so I don't have a strong opinion on <source> yet.
>

--
Michael

Re: Video DOM API

2009-10-14T03:50:49Z

On Wed, 14 Oct 2009 12:11:27 +0200, Michael A. Puls II
<shadow2531@...> wrote:

>> What behavior do you expect when using <source>s instead of src?
>>
>
> Well, you can insert, replace and remove a <source> element. You can
> change @src and @type on each <source> that's present.

Also keep in mind that the parser inserts <source> elements.

> One easy way (thought-wise) to handle that is that whenever any of that
> happens, the UA should stop, unload, reset states and figure out what
> <source> to play.

The resource selection algorithm tries each <source> in turn. It seems bad
to start over several times during parsing.

> On the other hand, you might want to change @src for multiple <source>s
> without triggering a reevalutation until you explicitly call for one.

Indeed.

> Or, you might want a mix of the two that depends on whether there's just
> one <source> or where you're inserting a <source> (before the one that's
> currently being used for example) or which <source> you're removing (the
> one being used or not).
>
> So, I mostly expect the first way. However, the second seems simpler and
> would just cover everything.
>
> But, note that I haven't really dealt with the multiple type fallback
> stuff yet, so I don't have a strong opinion on <source> yet.

--
Simon Pieters
Opera Software

Re: Video DOM API

2009-10-14T03:19:11Z

On Wed, 14 Oct 2009 04:54:57 -0400, Ian Hickson <ian@...> wrote:

> On Wed, 14 Oct 2009, Michael A. Puls II wrote:
>>
>> I am that other person and here's what I personally expect, fwiw:
>>
>> When setting src:
>>
>> 1. The current media should stop playing.
>>
>> 2. It should then be unloaded.
>>
>> 3. All states should be reset (including the play state).
>>
>> 4. The new media should start loading.
>>
>> 5. If autoplay is true, the new media should start playing. If not, it
>> only starts playing when you call play().
> That is now the case.

Thanks

--
Michael

Re: Video DOM API

2009-10-14T03:11:27Z

On Wed, 14 Oct 2009 04:25:42 -0400, Simon Pieters <simonp@...> wrote:

> On Wed, 14 Oct 2009 06:12:01 +0200, Michael A. Puls II
> <shadow2531@...> wrote:
>
>> Gervase Markham <gerv@...> wrote:
>>
>>> On a <video> element (I haven't tried <audio>), if you change the src=
>>> attribute to a new file, you have to call .load() before .play(),
>>> otherwise it replays the old file. This lost me half an hour of
>>> debugging, and recently another person posted in the Mozilla newsgroups
>>> having exactly the same problem.
>>
>> (Thanks for posting this)
>>
>> I am that other person and here's what I personally expect, fwiw:
>>
>> When setting src:
>>
>> 1. The current media should stop playing.
>>
>> 2. It should then be unloaded.
>>
>> 3. All states should be reset (including the play state).
>>
>> 4. The new media should start loading.
>>
>> 5. If autoplay is true, the new media should start playing. If not, it
>> only starts playing when you call play().
>>
>> My use-case is setting @src when clicking on a link (in an ordered list
>> of many links with click handlers) to an .ogg file.
>>
>> Having to call load() after setting src seems odd since I set src for a
>> reason, which is, to load it so I can play() it (or automatically play
>> it if I have autoplay set to true).
>>
>> For <object> when you change @type/@data, the object is pretty much
>> re-evaluated. I pretty much expect the same when setting src for
>> <audio> and <video>
>
> What behavior do you expect when using <source>s instead of src?
>

Well, you can insert, replace and remove a <source> element. You can
change @src and @type on each <source> that's present.

One easy way (thought-wise) to handle that is that whenever any of that
happens, the UA should stop, unload, reset states and figure out what
<source> to play.

On the other hand, you might want to change @src for multiple <source>s
without triggering a reevalutation until you explicitly call for one.

Or, you might want a mix of the two that depends on whether there's just
one <source> or where you're inserting a <source> (before the one that's
currently being used for example) or which <source> you're removing (the
one being used or not).

So, I mostly expect the first way. However, the second seems simpler and
would just cover everything.

But, note that I haven't really dealt with the multiple type fallback
stuff yet, so I don't have a strong opinion on <source> yet.

--
Michael

Re: Video DOM API

2009-10-14T01:44:37Z

On Thu, 8 Oct 2009, Gervase Markham wrote:

>
> On a <video> element (I haven't tried <audio>), if you change the src=
> attribute to a new file, you have to call .load() before .play(),
> otherwise it replays the old file. This lost me half an hour of
> debugging, and recently another person posted in the Mozilla newsgroups
> having exactly the same problem.
>
> I am told by an informed source (Boris Zbarsky) that the spec for
> <video> requires this behaviour. Having spent ten minutes reading the
> highly comprehensive specification, I could not find the location where
> it says this. However, I believe him :-)
>
> Question: why? This is counter-intuitive. Under what circumstances would
> you want to set the src= attribute of a <video> tag to a file which you
> did not want the loading process to begin immediately? Can we eliminate
> the requirement, e.g. by having play() implicitly call load() if it
> hasn't been called?

I've made setting .src stop the video and reload as you request.

It doesn't affect <source> processing, though.

On Thu, 8 Oct 2009, Simon Pieters wrote:

>
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }
>
> ?
>
> (You wouldn't need to invoke play() again, because the media isn't
> paused when it has ended.)

It calls load(), so you do have to do the check.

On Sat, 10 Oct 2009, Simon Pieters wrote:
> On Fri, 09 Oct 2009 18:34:02 +0200, Gervase Markham <gerv@...>
> wrote:
> >
> > I just want play() to implicitly invoke load(), because then it all
> > DWYM.
>
> Even if the first video hasn't ended yet? Even if src hasn't changed?

On Sat, 10 Oct 2009, Gervase Markham wrote:
>
> Well, if src hasn't changed, then presumably load() is a no-op under any
> circumstances?

load() always restarts the entire loading algorithm.

> If a video is playing, I change the src= and then call play() again, I don't
> think it's unreasonable to expect the element to start playing the new src.

play() maps to the play button in the UI. So if made it wait until play()
was called, then the script could change the src, not call play(), and
then the user would find that if he hit pause and then play again, it
would suddenly load the new video. That would be rather weird.

On Thu, 8 Oct 2009, Arthur Clifford wrote:

>
> Wouldn't it be easier to have play take an optional src parameter?
>
> var a=new Audio();
> a.onended = function() { if(a.src=='foo') a.play('bar'); }
> a.play('foo');
>
> internally play could do this check:
> if( inSrc !== src) src=inSrc ... load and play video
> else if at end of audio, rewind and play
> else play forward from where the playback head is at.

We could do that, but that would be redundant with setting src="" (which
we can't really remove), so I don't see much point.

On Thu, 8 Oct 2009, Musgrove, Jason L wrote:

>
> If what is being aimed for is the sequential playing of more than one
> media item, why not amend the spec such that the appropriate media
> element (either <audio> or <video>) be permitted to have child elements
> that define a playlist in lieu of a src attribute (which can still be
> used if only one media item is to played), and let the browser take care
> of the sequencing without the unnecessary addition of script to do this.
>
> Suggested example:
>
> <video>
> <clip src="video1.m4v" />
> <clip src="video2.m4v" />
> </video>
>
> The API could then be augmented to include a ".clips" property which
> represents a collection of the clip elements, and provides appropriate
> methods to manipulate the "playlist".

Playlists are on the cards for v2.

On Wed, 14 Oct 2009, Michael A. Puls II wrote:

>
> I am that other person and here's what I personally expect, fwiw:
>
> When setting src:
>
> 1. The current media should stop playing.
>
> 2. It should then be unloaded.
>
> 3. All states should be reset (including the play state).
>
> 4. The new media should start loading.
>
> 5. If autoplay is true, the new media should start playing. If not, it
> only starts playing when you call play().

That is now the case.

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

Re: Video DOM API

2009-10-14T01:25:42Z

On Wed, 14 Oct 2009 06:12:01 +0200, Michael A. Puls II
<shadow2531@...> wrote:

> Gervase Markham <gerv@...> wrote:
>
>> On a <video> element (I haven't tried <audio>), if you change the src=
>> attribute to a new file, you have to call .load() before .play(),
>> otherwise it replays the old file. This lost me half an hour of
>> debugging, and recently another person posted in the Mozilla newsgroups
>> having exactly the same problem.
>
> (Thanks for posting this)
>
> I am that other person and here's what I personally expect, fwiw:
>
> When setting src:
>
> 1. The current media should stop playing.
>
> 2. It should then be unloaded.
>
> 3. All states should be reset (including the play state).
>
> 4. The new media should start loading.
>
> 5. If autoplay is true, the new media should start playing. If not, it
> only starts playing when you call play().
>
> My use-case is setting @src when clicking on a link (in an ordered list
> of many links with click handlers) to an .ogg file.
>
> Having to call load() after setting src seems odd since I set src for a
> reason, which is, to load it so I can play() it (or automatically play
> it if I have autoplay set to true).
>
> For <object> when you change @type/@data, the object is pretty much
> re-evaluated. I pretty much expect the same when setting src for <audio>
> and <video>

What behavior do you expect when using <source>s instead of src?

--
Simon Pieters
Opera Software

Re: Video DOM API

2009-10-13T21:12:01Z

Gervase Markham <gerv@...> wrote:

> On a <video> element (I haven't tried <audio>), if you change the src=
> attribute to a new file, you have to call .load() before .play(),
> otherwise it replays the old file. This lost me half an hour of
> debugging, and recently another person posted in the Mozilla newsgroups
> having exactly the same problem.

(Thanks for posting this)

I am that other person and here's what I personally expect, fwiw:

When setting src:

1. The current media should stop playing.

2. It should then be unloaded.

3. All states should be reset (including the play state).

4. The new media should start loading.

5. If autoplay is true, the new media should start playing. If not, it
only starts playing when you call play().

My use-case is setting @src when clicking on a link (in an ordered list of
many links with click handlers) to an .ogg file.

Having to call load() after setting src seems odd since I set src for a
reason, which is, to load it so I can play() it (or automatically play it
if I have autoplay set to true).

For <object> when you change @type/@data, the object is pretty much
re-evaluated. I pretty much expect the same when setting src for <audio>
and <video>

--
Michael

RE: Video DOM API

2009-10-10T15:06:05Z

I would think that changing element.src would load and play unless
pre-buffering is enabled. If element is set to pre-buffer, then calling play
would be required after setting src. And calling play may not necessarily
need to be done immediately after src is set.

However, I think if you are going to have multiple audio clips playing back
to back that the idea someone mentioned a day or two ago makes more sense;
the idea of having a list of clip nodes that, in effect, is like having the
images array and the ability to preload images and dynamically swap image
sources at runtime via JS. Setting src on an img tag immediately displays
the image; should audio/video content be different? If a clip were preloaded
setting src to that clip would begin playing that clip, if it was not set to
preload it would load and play the clip as soon as you set the src of the
clip.

ArtC

Re: Video DOM API

2009-10-10T08:33:54Z

On Sat, 10 Oct 2009 12:02:42 +0200, Gervase Markham <gerv@...> wrote:

> On 10/10/09 10:44, Simon Pieters wrote:
>> I think it is unreasonable, because pause() and play() are intended to
>> be used for author-supplied scripted controls, and the user should be
>> able to pause and play the first video without that causing the new
>> video to be loaded.
>
> But then why has the app author set the src= element if they don't want
> the new file to be the one that element is playing?
>
> Here's the bottom line: I and at least one other person have been
> confused by this API, because we expect
>
> element.src = "file";
> element.play();
>
> to play "file". I don't think that's unreasonable, I think it's sensible
> and intuitive. My feedback on the spec is: make that work. I don't care
> how :-)

Making setting src implicitly call load() irrespective of the current
state would have desired effect and as far as I can see there's little
reason to think someone would set src without actually intending to use
the resource. There would be nothing special about play(), doing nothing
at all after setting src would also load the new resource, although it
would initially be paused.

While this would probably be more intuitive, I don't quite see the use
case for it if pre-buffering is important.

--
Philip Jägenstedt
Core Developer
Opera Software

Re: Video DOM API

2009-10-10T03:02:42Z

On 10/10/09 10:44, Simon Pieters wrote:
> I think it is unreasonable, because pause() and play() are intended to
> be used for author-supplied scripted controls, and the user should be
> able to pause and play the first video without that causing the new
> video to be loaded.

But then why has the app author set the src= element if they don't want
the new file to be the one that element is playing?

Here's the bottom line: I and at least one other person have been
confused by this API, because we expect

element.src = "file";
element.play();

to play "file". I don't think that's unreasonable, I think it's sensible
and intuitive. My feedback on the spec is: make that work. I don't care
how :-)

Gerv

Re: Video DOM API

2009-10-10T02:44:55Z

On Sat, 10 Oct 2009 11:20:10 +0200, Gervase Markham <gerv@...> wrote:

> On 10/10/09 09:19, Simon Pieters wrote:
>>> Actually, no, scratch that.
>>>
>>> I just want play() to implicitly invoke load(), because then it all
>>> DWYM.
>>
>> Even if the first video hasn't ended yet? Even if src hasn't changed?
>
> Well, if src hasn't changed, then presumably load() is a no-op under any
> circumstances?

No. load() empties the media element, resets playbackRate, fires some
events and restarts the resource selection algorithm.

> If a video is playing, I change the src= and then call play() again, I
> don't think it's unreasonable to expect the element to start playing the
> new src.

I think it is unreasonable, because pause() and play() are intended to be
used for author-supplied scripted controls, and the user should be able to
pause and play the first video without that causing the new video to be
loaded.

>> Invokind load() on play() still doesn't solve preloading, which you said
>> you wanted to have earlier.
>
> Yeah, scratch that. As you explained, much better to use two elements.

Ok.

--
Simon Pieters
Opera Software

Re: Video DOM API

2009-10-10T02:20:10Z

On 10/10/09 09:19, Simon Pieters wrote:
>> Actually, no, scratch that.
>>
>> I just want play() to implicitly invoke load(), because then it all DWYM.
>
> Even if the first video hasn't ended yet? Even if src hasn't changed?

Well, if src hasn't changed, then presumably load() is a no-op under any
circumstances?

If a video is playing, I change the src= and then call play() again, I
don't think it's unreasonable to expect the element to start playing the
new src.

> Invokind load() on play() still doesn't solve preloading, which you said
> you wanted to have earlier.

Yeah, scratch that. As you explained, much better to use two elements.

Gerv

Re: Video DOM API

2009-10-10T01:19:30Z

On Fri, 09 Oct 2009 18:34:02 +0200, Gervase Markham <gerv@...> wrote:

> On 08/10/09 15:45, Simon Pieters wrote:
>> So you want the media element to load two resources at the same time?
>> I'm very skeptical about this idea.
>
> Actually, no, scratch that.
>
> I just want play() to implicitly invoke load(), because then it all DWYM.

Even if the first video hasn't ended yet? Even if src hasn't changed?

Invokind load() on play() still doesn't solve preloading, which you said
you wanted to have earlier.

--
Simon Pieters
Opera Software

Re: Video DOM API

2009-10-09T09:34:02Z

On 08/10/09 15:45, Simon Pieters wrote:
> So you want the media element to load two resources at the same time?
> I'm very skeptical about this idea.

Actually, no, scratch that.

I just want play() to implicitly invoke load(), because then it all DWYM.

> Not sure I follow. Currently, inserting a <source> into a media element
> that is in a document and has networkState NETWORK_EMPTY will run the
> resource selection algorithm. Inserting another <source> will only be
> used if the first <source> fails.

I guess I'm not sure that the above change would affect this sort of
thing...

Gerv

RE: Video DOM API

2009-10-08T15:46:00Z

The clip tag idea is intriguing in that a clip could be audio, video, or an
image. If the clip tag supported optional 'delayBefore' and/or 'delayAfter'
attribute one could conceivably create an animation out of images, including
images of different types. The clips could also have a boolean 'preload'
attribute to indicate whether to load a clip when the video tag is
processed.

If the notion of a playlist is supported that would also mean the usual
playlist sorts of functions, next/back/repeat mode/playmode (i.e. shuffle,
sequential)

-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Musgrove, Jason L
Sent: Thursday, October 08, 2009 3:25 PM
To: art@...; Gervase Markham; Simon Pieters;
public-html-comments@...
Subject: RE: Video DOM API

If what is being aimed for is the sequential playing of more than one
media item, why not amend the spec such that the appropriate media
element (either <audio> or <video>) be permitted to have child elements
that define a playlist in lieu of a src attribute (which can still be
used if only one media item is to played), and let the browser take care
of the sequencing without the unnecessary addition of script to do this.

Suggested example:

<video>
<clip src="video1.m4v" />
<clip src="video2.m4v" />
</video>

The API could then be augmented to include a ".clips" property which
represents a collection of the clip elements, and provides appropriate
methods to manipulate the "playlist".

RE: Video DOM API

2009-10-08T15:25:02Z

If what is being aimed for is the sequential playing of more than one
media item, why not amend the spec such that the appropriate media
element (either <audio> or <video>) be permitted to have child elements
that define a playlist in lieu of a src attribute (which can still be
used if only one media item is to played), and let the browser take care
of the sequencing without the unnecessary addition of script to do this.

Suggested example:

<video>
<clip src="video1.m4v" />
<clip src="video2.m4v" />
</video>

The API could then be augmented to include a ".clips" property which
represents a collection of the clip elements, and provides appropriate
methods to manipulate the "playlist".

-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Arthur
Clifford
Sent: 08 October 2009 22:31
To: 'Gervase Markham'; 'Simon Pieters'; public-html-comments@...
Subject: RE: Video DOM API

Wouldn't it be easier to have play take an optional src parameter?

var a=new Audio();
a.onended = function() { if(a.src=='foo') a.play('bar'); }
a.play('foo');

internally play could do this check:
if( inSrc !== src) src=inSrc ... load and play video
else if at end of audio, rewind and play
else play forward from where the playback head is at.

Art C

-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Gervase
Markham
Sent: Thursday, October 08, 2009 5:54 AM
To: Simon Pieters; public-html-comments@...
Subject: Re: Video DOM API

On 08/10/09 13:29, Simon Pieters wrote:
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }

That seems like the obvious way one would implement the chaining of
videos, isn't it? Although it doesn't allow for pre-loading and
therefore seamless linking unless you've loaded 'bar' in another <audio>

somewhere else previously. Hmm...

I think I want to be able to do:

var a = new Audio('foo');
a.play();
a.src = 'bar';
a.load();
a.onended = function() { a.play(); a.onended = null; }

which gives me the preloading as well without needing an extra element.

> What do you think should happen when using <source> elements?

Good question. I think that if I add a <source> element, it should be
automatically load()ed. But if I call play(), then the resource
selection algorithm should be used at that point to tell which video
actually plays.

Gerv

--
Scanned by iCritical.

RE: Video DOM API

2009-10-08T14:30:45Z

Wouldn't it be easier to have play take an optional src parameter?

var a=new Audio();
a.onended = function() { if(a.src=='foo') a.play('bar'); }
a.play('foo');

internally play could do this check:
if( inSrc !== src) src=inSrc ... load and play video
else if at end of audio, rewind and play
else play forward from where the playback head is at.

Art C

-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Gervase Markham
Sent: Thursday, October 08, 2009 5:54 AM
To: Simon Pieters; public-html-comments@...
Subject: Re: Video DOM API

On 08/10/09 13:29, Simon Pieters wrote:
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }

That seems like the obvious way one would implement the chaining of
videos, isn't it? Although it doesn't allow for pre-loading and
therefore seamless linking unless you've loaded 'bar' in another <audio>
somewhere else previously. Hmm...

I think I want to be able to do:

var a = new Audio('foo');
a.play();
a.src = 'bar';
a.load();
a.onended = function() { a.play(); a.onended = null; }

which gives me the preloading as well without needing an extra element.

> What do you think should happen when using <source> elements?

Good question. I think that if I add a <source> element, it should be
automatically load()ed. But if I call play(), then the resource
selection algorithm should be used at that point to tell which video
actually plays.

Gerv

Re: Video DOM API

2009-10-08T07:45:16Z

On Thu, 08 Oct 2009 14:53:59 +0200, Gervase Markham <gerv@...> wrote:

> On 08/10/09 13:29, Simon Pieters wrote:
>> Maybe we could remove the networkState check when the src attribute is
>> set or changed. Should the "in a Document" check be removed, too? That
>> is, do you want to be able to do
>>
>> var a = new Audio('foo');
>> a.play();
>> a.onended = function() { a.src = 'bar'; a.onended = null; }
>
> That seems like the obvious way one would implement the chaining of
> videos, isn't it? Although it doesn't allow for pre-loading and
> therefore seamless linking unless you've loaded 'bar' in another <audio>
> somewhere else previously. Hmm...
>
> I think I want to be able to do:
>
> var a = new Audio('foo');
> a.play();
> a.src = 'bar';
> a.load();
> a.onended = function() { a.play(); a.onended = null; }
>
> which gives me the preloading as well without needing an extra element.

So you want the media element to load two resources at the same time? I'm
very skeptical about this idea. What should happen when the user clicks
pause and then play, should it suddenly switch to the new media?

I don't see the problem with having separate media elements for separate
media:

var a1 = new Audio('foo');
var a2 = new Audio('bar');
a1.play();
a1.onended = function() { a2.play(); a1 = null; /* allow a1 to be garbage
collected */ }

For video, you can do the same thing and just use replaceChild():

<video src='foo' autoplay controls></video>
<script>
var v1 = document.querySelector('video');
var v2 = document.createElement('video');
v2.autobuffer = true;
v2.controls = true;
v2.src = 'bar';
v2.load();
v1.onended = function() { v1.parentNode.replaceChild(v1, v2); }
</script>

>> What do you think should happen when using <source> elements?
>
> Good question. I think that if I add a <source> element, it should be
> automatically load()ed. But if I call play(), then the resource
> selection algorithm should be used at that point to tell which video
> actually plays.

Not sure I follow. Currently, inserting a <source> into a media element
that is in a document and has networkState NETWORK_EMPTY will run the
resource selection algorithm. Inserting another <source> will only be used
if the first <source> fails.

--
Simon Pieters
Opera Software

Re: Video DOM API

2009-10-08T05:53:59Z

On 08/10/09 13:29, Simon Pieters wrote:
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }

That seems like the obvious way one would implement the chaining of
videos, isn't it? Although it doesn't allow for pre-loading and
therefore seamless linking unless you've loaded 'bar' in another <audio>
somewhere else previously. Hmm...

I think I want to be able to do:

var a = new Audio('foo');
a.play();
a.src = 'bar';
a.load();
a.onended = function() { a.play(); a.onended = null; }

which gives me the preloading as well without needing an extra element.

> What do you think should happen when using <source> elements?

Good question. I think that if I add a <source> element, it should be
automatically load()ed. But if I call play(), then the resource
selection algorithm should be used at that point to tell which video
actually plays.

Gerv

Re: Video DOM API

2009-10-08T05:29:08Z

On Thu, 08 Oct 2009 13:14:37 +0200, Gervase Markham <gerv@...> wrote:

> On a <video> element (I haven't tried <audio>), if you change the src=
> attribute to a new file, you have to call .load() before .play(),
> otherwise it replays the old file. This lost me half an hour of
> debugging, and recently another person posted in the Mozilla newsgroups
> having exactly the same problem.
>
> I am told by an informed source (Boris Zbarsky) that the spec for
> <video> requires this behaviour. Having spent ten minutes reading the
> highly comprehensive specification, I could not find the location where
> it says this. However, I believe him :-)

"If a src attribute of a media element that is in a Document and whose
networkState has the value NETWORK_EMPTY is set or changed, the user agent
must invoke the media element's resource selection algorithm."

If you have already played a video, networkState is not NETWORK_EMPTY, so
the resource selection algorithm is not invoked (and thus play() will play
the already-loaded video).

> Question: why? This is counter-intuitive. Under what circumstances would
> you want to set the src= attribute of a <video> tag to a file which you
> did not want the loading process to begin immediately? Can we eliminate
> the requirement, e.g. by having play() implicitly call load() if it
> hasn't been called?

Maybe we could remove the networkState check when the src attribute is set
or changed. Should the "in a Document" check be removed, too? That is, do
you want to be able to do

var a = new Audio('foo');
a.play();
a.onended = function() { a.src = 'bar'; a.onended = null; }

?

(You wouldn't need to invoke play() again, because the media isn't paused
when it has ended.)

What do you think should happen when using <source> elements?

--
Simon Pieters
Opera Software

Video DOM API

2009-10-08T04:14:37Z

On a <video> element (I haven't tried <audio>), if you change the src=
attribute to a new file, you have to call .load() before .play(),
otherwise it replays the old file. This lost me half an hour of
debugging, and recently another person posted in the Mozilla newsgroups
having exactly the same problem.

I am told by an informed source (Boris Zbarsky) that the spec for
<video> requires this behaviour. Having spent ten minutes reading the
highly comprehensive specification, I could not find the location where
it says this. However, I believe him :-)

Question: why? This is counter-intuitive. Under what circumstances would
you want to set the src= attribute of a <video> tag to a file which you
did not want the loading process to begin immediately? Can we eliminate
the requirement, e.g. by having play() implicitly call load() if it
hasn't been called?

Gerv

HTML5 Comments from the User Agent Accessibility Guidelines Working Group

2009-10-06T08:54:50Z

The following comments have been gathered by members of the User Agent
Accessibility Guidelines Working Group (UAWG) which is part of the Web
Accessibility Initiative Technical Activity. The UAWG Working Group's
review of HTML5 is on-going and more comments will be submitted when
identified by the group members. The following comments were on the
version http://dev.w3.org/html5/spec/ during the week of 24 August – 4
September. Other WAI Working Groups are reviewing the HTML5 Working
Draft and their comments may be channeled into the Joint Task Force
discussion. Please reply back to UAAG WG at w3c-wai-ua@... and cc:
the WAI Protocols & Formats Working Group at w3c-wai-pf@...

Issue#: UAWG24
Section: 3.2.4
Comment: 3.2.4 There are many references to mutation events 'firing as
appropriate', but without knowing when that is - UAs can make
interpretations about what and when an event will fire - indeed some
sections state that no mutation events will fire. Consistent rules on
firing mutation events are needed for assistive technologies to capture
and communicate mutation events to users.

Issue#: UAWG04
Section: 3.2.6 Annotations
Comment: 3.2.6 “Annotations for assistive technology products” section
is not clear whether these are in sync with WAI-ARIA. WAI-ARIA is in
Last Call and is being implemented by browsers and assistive
technologies. Any conflict between HTML5 and WAI-ARIA must be identified
and resolved. Browser and assistive techology developers need
confirmation that these two sets of standards are not in conflict.

Issue#: UAWG21
Section: 3.3.3.8 Embedded Links to Non-Visible Data
Comment: 3.3.3.8 Embedded Links to Non-Visible Data could be a useful
accessibility feature, but as there is no concept of interoperability
beyond the site (as it is site bespoke) then we need to 1) ensure that
this kind of data is readable by the assistive technology and 2) the
semantics of the interaction are expressed in a readable fashion.

Issue#: UAWG30
Section: 4.8.7 Video [Captions]
Comment: 1) Captions provide a means to understand the video for those
who are deaf, hard of hearing, non-primary language, or watching in a
silent environment. No mechanism for defining or providing captions is
specified as part of the Video element, therefore implementation of
captioning will primarily occur via authored scripting around the video
element. It needs to be defined more fully in the HTML5 spec to ensure
that browsers implement it in a standard way. It is not clear that the
spec has specified/will specify a standard API that would allow a user
agent to query if media (either audio or video) ".hasCaptions", or to
otherwise get at the text of the captions(or the language, etc). W3C's
proposed DXFP [1], and even SMIL Text [2] provides guidance to create
accessible video content (assuming the authoring tools and browser
support were there).

2) Since the user agent is supposed to have the ability to control
captions, the video element needs to define the needed properties to
query and control the caption content in the video being loaded/played.

[1] http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/
[2] http://www.w3.org/TR/SMIL3/smil-text.html

Issue#: UAWG32
Section: 4.8.7 Video [Descriptive or alternate audio tracks]
Comment: There is no mention of descriptive video or alternate audio
tracks, which are needed by users who cannot see the video, or need to
hear the audio in another language. It is unclear whether this is
something that *may* be in the video source, or authored using a
combination of scripting and the audio/video elements. This needs to be
clearly defined.

Issue#: UAWG31
Section: 4.8.7 Video [Controls]
Comment: The User Agent should be required to provide the
controls/interface-elements for media (audio, video, etc.). The author
should be able to style or script for extended functionality. The core
functionality - start/stop, pause, seek, volume, size (full screen),
caption track(s)- on/off/fg-bg color/location, descriptive video(s),
should not be written by millions of authors.

Issue#: UAWG16
Section: 4.10 Forms
Comment: Form validation: Under form validation there is no stipulation
that validation errors should be stylable by the page author using CSS
and are currently only available as per how the UA styles them unless
the page author knows JavaScript. This is an issue if browsers simply
implement an arbitrary styling that some users find hard to read. As
such there needs to be scope for validation errors to be stylable
(without relying on JavaScript) or browser implementations to be as
readable / accessible as possible (the latter being pretty subjective).

Issue#: UAWG06
Section: 7.3 Scrolling elements into view
Comment: Automatic scrolling can make the cursor jump in ways that
causes the user to go through extra steps to get back to what s/he was
doing. This is a special hardship for some users who have limited hand
mobility and/or speech input users. There needs to be a way for the user
to override automatic scrolling.

Issue#: UAWG07
Section: 7.4.3 document-level focus APIs
Comment: Unwanted focus switches can produce bad results. Visually
impaired users can lose the focus, or magnifier users can have the focus
move to a part of the page that is off-screen. User macros including
speech commands execute over time. Speech users don't necessarily change
the focus by moving the mouse -- this makes them more likely to get
caught with bad focus changes. The user needs some way to
override/hold off focus changes.

Issue#: UAWG18
Section: 7.6 list-item 2 and 3.3
Comment: In 7.6 list-item 2 and 3.3 of the HTML5 spec on accesskeys,
only a single key is allowed as opposed to multiple sequential keys,
however, when you add this to the concept of the context menu in
4.11.5.3 it seems that the general model of interaction, and importantly
exploration of the interface, becomes broken as a single keystroke
without a modifier key cannot be allocated. While this follows on the
mac OS, the intuitive sequential keystrokes of Windows and Linux will
break. We recommend that if the context menu is in focus then a single
keystroke without a modifier key is sufficient.

Issue#: UAWG09
Section: 7.7 The content editable attribute (drag and drop implementation)
Comment: Select and move non-editable elements section does not
specifically require keyboard access. All drag and drop needs to be
accessible using key navigation and cut-and-paste. Users with limited
mobility have difficulty or are unable to use a mouse. Speech users are
less prone to mistakes and have fewer steps with drag-and-drop using key
navigation and cut paste, than with using mouse commands.

Issue#: UAWG08
Section: 7.7 The content editable attribute (move the carat)
Comment: The “Move the carat” section is phrased so it is either/or
choice of mouse and keyboard when it should be phrased as an “and” –
both mouse and keyboard options are required. For people with limited
mobility or speech input users, we recommend selecting text using
keyboard commands since it is easier, requires fewer steps and is more
precise than selecting text using mouse commands.

Issue#: UAWG10
Section: 7.9 Drag and drop
Comment: Drag and drop needs to be accessible using key navigation and
cut-and-paste. It's also important to have undo enabled for
drag-and-drop. Even if media has pointing device, it also needs keyboard
option for those users with limited mobility or using speech input
assistive technology.

Issue#: UAWG11
Section: 7.10 Undo History
Comment: Undo History needs to include Undo of drag and drop actions.
Users with limited hand mobility are more prone to movement mistakes.
Undo of drag and drop is equally important as other Undo actions.

Issue#: UAWG28
Section: 10.2.5 Fonts and colors
Comment: Automatic reduction of the font size of H elements nested in
the article, aside, nav, and section elements will decrease access for
users with low vision. Users with low vision adjust font sizes to the
minimum size needed for comfortable reading. Many users with low vision
do not use assistive technology, but rather adjust to the largest font
size supported by the user agent. Reducing the size of the font -
particularly a text-dense element like "article" - increases the
imbalance between font sizes in other parts of the page (e.g. the user
would be forced to increase font size for the article text to the point
where the font size in the non-nested parts of the page are enlarged so
much as to overflow their containers.) We recommend that nested
elements not have the containing text size reduced automatically.

Issue#: UAWG29
Section: HTML section: 10.2.3 Margins and padding
Comment: If the user wishes to increase the size of text in an iframe or
other container element, the text may overflow the container. When text
overflows the size of a box and the attribute value is set so that the
overflow value is "hidden", the overflow text may not be displayed or
passed to the Assistive Technology. When the user has increased the
text size of the document, the 'overflow' value needs to default to
'scroll'.

HTML5 Comments from UAWG.rtf (37K) Download Attachment

Re: The progress element: wording issues with steps

2009-10-04T04:45:03Z

On Fri, 4 Sep 2009, T.J. Crowder wrote:
>
> <nit>
> "....results of parsing the textContent was nothing..." either "result" or
> "were nothing" but not "results...was nothing"
> </nit>

Fixed, thanks.

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

Re: Spec event wording suggestion.

2009-10-04T04:34:02Z

On Wed, 2 Sep 2009, Ric Hardacre wrote:

>
> Throughout the spec a phrase similar to the following is used (square
> brackets indicate link to simple event definition):
>
> "[fire a simple event] that bubbles called change at the element,"
>
>
> The english is hard to follow and I also suggest that "called" is replaced
> with "named" to remove some ambiguity about wether or not it is referring
> to "calling" a function:
>
> "fire a [bubbling simple event] named change at the element,"

I've changed 'called' to 'named' throughout.

> The definition of the simple event would not need changing to accomodate
> the above:
>
> "which does not bubble (unless otherwise stated)"

I haven't changed 'fire a simple event' to 'fire a bubbling simple event'
because there are so many axes that are affected, e.g. whether the event
is cancelable, what it's various attributes should be, etc.

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

Re: Where is processing of binary attributes covered?

2009-09-24T04:00:46Z

On 23 Sep 2009, at 21:48, Henry S. Thompson wrote:

> Philip Taylor writes:
>
>> In particular, the tokenizer state machine will result in a start tag
>> token with name "input" and with one attribute, which has name
>> "disabled" and value "banana". That feeds into the tree construction
>> algorithm, which will http://whatwg.org/html5#insert-an-html-element
>> which will http://whatwg.org/html5#create-an-element-for-the-token
>> which requires "the attributes on the node being those given in the
>> given token". No error recovery occurs while parsing this case. The
>> attributes in the DOM are (very nearly) always exactly what was in
>> the
>> input document.
>>
>> The only kind of error recovery in this case is that
>> http://whatwg.org/html5#concept-fe-disabled defines the element to be
>> disabled if the 'disabled' attribute exists on the element in the
>> DOM,
>> regardless of the attribute's value.
>
> Hmm. OK, I misunderstood. I thought that in general the DOM which
> resulted from parsing was 'conformant', i.e., would if serialized by a
> conformant document, but it appears I was mistaken.

This would make it impossible to degrade new stuff nicely. E.g.,
<input type=date>. I can in JS do something like:

var type = input.getAttribute("type") ?
input.getAttribute("type").toLowerCase() : "text";
if (input.type != type)
{
if (type == "date")
applyMagicJSDatePicker(input);
else if (type == "color")
applyMagicJSColourPicker(input);
[etc…]
}

If the DOM was always conformant, it would be impossible to do that,
and would make degrading gracefully in older UAs a lot harder.

--
Geoffrey Sneddon
<http://gsnedders.com/>

Re: What makes illegal characters non-conformant

2009-09-23T19:34:42Z

* Henry S. Thompson wrote:
>I don't think I have a problem with that, I can imagine an argument
>that it's broken (although http://www.ltg.ed.ac.uk/~ht/char_alias.xml
>is _not_ broken per the XML specification. . .), but I can't find
>anywhere in the HTML5 spec. which says so. Does it/should it?

It is not broken per the XML specification by the same reasoning that a
PNG image is not broken per the XML specification. Procedurally for both
cases the XML processor determines some character encoding and attempts
to decode the document, and then encounters byte sequences that do not
have a well-defined meaning according to the encoding's specification.
It is therefore not possible to restore the textual data the binary data
represents, and the XML specification only defines conformance for pro-
cessors and textual data objects.

Consider that the XML specification does not normatively define exactly
how to determine the character encoding (and I am ignoring that you've
used text/xml as media type for the document which has other theoretical
considerations rarely met in practise), so you can easily define a new
character encoding very-bogus-encoding as "Any sequence of bytes stands
for the text <?xml version='1.0' encoding='very-bogus-encoding'?><x/>"
and your document would be perfectly conforming if the processor does
indeed support that encoding.

Cases like this do in fact exist in the real world, for example, with
UTF-32 encoded documents the processor may not support UTF-32 and may
instead detect UTF-16 or UTF-8 and encounter illegal byte sequences or
disallowed characters. The only difference is in perception as UTF-32
is widely recognized while very-bogus-encoding is not.

It is ultimately entirely irrelevant whether your document is broken
per the XML specification as it is as far as common sense goes broken
per the US-ASCII specification. You might just as well have your web
server send out malformed TCP datagrams or a malformed HTTP response
and muse how that is or is not broken per unrelated specifications.
Similarily is very-bogus-encoding irrelevant because it violates what
is considered common sense. http://xkcd.com/468/ comes to mind.

(The XML specification actually considers your case a fatal error and
those are errors which in turn are violations of the constraints of the
specification, I've argued unsuccessfully against that in the past as
having specification violations dependant on processor capabilities is
a violation of common sense.)
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: Where is processing of binary attributes covered?

2009-09-23T13:48:32Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philip Taylor writes:

> In particular, the tokenizer state machine will result in a start tag
> token with name "input" and with one attribute, which has name
> "disabled" and value "banana". That feeds into the tree construction
> algorithm, which will http://whatwg.org/html5#insert-an-html-element
> which will http://whatwg.org/html5#create-an-element-for-the-token
> which requires "the attributes on the node being those given in the
> given token". No error recovery occurs while parsing this case. The
> attributes in the DOM are (very nearly) always exactly what was in the
> input document.
>
> The only kind of error recovery in this case is that
> http://whatwg.org/html5#concept-fe-disabled defines the element to be
> disabled if the 'disabled' attribute exists on the element in the DOM,
> regardless of the attribute's value.

Hmm. OK, I misunderstood. I thought that in general the DOM which
resulted from parsing was 'conformant', i.e., would if serialized by a
conformant document, but it appears I was mistaken.

ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, e-mail: ht@...
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFKuomokjnJixAXWBoRApniAJ4lCVIjJ2j+F7hwlIteaVNiuIZNxQCfbYeA
p12WtG+aLX8+13zLnewYBv0=
=awfk
-----END PGP SIGNATURE-----

Re: Where is processing of binary attributes covered?

2009-09-23T13:15:19Z

Henry S. Thompson wrote:

> Document conformance of binary attributes is clearly specified, in
> section 2.4.2, and means that conforming documents must include
> boolean attributes in only one of three forms, e.g. "disabled",
> "disabled=''" or "disabled='disabled'", and conformance checkers have
> to detect and signal failures to observe this constraint.
>
> What I can't find clearly stated is how this get into the DOM in the
> right way, and where, if at all, error recovery happens. So, to make
> this precise, What DOM is built for <input disabled=banana>, and why?
> That is, which sections in the spec. give a user agent the necessary
> information?

http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html
and subsequent pages define how the DOM is constructed. (It's stated
'clearly' in the sense that it's precise and unambiguous, though it's
not exceedingly easy to read...)

In particular, the tokenizer state machine will result in a start tag
token with name "input" and with one attribute, which has name
"disabled" and value "banana". That feeds into the tree construction
algorithm, which will http://whatwg.org/html5#insert-an-html-element
which will http://whatwg.org/html5#create-an-element-for-the-token which
requires "the attributes on the node being those given in the given
token". No error recovery occurs while parsing this case. The attributes
in the DOM are (very nearly) always exactly what was in the input document.

The only kind of error recovery in this case is that
http://whatwg.org/html5#concept-fe-disabled defines the element to be
disabled if the 'disabled' attribute exists on the element in the DOM,
regardless of the attribute's value.

--
Philip Taylor
pjt47@...