From tantek at cs.stanford.edu  Sun Aug  1 02:43:18 2010
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Sun, 1 Aug 2010 02:43:18 -0700
Subject: [whatwg] Please consider simplifying authoring guidance for the
	<img> alt attribute
Message-ID: <AANLkTin6bKoDf=y8nuLtgp1Urr+YG2ZSFZSTZQ0tQuo-@mail.gmail.com>

With acknowledgement of existing issues (e.g.
http://www.w3.org/html/wg/tracker/issues/80 ) on the topic:

Summary: Please consider simplifying authoring guidance for the <img>
alt attribute, such as dropping the document is an e-mail and meta
generator cases.

More details provided on the wiki:

http://wiki.whatwg.org/wiki/Img_Alt

I encourage fellow web authors to add opinions/comments.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From narendra at narendrasisodiya.com  Sun Aug  1 15:06:55 2010
From: narendra at narendrasisodiya.com (Narendra Sisodiya)
Date: Mon, 2 Aug 2010 03:36:55 +0530
Subject: [whatwg] Regarding Downloading a webpage.
Message-ID: <AANLkTi=Q7Fn-jYzE3u666ZsetOp3JX1UUSgySJbzTCfq@mail.gmail.com>

A html webpage can contains js, css, image files. If we leave the server
side scripting part then all resource files will static. JavaScript may load
a resource (like another js/image/css file or DataURI) dynamically.
If I want to download a webpage, I have to look at the source code of html
and also JavaScript code which may load otherfiles on user interaction.
Is their any specification exist by which i can tell 'webpage downloader'
application about 'list of all files which may be use under a give web
application' ?



-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100802/dca2a4aa/attachment.htm>

From lists at eitanadler.com  Sun Aug  1 16:46:32 2010
From: lists at eitanadler.com (Eitan Adler)
Date: Sun, 1 Aug 2010 19:46:32 -0400
Subject: [whatwg] Regarding Downloading a webpage.
In-Reply-To: <AANLkTi=Q7Fn-jYzE3u666ZsetOp3JX1UUSgySJbzTCfq@mail.gmail.com>
References: <AANLkTi=Q7Fn-jYzE3u666ZsetOp3JX1UUSgySJbzTCfq@mail.gmail.com>
Message-ID: <AANLkTi=EgB2PUXQThFhbBxkDN5-BhrqQRA0WHr3tbPQO@mail.gmail.com>

On Sun, Aug 1, 2010 at 6:06 PM, Narendra Sisodiya
<narendra at narendrasisodiya.com> wrote:
> A html webpage can contains js, css, image files. If we leave the server
> side scripting part then all resource files will static. JavaScript may load
> a resource (like another js/image/css file or DataURI) dynamically.
> If I want to download a webpage, I have to look at the source code of html
> and also JavaScript code which may load otherfiles on user interaction.
> Is their any specification exist by which i can tell 'webpage downloader'
> application about 'list of all files which may be use under a give web
> application' ?

Take a look at
http://www.w3.org/TR/html5/offline.html

Specifically
http://www.w3.org/TR/html5/offline.html#manifests





-- 
Eitan Adler

From chris at pearce.org.nz  Sun Aug  1 18:50:20 2010
From: chris at pearce.org.nz (Chris Pearce)
Date: Mon, 02 Aug 2010 13:50:20 +1200
Subject: [whatwg] Race condition in media load algorithm
Message-ID: <4C56245C.3080604@pearce.org.nz>

  There's a race condition in the media load algorithm. When the 
resource selection algorithm begins, it sets a task to complete the rest 
of the resource selection algorithm asynchronously. In the asynchronous 
task, we set the delaying-the-load-event flag to true at step 4. But 
between the resource selection algorithm setting the task to 
asynchronously continue the algorithm, and the task actually running, 
the load event could fire, before we have a chance to set the 
delaying-the-load-event flag to true. I suggest we set the 
delaying-the-load-event flag to true before we set the task to continue 
the rest of the resource selection algorithm asynchronously.

Chris Pearce.

From tantek at cs.stanford.edu  Sun Aug  1 18:59:34 2010
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Sun, 1 Aug 2010 18:59:34 -0700
Subject: [whatwg] Please consider dropping the "sandbox" attribute from the
	<iframe> element
Message-ID: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com>

Summary: The new 'sandbox' feature on <iframe> should be considered
for removal. It needs a security review, it will be a lot of work to
implement properly, and may not actually solve the problem it is
intending to solve.

More details here:

http://wiki.whatwg.org/wiki/Iframe_Sandbox

I encourage fellow web authors and browser implementers to add their
opinions/comments to that wiki page.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From ifette at google.com  Sun Aug  1 19:08:22 2010
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Sun, 1 Aug 2010 19:08:22 -0700
Subject: [whatwg] Please consider dropping the "sandbox" attribute from
	the <iframe> element
In-Reply-To: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com>
References: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com>
Message-ID: <AANLkTimtaHQ7gGC=ST+UUZrN26k0RtJs0h5o9WHat66Y@mail.gmail.com>

We (webkit/chrome) have had iframe sandbox implemented for over half a year.
We've found some bugs in implementation here and there and fixed them. It
solves a very real problem, has already been implemented, and your argument
provides absolutely no information. Can you elaborate?

On Sun, Aug 1, 2010 at 6:59 PM, Tantek ?elik <tantek at cs.stanford.edu> wrote:

> Summary: The new 'sandbox' feature on <iframe> should be considered
> for removal. It needs a security review, it will be a lot of work to
> implement properly, and may not actually solve the problem it is
> intending to solve.
>
> More details here:
>
> http://wiki.whatwg.org/wiki/Iframe_Sandbox
>
> I encourage fellow web authors and browser implementers to add their
> opinions/comments to that wiki page.
>
> Thanks!
>
> Tantek
>
> --
> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100801/c97b4c42/attachment.htm>

From w3c at adambarth.com  Sun Aug  1 21:31:26 2010
From: w3c at adambarth.com (Adam Barth)
Date: Sun, 1 Aug 2010 21:31:26 -0700
Subject: [whatwg] Please consider dropping the "sandbox" attribute from
	the <iframe> element
In-Reply-To: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com>
References: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com>
Message-ID: <AANLkTikeux7kuZfRX2CJsstnj1ahfvmuDY1ZGyaPWDWk@mail.gmail.com>

There's been a lot of security review, both on this list and in the
W3C HTML WG.  I've been meaning to write up a summary of all the
discussion, but I haven't gotten around to it yet.  We ended up
tweaking a few aspects, but generally the design seems solid.

Adam


On Sun, Aug 1, 2010 at 6:59 PM, Tantek ?elik <tantek at cs.stanford.edu> wrote:
> Summary: The new 'sandbox' feature on <iframe> should be considered
> for removal. It needs a security review, it will be a lot of work to
> implement properly, and may not actually solve the problem it is
> intending to solve.
>
> More details here:
>
> http://wiki.whatwg.org/wiki/Iframe_Sandbox
>
> I encourage fellow web authors and browser implementers to add their
> opinions/comments to that wiki page.
>
> Thanks!
>
> Tantek
>
> --
> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
>

From narendra at narendrasisodiya.com  Sun Aug  1 22:25:15 2010
From: narendra at narendrasisodiya.com (Narendra Sisodiya)
Date: Mon, 2 Aug 2010 10:55:15 +0530
Subject: [whatwg] Regarding Downloading a webpage.
In-Reply-To: <AANLkTi=EgB2PUXQThFhbBxkDN5-BhrqQRA0WHr3tbPQO@mail.gmail.com>
References: <AANLkTi=Q7Fn-jYzE3u666ZsetOp3JX1UUSgySJbzTCfq@mail.gmail.com>
	<AANLkTi=EgB2PUXQThFhbBxkDN5-BhrqQRA0WHr3tbPQO@mail.gmail.com>
Message-ID: <AANLkTinC34h4aE8TLvGTb_Pw1oUG5sQ+ULNy2qhJg6OQ@mail.gmail.com>

On Mon, Aug 2, 2010 at 5:16 AM, Eitan Adler <lists at eitanadler.com> wrote:

>
> Specifically
> http://www.w3.org/TR/html5/offline.html#manifests
>

Got it .. I was looking for it,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100802/f26a3391/attachment.htm>

From narendra at narendrasisodiya.com  Mon Aug  2 00:00:52 2010
From: narendra at narendrasisodiya.com (Narendra Sisodiya)
Date: Mon, 2 Aug 2010 12:30:52 +0530
Subject: [whatwg] [OT] OpenWebIndia
Message-ID: <AANLkTim3jrQagx44arEbbsJWdBO5TWth4L5bdbnU2YK7@mail.gmail.com>

We are trying to collect Indian Developer who would like participate on
HTML5/openweb discussion and start community workshop in India for advocacy
for html5-related technologies.
Thanks
http://mail.openwebindia.org/mailman/listinfo/openwebindia_openwebindia.org

-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100802/366d7d87/attachment.htm>

From ian at hixie.ch  Mon Aug  2 02:17:55 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 2 Aug 2010 09:17:55 +0000 (UTC)
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C56245C.3080604@pearce.org.nz>
References: <4C56245C.3080604@pearce.org.nz>
Message-ID: <Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>

On Mon, 2 Aug 2010, Chris Pearce wrote:
>
> There's a race condition in the media load algorithm. When the resource 
> selection algorithm begins, it sets a task to complete the rest of the 
> resource selection algorithm asynchronously.

Not quite. It awaits a stable state and then runs a synchronous section, 
which means that it will run the subsequent steps as soon as the current 
task has finished, before anything else that is queued.

Thus:

> In the asynchronous task, we set the delaying-the-load-event flag to 
> true at step 4. But between the resource selection algorithm setting the 
> task to asynchronously continue the algorithm, and the task actually 
> running, the load event could fire

...the load event couldn't fire, because the load event is queued as a 
task, which will execute at the earliest _after_ the synchronous section 
has run (unless the task was queued before the task in which the resource 
selection algorithm was invoked started, of course). I don't think there's 
anything defined that delays the load event which can finish without a 
task executing. (And even if there was, moving this particular step around 
wouldn't change things other than theoretically making the race condition 
window a bit smaller.)

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

From jeremy at adactio.com  Mon Aug  2 03:31:31 2010
From: jeremy at adactio.com (Jeremy Keith)
Date: Mon, 2 Aug 2010 11:31:31 +0100
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <op.vgnjqqx448yz2f@dennis>
References: <op.vgnjqqx448yz2f@dennis>
Message-ID: <60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>

Dennis wrote:
> I have an idea which would be very cool for HTML5.
> 
> Having a Content-Disposition property on <a> tags which does the same as
> the HTTP Header.
> For example changing the file name of the file to be downloaded or rather
> have a image
> file download rather than it being shown in the browser directly.

Hang on... isn't the mechanism for this already available via the "type" attribute?

For example:

<a href="/path/to/image.jpg" type="image/jpeg">Full size image</a>

A browser could offer a preference setting, for example:

"Always download the following types of files, rather than opening in the browser:

* images	[x]
* movies		[  ]
...etc."

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From ben.schwarz at gmail.com  Mon Aug  2 03:45:57 2010
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Mon, 2 Aug 2010 20:45:57 +1000
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
Message-ID: <AANLkTinzh2EDEMNto4JY-P-33pBe4HjbZ2Wmw9YvmrAb@mail.gmail.com>

I'm really not too sure what pre-existing problem this actually solves.
Given that a server sets the correct mime-types for a given resource, we
know what "type" it is already.

Setting the Content-disposition on the client side creates an annoying user
experience.

If I want to open a link in a new tab, window or download, I'll do it like I
have done for the last ten years?via a keyboard modifier or a contextual
menu.

On Mon, Aug 2, 2010 at 8:31 PM, Jeremy Keith <jeremy at adactio.com> wrote:

> Dennis wrote:
> > I have an idea which would be very cool for HTML5.
> >
> > Having a Content-Disposition property on <a> tags which does the same as
> > the HTTP Header.
> > For example changing the file name of the file to be downloaded or rather
> > have a image
> > file download rather than it being shown in the browser directly.
>
> Hang on... isn't the mechanism for this already available via the "type"
> attribute?
>
> For example:
>
> <a href="/path/to/image.jpg" type="image/jpeg">Full size image</a>
>
> A browser could offer a preference setting, for example:
>
> "Always download the following types of files, rather than opening in the
> browser:
>
> * images        [x]
> * movies                [  ]
> ...etc."
>
> --
> Jeremy Keith
>
> a d a c t i o
>
> http://adactio.com/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100802/e1307acf/attachment.htm>

From mjs at apple.com  Mon Aug  2 06:41:46 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Mon, 02 Aug 2010 06:41:46 -0700
Subject: [whatwg] Please consider dropping the "sandbox" attribute from
 the <iframe> element
In-Reply-To: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com>
References: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com>
Message-ID: <1541D39E-A9B6-4F26-96C6-10A3BFD4B7C0@apple.com>


On Aug 1, 2010, at 6:59 PM, Tantek ?elik wrote:

> Summary: The new 'sandbox' feature on <iframe> should be considered
> for removal. It needs a security review, it will be a lot of work to
> implement properly, and may not actually solve the problem it is
> intending to solve.
> 
> More details here:
> 
> http://wiki.whatwg.org/wiki/Iframe_Sandbox
> 
> I encourage fellow web authors and browser implementers to add their
> opinions/comments to that wiki page.

As other have mentioned, <iframe sandbox> has been implemented in WebKit for some time. Additional points of information:

1) It's shipping in current versions of Safari and Chrome.
2) Security experts have reviewed it. @sandbox itself seems pretty solid, although there are possibly issues with related features such as text/html-sandboxed and @seamless.
3) Content has been built using it.
4) While it's unclear if <iframe sandbox> will work well for comments or other such cases of seamless untrusted content, it seems clearly useful for use cases like gadgets and ads.

While more security review is always welcome, it seems like the basic idea is solid, and it's demonstrably implementable. The initial patch implementing it for WebKit can be seen here: <http://trac.webkit.org/changeset/51577>. This patch was 100k, but more than half of it is tests and the ChangeLog entry.

Regards,
Maciej


From and-py at doxdesk.com  Mon Aug  2 07:36:46 2010
From: and-py at doxdesk.com (And Clover)
Date: Mon, 02 Aug 2010 16:36:46 +0200
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>	<4BD5C792.7050106@davidflanagan.com>	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
Message-ID: <4C56D7FE.7000705@doxdesk.com>

On 07/30/2010 06:43 AM, Oliver Hunt wrote:
> all array functions defined in ES5 are "generic" in that they work
> over any array-like object.

They're guaranteed to work over any array-like native JavaScript object. 
They're *not* guaranteed to work on host objects like the various node 
lists.

FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on 
the modern desktop browsers except for IE.

It would be possible to specify that the native-JS object guarantee 
should also extend to node lists. This would allow fast browser 
implementations of the array-like methods to be used without having to 
copy to a new Array. However this would still leave the method of 
calling them a little ugly.

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/

From bzbarsky at MIT.EDU  Mon Aug  2 08:10:38 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 02 Aug 2010 11:10:38 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
Message-ID: <4C56DFEE.3040602@mit.edu>

On 8/2/10 5:17 AM, Ian Hickson wrote:
>> There's a race condition in the media load algorithm. When the resource
>> selection algorithm begins, it sets a task to complete the rest of the
>> resource selection algorithm asynchronously.
>
> Not quite. It awaits a stable state and then runs a synchronous section,
> which means that it will run the subsequent steps as soon as the current
> task has finished, before anything else that is queued.

So the model is that there are asynchronous tasks but there are also 
things that run after the "current asynchronous task" finishes?

How are we defining "current asynchronous task" and "finish"?  How does 
this setup handle cases when the "current asynchronous task" spins the 
event loop, if at all?

-Boris

From dennis at efjot.de  Mon Aug  2 09:05:53 2010
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Mon, 02 Aug 2010 18:05:53 +0200
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
Message-ID: <op.vgtiz3g048yz2f@dennis>

Jeremy Keith <jeremy at adactio.com> wrote:

> Dennis wrote:
>> ...
> Hang on... isn't the mechanism for this already available via the "type"  
> attribute?
>
> For example:
>
> <a href="/path/to/image.jpg" type="image/jpeg">Full size image</a>

That wouldn't help in this case...

> A browser could offer a preference setting, for example:
>
> "Always download the following types of files, rather than opening in  
> the browser:
>
> * images	[x]
> * movies		[  ]
> ...etc."

Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings. Maybe it would do if the type was set to
application/octet-stream, since those, by default, always get downloaded.

From dennis at efjot.de  Mon Aug  2 09:09:40 2010
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Mon, 02 Aug 2010 18:09:40 +0200
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <AANLkTinzh2EDEMNto4JY-P-33pBe4HjbZ2Wmw9YvmrAb@mail.gmail.com>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<AANLkTinzh2EDEMNto4JY-P-33pBe4HjbZ2Wmw9YvmrAb@mail.gmail.com>
Message-ID: <op.vgti6etk48yz2f@dennis>

Ben Schwarz <ben.schwarz at gmail.com> wrote:

> I'm really not too sure what pre-existing problem this actually solves.
> Given that a server sets the correct mime-types for a given resource, we
> know what "type" it is already.

Yes, since we don't want to set MIME-Types. I want to be able to set
what a file actually is. Is it a file which is supposed to be shown in
the browser? Or is it an "attachment" (refering to the content-disposition
setting)

> Setting the Content-disposition on the client side creates an annoying  
> user
> experience.

I don't think so. What would you rather have?

<download>
(Please right click and save target as)

or

<download>

> If I want to open a link in a new tab, window or download, I'll do it  
> like I
> have done for the last ten years?via a keyboard modifier or a contextual
> menu.

No problem with what you want to have, but can't webmasters ALREADY set the
content-disposition? I just want to copy this functionality over to the  
client
to prevent that you always have to use a scripting language server-side.

> On Mon, Aug 2, 2010 at 8:31 PM, Jeremy Keith <jeremy at adactio.com> wrote:
>
>> ...

From mkozakewich at icosidodecahedron.com  Mon Aug  2 09:21:52 2010
From: mkozakewich at icosidodecahedron.com (Michael Kozakewich)
Date: Mon, 2 Aug 2010 11:21:52 -0500
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <op.vgtiz3g048yz2f@dennis>
References: <op.vgnjqqx448yz2f@dennis><60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
Message-ID: <0097F4E418EA47BBAF9C9433340158C6@NETBOOK>

>> Dennis wrote:
> Yes, but that wouldn't help since I want to force downloads regardless
> of the browser settings. Maybe it would do if the type was set to
> application/octet-stream, since those, by default, always get downloaded.

People don't often like it when they're forced to do something. If they want
to download it, they can select "Save Link As..." from their browser. If
they actually want to view it full-screen, they don't want to be forced to
download it.

I see where you're coming from, but we try not to force users to do things.
For the same reason, @target was removed from links.
 


From jeremy at adactio.com  Mon Aug  2 09:22:31 2010
From: jeremy at adactio.com (Jeremy Keith)
Date: Mon, 2 Aug 2010 17:22:31 +0100
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <op.vgtiz3g048yz2f@dennis>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
Message-ID: <C03ACBC9-542D-4937-A475-EFBC9C007E2A@adactio.com>

Dennis wrote:
> Yes, but that wouldn't help since I want to force downloads regardless
> of the browser settings.

Ah, I see. In that case, I fundamentally disagree with what you are asking for. Final control should be in the hands of the user, not the author.

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From ash at ashleysheridan.co.uk  Mon Aug  2 09:29:00 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Mon, 02 Aug 2010 17:29:00 +0100
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <op.vgti6etk48yz2f@dennis>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<AANLkTinzh2EDEMNto4JY-P-33pBe4HjbZ2Wmw9YvmrAb@mail.gmail.com>
	<op.vgti6etk48yz2f@dennis>
Message-ID: <1280766540.6111.26.camel@localhost>

On Mon, 2010-08-02 at 18:09 +0200, Dennis Joachimsthaler wrote:

> Ben Schwarz <ben.schwarz at gmail.com> wrote:
> 
> > I'm really not too sure what pre-existing problem this actually solves.
> > Given that a server sets the correct mime-types for a given resource, we
> > know what "type" it is already.
> 
> Yes, since we don't want to set MIME-Types. I want to be able to set
> what a file actually is. Is it a file which is supposed to be shown in
> the browser? Or is it an "attachment" (refering to the content-disposition
> setting)
> 
> > Setting the Content-disposition on the client side creates an annoying  
> > user
> > experience.
> 
> I don't think so. What would you rather have?
> 
> <download>
> (Please right click and save target as)
> 
> or
> 
> <download>
> 


Which can easily be done with sever-side code. It's still annoying for
the end user when things like this happen though. For example, who do
you know that hasn't turned off whatever PDF browser plugin has been
installed along with their Acrobat Reader?

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100802/abdd6319/attachment-0001.htm>

From jackalmage at gmail.com  Mon Aug  2 09:49:09 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 2 Aug 2010 09:49:09 -0700
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com> 
	<op.vgtiz3g048yz2f@dennis> <0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
Message-ID: <AANLkTikTX2Ki9YQ5f7gn7PEoEHP8X+vc1G8dQBJjtifp@mail.gmail.com>

On Mon, Aug 2, 2010 at 9:21 AM, Michael Kozakewich
<mkozakewich at icosidodecahedron.com> wrote:
>>> Dennis wrote:
>>
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings. Maybe it would do if the type was set to
>> application/octet-stream, since those, by default, always get downloaded.
>
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser. If
> they actually want to view it full-screen, they don't want to be forced to
> download it.
>
> I see where you're coming from, but we try not to force users to do things.
> For the same reason, @target was removed from links.

@target was not removed from links.  HTML4 Strict removed it, but
HTML5 rightly added it back because it has useful functionality.

~TJ

From oliver at apple.com  Mon Aug  2 09:51:22 2010
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Aug 2010 09:51:22 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <4C56D7FE.7000705@doxdesk.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
	<4C56D7FE.7000705@doxdesk.com>
Message-ID: <ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>


On Aug 2, 2010, at 7:36 AM, And Clover wrote:

> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>> all array functions defined in ES5 are "generic" in that they work
>> over any array-like object.
> 
> They're guaranteed to work over any array-like native JavaScript object. They're *not* guaranteed to work on host objects like the various node lists.

Uhhh, I have no idea what you're talking about -- there are no type checks in any of the array prototype functions, they all operate in terms of property access alone, all the methods we're talking about basically start out like this:

1.	Let O be the result of calling ToObject passing the this value as the argument. 
2.	Let lenValue be the result of calling the [[Get]] internal method of O with the argument "length". 
3.	Let len be ToUint32(lenValue). 
4.	If IsCallable(callbackfn) is false, throw a TypeError exception. 
5.	If thisArg was supplied, let T be thisArg; else let T be undefined. 
6.	Let k be 0.
7.	Repeat, while k < len
 ....

Eg. "array-like" in the context of ES5 should be interpreted as "has a property named 'length', the array methods will work on any type.

> 
> FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the modern desktop browsers except for IE.
> 
> It would be possible to specify that the native-JS object guarantee should also extend to node lists. This would allow fast browser implementations of the array-like methods to be used without having to copy to a new Array. However this would still leave the method of calling them a little ugly.

As above there is no question of it being possible -- the spec behaviour makes no exceptions for host vs. native object types.  If IE has a bug, then IE has a bug, that doesn't change the spec.

--Oliver


From kornel at geekhood.net  Mon Aug  2 09:53:24 2010
From: kornel at geekhood.net (=?utf-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Mon, 2 Aug 2010 17:53:24 +0100
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
References: <op.vgnjqqx448yz2f@dennis><60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
	<0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
Message-ID: <C90AAA8E-80DA-475D-BA3E-898268C79509@geekhood.net>

On 2 Aug 2010, at 17:21, Michael Kozakewich wrote:

>>> Dennis wrote:
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings. Maybe it would do if the type was set to
>> application/octet-stream, since those, by default, always get downloaded.
> 
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser. If
> they actually want to view it full-screen, they don't want to be forced to
> download it.
> 
> I see where you're coming from, but we try not to force users to do things.
> For the same reason, @target was removed from links.

I agree that it's not good to force users in general. However, this attribute can be implemented only as a hint for browsers to display Open/Save dialog. Users wouldn't be forced to download the file, it would just be easier for them to download.

OTOH users may be annoyed when their browser isn't saving some types of documents by default (and whether certain type of file should be viewed inline or saved might depend on context, e.g., I may want to read PDF booklets in the browser, but would prefer to save PDF receipts and tickets).

If Content-Disposition was attribute on <a>, then webmasters could easily offer right option (or both) where it makes sense.

Downloads can be "forced" already with Content-Disposition: attachment. It's just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular PHP snippets for forcing download are among the most disgusting cargo-cult code I've ever seen ? they're collection of self-contradictory and nonsensical HTTP headers, break caching and resuming, and often have security vulnerabilities.

It would be great if we could obsolete those scripts.

-- 
regards, Kornel


From jackalmage at gmail.com  Mon Aug  2 09:56:33 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 2 Aug 2010 09:56:33 -0700
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <C90AAA8E-80DA-475D-BA3E-898268C79509@geekhood.net>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com> 
	<op.vgtiz3g048yz2f@dennis> <0097F4E418EA47BBAF9C9433340158C6@NETBOOK> 
	<C90AAA8E-80DA-475D-BA3E-898268C79509@geekhood.net>
Message-ID: <AANLkTimdCE+p0bUKF1BNO9udH96t2_OkFwAKtGcPyvA2@mail.gmail.com>

2010/8/2 Kornel Lesi?ski <kornel at geekhood.net>:
> Downloads can be "forced" already with Content-Disposition: attachment. It's just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular PHP snippets for forcing download are among the most disgusting cargo-cult code I've ever seen ? they're collection of self-contradictory and nonsensical HTTP headers, break caching and resuming, and often have security vulnerabilities.
>
> It would be great if we could obsolete those scripts.

Indeed; I've used those code samples, and since the entire area is
basically voodoo to me, I still have no idea which headers I sent did
anything and which are useless or even harmful cruft.  In general,
even well-educated authors have no clue what they're doing here.

~TJ

From dennis at efjot.de  Mon Aug  2 10:00:49 2010
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Mon, 02 Aug 2010 19:00:49 +0200
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <C03ACBC9-542D-4937-A475-EFBC9C007E2A@adactio.com>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
	<C03ACBC9-542D-4937-A475-EFBC9C007E2A@adactio.com>
Message-ID: <op.vgtljnea48yz2f@dennis>

Jeremy Keith <jeremy at adactio.com> wrote:

> Dennis wrote:
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings.
>
> Ah, I see. In that case, I fundamentally disagree with what you are  
> asking for. Final control should be in the hands of the user, not the  
> author.
>

Don't we already force many things on the user? Of course they can control
everything but nobody really knows what happens in the deep javascript of
any page except for the author or other authors if the JS is not  
obfuscated.

I want to force for convenience. This doesn't mean that web masters should  
not
provide a different way of visiting said content.

It was meant for download pages which often struggle with redirects which
directly open in the browser window.

Or picture galleries, saves you a few clicks. Or any other browser-opened
content like Adobe Flash, PDF of course, insert anything here.

From dennis at efjot.de  Mon Aug  2 10:03:03 2010
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Mon, 02 Aug 2010 19:03:03 +0200
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <C90AAA8E-80DA-475D-BA3E-898268C79509@geekhood.net>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
	<0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
	<C90AAA8E-80DA-475D-BA3E-898268C79509@geekhood.net>
Message-ID: <op.vgtlnduf48yz2f@dennis>

Kornel Lesi?ski <kornel at geekhood.net> wrote:

> On 2 Aug 2010, at 17:21, Michael Kozakewich wrote:
> I agree that it's not good to force users in general. However, this  
> attribute can be implemented only as a hint for browsers to display  
> Open/Save dialog. Users wouldn't be forced to download the file, it  
> would just be easier for them to download.
>
> OTOH users may be annoyed when their browser isn't saving some types of  
> documents by default (and whether certain type of file should be viewed  
> inline or saved might depend on context, e.g., I may want to read PDF  
> booklets in the browser, but would prefer to save PDF receipts and  
> tickets).
>
> If Content-Disposition was attribute on <a>, then webmasters could  
> easily offer right option (or both) where it makes sense.
>
> Downloads can be "forced" already with Content-Disposition: attachment.  
> It's just harder to do, and unfortunately that doesn't stop webmasters  
> from trying. Popular PHP snippets for forcing download are among the  
> most disgusting cargo-cult code I've ever seen ? they're collection of  
> self-contradictory and nonsensical HTTP headers, break caching and  
> resuming, and often have security vulnerabilities.
>
> It would be great if we could obsolete those scripts.
>

Thank you, this is exactly what I was trying to say. To "force" was maybe
the wrong word.

From derernst at gmx.ch  Mon Aug  2 10:07:01 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Mon, 02 Aug 2010 19:07:01 +0200
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
References: <op.vgnjqqx448yz2f@dennis><60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>	<op.vgtiz3g048yz2f@dennis>
	<0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
Message-ID: <4C56FB35.3000103@gmx.ch>

Am 02.08.2010 18:21 schrieb Michael Kozakewich:
>>> Dennis wrote:
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings. Maybe it would do if the type was set to
>> application/octet-stream, since those, by default, always get downloaded.
> 
> People don't often like it when they're forced to do something. If they 
> want
> to download it, they can select "Save Link As..." from their browser. If
> they actually want to view it full-screen, they don't want to be forced to
> download it.
> 
> I see where you're coming from, but we try not to force users to do things.
> For the same reason, @target was removed from links.

But it has made it back into HTML5:
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element

I assume the reason is that some de-facto standards have established 
that users have got used to.

One of them seems to be that clicking on an external link in a corporate 
web site usually opens a new window or tab, whatever they set in their 
browser prefs. Some users (like me) might forget to hold the ctrl key 
because most corporate websites use target="_blank" anyway on all 
external links, and get annoyed if the original page disappears and they 
have to go back their session history.

Another de-facto expectation could be, that on a "download" page with 
several links, they behave consistently, starting a download:

<h1>Press downloads</h1>
<ul>
   <li><a href="portrait.jpg">Portrait image (JPG)</a></li>
   <li><a href="band-photo.tif">My band (TIFF)</a></li>
   <li><a href="cv.pdf">Curriculum vitae (PDF)</a></li>
   <li><a href="discography.xls">Discography (Excel File)</a></li>
</ul>

Every link is likely to invoke an other default action, which does not 
seem consistent to me in this context - even if the downloading 
journalist as an experienced user might be able to anticipate the action 
based on the file type information in the brackets. Dennis' and Roger's 
proposal would definitely be helpful here.

From Simetrical+w3c at gmail.com  Mon Aug  2 10:15:52 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 2 Aug 2010 13:15:52 -0400
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
	<0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
Message-ID: <AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com>

On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich
<mkozakewich at icosidodecahedron.com> wrote:
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser.

If the author can predict that the user probably wants to do this
(like because they just clicked on a button that says "Save"), they
should be able to trigger it directly.  This isn't to say that the
user must be *forced* to do it -- if authors use this annoyingly,
browsers will compete on providing UI to avoid the annoyance.  As with
anything UI-related in specs, it would just serve as a hint or
guideline, not an iron-clad command that all browsers must obey to the
letter.

> I see where you're coming from, but we try not to force users to do things.

Let's say you have an image editor, written using canvas and whatnot.
You want to have similar UI to native image editors, and that includes
a "Save" button (probably adorned with a little picture of a 3.5"
floppy, which is amusing when you think about it).  Clicking the
"Save" button should pop up a dialog like in a native app, asking you
where to save it.  Currently this can be done, but you have to send a
request to the server and get a Content-Disposition: attachment
response.  Probably you have to do it in a hidden iframe so it doesn't
navigate the whole page, etc.  The request is for some feature to do
this without the rigamarole.

If you don't agree that this use-case is worth adding the feature for,
do you think that:

1) The status quo is fine: you should have to send a request to the
server to implement a "Save" button.  Offline image-editing apps don't
matter.  Probably not a popular attitude here.

2) You (the app author) shouldn't even be able to do that.  You should
have to say "Right-click and choose 'Save As'".  Except that of course
this is less convenient for the user, it takes up more space in the
UI, the option might not be named the same thing in all browsers, apps
might want to make right-click do something else so that context menus
don't work, there are plenty of platforms (like phones) where "right
click" doesn't even make sense, and in general the web platform makes
no UI guarantees at all.  So then we get multipage guides explaining
how to do it in a handful of popular browsers, with images and
step-by-step instructions like
<http://www.wikihow.com/Clear-Your-Browser's-Cache>, and unpopular
browser users get to figure it out themselves.

3) Something else?

All in all, this seems like a very straightforward, useful thing to
ask for.  Yes, users can do it through browser UI, but that doesn't
permit authors to present it in a consistent way, draw the user's
attention to it, put it where the user will expect it in context, etc.
 It's very similar to print(): of course the user can just hit Ctrl-P,
but some people are used to clicking "Print" buttons and will be
puzzled and unhappy if they don't find one.

Not everyone will try to think of alternative ways to perform a task
when their initial expectation fails.  That's the point where a lot of
people give up, or call their techy friends or relatives for help.
Many people use computers by rote, and don't know what to do when the
usual incantation fails.  Even for those of us who know better, it's
can be more convenient if the application has more control, so they we
don't *have* to manually click through menus when the app can do it
for us.

From bzbarsky at MIT.EDU  Mon Aug  2 10:37:47 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 02 Aug 2010 13:37:47 -0400
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com>
References: <op.vgnjqqx448yz2f@dennis>	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>	<op.vgtiz3g048yz2f@dennis>	<0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
	<AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com>
Message-ID: <4C57026B.2020806@mit.edu>

On 8/2/10 1:15 PM, Aryeh Gregor wrote:
> If you don't agree that this use-case is worth adding the feature for,
> do you think that:
> 3) Something else?

For the use case your describe, it might just make more sense for 
browsers to support Content-Disposition on data: URIs directly 
somehow...  Maybe.

-Boris

From derernst at gmx.ch  Mon Aug  2 08:19:10 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Mon, 02 Aug 2010 17:19:10 +0200
Subject: [whatwg] Please consider simplifying authoring guidance for the
 <img> alt attribute
In-Reply-To: <AANLkTin6bKoDf=y8nuLtgp1Urr+YG2ZSFZSTZQ0tQuo-@mail.gmail.com>
References: <AANLkTin6bKoDf=y8nuLtgp1Urr+YG2ZSFZSTZQ0tQuo-@mail.gmail.com>
Message-ID: <4C56E1EE.1030304@gmx.ch>

Am 01.08.2010 11:43 schrieb Tantek ?elik:
> http://wiki.whatwg.org/wiki/Img_Alt
> 
> I encourage fellow web authors to add opinions/comments.

My personal opinion on the alt attribute is that:
- it should only be used if the image is crucial for understanding the 
content, or for navigation (such as headline or link images or charts)
- it's absence should default to what is alt="" in HTML4
- search engines should generally ignore text in the alt attribute, but 
evaluate the title attribute instead

Rationale:

4.8.1.1.12 says: "A corollary to this is that the alt attribute's value 
should never contain text that could be considered the image's caption, 
title, or legend. It is supposed to contain replacement text that could 
be used by users instead of the image; it is not meant to supplement the 
image. The title attribute can be used for supplemental information."

The most common use cases of @alt are (at least as far as I know from my 
authoring practise):
- Insert the text contained in a headline or link image
- Insert an empty string to make the page validate
- Insert a short description of the image, preferably containing some 
keywords for search engines; sometimes the search engine aspect is 
weighted even higher than the contents of the image here

Only the first one of these use cases matches the gideline given in 
4.8.1.1.12. The second one is not harmful, exept some minimal bandwidth 
impact. But the third one is actually counterproductive with regard to 
accessibility.

An image which conveys information, if it is not a text replacement 
(such as a headline or link image), a corporate logo, or some kind of 
chart, is usually almost impossible to describe in a way that can't be 
considered the image's caption, title, or legend. Usually, the 
information conveyed by the image is either duplicated in the text that 
the image is associated to (or in it's caption or legend), or at all 
useless for anybody that does not see the image. Either way, the 
presence of an alt text does not provide useful information, but 
possibly confuses - specially if it is written with regard to search 
engines.

I am confident that declaring the alt attribute as optional would not 
only simplify the spec and validation, but also have no significant 
effect regarding accessibility, as poor authoring cannot really be 
prevented by structural means.

And I am also confident that if search engines ignored the alt 
attribute, and authors were encouraged to only insert alt text if helps 
to understand the content, this would have a positive effect on 
accessibility, as authors would be discouraged to put unnecessary 
information in the alt attribute for seo purposes, or duplicate the 
legend or caption (what I used to do before I read 4.8.1.1.12, because 
HTML4 seemed to require exactly this).

From nzakas at yahoo-inc.com  Mon Aug  2 11:23:46 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Mon, 2 Aug 2010 11:23:46 -0700
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com>
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com>
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com>
Message-ID: <B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>

If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present.

Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. 

I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way.

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: Scott Hess [mailto:shess at google.com] 
Sent: Friday, July 30, 2010 5:05 PM
To: Nicholas Zakas
Cc: Jeremy Orlow; Alexandre Morgaut; whatwg at lists.whatwg.org; Jonas Sicking
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> And I totally agree, this is not a strong security feature, and that's not
> the intent. The intent is just to give an extra measure of control of the
> lifetime of the data to bring Web Storage closer to being a replacement for
> a wider range of functionality that currently uses cookies.

I don't think this really follows.  Cookies were invented quite awhile
ago, and may not be a good model for development.  A reasonably small
dataset allows the client to expire cookies aggressively.  With large
local storage, doing per-item expiration is not a good idea - you do
not want your UA groveling through a gig of data you are not otherwise
using to expire a couple dozen items.  Per-database expiration might
make sense, because the expiration information could be stored in a
central location as a hint to the UA (if the site isn't going to use
the data after two weeks, might as well delete it).  Sites could
segment their expiration needs by using multiple data stores.

That said, idle storage is eventually going to be reclaimed anyhow, so
you could just ignore the problem.  Current storage proposals are much
richer than cookies, so the developer could just store dates alongside
their other data and make the decisions directly, no need for the
system to help.  Since the JavaScript accessing the data is executing
right next to the data, you don't have the latency issues
client/server communication introduces.  So long as expiration is a
SHOULD, its not clear to me that this idiom is powerful enough to
deserve footprint in the spec.

-scott

From ash at ashleysheridan.co.uk  Mon Aug  2 11:54:41 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Mon, 02 Aug 2010 19:54:41 +0100
Subject: [whatwg] Please consider simplifying authoring guidance for the
 <img> alt attribute
In-Reply-To: <4C56E1EE.1030304@gmx.ch>
References: <AANLkTin6bKoDf=y8nuLtgp1Urr+YG2ZSFZSTZQ0tQuo-@mail.gmail.com>
	<4C56E1EE.1030304@gmx.ch>
Message-ID: <1280775281.2323.7.camel@localhost>

On Mon, 2010-08-02 at 17:19 +0200, Markus Ernst wrote:

> - search engines should generally ignore text in the alt attribute,
> but 
> evaluate the title attribute instead
> 
> Rationale:
> 
> 4.8.1.1.12 says: "A corollary to this is that the alt attribute's
> value 
> should never contain text that could be considered the image's
> caption, 
> title, or legend. It is supposed to contain replacement text that
> could 
> be used by users instead of the image; it is not meant to supplement
> the 
> image. The title attribute can be used for supplemental information."


What you said doesn't make sense. The alt text is to be used instead of
the image, and the title is for supplemental content. Therefore, search
engines should use alt text, as that is what they are attempting to
convey in the lost (in the sense that search engines don't process
images like they do text) image. If they used the title, one can only
imagine the trouble.



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100802/9a3b3d3a/attachment.htm>

From ian at hixie.ch  Mon Aug  2 12:11:53 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 2 Aug 2010 19:11:53 +0000 (UTC)
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C56DFEE.3040602@mit.edu>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C56DFEE.3040602@mit.edu>
Message-ID: <Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>

On Mon, 2 Aug 2010, Boris Zbarsky wrote:
> 
> So the model is that there are asynchronous tasks but there are also 
> things that run after the "current asynchronous task" finishes?

It's a little more detailed than that, but yes, that describes the event 
loop model.


> How are we defining "current asynchronous task" and "finish"?

In terms of the event loop algorithm:

   http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2


> How does this setup handle cases when the "current asynchronous task" 
> spins the event loop, if at all?

The spinning of the event loop is also defined in terms of the event loop 
in a manner that strictly defines this:

   http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop

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

From dhtmlkitchen at gmail.com  Mon Aug  2 12:25:57 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 2 Aug 2010 12:25:57 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
	<4C56D7FE.7000705@doxdesk.com>
	<ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>
Message-ID: <AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>

On 8/2/10, Oliver Hunt <oliver at apple.com> wrote:
>
> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>
>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>> all array functions defined in ES5 are "generic" in that they work
>>> over any array-like object.
>>
>> They're guaranteed to work over any array-like native JavaScript object.
>> They're *not* guaranteed to work on host objects like the various node
>> lists.
>
> Uhhh, I have no idea what you're talking about -- there are no type checks
> in any of the array prototype functions, they all operate in terms of
> property access alone, all the methods we're talking about basically start
> out like this:
>

[..]

And they continue like this:

"Whether the [something] function can be applied successfully to a
host object is implementation-dependent."

Where "[something]" is replaced by "slice" in this case.

> Eg. "array-like" in the context of ES5 should be interpreted as "has a
> property named 'length', the array methods will work on any type.
>

That is not true. ECMAScript has what is called "host object". A host
is any ecmascript object that is not defined by the specification; it
is not a user-defined object (because that explicitly defined to be a
native object).

A host object may or may not be implemented as a native ECMAScript
object. That leaves two types of host objects:
 1) native
 2) non-native

More on that:
<https://mail.mozilla.org/pipermail/es-discuss/2010-July/thread.html#11501>

Nothing says that any of the various dom "collection" objects must be
native object.

The W3C does not define an interface "collection"; The term itself
comes from Microsoft IE 4, which predates the w3c DOM; hence the
quotes around the term "collection".

>>
>> FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the
>> modern desktop browsers except for IE.
>>
>> It would be possible to specify that the native-JS object guarantee should
>> also extend to node lists. This would allow fast browser implementations
>> of the array-like methods to be used without having to copy to a new
>> Array. However this would still leave the method of calling them a little
>> ugly.
>
> As above there is no question of it being possible -- the spec behaviour
> makes no exceptions for host vs. native object types.  If IE has a bug, then
> IE has a bug, that doesn't change the spec.
>

IE does not have a bug. IE does not implement its host objects as
native ES objects. I proposed to change that by defining an interface
that would require that, as well as putting a definition of [[Get]]
property access on such objects in one place; not scattered through
various interfaces as they currently are and will continue to be
otherwise, with the proliferation of new indexed "collection" type
interfaces.

Garrett

From bzbarsky at MIT.EDU  Mon Aug  2 12:39:34 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 02 Aug 2010 15:39:34 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>
References: <4C56245C.3080604@pearce.org.nz>	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>	<4C56DFEE.3040602@mit.edu>
	<Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>
Message-ID: <4C571EF6.5010206@mit.edu>

On 8/2/10 3:11 PM, Ian Hickson wrote:
>> How are we defining "current asynchronous task" and "finish"?
>
> In terms of the event loop algorithm:
>
>     http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2

Ah, I see.  Is the note there about synchronous sections having no 
side-effects something that is true by default due to the way 
synchronous sections are used in the specification?

>> How does this setup handle cases when the "current asynchronous task"
>> spins the event loop, if at all?
>
> The spinning of the event loop is also defined in terms of the event loop
> in a manner that strictly defines this:
>
>     http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop

I'm not sure I follow the steps here, actually.  Just to make sure I do 
understand....

Say I have a task T in the event queue.  Task T begins some algorithm 
that has a synchronous section, then spins the event loop.  If I 
understand the steps in #processing-model-2 correctly, the synchronous 
sections would run after task T completes, not while task T is spinning 
the event loop?  Or does "stop the currently running task" in 
#spin-the-event-loop imply a jump to step 2 of the algorithm under 
#processing-model2?

(Note: I still have a problem with the way "pause" is defined here, but 
I've raised that before, I believe.)

-Boris


From oliver at apple.com  Mon Aug  2 12:47:13 2010
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Aug 2010 12:47:13 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
	<4C56D7FE.7000705@doxdesk.com>
	<ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>
	<AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
Message-ID: <DA35DC07-74AE-4914-9937-DE5E50BE4AB3@apple.com>


On Aug 2, 2010, at 12:25 PM, Garrett Smith wrote:

> On 8/2/10, Oliver Hunt <oliver at apple.com> wrote:
>> 
>> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>> 
>>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>>> all array functions defined in ES5 are "generic" in that they work
>>>> over any array-like object.
>>> 
>>> They're guaranteed to work over any array-like native JavaScript object.
>>> They're *not* guaranteed to work on host objects like the various node
>>> lists.
>> 
>> Uhhh, I have no idea what you're talking about -- there are no type checks
>> in any of the array prototype functions, they all operate in terms of
>> property access alone, all the methods we're talking about basically start
>> out like this:
>> 
> 
> [..]
> 
> And they continue like this:
> 
> "Whether the [something] function can be applied successfully to a
> host object is implementation-dependent."
> 
> Where "[something]" is replaced by "slice" in this case.
> 
>> Eg. "array-like" in the context of ES5 should be interpreted as "has a
>> property named 'length', the array methods will work on any type.
>> 
> 
> That is not true. ECMAScript has what is called "host object". A host
> is any ecmascript object that is not defined by the specification; it
> is not a user-defined object (because that explicitly defined to be a
> native object).
> 
> A host object may or may not be implemented as a native ECMAScript
> object. That leaves two types of host objects:
> 1) native
> 2) non-native
> 
> More on that:
> <https://mail.mozilla.org/pipermail/es-discuss/2010-July/thread.html#11501>
> 
> Nothing says that any of the various dom "collection" objects must be
> native object.
> 
> The W3C does not define an interface "collection"; The term itself
> comes from Microsoft IE 4, which predates the w3c DOM; hence the
> quotes around the term "collection".

I didn't say that Host Objects don't exist, i said that "array like" is equivalent basically "has a property named length"

Things like Array.prototype.splice not working "as expected" on a NodeList is because the numeric properties on the nodelist are essentially DontDelete(or configurable=false in es5)

If I define an Object with:
var o = {length:1};
Object.defineProperty(o, "0", {value: "foo", configurable: false});

Then do:
var result = Array.prototype.splice.call(o, 0)

result will be ["foo"], but the property will not have been removed from object o.

There is no part of the spec that performs a type check, being a Host Object does not get you out of the required behaviour of the Array methods.

The reason the behaviour of Host Objects is considered magic is not so that you can say a function doesn't need to work on them, it is _specifically_ to allow the behaviour shown by the DOM where you can have properties that are have the attributes writable=false, configurable=false, and yet can still change.  This is the basis of the Host Object exception.  No property on a non-Host Object can change if it is not writable, yet the DOM requires that there be objects that do just that.

That said there is also no way in which you can implement any of the live collection types using EcmaScript.

Re: IE + Array methods, for whatever reason the ES5 spec does have an addendum that allows an implementation to disallow array methods on host objects -- i think this was foolish as the specification of the array methods should behave exactly as they would with a object with equivalent properties and attributes.

--Oliver


From dhtmlkitchen at gmail.com  Mon Aug  2 12:57:03 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 2 Aug 2010 12:57:03 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
	<4C56D7FE.7000705@doxdesk.com>
	<ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>
	<AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
Message-ID: <AANLkTi=PrPbuO-D8SKmKqzGRfybXWpe+yj1dAdKC=eBj@mail.gmail.com>

On 8/2/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On 8/2/10, Oliver Hunt <oliver at apple.com> wrote:
>>
>> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>>
>>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>>> all array functions defined in ES5 are "generic" in that they work
>>>> over any array-like object.
>>>
>>> They're guaranteed to work over any array-like native JavaScript object.
>>> They're *not* guaranteed to work on host objects like the various node
>>> lists.
>>
>> Uhhh, I have no idea what you're talking about -- there are no type
>> checks
>> in any of the array prototype functions, they all operate in terms of
>> property access alone, all the methods we're talking about basically
>> start
>> out like this:
>>
>
> [..]
>
> And they continue like this:
>
> "Whether the [something] function can be applied successfully to a
> host object is implementation-dependent."
>
> Where "[something]" is replaced by "slice" in this case.
>
>> Eg. "array-like" in the context of ES5 should be interpreted as "has a
>> property named 'length', the array methods will work on any type.
>>
>
> That is not true. ECMAScript has what is called "host object". A host
> is any ecmascript object that is not defined by the specification; it

Should be:
any object that is not defined by the specification.

I also linked to the old "catchalls" proposal earlier in the thread.
That is because the host objects mentioned here have a specialized
"catchall" behavior that isn't yet defined by any specification, so
when the code has property access with an integer index, as: anObj[2]
- then it's supposed to be the same as a  call to the `item` method.
That mostly works, but isn't specified isn't completely and isn't
completely interoperable due to variance in undefined vs null.

I noticed that rather than define catchall, HTML5 copied the old DOM text:

| In the ECMAScript DOM binding, objects implementing the
| HTMLFormControlsCollection  interface must support being
| dereferenced using the square bracket notation, such that dereferencing
| with an integer index is equivalent to invoking the item() method with that
| index, and such that dereferencing with a string index is equivalent to
| invoking the namedItem() method with that index.

The problem with that is that property access doesn't do any
typechecking, and so
  obj[2]
 - is equivalent to:-
  obj["2"]

Can it be argued as to what "integer index" means? And what is a "string index"?

Garrett

From oliver at apple.com  Mon Aug  2 13:24:53 2010
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Aug 2010 13:24:53 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTi=PrPbuO-D8SKmKqzGRfybXWpe+yj1dAdKC=eBj@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
	<4C56D7FE.7000705@doxdesk.com>
	<ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>
	<AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
	<AANLkTi=PrPbuO-D8SKmKqzGRfybXWpe+yj1dAdKC=eBj@mail.gmail.com>
Message-ID: <B6327845-1BFC-43E7-AC70-F0DC2D9EA985@apple.com>


On Aug 2, 2010, at 12:57 PM, Garrett Smith wrote:
> I also linked to the old "catchalls" proposal earlier in the thread.
> That is because the host objects mentioned here have a specialized
> "catchall" behavior that isn't yet defined by any specification, so
> when the code has property access with an integer index, as: anObj[2]
> - then it's supposed to be the same as a  call to the `item` method.
> That mostly works, but isn't specified isn't completely and isn't
> completely interoperable due to variance in undefined vs null.
> 
> I noticed that rather than define catchall, HTML5 copied the old DOM text:
> 
> | In the ECMAScript DOM binding, objects implementing the
> | HTMLFormControlsCollection  interface must support being
> | dereferenced using the square bracket notation, such that dereferencing
> | with an integer index is equivalent to invoking the item() method with that
> | index, and such that dereferencing with a string index is equivalent to
> | invoking the namedItem() method with that index.
> 
> The problem with that is that property access doesn't do any
> typechecking, and so
>  obj[2]
> - is equivalent to:-
>  obj["2"]
> 
> Can it be argued as to what "integer index" means? And what is a "string index"?

It does seem a little weird as EcmaScript does not distinguish between string and non-string property names, the special handling of "numeric" indices inside the [[GetOwnProperty]]/[[PutOwnProperty]] methods of those types that have special handling, in those types the special "numeric index" path is hit if the property name is an "Array index", which is defined as (pseudo code)

bool isArrayIndex(String property)
{
    unsigned index = ToUint32(property);
    return ToString(index) == property && index >= 0 && index < 0xFFFFFFFF; 
}

> Garrett

--Oliver


From jonas at sicking.cc  Mon Aug  2 14:09:43 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 2 Aug 2010 14:09:43 -0700
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com> 
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com> 
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
Message-ID: <AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com>

On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present.

If we add this to IndexedDB then there are certainly multiple storage
areas. You can have any number of objectStores inside any number of
databases.

> Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible.
>
> I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way.

If we add expiration to IndexedDB on an objectStore level, then the
page author doesn't need to do anything beyond setting an expiration
date, right?

/ Jonas

From ian at hixie.ch  Mon Aug  2 14:20:29 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 2 Aug 2010 21:20:29 +0000 (UTC)
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C571EF6.5010206@mit.edu>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C56DFEE.3040602@mit.edu>
	<Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>
	<4C571EF6.5010206@mit.edu>
Message-ID: <Pine.LNX.4.64.1008022113330.3056@ps20323.dreamhostps.com>

On Mon, 2 Aug 2010, Boris Zbarsky wrote:
> On 8/2/10 3:11 PM, Ian Hickson wrote:
> > > How are we defining "current asynchronous task" and "finish"?
> > 
> > In terms of the event loop algorithm:
> > 
> >     http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2
> 
> Ah, I see.  Is the note there about synchronous sections having no 
> side-effects something that is true by default due to the way 
> synchronous sections are used in the specification?

Yeah. It's intended to help keep the ways to implement this somewhat open.


> > > How does this setup handle cases when the "current asynchronous task"
> > > spins the event loop, if at all?
> > 
> > The spinning of the event loop is also defined in terms of the event loop
> > in a manner that strictly defines this:
> > 
> >     http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop
> 
> I'm not sure I follow the steps here, actually.  Just to make sure I do
> understand....
> 
> Say I have a task T in the event queue.  Task T begins some algorithm that has
> a synchronous section, then spins the event loop. If I understand the steps
> in #processing-model-2 correctly, the synchronous sections would run after
> task T completes, not while task T is spinning the event loop?

The synchronous section would run as soon as the task span the event loop. 
Spinning the event loop is defined essentially as being equivalent to 
breaking the original task in two, one that does everything up to spinning 
the event loop, and one that does everything after spinning the event 
loop. You are effectively waiting for some condition to become true and 
then queueing a task to run the continuation of the algorithm. It's just 
more convenient to write the algorithms as one long set of steps rather 
than having split them up into multiple algorithms that invoke each other 
and pass state around.


> Or does "stop the currently running task" in #spin-the-event-loop imply 
> a jump to step 2 of the algorithm under #processing-model2?

Yes.


> (Note: I still have a problem with the way "pause" is defined here, but 
> I've raised that before, I believe.)

I think we all have a problem with "pause", but I don't know what we can 
do about it. I don't have any pending feedback from you on this topic, as 
far as I can tell.

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

From jonas at sicking.cc  Mon Aug  2 14:59:28 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 2 Aug 2010 14:59:28 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com> 
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com> 
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com> 
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr> 
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com> 
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com> 
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
Message-ID: <AANLkTikaUf9SUpsDuSYudc36w6nn6DBfUCGkPXt6w-Bk@mail.gmail.com>

On Fri, Jul 30, 2010 at 2:46 PM, Alex Russell <slightlyoff at google.com> wrote:
> On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>> The e-mails quoted below consist of the salient points of this thread:
>>>
>>> On Fri, 23 Apr 2010, David Bruant wrote:
>>>>
>>>> Make that HTMLCollection (and all HTML*Collection, as a consequence of
>>>> inheritence of HTMLCollection) inherit from the ECMAScript Array
>>>> prototype. This way, it will make available all Array extra methods
>>>> (forEach, map, filter...) added in ECMAScript5 (and next versions which
>>>> should go in the same direction).
>>>>
>>>> As far as I know, adding this won't break any existing code. The
>>>> semantics of a Collection and the way it is used is very close from
>>>> ECMAScript Arrays. I don't think that the notion of "live object" and
>>>> ECMAScript Array are incompatible either. Once again, I am talking about
>>>> ECMAScript binding. I have no intention to touch the HTMLCollection
>>>> interface or other languages bindings.
>>>
>>> On Sun, 25 Apr 2010, J Z wrote:
>>>>
>>>> If HTMLCollection was inheriting from Array, and methods like `forEach`,
>>>> `map`, etc. were to operate on a live object, there would definitely be
>>>> undesired consequences. We can see this in, say, Firefox (which allows to
>>>> set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
>>>>
>>>> HTMLCollection.prototype.__proto__ = Array.prototype;
>>>>
>>>> document.getElementsByTagName('div').forEach(function(el) {
>>>> ? el.parentNode.removeChild(el); // doesn't work as expected
>>>> });
>>>>
>>>> // turning live collection into static array fixes this
>>>> Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
>>>> ? el.parentNode.removeChild(el);
>>>> });
>>>
>>> On Sat, 24 Apr 2010, David Bruant wrote:
>>>>
>>>> I think I can take your point as a "pro" more than a "con", because in
>>>> ES5, right before the definition of each array extra method, a paragraph
>>>> like the following can be found :
>>>>
>>>> "The range of elements processed by forEach is set before the first call
>>>> to callbackfn. Elements which are appended to the array after the call
>>>> to forEach begins will not be visited by callbackfn. If existing
>>>> elements of the array are changed, their value as passed to callback
>>>> will be the value at the time forEach visits them; elements that are
>>>> deleted after the call to forEach begins and before being visited are
>>>> not visited."
>>>>
>>>> This point is confirmed by every algorithm where the length is "saved"
>>>> once for all before the loop and not got from the .length property each
>>>> time.
>>>
>>> On Mon, 26 Apr 2010, Erik Arvidsson wrote:
>>>> On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
>>>> > Le 25/04/2010 00:39, J Z a ?crit?:
>>>> >>
>>>> >> I have thought a lot about weirdnesses that people could think about
>>>> >> like trying to assign a value to the HTMLCollection (divs[14] =
>>>> >> myOtherDiv), but once again, it wouldn't be more allowed than it
>>>> >> currently is (I have no idea of what happens today, but if an error
>>>> >> is thrown in a for-loop, it should throw an error as well in a call
>>>> >> within a forEach).
>>>> >
>>>> > How would destructive methods like `push` or `sort` behave? Would
>>>> > `document.body.childNodes.push(document.createTextNode('foo'))` append
>>>> > text node to a body element? Or would it be a noop?
>>>> >
>>>> > That is actually a very good point. It think that the behavior should
>>>> > be exactly the same as "an equivalent without array methods". (this
>>>> > point of my proposal would need to be made completly explicit for each
>>>> > method)
>>>>
>>>> One way to solve this could be to split Array into two interfaces. One
>>>> to be used with immutable array like objects and one to use to mutate
>>>> objects. Then we could apply the immutable array like interface to
>>>> NodeList and its related interfaces. The benefit of doing that is that
>>>> NodeList.prototype.push would be undefined instead of failing when
>>>> called.
>>>
>>> On Mon, 26 Apr 2010, David Flanagan wrote:
>>>>
>>>> Rather that trying to make DOM collections feel like arrays, how about
>>>> just giving them a toArray() method? ?This makes it clear that a
>>>> collection is not an array, but clearly defines a way to obtain an
>>>> array. ?Clever implementors might even be able to optimize common
>>>> uses-cases using some kind of copy-on-write strategy so that toArray()
>>>> doesn't involve memory allocation and copying.
>>>>
>>>> Of course, trying to teach programmers when they ought to call toArray()
>>>> and when it is not necessary is another matter. ?Perhaps calling the
>>>> method snapshot() and focusing on the live vs. static distinction
>>>> instead of the fake array vs. true array distinction would invite less
>>>> misuse.
>>>>
>>>> Or we can just leave the DOM as it is and get used to calling the
>>>> equivalent of Prototype's $A() function.
>>>
>>> Before changing something this substantial, I'd like to have implementor
>>> feedback regarding what the best way to address this is:
>>>
>>> ?- somehow make HTMLCollections and NodeLists inherit from Array?
>>>
>>> ?- define a bunch of feature on HTMLCollections and NodeLists so that
>>> ? they're like arrays?
>>
>> I don't think this makes sense given the immutability of NodeLists.
>
> Wait...what? Shouldn't some sort of NodeList be mutable?

Hard to say given that none exist yet. If there is an API that returns
a mutable NodeList, why not just return a JS Array instead?

> And shouldn't JS support immutable Arrays?

Again, hard to say given that the need doesn't seem to have come up
yet. But assuming that immutable Arrays would make sense, that raises
a host of questions:

Would isArray for them return true or false?
Would the immutable-Array prototype be in the prototype chain for
mutable Arrays?
Would making a change to the prototype chain for normal Arrays be
considered a backwards incompatible change to ECMAScript?
What is the use case for immutable Arrays?
Is a immutable Array the same thing as a NodeList given that NodeLists
can change their contents, for example when a document is mutated?
How fast could we expect EMCAScript to come to reasonable agreement of
how immutable Arrays work?

These all seem like very important questions, and I don't have the
answer to any of them. I do note that there were 10 years between
ECMAScript 3 and 5.

> We need to fix both of these APIs, and we
> keep heaping back-pressure on JavaScript's Array without any
> reasonable resolution because we're not exploring how to make Array
> subtypes work as we want them to for all the use cases (like this)
> that we care to express.
>
>>> ?- provide a toArray() method or equivalent?
>>
>> I think this would make sense, though I think it's also worth
>> supplying functions that apply array-like operations directly on the
>> nodelist. To avoid the overhead of copying the data.
>
> Elided if they're *actual* Arrays.

At the most they would be actual immutable Arrays, so a toArray()
method would still make sense, though maybe a better name is
toMutableArray() or some such.

>>> ?- do nothing?
>>
>> Given how often this comes up, I think it's worth addressing this.
>>
>>> ?- something else?
>>
>> John Resig has been working on something in this area. I don't know if
>> that's ready to publish yet though.
>
> I'd like to see any proposal in this area include NodeLists that are
> *real* Array subtypes. Anything that's not is a missed opportunity
> both for this list and for TC39.

I'd definitely recommend trying to get TC39 to spend time on this.
However my impression is that the best way to get them to do so is to
have a coherent proposal and get a member of TC39 raise it for
inclusion in Harmony. Such a proposal would likely have to answer the
questions I list above.

/ Jonas

From and-py at doxdesk.com  Mon Aug  2 15:10:54 2010
From: and-py at doxdesk.com (And Clover)
Date: Tue, 03 Aug 2010 00:10:54 +0200
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTi=PrPbuO-D8SKmKqzGRfybXWpe+yj1dAdKC=eBj@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>	<4BD5C792.7050106@davidflanagan.com>	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>	<4C56D7FE.7000705@doxdesk.com>	<ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>	<AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
	<AANLkTi=PrPbuO-D8SKmKqzGRfybXWpe+yj1dAdKC=eBj@mail.gmail.com>
Message-ID: <4C57426E.4090909@doxdesk.com>

On 08/02/2010 09:57 PM, Garrett Smith wrote:

> Can it be argued as to what "integer index" means? And what is a "string index"?

Good catch, that's pretty ambiguous language. Browsers implement this as 
if "integer index" were equal to the term "array index" defined section 
15.4 of ECMA262 (that is an unsigned 32-bit integer other than 
(1<<32)-1, expressed in simplest-possible decimal form), and "string 
index" meaning any other index.

The paragraph should be updated to explicitly reference this; probably 
the language about square brackets should be dropped too, as it seems to 
represent a misunderstanding of exactly how the ECMAScript 
square-bracket and dot operators actually work.

Whether a property name is an "array index" or not is an unrelated issue 
to the matter of how the property value is retrieved. OK, you can't use 
the direct dot syntax on an array index purely as a grammatical manner, 
but . and [] aren't the only way to access properties. (eg. 
document.links.hasOwnProperty('0').)

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/

From ian at hixie.ch  Mon Aug  2 15:16:54 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 2 Aug 2010 22:16:54 +0000 (UTC)
Subject: [whatwg] [canvas] getContext & multiple contexts
In-Reply-To: <4BD9A96C.4030909@pobox.com>
References: <4BD9A96C.4030909@pobox.com>
Message-ID: <Pine.LNX.4.64.1007302259420.7470@ps20323.dreamhostps.com>


On Thu, 29 Apr 2010, Vladimir Vukicevic wrote:
> 
> A while ago questions came up in the WebGL WG about using a canvas with 
> multiple rendering contexts, and synchronization issues that arise 
> there. Here's our suggested change to getContext.

This seems overly complex. I've gone for a somewhat simpler approach, 
which basically makes <canvas> fail getContext() if you call it with a 
context that isn't "compatible" with the last one that was used, as 
defined by a registry of contexts types. Currently, only '2d' and '3d' are 
defined in this registry, and they are not defined as compatible.


> It essentially allows for multiple contexts but adds no synchronization 
> primitives other than the requirement that rendering must be visible to 
> all contexts (that is, that they're rendered to the same destination 
> space).

Having 3D and 2D contexts rendering to the same space -- especially given 
getImageData() and the like -- seems like an interoperability nightmare.


> This also adds the 'attributes' parameter which can customize the 
> context that's created, as defined by the context itself.  WebGL has its 
> own context attributes object, and I'd suggest that the 2D context gain 
> at least an attribute to specify whether the context should be opaque or 
> not; but that's a separate suggestion from the below text.

I haven't added this. Could you elaborate on why this is needed? What 
happens if the method is invoked agains with different parameters?

It seems far preferable to have this on the API rather than as part of the 
getContext() method.

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

From chris at pearce.org.nz  Mon Aug  2 15:40:26 2010
From: chris at pearce.org.nz (Chris Pearce)
Date: Tue, 03 Aug 2010 10:40:26 +1200
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
Message-ID: <4C57495A.9020800@pearce.org.nz>

  On 2/08/2010 9:17 p.m., Ian Hickson wrote:
> On Mon, 2 Aug 2010, Chris Pearce wrote:
>> There's a race condition in the media load algorithm. When the resource
>> selection algorithm begins, it sets a task to complete the rest of the
>> resource selection algorithm asynchronously.
> Not quite. It awaits a stable state and then runs a synchronous section,
> which means that it will run the subsequent steps as soon as the current
> task has finished, before anything else that is queued.
>

Ah, I see. My understanding of the processing model was incomplete, 
thanks for clarifying!

All the best,
Chris Pearce.

From dhtmlkitchen at gmail.com  Mon Aug  2 17:22:44 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 2 Aug 2010 17:22:44 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <4C57426E.4090909@doxdesk.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
	<4C56D7FE.7000705@doxdesk.com>
	<ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>
	<AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
	<AANLkTi=PrPbuO-D8SKmKqzGRfybXWpe+yj1dAdKC=eBj@mail.gmail.com>
	<4C57426E.4090909@doxdesk.com>
Message-ID: <AANLkTin+gKyxNj9P2ifKYDSiGptn6cC+tzsdXw8qm+io@mail.gmail.com>

On 8/2/10, And Clover <and-py at doxdesk.com> wrote:
> On 08/02/2010 09:57 PM, Garrett Smith wrote:
>
>> Can it be argued as to what "integer index" means? And what is a "string
>> index"?
>
> Good catch, that's pretty ambiguous language. Browsers implement this as
> if "integer index" were equal to the term "array index" defined section
> 15.4 of ECMA262 (that is an unsigned 32-bit integer other than
> (1<<32)-1, expressed in simplest-possible decimal form), and "string
> index" meaning any other index.
>

Not exactly.

An array's `length` is 1 greater than the largest index in the array;
represented as uint internally. The largest possible array index is
2^32 - 2. ES5 specification says this a bit differently:


| A property name P (in the form of a String value) is
| an array index if and only if ToString(ToUint32(P)) is
| equal to P and ToUint32(P) is not equal to 232-1

That could cover "integer index", but the remaining undefined is
"string index", which seems a paradoxical name, even for Java
programmers.

Suppose string index could be any other index. Or it could be any
index matching production for NAME.

But then, does that mean property access on an HTMLCollection can
never return undefined? Seems so; must be either `null` or an object.

If the a collection is spec'd to use specialized [[Get]] access, then
it may need to use catchalls. Again, browsers do use these in some
cases and they aren't specified.

> The paragraph should be updated to explicitly reference this; probably
> the language about square brackets should be dropped too, as it seems to
> represent a misunderstanding of exactly how the ECMAScript
> square-bracket and dot operators actually work.
>


> Whether a property name is an "array index" or not is an unrelated issue

Depends. If a specialized [[Get]] implemented as a catchall, then the
browsers do some checking.

A specialized [[Get]] may be interfering with array generics working
with IE host object collections. It may have been that it was too
complicated and that the developers decided that it was easier to fail
fast by throwing "JScript object expected'.

Again, on that error, if `ho` is a host object, then the behavior in
IE <= 8 for `[].slice.call( ho )` is "JScript object expected." IE
operation sees that the context -- the `this`value -- is not a JScript
object and then aborts prematurely, without trying. It could be that
the attempt to slice the object could actually succeed, as: -
  "0" in ho && "length" in ho

- is true.

> to the matter of how the property value is retrieved. OK, you can't use
> the direct dot syntax on an array index purely as a grammatical manner,
> but . and [] aren't the only way to access properties. (eg.
> document.links.hasOwnProperty('0').)
>

That shows that `hasOwnProperty` is present on the object and that
calling it returns true where there.

For compatibility with IE, a layer of indirection may be used:

({}).hasOwnProperty.call(document.links, "0");

- and resulting true in IE.

However, that hasOwnProperty check does not always true for
collections. As seen in the previous example I posted, for property P,
[[HasProperty]] resulted false when there is a property P. Once again,
this time with hasOwnProperty, I see a result in Firefox 3.6: [false,
object]

javascript: var result =
  [
  ({}).hasOwnProperty.call(document.forms[0], "0"),
  typeof document.forms[0][0]
  ];

 alert( result )

HTML5 also codifies a common form memory leak as "past names map".

Both of those oddities were explained more here:
<http://www.jibbering.com/faq/names/>

However, AFAIK, HTML5 does not specify the catchall behavior for the
approach for specialized property access seen there.

Does a collection have element properties?  (and by "element", I do
not mean Element, but indexed/keyed item that represents an object in
the collection.

If it does, then that's a lot easier. Spec'd specialized behavior for
property accessors can be removed; as that behavior is already defined
by ECMA-262. The only change could be to allow for "integer index"
access to return `undefined`, as it currently does in most browsers.

If any collection does not have element properties, then it is
necessary to define "integer index" and "string access", at least for
that collection.

Most collections appear to have element properties and so I can't see
any reason for not specifying that. I recall raising discussion of
property access on collections over a year ago, before writing the
article I've linked above.

Garrett

From nzakas at yahoo-inc.com  Mon Aug  2 17:24:08 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Mon, 2 Aug 2010 19:24:08 -0500
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com>
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com>
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com>
Message-ID: <B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>

Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage.

To be clear, I think there should be expiration for all forms of client-side data storage, and adding it to one doesn't seem like a reason to not add it to all.

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: Monday, August 02, 2010 2:10 PM
To: Nicholas Zakas
Cc: Scott Hess; Alexandre Morgaut; whatwg at lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present.

If we add this to IndexedDB then there are certainly multiple storage
areas. You can have any number of objectStores inside any number of
databases.

> Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible.
>
> I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way.

If we add expiration to IndexedDB on an objectStore level, then the
page author doesn't need to do anything beyond setting an expiration
date, right?

/ Jonas

From dhtmlkitchen at gmail.com  Mon Aug  2 17:28:54 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 2 Aug 2010 17:28:54 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTin+gKyxNj9P2ifKYDSiGptn6cC+tzsdXw8qm+io@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<AANLkTinGJhb8w8cMcGA=UJuCkAsfs4ZC6q6SOfsF8wJw@mail.gmail.com>
	<33B7E98E-D1D7-48AE-8F8D-4C476A567726@apple.com>
	<4C56D7FE.7000705@doxdesk.com>
	<ED4A5698-A8F6-416E-AA8A-5C98F2D5A99A@apple.com>
	<AANLkTi=RW9+T_Tj2GO2hFmw=ZbBg8mByFNm5Wov7o96s@mail.gmail.com>
	<AANLkTi=PrPbuO-D8SKmKqzGRfybXWpe+yj1dAdKC=eBj@mail.gmail.com>
	<4C57426E.4090909@doxdesk.com>
	<AANLkTin+gKyxNj9P2ifKYDSiGptn6cC+tzsdXw8qm+io@mail.gmail.com>
Message-ID: <AANLkTimT2KOqn593+bS-UfMZ4nePKtcHLFoeZ54U4vVa@mail.gmail.com>

On 8/2/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On 8/2/10, And Clover <and-py at doxdesk.com> wrote:
>> On 08/02/2010 09:57 PM, Garrett Smith wrote:
>>
[...]

> ({}).hasOwnProperty.call(document.links, "0");
>
> - and resulting true in IE.
>
> However, that hasOwnProperty check does not always true for

...does not always result `true for...

> collections. As seen in the previous example I posted, for property P,
> [[HasProperty]] resulted false when there is a property P. Once again,
> this time with hasOwnProperty, I see a result in Firefox 3.6: [false,
> object]
>

That was not clear, I meant that [[HasProperty]] resulted false and
[[Get]], via property accessors. resulted in the element being
retrieved.

Garrett

From ian at hixie.ch  Mon Aug  2 17:30:25 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 00:30:25 +0000 (UTC)
Subject: [whatwg] The real issue with HTML5's sectioning model
In-Reply-To: <m2l6ea53251005010411u8d34d24ax59713120583b3c0a@mail.gmail.com>
References: <x2j6ea53251004301157hf07485dap9a7a0f2f110b01be@mail.gmail.com>
	<op.vbz6a5hs64w2qv@annevk-t60>
	<z2pad1a0c1e1004301842i5871dde0j1fad91ac32d9f513@mail.gmail.com>
	<op.vbz7oxw264w2qv@annevk-t60>
	<m2l6ea53251005010411u8d34d24ax59713120583b3c0a@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008022234470.7470@ps20323.dreamhostps.com>

On Fri, 30 Apr 2010, Eduard Pascual wrote:
>
> Basically, most of the issues with headings boil down to a single fact: 
> the sectioning model is (probably needlessly) over-bloated. [...]
> 
> And now, in HTML5, not only have <h1-6> been kept, but a plethora of new 
> elements: <section>, <nav>, <aside>, <article>, <hgroup>, <header>, 
> <footer>; and it even messes with <address>. The justifications for 
> <h1-6> (backwards compatibility, better transition, etc) are quite 
> sound; but the 7 new elements more than double the mess.

Another way to look at it is that the new elements simplify the markup 
authors have to use. Most of the new elements correspond to very commonly 
used class names.


> Actually, if we try to "implement" the outlining algorithm in the form 
> of selectors that match each level of headings we have: On the case that 
> the <h1>-only approach, selecting each level of heading requires a list 
> of something raised to the n-th power selectors, where n is the heading 
> level minus one.

Not necessarily. We can fix Selectors to make this much shorter, in a way 
equivalent to what the spec says, for example using a pseudo-class like 
Mozilla's :-moz-any().


> On the case of a mixed approach, it is *absolutely* impossible to get 
> the headings properly matched with current selector technology.

Indeed. We can always improve that technology if that's a problem, though.

In practice it's not clear what the needs are here. I don't see most 
authors needing to select both <section>/<h1> and <h2>/<h3> etc with the 
styles interacting. Do you have any concrete use cases in mind where this 
is a problem?


> My suggestion is to clean things a bit: consolidate the sectioning model 
> into a single element+attribute pair, like this:
> <section> stays as is.
> <nav> becomes <section kind="nav">
> <aside> becomes <section kind="aside">
> <article> becomes <section kind="article">
> <address> becomes <section kind="address"> (and the former is defined
> in the compatibility section as equivalent to the later, because it is
> the only element of the sectioning model that already exists in
> previous versions of HTML).
> I'm not sure about what should be done with <header>, <footer>, and
> <hgroup>, but I hope this is a good place to discuss it ;-)

I don't understand what problem this solves. All its seems to do is make 
the language more verbose.


> This yields several advantages:
> 1) The styling issue improves drastically: any pre-HTML5 will
> understand this (IE would require a bit of javascript anyway) out of
> the box:
> h1 { styling for top-level }
> section h1 { styling for second-level }
> section section h1 { styling for third-level }
> and so on, for as many levels as you need.

If you want to target older UAs, you can just use <h2>-<h6> with 
<section>, instead of relying on the automatic sizing of <h1>.


> 2) All of a sudden, something like <section kind="aside nav"><h1>See
> also</h1> some indirectly related links here...</section> becomes
> possible, plus easy to style, and works happily with the outlining
> algorithm.

Isn't that a negative, rather than a positive?


> 3) Future needs will become easier to solve on future versions of the 
> specification, and with significantly smaller costs: for example, let's 
> assume a new sectioning element such as <attachment> becomes a 
> widespread need (it would already make sense on sites like web-mail 
> services, discussion boards, bug-trackers, and some others...). So a new 
> crouton on the soup, which would be treated quite like a generic <div> 
> by pre-HTML6 (or 7, or whatever) browsers. Now, with the 
> <section>+attribute approach, we'd get something like <section 
> kind="attachment">: that'd would still work with the outlining algoryth 
> (it could be treated as generic section), it's styling will work 
> smoothly, etc.

Given how often we add new sectioning elements, I don't think that's 
something to worry about optimising for. At least not in favour of a 
simple language.


On Sat, 1 May 2010, Eduard Pascual wrote:
>
> It's not a matter of saving a few characters here and there.

Well, that was more or less the reasoning behind having these elements in 
the first place, so it is a _bit_ about that. :-)


> The very purpose of <section> and its friends is to implement explicit 
> sectioning on HTML, so there is no need to rely on error-prone, 
> painful-to-maintain implicit <h1-6>-based sectioning. However, the spec 
> recommends still using <h1-6> anyway, to ensure backwards compatibility. 
> The compatibility goal itself is a quite good thing but, on this case, 
> it not only destroys the primary purpose of the feature, but makes 
> things even worse: having to state the same thing (the sectioning of the 
> document) twice (with the sectioning elements and with the numbered 
> headings) doubles the chance to introduce errors, and doubles the effort 
> required to maintain the content.

Yeah, but it's only an issue during the transition period.


> In summary: the <section>+attribute approach solves all the issues the
> current model solves

Not all of them; the main problem was that using <div class=""> made ugly 
documents that are a mess to maintain.


> provides better (backward and forward) compatibility

It provides no better backwards compatibility unless you are relying on 
CSS, and the forward-compatibility in this case is of minimal concern 
given the timescales we're talking about here.


> allows better leveraging existing technologies (such as CSS) to work 
> with it

Is that a goal? It seems that we should improve the platform as a whole, 
not design features in HTML based on CSS' current limitations.


> would be simpler to specify and to implement

It wouldn't be simpler to specify, since the status quo is already 
specified, so would require no work. :-)

The implementation burden also seems minimal in either case.


> and easier for authors to learn

That I'm not convinced of at all.


> and solves some use cases the current model does not.

It's not clear that those use cases are real problems, though.


On Fri, 30 Apr 2010, Eduard Pascual wrote:
>
> Quoting the HTML5 spec:
> "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."
> "The aside element represents a section of a page that consists of
> content that is tangentially related to the content around the aside
> element, and which could be considered separate from that content."
> Putting that together, a section that links to other pages *and*
> consists of content that is tangentially related to the content around
> it *must* be *both* a nav and an aside.

That doesn't follow. It just means both either be appropriate.


> The most blatant example
> (which I thought was clear enough from the example) are "See also"
> sections found on many sites (see a couple of examples on [1] and
> [2]). Currently, the closest thing we may get is
> <nav><aside>...</aside></nav> or <aside><nav>...</nav></aside>.

Just <aside>...</aside> or <nav>...</nav> works too.


> This raises several concerns: which one should be the outer, and which 
> the inner section? How would that interact with the sectioning 
> algorithm? (ie: would a heading inside there be taken as one level lower 
> than the expected one?).

I think you may be overthinking this. :-)

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

From ian at hixie.ch  Mon Aug  2 17:33:09 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 00:33:09 +0000 (UTC)
Subject: [whatwg] :checked should match selected option elements
In-Reply-To: <20100430190747.GA16306@pickering.dbaron.org>
References: <20100430190747.GA16306@pickering.dbaron.org>
Message-ID: <Pine.LNX.4.64.1008030032120.7470@ps20323.dreamhostps.com>

On Fri, 30 Apr 2010, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-checked
> defines what elements match the :checked pseudo-class.  However, I
> think it's missing an important case: selected option elements
> within a select.
> 
> http://www.w3.org/TR/css3-selectors/#checked says:
>   # For example, the :checked pseudo-class initially applies to such
>   # elements that have the HTML4 selected and checked attributes as
>   # described in Section 17.2.1 of HTML4, but of course the user can
>   # toggle "off" such elements in which case the :checked
>   # pseudo-class would no longer apply. 
> which clearly shows that it's the intent of css3-selectors that the
> pseudo-class apply in this case.
> 
> From looking at VCS history, Gecko has implemented :checked on option 
> elements since Gecko 1.8 == Firefox 1.5.

Fixed.

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

From ian at hixie.ch  Mon Aug  2 17:46:15 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 00:46:15 +0000 (UTC)
Subject: [whatwg] Should :default apply to checkboxes, radios,
	and options?
In-Reply-To: <20100430205555.GA18401@pickering.dbaron.org>
References: <20100430191209.GA16452@pickering.dbaron.org>
	<h2kdd0fbad1004301305pbd0ff2a9xb12d86d93db9d91d@mail.gmail.com>
	<20100430204313.GA18036@pickering.dbaron.org>
	<20100430204414.GA18087@pickering.dbaron.org>
	<w2q63df84f1004301346ld0ebe287r560e588b893a172f@mail.gmail.com>
	<20100430205555.GA18401@pickering.dbaron.org>
Message-ID: <Pine.LNX.4.64.1008030034520.7470@ps20323.dreamhostps.com>

On Fri, 30 Apr 2010, L. David Baron wrote:
>
> For a long time, Gecko has implemented the behavior that the
> :default pseudo-class matches checkboxes, radios, and options that
> are selected by default (i.e., anything that matches :checked by
> default).  I think supporting it for option elements is explicitly
> stated in the spec where :default was introduced:
>   # One example is the default submit button among a set of buttons.
>   # Another example is the default option from a popup menu.
>   # Multiple elements in a select-many group could have multiple
>   # :default elements, like a selection of pizza toppings for
>   # example. 
>     -- http://www.w3.org/TR/css3-ui/#pseudo-default
> and I think supporting it for radios and checkboxes logically
> follows from that.
> 
> However, the HTML5 spec says that :default should not apply in these
> cases:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-default
> 
> I don't feel particularly strongly about this one, but it seems like the 
> original intent of :default was to match both things that are the 
> "default button" and things that are "selected by default".
> 
> Was this difference with existing implementation behavior intentional?

No, that particular definition just didn't come to mind.


On Fri, 30 Apr 2010, Jonas Sicking wrote:
> 
> Out of curiosity, what is the use case for :default?

On Fri, 30 Apr 2010, L. David Baron wrote:
> 
> For buttons, it's common to present the button that's the default action 
> for a dialog (the one that submits if you hit enter in a textfield, for 
> example), with a thicker border.  (For example, in dialog boxes in 
> Windows.)
> 
> For radios/checkboxes, one might want to present the labels 
> corresponding to the current state in a different font (perhaps bold?) 
> or color so that if a user switches away from the defaults they can 
> switch back without having to remember what they changed. (I believe 
> I've seen UI that does this, although I can't think where.)

Since nobody seemed to object to this, and we already have an 
implementation, I've added it to the spec. I don't feel strongly about 
this either.

Note that the definition of :default isn't quite the same as what is 
:checked by default. For example, the first <option> here matches 
:default, even though the second is the one that matches :checked by 
default, and indeed the first can never match :checked while disabled:

   <select>
     <option disabled selected>A
     <option>B
   </select>

I did this for compat with Firefox. We could change it but it would make 
the rules somewhat more convoluted.

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

From jonas at sicking.cc  Mon Aug  2 17:51:05 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 2 Aug 2010 17:51:05 -0700
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com> 
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com> 
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
Message-ID: <AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com>

On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage.

I suspect it will be much easier to add to IndexedDB than to
localStorage/sessionStorage. I don't expect the latter to go away,
though generally it seems like people are disliking localStorage
enough that it's hard to get any changes made to it.

/ Jonas

From ian at hixie.ch  Mon Aug  2 17:52:10 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 00:52:10 +0000 (UTC)
Subject: [whatwg] definition of :link and :visited should allow
	flexibility
In-Reply-To: <20100430191702.GA16567@pickering.dbaron.org>
References: <20100430191702.GA16567@pickering.dbaron.org>
Message-ID: <Pine.LNX.4.64.1008030051220.7470@ps20323.dreamhostps.com>

On Fri, 30 Apr 2010, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-link
> says:
>   # All a elements that have an href attribute, all area elements
>   # that have an href attribute, and all link elements that have an
>   # href attribute, must match one of :link and :visited.
> 
> A number of user agents have recently implemented changes to
> handling of :link and :visited that can't be described strictly in
> terms of an element matching a selector.  These are described in
> more detail in http://dbaron.org/mozilla/visited-privacy .
> 
> css3-selectors has an exception that allows this:
>   # UAs may therefore treat all links as unvisited links, or
>   # implement other measures to preserve the user's privacy while
>   # rendering visited and unvisited links differently. 
>     --http://www.w3.org/TR/css3-selectors/#the-link-pseudo-classes-link-and-visited
> 
> HTML5 should have a similar exception that allows user agents to be more 
> flexible than requiring that all of the elements listed match exactly 
> one of :link and :visited.

I've added a paragraph saying that another spec might introduce additional 
requirements here.

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

From ian at hixie.ch  Mon Aug  2 17:53:49 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 00:53:49 +0000 (UTC)
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
Message-ID: <Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>

On Sat, 1 May 2010, ryan14 at mail.com wrote:
> 
> My suggestion for the HTML5 spec is that the video tag should have a 
> feature that can enable GPU acceleration on a user's graphics card, so 
> it will take some stress off the CPU.
> 
> Do you like my suggestion?

Why would a user ever want anyone to disable their GPU acceleration?


On Sun, 2 May 2010, Simon Fraser wrote:
> 
> The only reason I can think of why this should be exposed to web authors 
> is if a browser is unable to use GPU accelerated for video without side 
> effects (like always rendering on top of the rest of the content). Such 
> an option would be similar to the "wmode" param on plugins, which is a 
> huge mess, and should be avoided at all costs. One of the benefits of 
> video being a real HTML element is that it respects CSS properties like 
> any other element.

Indeed, it seems like we'd just want this to be automatic.

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

From ian at hixie.ch  Mon Aug  2 18:12:37 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 01:12:37 +0000 (UTC)
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <y2peed7f4a91005070307n4fbea881y4ff879b7088aaa2e@mail.gmail.com>
References: <y2peed7f4a91005070307n4fbea881y4ff879b7088aaa2e@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008030057200.7470@ps20323.dreamhostps.com>


This thread primarily discussed ways to allow users to log in and out of 
sites, possibly through improvements to the forms model.

This is an area that seems to be under a lot of active research, so it's 
probably premature to change the HTML spec at this point. I haven't 
introduced any new form types.

Some comments on a few of the specific points raised:

On Tue, 4 May 2010, Eitan Adler wrote:
>
> Use cases:
> 1) A screen reader that sees a form with a type=username and a
> password field. The screen reader could just ask "Log in to this site?
> [y/n]?". No further context would be needed.

My browsers already do this on many of my sites; why can't an AT?


> 2) UAs can more easily discover login forms and offer things such as
> Firefox's Account Manager [1] or a "remember me" feature

There are a variety of ways this can be done today (e.g. the name="", 
id="", or class="" attributes; declarative descriptions as used by [1]; a 
<link rel> pointing to a form control; microformats; etc); a new input 
field type doesn't seem necessary to do this.


> 3) Currently autofill for usernames looks for something like 
> id="username" or name="username". However on certain websites this 
> fails. Furthermore some websites offer a "find other members" feature 
> where you could type in a username. I've often seen these fields filled 
> in automatically with my name.

Why would sites where this doesn't work today use a new feature to do 
this? Surely they can do this now already, so why aren't they doing it?


> [1] http://www.mozilla.com/en-US/firefox/accountmanager/

On Tue, 4 May 2010, Steve Dennis wrote:
> On 4/05/2010, at 9:07 AM, timeless wrote:
> > 
> > Why would a site which doesn't cooperate with today's autofill 
> > features choose to cooperate with your proposal?
> 
> Because id="username" isn't a standard as such.  Having it specified in 
> a spec is likely to help people adopt it more quickly.

RFC3106 has specified this since 2001, and has been implemented for a long 
time: https://tools.ietf.org/html/rfc3106

It didn't seem to do much to make adoption happen more quickly.

Why would this new idea make things go faster?


> Saying "why bother?" about all the broken sites on the web totally 
> defeats the purpose of what everyone here's trying to achieve.

Sure, but we can't help these sites without their cooperation. How do we 
get them to cooperate? We've tried standards (RFC3106), we've tried making 
the user experience better (password fillers). What else can we try? 
Another <input> doesn't seem to address this.


On Tue, 4 May 2010, Dirk Pranke wrote:
>
> I think this idea is halfway to what I'd want to see. Namely, we should 
> add an <input type="login"> field that triggers a powerbox/dialog (much 
> like the <input type="file"> dialog) that can collect whatever sort of 
> credentials are needed (username / password, two-factor auth, FB connect 
> credentials, OpenID/OAuth credentials, etc.). I agree that it should 
> probably build on top of the Account Manager spec.
> 
> I think the whole login process needs to be taken as out of page as 
> possible. Unfortunately, the auto-login mechanism in Mozilla's prototype 
> is probably too out of page, and so there should be a way to trigger the 
> login from an in-page element (hence the above).

I strongly urge people to experiment in this area. This is the kind of 
thing that should precede standardisation.


On Thu, 6 May 2010, Markus Ernst wrote:
> 
> Maybe it is a problem to have several functionalities mixed up in the 
> type attribute, such as control display, autofill and validation 
> functionalities. OTOH there are validation hints both in the type and 
> pattern attributes.
> 
> Maybe keywords could be added as possible values of the pattern 
> attribute, in order to provide standard validation types such as e-mail, 
> numeric, or maybe also date and datetime.
> 
> <input type="text" pattern="email">
> <input type="username" pattern="email">

This only seems to be a problem if we overload type="" for two different 
axes (the type of data, in this case an e-mail address, and the intent of 
the data, in this case a username).

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

From ian at hixie.ch  Mon Aug  2 18:27:34 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 01:27:34 +0000 (UTC)
Subject: [whatwg] Questions about meter element
In-Reply-To: <B9B55EB1B426EA479A5B5EE9B292A675531CB05411@NOK-EUMSG-05.mgdnok.nokia.com>
References: <B9B55EB1B426EA479A5B5EE9B292A675531CB05411@NOK-EUMSG-05.mgdnok.nokia.com>
Message-ID: <Pine.LNX.4.64.1008030117520.7470@ps20323.dreamhostps.com>

On Wed, 5 May 2010, Yael.Aharon at nokia.com wrote:
>
> I have a couple of questions regarding the meter element.
> 
> 1. I could not find the meter element in the tables in 
> http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria. 
> What is the ARIA role for the meter element?

I don't think ARIA currently has one that is appropriate.


> 2. From UA requirements for showing the gauge: When representing a meter 
> element to the user, the UA should indicate the relative position of the 
> actual value to the minimum and maximum values, and the relationship 
> between the actual value and the three regions of the gauge. Considering 
> that the default size of this element is 5em width and 1em height, how 
> should the 3 regions be represented by the UA?

The simplest way is probably a flat bar with the regions coloured (e.g. 
green for the optimal region, red for the regions on the other end, yellow 
for the remaining region if any) and with a black notch showing where the 
value lies.

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

From dpranke at chromium.org  Mon Aug  2 18:43:33 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Mon, 2 Aug 2010 18:43:33 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
Message-ID: <AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>

On Mon, Aug 2, 2010 at 5:53 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 1 May 2010, ryan14 at mail.com wrote:
>>
>> My suggestion for the HTML5 spec is that the video tag should have a
>> feature that can enable GPU acceleration on a user's graphics card, so
>> it will take some stress off the CPU.
>>
>> Do you like my suggestion?
>
> Why would a user ever want anyone to disable their GPU acceleration?
>

I believe I've heard people say that they might sometimes want this
for power management, i.e. performing the same computation on the GPU
might take more power than performing it more slowly on the CPU. I
imagine this would depend on the specific configuration and
computations involved, though.

-- Dirk

From ian at hixie.ch  Mon Aug  2 18:54:28 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 01:54:28 +0000 (UTC)
Subject: [whatwg] Input URL State and Files object
In-Reply-To: <4BE1CCD9.1030005@jumis.com>
References: <4BE15D7B.7060009@jumis.com>
	<Pine.LNX.4.64.1005051942080.8532@ps20323.dreamhostps.com>
	<4BE1CCD9.1030005@jumis.com>
Message-ID: <Pine.LNX.4.64.1008030153100.7470@ps20323.dreamhostps.com>

On Wed, 5 May 2010, Charles Pritchard wrote:
> On 5/5/2010 12:42 PM, Ian Hickson wrote:
> > On Wed, 5 May 2010, Charles Pritchard wrote:
> > >
> > > Awhile ago, it appears, the "files" object was removed from <input 
> > > type="url">
> >
> > "files" doesn't really make much sense for type=url... Do you mean 
> > type=file?
>
> Sorry, it didn't make much sense: I meant a FileList object which 
> FileReader would use.

I still don't really see what you want here.


> > > Is there currently a method for allowing cross-domain access to an 
> > > image based on user input?
> >
> > XMLHttpRequest is the intended way to do this.
>
> XMLHttpRequest relies upon CORS headers from the server

Yes. We would have to rely on CORS whatever the solution was to be.


> Should a user intentional drag an image or URL object, or otherwise 
> select one from their browser UI, the interaction is quite similar to 
> the <input type="file"> object. Only, with a remote resource.

Is this a common occurance?


> I'm sorry to have approached this so poorly; what I'm looking for is a 
> solution to the following use case:
> 
> A person is assembling a digital scrap-book, using a web application, of 
> pictures they've found related to their love of kittens. Those that 
> they've downloaded to their computer, they simply drag and drop into the 
> application -- (File API, FileReader, ondrop). Those that they find on 
> the internet, they drag their bookmark onto the application, drag the 
> image onto the application, or simply, copy and paste the URL into an 
> <input type="url"> box.

Oh, you mean the ability for the user to give the page access to remote 
resources that themselves aren't opting in to giving the page access.

Why wouldn't <input type=file> be usable for this? You should be able to 
drag any file to that, just like you can type in a URL in Windows in an 
open file dialog box.

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

From jamesr at google.com  Mon Aug  2 18:54:34 2010
From: jamesr at google.com (James Robinson)
Date: Mon, 2 Aug 2010 18:54:34 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
	<AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
Message-ID: <AANLkTimdUs4YyRtCt5ZmOLVtqZ4jGX+4WDvR9sOaNOzQ@mail.gmail.com>

On Mon, Aug 2, 2010 at 6:43 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> On Mon, Aug 2, 2010 at 5:53 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Sat, 1 May 2010, ryan14 at mail.com wrote:
> >>
> >> My suggestion for the HTML5 spec is that the video tag should have a
> >> feature that can enable GPU acceleration on a user's graphics card, so
> >> it will take some stress off the CPU.
> >>
> >> Do you like my suggestion?
> >
> > Why would a user ever want anyone to disable their GPU acceleration?
> >
>
> I believe I've heard people say that they might sometimes want this
> for power management, i.e. performing the same computation on the GPU
> might take more power than performing it more slowly on the CPU. I
> imagine this would depend on the specific configuration and
> computations involved, though.
>

That's a decision for either a user or a user agent, not an author.  It
should not be toggleable from HTML.

- James



>
> -- Dirk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100802/fee75650/attachment-0001.htm>

From dpranke at chromium.org  Mon Aug  2 18:55:37 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Mon, 2 Aug 2010 18:55:37 -0700
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <Pine.LNX.4.64.1008030057200.7470@ps20323.dreamhostps.com>
References: <y2peed7f4a91005070307n4fbea881y4ff879b7088aaa2e@mail.gmail.com>
	<Pine.LNX.4.64.1008030057200.7470@ps20323.dreamhostps.com>
Message-ID: <AANLkTinV--JrGQ9id4faueb1kcUGntYrNjX7ic-UZdK7@mail.gmail.com>

On Mon, Aug 2, 2010 at 6:12 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> This thread primarily discussed ways to allow users to log in and out of
> sites, possibly through improvements to the forms model.
>
> This is an area that seems to be under a lot of active research, so it's
> probably premature to change the HTML spec at this point. I haven't
> introduced any new form types.
>
> Some comments on a few of the specific points raised:
>
> On Tue, 4 May 2010, Eitan Adler wrote:
>>
>> Use cases:
>> 1) A screen reader that sees a form with a type=username and a
>> password field. The screen reader could just ask "Log in to this site?
>> [y/n]?". No further context would be needed.
>
> My browsers already do this on many of my sites; why can't an AT?
>
>
>> 2) UAs can more easily discover login forms and offer things such as
>> Firefox's Account Manager [1] or a "remember me" feature
>
> There are a variety of ways this can be done today (e.g. the name="",
> id="", or class="" attributes; declarative descriptions as used by [1]; a
> <link rel> pointing to a form control; microformats; etc); a new input
> field type doesn't seem necessary to do this.
>
>
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails. Furthermore some websites offer a "find other members" feature
>> where you could type in a username. I've often seen these fields filled
>> in automatically with my name.
>
> Why would sites where this doesn't work today use a new feature to do
> this? Surely they can do this now already, so why aren't they doing it?
>

I suspect that this is usually a result of ignorance. I don't think
many content authors are aware of how form-fillers work.

>
>> [1] http://www.mozilla.com/en-US/firefox/accountmanager/
>
> On Tue, 4 May 2010, Steve Dennis wrote:
>> On 4/05/2010, at 9:07 AM, timeless wrote:
>> >
>> > Why would a site which doesn't cooperate with today's autofill
>> > features choose to cooperate with your proposal?
>>
>> Because id="username" isn't a standard as such. ?Having it specified in
>> a spec is likely to help people adopt it more quickly.
>
> RFC3106 has specified this since 2001, and has been implemented for a long
> time: https://tools.ietf.org/html/rfc3106
>
> It didn't seem to do much to make adoption happen more quickly.
>
> Why would this new idea make things go faster?
>

I'm not sure what you mean by "has been implemented for a long time".
I am not aware of any ecommerce site of any significant size
implementing this standard. Having been responsible for one such site
from roughly 2002-2008, I had never heard of this spec, nor have
several people that I would expect to have heard of it if it had ever
achieved any traction at all. This makes me suspect that this is not a
great example to hold up.

I think it is pretty well known that simply getting a document
published and declaring it a standard is not sufficient to ensuring
adoption, but not having a document published is certainly a deterrent
to adoption.

>
>> Saying "why bother?" about all the broken sites on the web totally
>> defeats the purpose of what everyone here's trying to achieve.
>
> Sure, but we can't help these sites without their cooperation. How do we
> get them to cooperate? We've tried standards (RFC3106), we've tried making
> the user experience better (password fillers). What else can we try?
> Another <input> doesn't seem to address this.
>

In the absence of any recommended convention that people are actually
aware of, sites will continue to make life difficult for password
managers and form-fillers. Encouraging people to follow a convention
would be a good thing, even if we have a large legacy problem that
would have to be addressed through other things.

Suggesting that people follow 3106 instead of creating a new input
type (which is I think what you're doing) is certainly one possible
solution here.

>
> On Tue, 4 May 2010, Dirk Pranke wrote:
>>
>> I think this idea is halfway to what I'd want to see. Namely, we should
>> add an <input type="login"> field that triggers a powerbox/dialog (much
>> like the <input type="file"> dialog) that can collect whatever sort of
>> credentials are needed (username / password, two-factor auth, FB connect
>> credentials, OpenID/OAuth credentials, etc.). I agree that it should
>> probably build on top of the Account Manager spec.
>>
>> I think the whole login process needs to be taken as out of page as
>> possible. Unfortunately, the auto-login mechanism in Mozilla's prototype
>> is probably too out of page, and so there should be a way to trigger the
>> login from an in-page element (hence the above).
>
> I strongly urge people to experiment in this area. This is the kind of
> thing that should precede standardisation.
>

Agreed; I think there is a lot of value in having a conversation about
how we might improve login flows on this list, but it is too early to
think that we can standardize on one particular implementation.
Perhaps the WHATWG needs an experimental track in addition to a
standards track?

-- Dirk

From ian at hixie.ch  Mon Aug  2 18:56:44 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 01:56:44 +0000 (UTC)
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
	<AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008030156220.3056@ps20323.dreamhostps.com>

On Mon, 2 Aug 2010, Dirk Pranke wrote:
> >
> > Why would a user ever want anyone to disable their GPU acceleration?
> 
> I believe I've heard people say that they might sometimes want this for 
> power management, i.e. performing the same computation on the GPU might 
> take more power than performing it more slowly on the CPU. I imagine 
> this would depend on the specific configuration and computations 
> involved, though.

This seems like a matter for the user, not the Web page, though.

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

From dpranke at chromium.org  Mon Aug  2 19:05:56 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Mon, 2 Aug 2010 19:05:56 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <Pine.LNX.4.64.1008030156220.3056@ps20323.dreamhostps.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
	<AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
	<Pine.LNX.4.64.1008030156220.3056@ps20323.dreamhostps.com>
Message-ID: <AANLkTinQPasJ_H30CGisOFfUdQonX8B-yrWgo-zGU0ou@mail.gmail.com>

On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>> >
>> > Why would a user ever want anyone to disable their GPU acceleration?
>>
>> I believe I've heard people say that they might sometimes want this for
>> power management, i.e. performing the same computation on the GPU might
>> take more power than performing it more slowly on the CPU. I imagine
>> this would depend on the specific configuration and computations
>> involved, though.
>
> This seems like a matter for the user, not the Web page, though.

Ah, I knew you were going to say this. I agree, but I can also imagine
that the way the user selects this is by choosing one of two different
resources from a page, just like we do today for videos of different
bandwidths.

-- Dirk

From ian at hixie.ch  Mon Aug  2 19:09:00 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 02:09:00 +0000 (UTC)
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <AANLkTinQPasJ_H30CGisOFfUdQonX8B-yrWgo-zGU0ou@mail.gmail.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
	<AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
	<Pine.LNX.4.64.1008030156220.3056@ps20323.dreamhostps.com>
	<AANLkTinQPasJ_H30CGisOFfUdQonX8B-yrWgo-zGU0ou@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008030207380.3056@ps20323.dreamhostps.com>

On Mon, 2 Aug 2010, Dirk Pranke wrote:
> On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 2 Aug 2010, Dirk Pranke wrote:
> >> >
> >> > Why would a user ever want anyone to disable their GPU acceleration?
> >>
> >> I believe I've heard people say that they might sometimes want this for
> >> power management, i.e. performing the same computation on the GPU might
> >> take more power than performing it more slowly on the CPU. I imagine
> >> this would depend on the specific configuration and computations
> >> involved, though.
> >
> > This seems like a matter for the user, not the Web page, though.
> 
> Ah, I knew you were going to say this. I agree, but I can also imagine 
> that the way the user selects this is by choosing one of two different 
> resources from a page, just like we do today for videos of different 
> bandwidths.

It seems better to have a way for the user agent to automaically negotiate 
the right bandwidth usage based on user preference, too.

Any setting like this that we offer authors _will_ be misused, possibly as 
often as used correctly. Unless there's a really compelling reason to have 
it, it seems better to let the user be in control.

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

From ian at hixie.ch  Mon Aug  2 19:09:53 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 02:09:53 +0000 (UTC)
Subject: [whatwg] Expanding the cite element
In-Reply-To: <FD248B7D-9A28-4CD3-8915-CF0003E5B925@indiana.edu>
References: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
	<m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>
	<A695BF56-E39E-4C65-B2B3-BDC14999F6F0@indiana.edu>
	<AANLkTimBOQZVVgaa6fTiUWFUm2cJf03-TA8Lpns6j-te@mail.gmail.com>
	<FD248B7D-9A28-4CD3-8915-CF0003E5B925@indiana.edu>
Message-ID: <Pine.LNX.4.64.1008030157360.7470@ps20323.dreamhostps.com>

On Wed, 5 May 2010, Simpson, Grant Leyton wrote:
>
> Is there any value in adding an "href" or "uri" or similar attribute to 
> the <cite> element to indicate a location for a work (or information 
> about the work) or, in the case of a URI, an indicator that can be used 
> as a reference programmatically?

I don't know; is there? What would the use case be?


> <q> has a "cite" attribute, so it seems to me that if we have a place to 
> link to further information in <q> it makes sense to do so in <cite>.

To be honest, <q cite> hasn't been very successful. One could argue it is 
a failed experiment. :-) If it wasn't more or less harmless, I'd probably 
be arguing to remove it.


> If it were a URI (and therefore not necessarily retrievable), it would 
> help in cases where the same work gets referenced in slightly different 
> ways:
> 
> <p>As Ashley Crandall Amos says in <cite 
> uri="http://example.com/books/crandall/linguisticmeans">Linguistic Means 
> of Determining the Dates of Old English Literary Texts</cite> ... Amos 
> also mentions in <cite 
> uri="http://example.com/books/crandall/linguisticmeans">Linguistic 
> Means</cite></p>

Works tend to have as many different URIs to reference them as titles, 
sometimes more. :-)


On Thu, 6 May 2010, Edward O'Connor wrote:
> 
> <cite uri> has a much worse fallback story than simply embedding a link 
> in <cite>.
> 
> > <p>As Ashley Crandall Amos says in <cite 
> > uri="http://example.com/books/crandall/linguisticmeans">Linguistic 
> > Means of Determining the Dates of Old English Literary Texts</cite> 
> > ... Amos also mentions in <cite 
> > uri="http://example.com/books/crandall/linguisticmeans">Linguistic 
> > Means</cite></p>
> 
> Consider how the above would work in legacy browsers, and then consider 
> how this would work in them:
> 
> <p>As Ashley Crandall Amos says in <cite><a 
> href="http://example.com/books/crandall/linguisticmeans">Linguistic 
> Means of Determining the Dates of Old English Literary Texts</a></cite> 
> ... Amos also mentions in <cite><a 
> href="http://example.com/books/crandall/linguisticmeans">Linguistic 
> Means</a></cite></p>

Using <a> does seem like it would solve this neatly without additional 
effort.


On Thu, 6 May 2010, Schalk Neethling wrote:
>
> I guess this is the 'Paving the cowpaths' situation. Is there a 
> 'standard' where most developers do as in the sample by Ted?

That's a good question; have people found this useful enough to work 
around the lack of an attribute here? If not, maybe there's no problem to 
solve in the first place.


On Fri, 7 May 2010, Simpson, Grant Leyton wrote:
> 
> 1. Referencing something in the href attributed of an <a> tag implies 
> that the URI will resolve to a URL, that is, that it will be accessible 
> on the web at that address. Not every URI is a URL, though. That's what 
> I was trying to do with a "uri" attribute for the <cite> tag is to 
> identify the resource, not necessarily link to it.

Any link could be resolved; for example the browser could have a handler 
for isbn: links that looks up the book on Amazon or Google Books.


> 2. We would have to formally define what <a> within <cite> means, 
> otherwise we would leave the pairing up for interpretation.

Until we know that this is a problem people really want solving, that's 
probably ok.


> 3. Are there instances where tags that can be used separately take on a 
> different meaning in relation to one another?  I know what <li> means in 
> relation to <ol> and <ul>, but then again, I can't really use <li> 
> outside of either of those two.

<a> wouldn't take on a different meaning, it would just add additional 
information to the page.


On Sat, 8 May 2010, Benjamin Hawkes-Lewis wrote:
>
> I'm not opposed to adding @cite to <cite> but note that when you are 
> identifying a resource rather than linking to a resource, you could use 
> microdata or RDFa.
> 
> For example:
> 
>    http://dev.w3.org/html5/md/#global-identifiers-for-items
> 
>    http://rdfa.info/wiki/Rdfa-microdata-markup-comparison#Book_markup_with_ISBN_and_description

Indeed, that may be a better solution in general.


> > 2. We would have to formally define what <a> within <cite> means, 
> > otherwise we would leave the pairing up for interpretation.
> 
> You stated that you want to "indicate a location for a work (or 
> information about the work)".
> 
> A hyperlink indicates the location of an item or information about an 
> item, and "a href" creates a hyperlink.
> 
> What could be the other interpretations of <cite><a href="...">Work 
> title</a></cite> or <a href="..."><cite>Work title</cite></a> other than 
> that the hyperlink locates the work or information about the work?

Indeed.


> > 3. Are there instances where tags that can be used separately take on 
> > a different meaning in relation to one another?  I know what <li> 
> > means in relation to <ol> and <ul>, but then again, I can't really use 
> > <li> outside of either of those two.
> 
> I think the combination of "cite" and "a" to indicate a work title and 
> the location of the work or information about the work does not involve 
> changing the meaning of either "cite" or "a". This is the markup 
> equivalent of:
> 
>    http://en.wikipedia.org/wiki/Object_composition

Right.


On Mon, 10 May 2010, Simpson, Grant Leyton wrote:
>
> I was unaware of the Microdata spec.  Now that I have seen it, I think 
> it offers a lot of power and flexibility.  I think it should adequately 
> cover the use case I was thinking of.

Excellent!


> I'm in favor of adding a non-normative note to the section of the HTML5 
> spec that discusses <cite> that demonstrates how Microdata or RDFa could 
> be used for this purpose.  There will likely be other people like me who 
> read the <cite> section of the spec and think "What? I can't actually 
> make the citation point to something?"

Do you have a suggested example of how you've ended up using this? I 
prefer to use real-world examples where possible for this kind of thing.

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

From dpranke at chromium.org  Mon Aug  2 19:20:24 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Mon, 2 Aug 2010 19:20:24 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <Pine.LNX.4.64.1008030207380.3056@ps20323.dreamhostps.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
	<AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
	<Pine.LNX.4.64.1008030156220.3056@ps20323.dreamhostps.com>
	<AANLkTinQPasJ_H30CGisOFfUdQonX8B-yrWgo-zGU0ou@mail.gmail.com>
	<Pine.LNX.4.64.1008030207380.3056@ps20323.dreamhostps.com>
Message-ID: <AANLkTi=YiiR-ueZ3x+8rTe=q+aRYajufZqKkZGb_5oYT@mail.gmail.com>

On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>> On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Mon, 2 Aug 2010, Dirk Pranke wrote:
>> >> >
>> >> > Why would a user ever want anyone to disable their GPU acceleration?
>> >>
>> >> I believe I've heard people say that they might sometimes want this for
>> >> power management, i.e. performing the same computation on the GPU might
>> >> take more power than performing it more slowly on the CPU. I imagine
>> >> this would depend on the specific configuration and computations
>> >> involved, though.
>> >
>> > This seems like a matter for the user, not the Web page, though.
>>
>> Ah, I knew you were going to say this. I agree, but I can also imagine
>> that the way the user selects this is by choosing one of two different
>> resources from a page, just like we do today for videos of different
>> bandwidths.
>
> It seems better to have a way for the user agent to automaically negotiate
> the right bandwidth usage based on user preference, too.
>
> Any setting like this that we offer authors _will_ be misused, possibly as
> often as used correctly. Unless there's a really compelling reason to have
> it, it seems better to let the user be in control.

If users can choose between two links on a page labelled "high FPS -
will destroy your battery" and "low FPS", they are in control, in a
way that is easily understood by the user and allows them to make the
choice at the point in time that it matters. Compare this with
changing the streaming settings on QT Player or Windows Media Player,
or even toggling the "use the video card" button on your laptop (and
hoping that the content is smart enough to degrade gracefully instead
of choking).

We've seen this exact same argument play out over the last fifteen
years in video on the web. The technology for detecting and adjusting
bandwidth dynamically has been around forever (actually implemented,
even), and yet for every one multi-bitrate stream available on the
web, I imagine there are very many more that are single-bitrate. A big
part of the reason for this is because doing it this way is (in my
opinion) a better user experience.

That said, I do also agree that it opens up the possibility for abuse
or incorrect usage (just like it's possible to send a HD stream down a
modem line). And, I'm not actually advocating a solution here one way
or another, just attempting to answer your question.

-- Dirk

From bzbarsky at MIT.EDU  Mon Aug  2 21:13:17 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 03 Aug 2010 00:13:17 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <Pine.LNX.4.64.1008022113330.3056@ps20323.dreamhostps.com>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C56DFEE.3040602@mit.edu>
	<Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>
	<4C571EF6.5010206@mit.edu>
	<Pine.LNX.4.64.1008022113330.3056@ps20323.dreamhostps.com>
Message-ID: <4C57975D.5070405@mit.edu>

On 8/2/10 5:20 PM, Ian Hickson wrote:
>> Or does "stop the currently running task" in #spin-the-event-loop imply
>> a jump to step 2 of the algorithm under #processing-model2?
>
> Yes.

OK, that might be worth clarifying.

>> (Note: I still have a problem with the way "pause" is defined here, but
>> I've raised that before, I believe.)
>
> I think we all have a problem with "pause", but I don't know what we can
> do about it. I don't have any pending feedback from you on this topic, as
> far as I can tell.

Odd.  I definitely sent something about it (in particular that it 
doesn't seem very easily implementable in terms of network event 
behavior, if the pause is waiting on a network event and other network 
events need to not be delivered in the meantime).

-Boris


From whatwg at fowlsmurf.net  Mon Aug  2 22:06:35 2010
From: whatwg at fowlsmurf.net (James May)
Date: Tue, 3 Aug 2010 15:06:35 +1000
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <AANLkTikcgaUfgXTfJAb80kuecZ0Gue=2C9ciJoKMPJHM@mail.gmail.com>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com> 
	<op.vgtiz3g048yz2f@dennis> <0097F4E418EA47BBAF9C9433340158C6@NETBOOK> 
	<AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com> 
	<4C57026B.2020806@mit.edu>
	<AANLkTikcgaUfgXTfJAb80kuecZ0Gue=2C9ciJoKMPJHM@mail.gmail.com>
Message-ID: <AANLkTi=X8bKF0kY5dy5UE_aeYGRF8E7vV3S_0KnTKpsL@mail.gmail.com>

Perhaps to avoid the "legacy baggage" it could be a simple attribute

eg. <a href="blah" download>

This would prevent duplicating 'type', and bringing in all the
"knowledge" people seem to not have about how 'content-disposition'
works in headers.

or even an extension of target?

eg. <a href="blah" target="_save">

Then it would be clear that it's only a hint, like the other target values.

-- James

(I accidentally sent this to the wrong address before sorry for the dupe)

On 3 August 2010 03:37, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 8/2/10 1:15 PM, Aryeh Gregor wrote:
>>
>> If you don't agree that this use-case is worth adding the feature for,
>> do you think that:
>> 3) Something else?
>
> For the use case your describe, it might just make more sense for browsers
> to support Content-Disposition on data: URIs directly somehow... ?Maybe.
>
> -Boris
>

From chuck at jumis.com  Mon Aug  2 22:26:09 2010
From: chuck at jumis.com (Charles Pritchard)
Date: Mon, 02 Aug 2010 22:26:09 -0700
Subject: [whatwg] Input URL State and Files object
In-Reply-To: <Pine.LNX.4.64.1008030153100.7470@ps20323.dreamhostps.com>
References: <4BE15D7B.7060009@jumis.com>
	<Pine.LNX.4.64.1005051942080.8532@ps20323.dreamhostps.com>
	<4BE1CCD9.1030005@jumis.com>
	<Pine.LNX.4.64.1008030153100.7470@ps20323.dreamhostps.com>
Message-ID: <4C57A871.6020001@jumis.com>

On 8/2/2010 6:54 PM, Ian Hickson wrote:
> On Wed, 5 May 2010, Charles Pritchard wrote:
>    
>> Sorry, it didn't make much sense: I meant a FileList object which
>> FileReader would use.
>>      
> I still don't really see what you want here.
>    
>>>> Is there currently a method for allowing cross-domain access to an
>>>> image based on user input?
>>>>          
>>> XMLHttpRequest is the intended way to do this.
>>>        
>> XMLHttpRequest relies upon CORS headers from the server
>>      
> Yes. We would have to rely on CORS whatever the solution was to be.
>
>    
>> I'm sorry to have approached this so poorly; what I'm looking for is a
>> solution to the following use case:
>>
>> A person is assembling a digital scrap-book, using a web application, of
>> pictures they've found related to their love of kittens. Those that
>> they've downloaded to their computer, they simply drag and drop into the
>> application -- (File API, FileReader, ondrop). Those that they find on
>> the internet, they drag their bookmark onto the application, drag the
>> image onto the application, or simply, copy and paste the URL into an
>> <input type="url">  box.
>>      
> Oh, you mean the ability for the user to give the page access to remote
> resources that themselves aren't opting in to giving the page access.
>
> Why wouldn't<input type=file>  be usable for this? You should be able to
> drag any file to that, just like you can type in a URL in Windows in an
> open file dialog box.
>    
<input type="file"> would be usable.

Were this implemented:

When a user through selection, click+drag or manual entry of a URL
should the browser still submit an Origin request header? It seems that 
CORS doesn't come
into effect here -- but at the same time, it'd be handy for logging 
purposes and added security.

When a cross-site resource is fetched via CORS, the agent submits an 
"Origin" header.
A secure site (such as a bank), may always return a Forbidden response 
if the "Origin" header is set;
blocking any kind of cross-site sharing, even sharing attempted by a 
user (through an <input type="file"> field).








From whatwg at fowlsmurf.net  Mon Aug  2 23:18:15 2010
From: whatwg at fowlsmurf.net (James May)
Date: Tue, 3 Aug 2010 16:18:15 +1000
Subject: [whatwg] Input URL State and Files object
In-Reply-To: <4C57A871.6020001@jumis.com>
References: <4BE15D7B.7060009@jumis.com>
	<Pine.LNX.4.64.1005051942080.8532@ps20323.dreamhostps.com> 
	<4BE1CCD9.1030005@jumis.com>
	<Pine.LNX.4.64.1008030153100.7470@ps20323.dreamhostps.com> 
	<4C57A871.6020001@jumis.com>
Message-ID: <AANLkTikUtNZd9+QRFj49fAUL3cgi9vB5V5xhrxG6_GKO@mail.gmail.com>

>> Why wouldn't<input type=file> ?be usable for this? You should be able to
>> drag any file to that, just like you can type in a URL in Windows in an
>> open file dialog box.
>>
>
> <input type="file"> would be usable.
>
> Were this implemented:
>
> When a user through selection, click+drag or manual entry of a URL
> should the browser still submit an Origin request header? It seems that CORS
> doesn't come
> into effect here -- but at the same time, it'd be handy for logging purposes
> and added security.
>
> When a cross-site resource is fetched via CORS, the agent submits an
> "Origin" header.
> A secure site (such as a bank), may always return a Forbidden response if
> the "Origin" header is set;
> blocking any kind of cross-site sharing, even sharing attempted by a user
> (through an <input type="file"> field).
>

On Windows at least, when put a URL in the open dialog the shell
downloads it then passes a temporary file. The browser never gets the
source URL - so it'd be difficult without re-implementing the dialog
(undesirable).  Plus user control, and all that.


-- James

From philipj at opera.com  Tue Aug  3 01:27:10 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Tue, 03 Aug 2010 10:27:10 +0200
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C57495A.9020800@pearce.org.nz>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C57495A.9020800@pearce.org.nz>
Message-ID: <op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>

On Tue, 03 Aug 2010 00:40:26 +0200, Chris Pearce <chris at pearce.org.nz>  
wrote:

>   On 2/08/2010 9:17 p.m., Ian Hickson wrote:
>> On Mon, 2 Aug 2010, Chris Pearce wrote:
>>> There's a race condition in the media load algorithm. When the resource
>>> selection algorithm begins, it sets a task to complete the rest of the
>>> resource selection algorithm asynchronously.
>> Not quite. It awaits a stable state and then runs a synchronous section,
>> which means that it will run the subsequent steps as soon as the current
>> task has finished, before anything else that is queued.
>>
>
> Ah, I see. My understanding of the processing model was incomplete,  
> thanks for clarifying!

For the record, here's how I interpreted "await a stable state":

The only state that is not stable is a running script. The only step in  
any video-related algorithm one can reach from a script is step 2 of the  
resource selection algorithm. Therefore, when reaching that step, if the  
resource selection algorithm was triggered by a script, wait until that  
script has finished and then continue. The only somewhat tricky part is  
that if we are in an event handler triggered by script, we should wait  
until the script that triggered the event handler has finished. The only  
way I know of triggering this corner case is by invoking a synchronous  
event handler from script, e.g. by calling click().

All other occurrences of "await a stable state" I've ignored as we can't  
not be in a stable state when reaching them.

-- 
Philip J?genstedt
Core Developer
Opera Software

From derernst at gmx.ch  Tue Aug  3 02:58:41 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Tue, 03 Aug 2010 11:58:41 +0200
Subject: [whatwg] Please consider simplifying authoring guidance for the
 <img> alt attribute
In-Reply-To: <1280775281.2323.7.camel@localhost>
References: <AANLkTin6bKoDf=y8nuLtgp1Urr+YG2ZSFZSTZQ0tQuo-@mail.gmail.com>	
	<4C56E1EE.1030304@gmx.ch> <1280775281.2323.7.camel@localhost>
Message-ID: <4C57E851.3030706@gmx.ch>

Am 02.08.2010 20:54 schrieb Ashley Sheridan:
> On Mon, 2010-08-02 at 17:19 +0200, Markus Ernst wrote:
>> - search engines should generally ignore text in the alt attribute, but
>> evaluate the title attribute instead
>>
>> Rationale:
>>
>> 4.8.1.1.12 says: "A corollary to this is that the alt attribute's value
>> should never contain text that could be considered the image's caption,
>> title, or legend. It is supposed to contain replacement text that could
>> be used by users instead of the image; it is not meant to supplement the
>> image. The title attribute can be used for supplemental information."
> 
> What you said doesn't make sense. The alt text is to be used instead of 
> the image, and the title is for supplemental content. Therefore, search 
> engines should use alt text, as that is what they are attempting to 
> convey in the lost (in the sense that search engines don't process 
> images like they do text) image. If they used the title, one can only 
> imagine the trouble.

Ok, maybe the search engine aspect obfuscates the main statement I 
wanted to make; let's just drop it and try to be some more specific.

4.8.1.1 says: "Except where otherwise specified, the alt attribute must 
be specified and its value must not be empty; the value must be an 
appropriate replacement for the image. The specific requirements for the 
alt attribute depend on what the image is intended to represent, as 
described in the following sections."

In the sub sections, many cases are stated where the alt attribute must 
be set to the empty string, and some cases where the alt attribute can 
even be omitted. These seem to be the ones that are considered to be too 
complicated.

My point is, that it would simplify things (e.g. the cases treated in 
the links Tantek provided) a lot to do it the other way around:
- Declare the alt attribute as optional, and default a missing alt 
attribute to alt=""
- Explicitly specify the cases where the alt attribute must be set 
(e.g.: if the image is the only child of an <a> or <h1-6> element)
- Update some of the authoring guidance in the sense of encouraging 
authors to apply alt text where appropriate, and omit it where not (I 
specially think of 4.8.1.1.9 here; I will post a separate proposal about 
this section)

I doubt that there is much benefit in the requirement for the alt 
attribute, for the following reasons:
- The paedagogig aspect of making a document invalid if an alt attribute 
is omitted is obsolete, as authors have got used to just insert alt="" 
if they are too lazy to write an alternative text, and many authoring 
tools even insert the empty string by default if the author does not 
specify an alt text. Bad authoring cannot be prevented by structural 
specification.
- I have no personal experience using screen readers or text-only 
browsers, but I am quite sure that unnecessary (not speaking of 
inadequate) alt text is not helpful, but even harmful as it interrupts 
the reading or listening flow. (If screen reader or braille browser 
users contradict me here, I am happy to learn, of course.)

From ash at ashleysheridan.co.uk  Tue Aug  3 03:07:50 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 03 Aug 2010 11:07:50 +0100
Subject: [whatwg] Please consider simplifying authoring guidance for the
 <img> alt attribute
In-Reply-To: <4C57E851.3030706@gmx.ch>
References: <AANLkTin6bKoDf=y8nuLtgp1Urr+YG2ZSFZSTZQ0tQuo-@mail.gmail.com>
	<4C56E1EE.1030304@gmx.ch> <1280775281.2323.7.camel@localhost>
	<4C57E851.3030706@gmx.ch>
Message-ID: <1280830070.2293.8.camel@localhost>

On Tue, 2010-08-03 at 11:58 +0200, Markus Ernst wrote:

> Am 02.08.2010 20:54 schrieb Ashley Sheridan:
> > On Mon, 2010-08-02 at 17:19 +0200, Markus Ernst wrote:
> >> - search engines should generally ignore text in the alt attribute, but
> >> evaluate the title attribute instead
> >>
> >> Rationale:
> >>
> >> 4.8.1.1.12 says: "A corollary to this is that the alt attribute's value
> >> should never contain text that could be considered the image's caption,
> >> title, or legend. It is supposed to contain replacement text that could
> >> be used by users instead of the image; it is not meant to supplement the
> >> image. The title attribute can be used for supplemental information."
> > 
> > What you said doesn't make sense. The alt text is to be used instead of 
> > the image, and the title is for supplemental content. Therefore, search 
> > engines should use alt text, as that is what they are attempting to 
> > convey in the lost (in the sense that search engines don't process 
> > images like they do text) image. If they used the title, one can only 
> > imagine the trouble.
> 
> Ok, maybe the search engine aspect obfuscates the main statement I 
> wanted to make; let's just drop it and try to be some more specific.
> 
> 4.8.1.1 says: "Except where otherwise specified, the alt attribute must 
> be specified and its value must not be empty; the value must be an 
> appropriate replacement for the image. The specific requirements for the 
> alt attribute depend on what the image is intended to represent, as 
> described in the following sections."
> 
> In the sub sections, many cases are stated where the alt attribute must 
> be set to the empty string, and some cases where the alt attribute can 
> even be omitted. These seem to be the ones that are considered to be too 
> complicated.
> 
> My point is, that it would simplify things (e.g. the cases treated in 
> the links Tantek provided) a lot to do it the other way around:
> - Declare the alt attribute as optional, and default a missing alt 
> attribute to alt=""
> - Explicitly specify the cases where the alt attribute must be set 
> (e.g.: if the image is the only child of an <a> or <h1-6> element)
> - Update some of the authoring guidance in the sense of encouraging 
> authors to apply alt text where appropriate, and omit it where not (I 
> specially think of 4.8.1.1.9 here; I will post a separate proposal about 
> this section)
> 
> I doubt that there is much benefit in the requirement for the alt 
> attribute, for the following reasons:
> - The paedagogig aspect of making a document invalid if an alt attribute 
> is omitted is obsolete, as authors have got used to just insert alt="" 
> if they are too lazy to write an alternative text, and many authoring 
> tools even insert the empty string by default if the author does not 
> specify an alt text. Bad authoring cannot be prevented by structural 
> specification.
> - I have no personal experience using screen readers or text-only 
> browsers, but I am quite sure that unnecessary (not speaking of 
> inadequate) alt text is not helpful, but even harmful as it interrupts 
> the reading or listening flow. (If screen reader or braille browser 
> users contradict me here, I am happy to learn, of course.)


If the content of the alt attribute is interrupting the flow of the
text, then it is either not describing the image it represents well, or
the image is not something which should appear in the flow of text at
that position. HTML5 brings many new layout devices which can help lay
out the code in a logical and coherent manner, while still rendering on
screen in the traditional manner. I do test thing in text browsers, and
frequently see bad alt text markup on sites along the lines of
alt="Company Logo" or somesuch, where in-fact it should have read
alt="ACME Trading Co." because that is the text that was on the image
anyway.

I agree that there is a lot of bad markup out there with lots of empty
alt attributes, inserted only to pass the validators, but I think making
the attribute optional would just cause further accessibility issues.
Better to improve the validators to give warnings about empty alt
attributes (only warnings rather than outright errors) to notify the
developer that there could be a potential issue with the markup.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100803/15ad7750/attachment-0001.htm>

From derernst at gmx.ch  Tue Aug  3 03:55:06 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Tue, 03 Aug 2010 12:55:06 +0200
Subject: [whatwg] Proposal for an addition to the authoring guidance
 regarding the alt attribute
Message-ID: <4C57F58A.3060409@gmx.ch>

Section 4.8.1.1.9 describes how alternative text for content images 
should be written: 
http://www.w3.org/TR/html5/embedded-content-1.html#a-key-part-of-the-content

Then, there is a general guideline about writing alternative texts in 
section 4.8.1.1.12: "A corollary to this is that the alt attribute's 
value should never contain text that could be considered the image's 
caption, title, or legend. It is supposed to contain replacement text 
that could be used by users instead of the image; it is not meant to 
supplement the image. The title attribute can be used for supplemental 
information."

IMO the wording of 4.8.1.1.9 is somehow contradictive to the general 
guidance in two cases:

1. The image is the information itself, it does not convey any 
information beyond it's visuals. This is a very common case, for example 
in photo galleries. Unlike the examples given under "The general case" 
(where lack of the image is lack of information), the images in a 
wedding photo gallery cannot be described in a way that matches 
4.8.1.1.12 and provides any useful information for e.g. a blind user. 
The information "Me, Gary, and his parents eating the cake" is rather 
useful for those who actually see the image, and should go to the 
caption, as correctly stated in 4.8.1.1.12.

2. The image illustrates what is discussed in the surrounding text, or 
has a caption describing it. Inserting alt text would actually duplicate 
the information, but not convey anything useful for those who don't see 
the image. IMO alternative text should be omitted in this case (as e.g. 
Wikipedia does: http://en.wikipedia.org/wiki/Squirrel - the alt 
attribute values of all content images are empty).

So I propose to:
- Explicitly treat these two cases in 4.8.1.1.9, requiring to insert no 
alt text there
- In the part "Images whose contents are not known", remove the word 
"unfortunate" at the beginning ("In some cases"), and the first note.

(Apparently, the W3C itself is not so sure about alt text in content 
images; http://www.w3.org/Consortium/mission illustrates this: There is 
a picture of Tim Berners-Lee, with no direct reference in the text. It 
does not seem to be decorative, as according to 4.8.1.1.6 the alt 
attribute should be empty in this case; but the alt text says: "Tim 
Berners-Lee speaking at W3C10", which is not an information conveyed by 
the image itself if you don't know how Tim Berners-Lee looks like. Thus, 
according to 4.8.1.1.9, this information should be displayed in a 
caption, and the alt attribute should say something like "A male speaker 
in front of a display containing the text 'W3C10 Tenth Anniversary' and 
some sponsor logos" - which is of course stupid. The empty string would 
IMO be the appropriate value for the alt attribute here.)

From timeless at gmail.com  Tue Aug  3 05:51:32 2010
From: timeless at gmail.com (timeless)
Date: Tue, 3 Aug 2010 15:51:32 +0300
Subject: [whatwg] Input URL State and Files object
In-Reply-To: <AANLkTikUtNZd9+QRFj49fAUL3cgi9vB5V5xhrxG6_GKO@mail.gmail.com>
References: <4BE15D7B.7060009@jumis.com>
	<Pine.LNX.4.64.1005051942080.8532@ps20323.dreamhostps.com>
	<4BE1CCD9.1030005@jumis.com>
	<Pine.LNX.4.64.1008030153100.7470@ps20323.dreamhostps.com>
	<4C57A871.6020001@jumis.com>
	<AANLkTikUtNZd9+QRFj49fAUL3cgi9vB5V5xhrxG6_GKO@mail.gmail.com>
Message-ID: <AANLkTimOJJvnv7AnDNxfhiPAKb3RVnPacU-Y_WnxVaQT@mail.gmail.com>

On Tue, Aug 3, 2010 at 9:18 AM, James May <whatwg at fowlsmurf.net> wrote:
> On Windows at least, when put a URL in the open dialog the shell
> downloads it then passes a temporary file. The browser never gets the
> source URL - so it'd be difficult without re-implementing the dialog
> (undesirable). ?Plus user control, and all that.

Actually, this is not a mandatory feature of the Windows file picker,
the application can provide its own handling if it so wishes.

Whether that applies to other platforms' file pickers, I'm not certain.

From svartman95 at gmail.com  Tue Aug  3 08:21:36 2010
From: svartman95 at gmail.com (bjartur)
Date: Tue, 03 Aug 2010 15:21:36 +0000
Subject: [whatwg] [URL] Starting work on a URL spec
In-Reply-To: <4C4C3F87.6050408@mit.edu>
References: <AANLkTikBCEGJC4PNVB=m09GxSHAr4H=frYUcgXax9_AN@mail.gmail.com>
	<AANLkTi=DDow5fP-+-fvaZNdK0afitkigZtHBEyS9Dod=@mail.gmail.com>
	<4C4A65D5.2000000@mit.edu>
	<AANLkTi=88AtQTJroZUuC5ihX5jqOuj5RL4nop7Cm5eSr@mail.gmail.com>
	<AANLkTi=7-oMG9g43cC0E0ee_TrOQf2L4ZBvE-Y=tDsUi@mail.gmail.com>
	<083933CF-BEA0-4DE7-91CC-F1E41593F7EA@apple.com>
	<AANLkTi=g3jrC8bvoigrQBY-SQ-4GeoM+mZtasp2V-Rmf@mail.gmail.com>
	<4C4C3F87.6050408@mit.edu>
Message-ID: <4c583416.0315e30a.5b04.0af7@mx.google.com>

> On 7/25/10 8:57 AM, Adam Barth wrote:
> >> There's also the related question of what browsers should do with input typed into the URL field. Other than establishing that these rules may be different between the URL field and URLs present in content, I'm not sure this is amenable to spec. But perhaps a survey of what browsers do would be useful.
> >
> > I wasn't planning to cover that because it's not a critical to
> > interoperability
> 
> Unfortunately, it is.  In particular, servers need to know what to
> expect the browser to send if a user types non-ASCII into the url bar.
> There are real interoperability problems out there due to differing
> server and browser behavior in this regard.
> 
> It may not be an _html_ interoperability problem, but it's certainly a
> _web_ interoperability problem.
> 
It's a question of how HTTP messages are encoded (and in special the encoding of the IRI).
WHATWG does not specify HTTP, these concerns should be directed to IETF.

From w3c at adambarth.com  Tue Aug  3 08:38:28 2010
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 3 Aug 2010 08:38:28 -0700
Subject: [whatwg] [URL] Starting work on a URL spec
In-Reply-To: <4c583416.0315e30a.5b04.0af7@mx.google.com>
References: <AANLkTikBCEGJC4PNVB=m09GxSHAr4H=frYUcgXax9_AN@mail.gmail.com> 
	<AANLkTi=DDow5fP-+-fvaZNdK0afitkigZtHBEyS9Dod=@mail.gmail.com> 
	<4C4A65D5.2000000@mit.edu>
	<AANLkTi=88AtQTJroZUuC5ihX5jqOuj5RL4nop7Cm5eSr@mail.gmail.com> 
	<AANLkTi=7-oMG9g43cC0E0ee_TrOQf2L4ZBvE-Y=tDsUi@mail.gmail.com> 
	<083933CF-BEA0-4DE7-91CC-F1E41593F7EA@apple.com>
	<AANLkTi=g3jrC8bvoigrQBY-SQ-4GeoM+mZtasp2V-Rmf@mail.gmail.com> 
	<4C4C3F87.6050408@mit.edu> <4c583416.0315e30a.5b04.0af7@mx.google.com>
Message-ID: <AANLkTimZj4gBPHyP13cUZZem8BCbqjEqY79GD2U6g5c7@mail.gmail.com>

On Tue, Aug 3, 2010 at 8:21 AM, bjartur <svartman95 at gmail.com> wrote:
>> On 7/25/10 8:57 AM, Adam Barth wrote:
>> >> There's also the related question of what browsers should do with input typed into the URL field. Other than establishing that these rules may be different between the URL field and URLs present in content, I'm not sure this is amenable to spec. But perhaps a survey of what browsers do would be useful.
>> >
>> > I wasn't planning to cover that because it's not a critical to
>> > interoperability
>>
>> Unfortunately, it is. ?In particular, servers need to know what to
>> expect the browser to send if a user types non-ASCII into the url bar.
>> There are real interoperability problems out there due to differing
>> server and browser behavior in this regard.
>>
>> It may not be an _html_ interoperability problem, but it's certainly a
>> _web_ interoperability problem.
>
> It's a question of how HTTP messages are encoded (and in special the encoding of the IRI).
> WHATWG does not specify HTTP, these concerns should be directed to IETF.

There are various ways to spec lawyer things so you can make this work
appear to be the responsibility of various folks.  The work needs to
be done.  I'm inclined to do the work first and worry about what
organization (if any) has "jurisdiction" later.

Adam

From bzbarsky at MIT.EDU  Tue Aug  3 08:40:33 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 03 Aug 2010 11:40:33 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>
References: <4C56245C.3080604@pearce.org.nz>	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>	<4C57495A.9020800@pearce.org.nz>
	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>
Message-ID: <4C583871.4020004@mit.edu>

On 8/3/10 4:27 AM, Philip J?genstedt wrote:
> For the record, here's how I interpreted "await a stable state":
>
> The only state that is not stable is a running script.

I don't think that's true; for example you could be in an unstable state 
if you're in the middle of the parser inserting some nodes into the DOM.

> Therefore, when reaching that step, if the
> resource selection algorithm was triggered by a script, wait until that
> script has finished and then continue.

Per spec as currently written, this will give the wrong behavior.  For 
example, if the script in question calls showModalDialog, this is 
supposed to interrupt the script task and spin the event loop, and so 
your synchronous section would need to run while the modal dialog is up. 
  It doesn't sound like your implementation does that.

-Boris

From svartman95 at gmail.com  Tue Aug  3 08:56:56 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 03 Aug 2010 15:56:56 +0000
Subject: [whatwg] Simple Links
In-Reply-To: <AANLkTi=hxj-j2=AmmR7QMrL+=p4OJM1jShh6So9SLRxi@mail.gmail.com>
References: <9B39B677-8E19-41BD-B843-50A902B44C10@crissov.de>
	<1269988113.23602.81.camel@localhost>
	<Pine.LNX.4.64.1007271900560.7470@ps20323.dreamhostps.com>
	<AANLkTi=hxj-j2=AmmR7QMrL+=p4OJM1jShh6So9SLRxi@mail.gmail.com>
Message-ID: <4c583c5f.9decd80a.16c9.ffffc980@mx.google.com>

> On Tue, Jul 27, 2010 at 3:13 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I also randomly picked a Wikipedia page (Potato) and looked at some of th=
> e
> > links there. The only link that matched that pattern on the whole page wa=
> s
> > in the footer that only gets displayed in the print media:
> >
> > =C2=A0 <div class=3D"printfooter"> Retrieved from "<a href=3D"http://en.w=
> ikipedia.org/wiki/Potato">http://en.wikipedia.org/wiki/Potato</a>"</div>
> 
It's also presented to unknown UAs (as Wikimedia assumes they're dumb bots).

> For what it's worth, this is because the href's in the articles
> themselves have /wiki/ prepended (<a href=3D"/wiki/Potato">, not <a
> href=3D"Potato">).  In turn, this is because the pages can actually be
> served from multiple directories: http://en.wikipedia.org/wiki/Potato
> is the same as http://en.wikipedia.org/w/index.php?title=3DPotato.
> (There are actually some differences at the moment if you do a diff,
> but that's because they're cached separately by Squid.  If you log in,
> the differences should disappear.)  So href=3D"Potato" would do the
> wrong thing in the latter case.
> 
> Indeed, in a dynamic web application, something like href=3D"Potato" is
> practically useless unless you can guarantee that you're always
> rewriting URLs to look pretty and conceal the actual script serving
> the request.  So in particular, MediaWiki could not use the proposed
> <a href> syntax.
> 
I consider the equivalence of /wiki/Potato and /w/index.php?title=Potato
a bug. Metadata such as the URI of the document can be served by various
means, such as the Location header in HTTP, and a seperate "base" URI to
use for relative linking can be specified with the <base> element in HTML.

> Ian Hickson:
> > On Tue, 30 Mar 2010, Christoph P=E4per wrote:
> >> I wonder whether HTML could and should provide some sort of similar =
> shortening, i.e. =93<a href>Foo</a>=94 or even, just maybe, =
> =93<a>Foo</a>=94.
> 
> I later came to the conclusion that this might be a nice thing for HTML =
> editors, but not for browsers.=20
> 
> If nothing else, it would probably be abused for comment spam, because =
> there probably are scripts out there that do not filter =91href=92-less =
> =91a=92-elements.
> 
> >> The UA would append the string content, properly encoded, to the base =
> Web address as the hyperlink=92s target, =85
> >=20
> > I (=85) couldn't find any pages that matched the pattern <a =
> href=3D"(.+)">$1</a>, =85
> 
> Um, that=92s not exactly what I meant, note =93append =85 to the base =
> Web address=94.
> 
> These are conversions I had in mind, assuming the location =
> <https://example.com/Bar/baz.html>:
> 
> derived href value
> <a href>Foo</a>            =3D> /Bar/Foo or ./Foo or Foo
> <a href>Foo.html</a>       =3D> /Bar/Foo.html or ./Foo.html or =
> Foo.html
> <a href>Foo.com</a>        =3D> /Bar/Foo.com or ./Foo.com or Foo.com
> <a href>Foo/</a>           =3D> /Bar/Foo/ or ./Foo/ or Foo/
> <a href>/Foo</a>           =3D> /Foo
> <a href>#Foo</a>           =3D> #Foo
> <a href>/</a>              =3D> /
> <a href>http://Foo.com</a> =3D> http://foo.com
> <a href>://Foo.com</a>     =3D> https://foo.com (?)=

According to RFC 3986, section 4.2, the first component of a relative
reference can't contain a colon (':'). The last example should be:
<a href>//Foo.com</a>	https://foo.com

We don't need to define a new "append" algorithm, relative [IU]RI
references are powerful enaugh.

From nzakas at yahoo-inc.com  Tue Aug  3 11:46:50 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Tue, 3 Aug 2010 11:46:50 -0700
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com>
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com>
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com>
Message-ID: <B66541E954ECF146AD8CA69D34A283FF12CD8357E9@SP2-EX07VS02.ds.corp.yahoo.com>

Is it easier in terms of implementation issues or general consensus?

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: Jonas Sicking [mailto:jonas at sicking.cc] 
Sent: Monday, August 02, 2010 5:51 PM
To: Nicholas Zakas
Cc: Scott Hess; Alexandre Morgaut; whatwg at lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage.

I suspect it will be much easier to add to IndexedDB than to
localStorage/sessionStorage. I don't expect the latter to go away,
though generally it seems like people are disliking localStorage
enough that it's hard to get any changes made to it.

/ Jonas

From tantek at cs.stanford.edu  Tue Aug  3 12:10:26 2010
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Tue, 3 Aug 2010 12:10:26 -0700
Subject: [whatwg] Please consider dropping the "sandbox" attribute from
	the <iframe> element
In-Reply-To: <1541D39E-A9B6-4F26-96C6-10A3BFD4B7C0@apple.com>
References: <AANLkTikg0s8Y+cb_wwM5xywEJyCKH1ey71aK9-enzF34@mail.gmail.com> 
	<1541D39E-A9B6-4F26-96C6-10A3BFD4B7C0@apple.com>
Message-ID: <AANLkTi=7xJBofr+8VJWN=zSnyBuv4H6G_EgkXxu6fXOj@mail.gmail.com>

On Mon, Aug 2, 2010 at 6:41 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 1, 2010, at 6:59 PM, Tantek ?elik wrote:
>
>> Summary: The new 'sandbox' feature on <iframe> should be considered
>> for removal. It needs a security review, it will be a lot of work to
>> implement properly, and may not actually solve the problem it is
>> intending to solve.
>>
>> More details here:
>>
>> http://wiki.whatwg.org/wiki/Iframe_Sandbox
>>
>> I encourage fellow web authors and browser implementers to add their
>> opinions/comments to that wiki page.
>
> As other have mentioned, <iframe sandbox> has been implemented in WebKit for some time. Additional points of information:
>
> 1) It's shipping in current versions of Safari and Chrome.
> 2) Security experts have reviewed it. @sandbox itself seems pretty solid, although there are possibly issues with related features such as text/html-sandboxed and @seamless.
> 3) Content has been built using it.
> 4) While it's unclear if <iframe sandbox> will work well for comments or other such cases of seamless untrusted content, it seems clearly useful for use cases like gadgets and ads.
>
> While more security review is always welcome, it seems like the basic idea is solid, and it's demonstrably implementable. The initial patch implementing it for WebKit can be seen here: <http://trac.webkit.org/changeset/51577>. This patch was 100k, but more than half of it is tests and the ChangeLog entry.


Ian, Adam, Maciej, I very much appreciate the follow-up information
you provided regarding this proposal.


I've captured it on the WHATWG wiki here:

http://wiki.whatwg.org/wiki/Iframe_Sandbox#why_sandbox_should_be_kept


The only outstanding requests I have are (on that wiki page)

1. Adam, it would be great if you could write up the "summary of all the
security discussion" - or at least provide links to some of it for
further reading.

http://wiki.whatwg.org/wiki/Iframe_Sandbox#security


2. Maciej, could you provide a few URLs to  "content [that] has been
built using it." ?

http://wiki.whatwg.org/wiki/Iframe_Sandbox#examples_in_the_wild


3. Maciej, could you provide code examples for how sandbox could be
used for the use cases you mention of gadgets and ads?

http://wiki.whatwg.org/wiki/Iframe_Sandbox#use_cases


Thanks much,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From ian at hixie.ch  Tue Aug  3 13:29:33 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 20:29:33 +0000 (UTC)
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <4BE962E2.90103@peda.net>
References: <20100510224058.88643zifc3q21unu@webmail-srv2.servage.net>
	<4BE962E2.90103@peda.net>
Message-ID: <Pine.LNX.4.64.1008031949150.7470@ps20323.dreamhostps.com>

On Thu, 6 May 2010, juuso_html5 at tele3d.net wrote:
>
> <meta="encrypt" pubkey="ABABAEFEF2626EFEFEF" 
> pubtool="EC256-AES|RSA2048-AES" passsalt="no|domainname" 
> auth="verisign">
> 
> Please try to fully decrypt the above meta-encrypt tag and *see* how the 
> browser-server communication could utilize it. (HINT: browser submits a 
> (session specific) 256bit elliptic curve public key to the server inside 
> every URI-request AND if the target page has meta-encrypt tag, the 
> server uses the browser's elliptic curve key and encrypts the page 
> content with that.) It is very simple, doable and STATELESS. And in 
> html5 it would eliminate some of the biggest real life security threats 
> at the internet. If you *could* learn and instinctly use the above 
> meta-encrypt tag then it should be enough simple for actual usage.

What problem is this solving?

Please see the WHATWG FAQ for details on how to propose features:

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

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

From tantek at cs.stanford.edu  Tue Aug  3 13:48:16 2010
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Tue, 3 Aug 2010 13:48:16 -0700
Subject: [whatwg] Please consider making <summary> more generic/flexible (or
	renaming)
Message-ID: <AANLkTikjXqHTvHy6y_D6Oj8q_0CWA+Ef9h_OU7rd1B_G@mail.gmail.com>

Summary: the new <summary> element is very generic sounding but has a
very special purpose (only allowed inside <details>). It would be
helpful if we made it more generic, in particular allow use of
<summary> inside <article> <body> (and perhaps <section>) to provide
general "summary" text semantics (e.g. this paragraph :), and a
potential enhancement to the HTML5-to-Atom conversion algorithm.

Alternatively, we could rename summary inside details to something
more specific so it won't be confused as a generic-sounding
element/feature.

More details here: http://wiki.whatwg.org/wiki/Summary

I encourage fellow web authors and browser implementers to add their
opinions/comments to that wiki page.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From ian at hixie.ch  Tue Aug  3 14:00:42 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 21:00:42 +0000 (UTC)
Subject: [whatwg] Various forms-related comments
In-Reply-To: <x2jbb9848a71005070030t1ef92b0keb97c97c322343@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
	<AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>
	<v2tc9e12661005061850jad317242r9f15c28023fa9be9@mail.gmail.com>
	<z2mc9e12661005061852i7fbc5239r81f20e244412b86f@mail.gmail.com>
	<op.vcbc9kzv64w2qv@annevk-t60>
	<x2ic9e12661005061958p5cf55952kf19d3b68a1f6396b@mail.gmail.com>
	<x2jbb9848a71005070030t1ef92b0keb97c97c322343@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008032035160.7470@ps20323.dreamhostps.com>

On Thu, 6 May 2010, Schalk Neethling wrote:
> 
> I absolutely love the fact that browsers will have certain validation 
> baked in like email addresses etc. With that, is there currently a way 
> to, or plans to add a way, where the way the browser displays these 
> errors can be styled with CSS?

To a limited extent you can use :invalid and company, but since browsers 
are still experimenting with how to expose the error messages, there's no 
standard way to style them yet. Maybe in time, if it makes sense.


On Thu, 6 May 2010, Schalk Neethling wrote:
> 
> Are there any talks at the moment whether the type=date input will allow 
> a user to enter a date manually or use the date picker or, should 
> developers fall back to using a standard input field and add the date 
> picker via JavaScript?

I don't really understand the question.


On Thu, 6 May 2010, Tab Atkins Jr. wrote:
> 
> The purpose of <input type=date> is to allow the browser to supply the 
> user with a datepicker.
> 
> If you would like to show a datepicker to users of all browsers, use 
> feature detection (such as through the Modernizr script) to detect 
> whether or not the browser support date inputs, and if not, supply the 
> js version.

Indeed.


On Fri, 7 May 2010, Schalk Neethling wrote:
>
> Just to rectify any misunderstanding, I love the date picker that Opera 
> provides and others will hopefully do in turn but, my question is that 
> currently using type=date only provides the option of selecting a date 
> using the date picker. In a recent talk I gave on HTML 5 the question 
> arose that well, what if the user wants to have both options on the same 
> field?
> 
> My suggestion was to fall back to using a standard text input field and 
> use JavaScript to add the date picker which will allow the user to enter 
> the date manually if so desired. Are there any current plans to add this 
> ability to type=date or is the fallback the best option?

On the long term, the theory is that you'll be able to use XBL to override 
the rendering and behaviour of these controls, but that's still some way 
in the future.


On Fri, 7 May 2010, Schalk Neethling wrote:
> 
> Hey TJ, I understand what type=date is supposed to offer the user and 
> agree that using Modernizr to detect whether the element is supported 
> and provide a fallback but my more direct question is, would HTML 5 
> offer the ability to allow a user to use either the date picker or enter 
> the date manually if the type=date attribute is specified. Something 
> like for example <input type=date editable=true />

On Fri, 7 May 2010, Tab Atkins Jr. wrote:
> 
> HTML5 doesn't specify anything about how the date input is presented. 
> It's entirely up to the browser to decide if they want to allow the user 
> to type a date in, or just use a datepicker, or what.

Indeed.

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

From ian at hixie.ch  Tue Aug  3 14:17:18 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 21:17:18 +0000 (UTC)
Subject: [whatwg] syncronous device upload
In-Reply-To: <w2wa3c2bd6c1005081251hecb6134eqe22e5104bf256e0d@mail.gmail.com>
References: <w2wa3c2bd6c1005081251hecb6134eqe22e5104bf256e0d@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008032116210.7470@ps20323.dreamhostps.com>

On Sat, 8 May 2010, James Salsman wrote:
>
> I propose including the specification at 
> http://www.w3.org/TR/device-upload in HTML5, provided that it is updated 
> to include Speex, Ogg Vorbis, and Ogg Theora.

What problem would this solve? As far as I can tell, nothing stops the 
user agent from offering to record data from any device.

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

From andrew.hayward+whatwg.specs at gmail.com  Tue Aug  3 14:20:22 2010
From: andrew.hayward+whatwg.specs at gmail.com (Andrew Hayward)
Date: Tue, 3 Aug 2010 22:20:22 +0100
Subject: [whatwg] Please consider making <summary> more generic/flexible
	(or renaming)
In-Reply-To: <AANLkTikjXqHTvHy6y_D6Oj8q_0CWA+Ef9h_OU7rd1B_G@mail.gmail.com>
References: <AANLkTikjXqHTvHy6y_D6Oj8q_0CWA+Ef9h_OU7rd1B_G@mail.gmail.com>
Message-ID: <AANLkTimR7Nfs+BNmn=ZGzvYQTv06ABDz=eP_9NZSDXwY@mail.gmail.com>

> Summary: the new <summary> element is very generic sounding but has a
> very special purpose (only allowed inside <details>). It would be
> helpful if we made it more generic, in particular allow use of
> <summary> inside <article> <body> (and perhaps <section>) to provide
> general "summary" text semantics (e.g. this paragraph :), and a
> potential enhancement to the HTML5-to-Atom conversion algorithm.
>
> Alternatively, we could rename summary inside details to something
> more specific so it won't be confused as a generic-sounding
> element/feature.

In a somewhat related note, following a real-world conversation I had
with Jeremy Keith a short while ago, is there a reason why <summary>
(or the theoretical renamed less generic alternative) isn't being used
inside <figure>s too, instead of another new element (<figcaption>)?
At the time Jeremy wasn't able to give me an answer, but if it's
already been discussed and I just missed it, my apologies.

- Andrew

From ian at hixie.ch  Tue Aug  3 14:39:52 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 21:39:52 +0000 (UTC)
Subject: [whatwg] Security thoughts
In-Reply-To: <FA5B25AB-E211-4724-B9C3-B7AFB5073AE0@gmail.com>
References: <FA5B25AB-E211-4724-B9C3-B7AFB5073AE0@gmail.com>
Message-ID: <Pine.LNX.4.64.1008032118420.7470@ps20323.dreamhostps.com>

On Sun, 9 May 2010, Perry Smith wrote:
>
> In HTML5 6.3.1 Relaxing The Same Origin Restriction [1] bullet 3, sub 
> bullet 3 there is a clause that says that if the domain is reduced down 
> to something that is on the Public Suffix List, the new value is 
> rejected.  That phrase caused me to pause.
> 
> I was wondering about internal attacks.  First, we need to assume a 
> couple of things but they are relatively easy to assume.  The first is 
> that the relaxing of the restriction has a valid use.  This seems easy 
> or it would not be in the spec.  The second is that an internal domain 
> can effectively be a public suffix list to users on the internal 
> intranet.  For example, at the place I work, I connect my laptop to the 
> wifi, it grabs an address and also registers the name.  Even if the name 
> was not registered, it would still have some DNS entry.  The point is 
> that all DNS entries within this subdomain are not trusted.
> 
> If we have a site like official_site.area_subdomain.big.com which 
> relaxes the restriction to area_subdomain.big.com, it is now exposed to 
> the potential of an attack from any of the systems within the same 
> area_subdomain including laptops connected via wifi.  The wifi is 
> secure.  The place I work at trusts me to some degree but with a large 
> corporation, they very often try to restrict information on the "need to 
> know" basis.  And, corporate espionage is a real threat.
> 
> I don't know how common it is for internal corporate sites to relax the 
> same origin restriction but I could see it becoming more and more common 
> as they try to take advantage of various technologies.
> 
> The corporations could take steps of course to secure the sites.  They 
> could put all official web sites in their own subdomain and then relax 
> to this more trusted subdomain.
> 
> The purposed of this email is to ask if a warning should be added in the 
> 3rd bullet to advise web developers of internal sites to be careful in 
> assuming that all the hosts on their internal subdomain are trusted.

I would be happy to add such a warning, but I'm not sure I understand the 
attack you had in mind.

Is this the scenario you have in mind?:

   User A controls a laptop within Example Corp's firewall and has a host 
   name of laptop1.corp.example.com.

   User B is also within the firewall.

   Service V is at service.corp.example.com, and it uses document.domain 
   to relax its same-domain restrictions to "example.com".

   User A tricks User B into visiting a file hosted on his laptop.

   That file relaxes its same-domain restriction to "example.com", loads 
   service V in an iframe, and uses the DOM to perform an attack on V 
   using B's credentials.

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

From ian at hixie.ch  Tue Aug  3 14:45:09 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 21:45:09 +0000 (UTC)
Subject: [whatwg] Avoiding new globals in HTML5 ECMAScript
In-Reply-To: <4BE794DA.6090108@yahoo.com>
References: <4BE794DA.6090108@yahoo.com>
Message-ID: <Pine.LNX.4.64.1008032141010.7470@ps20323.dreamhostps.com>

On Mon, 10 May 2010, Brett Zamir wrote:
> 
> Although it seems a lot of attention has been given to ensuring 
> backward-compatibility in HTML5, and while a kind of namespacing has 
> been considered in use of data- attributes (over expando properties), it 
> appears to my limited observations that global (window) properties are 
> being added without sufficient regard for backward compatibility (and in 
> any case limiting future variable naming by authors).
> 
> While I can understand the convenience of properties like 
> window.localStorage or window.JSON, it seems to me that new global 
> properties and methods (at least future ones!) should be added within 
> some other reserved object container besides "window".
> 
> While I can appreciate that some would argue that the convenience of 
> globals to authors outweighs potential conflict concerns (and I know I'm 
> not offering this suggestion very early in the process), it seems to me 
> that HTML5's client-side ECMAScript should model good practices in 
> limiting itself as far as new globals perhaps similar to how XML 
> reserved identifiers beginning with "xml", doing the same with allowing 
> one "W3C" global or maybe "HTML{N}" globals or the like ("HTML" alone 
> would no doubt be way too likely to conflict), allowing authors the 
> assurance that they can name their properties freely within a given set 
> of constraints without fear of being over-ridden later.

I agree with you in principle, but there are three other factors to bear 
in mind:

1. When we add something in the global namespace, we do get to test to see 
   if it breaks anything before making it final. It's not like we're just 
   adding things willy-nilly.

2. Other namespaces tend to be just as problematic. For example, we've run 
   into problems adding attributes to elements, even though there's really
   no reason anyone should be doing anything there.

3. If we can add to the global namespace without conflicts, it's 
   preferably to other options because it's much more convenient and 
   memorable.

These, as well as everything you say, are all taken into account when we 
add new DOM APIs.

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

From ian at hixie.ch  Tue Aug  3 14:56:36 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 21:56:36 +0000 (UTC)
Subject: [whatwg] getElementById
In-Reply-To: <C01E5911-2C58-4FF1-8AA4-6B57B43ADBED@gmail.com>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
	<AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
	<357FA5BA-172F-4FCD-A55B-89A455C03C48@gmail.com>
	<AANLkTimwFWcxF2nMtrzEUxSFNin_E1j_aMldUyXUQrnk@mail.gmail.com>
	<E3EB3EE2-5947-4B99-805F-CC185C38B934@gmail.com>
	<AANLkTilgZAlHkkTxws7AdLLhEK5NDTMKCeI82iBiAo79@mail.gmail.com>
	<DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>
	<AANLkTikFunHjQksT3nBmi7Ob_BR5F5-vtdaQyf-1deb_@mail.gmail.com>
	<C01E5911-2C58-4FF1-8AA4-6B57B43ADBED@gmail.com>
Message-ID: <Pine.LNX.4.64.1008032152180.7470@ps20323.dreamhostps.com>

On Mon, 10 May 2010, Perry Smith wrote:
>
> I see places that explicitly state that the same object is returned on 
> some operations.  For example, the element.style has that clause.
> 
> I have not found in either html5 or the DOM documentation that is 
> referenced an explicit statement to this effect for getElementById.

getElementById() is a DOM Core method, so not defined by the HTML spec.

However, the DOM spec says it returns "the Element", so that seems to 
require that the same Element object representing the element be returned.
In practice there is always only one object per element anyway.


> The other part to this that is not explicitly mentioned is if I attach a 
> new javascript attribute to the object, is that legal?  Is it defined to 
> work?  I have not found a statement one way or the other.
> 
> e.g.
> 
> foo = getElementById('foo');
> foo.newAttr = true;
> 
> /* later */
> 
> foo = getElementById('foo');
> if (foo.newAttr) {
>   alert("happy happy joy joy");
> }

This would be defined by WebIDL.

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

From cmarrin at apple.com  Tue Aug  3 15:15:10 2010
From: cmarrin at apple.com (Chris Marrin)
Date: Tue, 03 Aug 2010 15:15:10 -0700
Subject: [whatwg] [canvas] getContext & multiple contexts
In-Reply-To: <Pine.LNX.4.64.1007302259420.7470@ps20323.dreamhostps.com>
References: <4BD9A96C.4030909@pobox.com>
	<Pine.LNX.4.64.1007302259420.7470@ps20323.dreamhostps.com>
Message-ID: <725B9739-2F18-47C6-9C85-BBAB9DC88187@apple.com>


On Aug 2, 2010, at 3:16 PM, Ian Hickson wrote:

> 
> On Thu, 29 Apr 2010, Vladimir Vukicevic wrote:
>> 
>> A while ago questions came up in the WebGL WG about using a canvas with 
>> multiple rendering contexts, and synchronization issues that arise 
>> there. Here's our suggested change to getContext.
> 
> This seems overly complex. I've gone for a somewhat simpler approach, 
> which basically makes <canvas> fail getContext() if you call it with a 
> context that isn't "compatible" with the last one that was used, as 
> defined by a registry of contexts types. Currently, only '2d' and '3d' are 
> defined in this registry, and they are not defined as compatible.

'3d'? We're calling it 'webgl'. Is there another 3D context registered somewhere? I don't have a problem with this simplification.

> 
> 
>> It essentially allows for multiple contexts but adds no synchronization 
>> primitives other than the requirement that rendering must be visible to 
>> all contexts (that is, that they're rendered to the same destination 
>> space).
> 
> Having 3D and 2D contexts rendering to the same space -- especially given 
> getImageData() and the like -- seems like an interoperability nightmare.

I agree.

> 
> 
>> This also adds the 'attributes' parameter which can customize the 
>> context that's created, as defined by the context itself.  WebGL has its 
>> own context attributes object, and I'd suggest that the 2D context gain 
>> at least an attribute to specify whether the context should be opaque or 
>> not; but that's a separate suggestion from the below text.
> 
> I haven't added this. Could you elaborate on why this is needed? What 
> happens if the method is invoked agains with different parameters?
> 
> It seems far preferable to have this on the API rather than as part of the 
> getContext() method.

We feel it's more appropriate on the getContext() call because it involves creation of the resources for the context. If it were a separate call, you'd need to defer creation of those resources until the attribute call is made or create them as needed. This not only involves overhead in every call, but it requires you to provide specific rules on which calls cause automatic resource creation. Making it a parameter to getContext simplifies the definition. And it seems this would be a useful parameter for many types of contexts, even the 2D context as Vlad pointed out.

-----
~Chris
cmarrin at apple.com





From cmarrin at apple.com  Tue Aug  3 15:22:51 2010
From: cmarrin at apple.com (Chris Marrin)
Date: Tue, 03 Aug 2010 15:22:51 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <AANLkTi=YiiR-ueZ3x+8rTe=q+aRYajufZqKkZGb_5oYT@mail.gmail.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
	<AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
	<Pine.LNX.4.64.1008030156220.3056@ps20323.dreamhostps.com>
	<AANLkTinQPasJ_H30CGisOFfUdQonX8B-yrWgo-zGU0ou@mail.gmail.com>
	<Pine.LNX.4.64.1008030207380.3056@ps20323.dreamhostps.com>
	<AANLkTi=YiiR-ueZ3x+8rTe=q+aRYajufZqKkZGb_5oYT@mail.gmail.com>
Message-ID: <29787D3B-7ACF-4E7C-92D8-2B91A3E53226@apple.com>


On Aug 2, 2010, at 7:20 PM, Dirk Pranke wrote:

> On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>>> On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>>>>>> 
>>>>>> Why would a user ever want anyone to disable their GPU acceleration?
>>>>> 
>>>>> I believe I've heard people say that they might sometimes want this for
>>>>> power management, i.e. performing the same computation on the GPU might
>>>>> take more power than performing it more slowly on the CPU. I imagine
>>>>> this would depend on the specific configuration and computations
>>>>> involved, though.
>>>> 
>>>> This seems like a matter for the user, not the Web page, though.
>>> 
>>> Ah, I knew you were going to say this. I agree, but I can also imagine
>>> that the way the user selects this is by choosing one of two different
>>> resources from a page, just like we do today for videos of different
>>> bandwidths.
>> 
>> It seems better to have a way for the user agent to automaically negotiate
>> the right bandwidth usage based on user preference, too.
>> 
>> Any setting like this that we offer authors _will_ be misused, possibly as
>> often as used correctly. Unless there's a really compelling reason to have
>> it, it seems better to let the user be in control.
> 
> If users can choose between two links on a page labelled "high FPS -
> will destroy your battery" and "low FPS", they are in control, in a
> way that is easily understood by the user and allows them to make the
> choice at the point in time that it matters. Compare this with
> changing the streaming settings on QT Player or Windows Media Player,
> or even toggling the "use the video card" button on your laptop (and
> hoping that the content is smart enough to degrade gracefully instead
> of choking).

But an author can't make that claim if it involves forcing the GPU on or off. If we were to do this, I'm sure there would be implementations where the exact opposite of the author's intent would be the result. Saying something like "turn off the GPU" can result in more or less battery usage, depending on the hardware, software and content. Preserving battery life should be the job of the system (possibly with "I care more about battery life than quality" input from the User Agent).

> 
> We've seen this exact same argument play out over the last fifteen
> years in video on the web. The technology for detecting and adjusting
> bandwidth dynamically has been around forever (actually implemented,
> even), and yet for every one multi-bitrate stream available on the
> web, I imagine there are very many more that are single-bitrate. A big
> part of the reason for this is because doing it this way is (in my
> opinion) a better user experience.

Sure, you might be able to say that a lower bitrate video will use less power than a higher bitrate one. So the author might want to provide two videos. But leave it up to the system to decide what hardware to use to play them.

-----
~Chris
cmarrin at apple.com





From cmarrin at apple.com  Tue Aug  3 15:25:54 2010
From: cmarrin at apple.com (Chris Marrin)
Date: Tue, 03 Aug 2010 15:25:54 -0700
Subject: [whatwg] [canvas] getContext & multiple contexts
In-Reply-To: <725B9739-2F18-47C6-9C85-BBAB9DC88187@apple.com>
References: <4BD9A96C.4030909@pobox.com>
	<Pine.LNX.4.64.1007302259420.7470@ps20323.dreamhostps.com>
	<725B9739-2F18-47C6-9C85-BBAB9DC88187@apple.com>
Message-ID: <52261811-47CC-4F65-AF96-8A3B9117CEBD@apple.com>


On Aug 3, 2010, at 3:15 PM, Chris Marrin wrote:

> 
> On Aug 2, 2010, at 3:16 PM, Ian Hickson wrote:
> 
>> 
>> On Thu, 29 Apr 2010, Vladimir Vukicevic wrote:
>>> 
>>> A while ago questions came up in the WebGL WG about using a canvas with 
>>> multiple rendering contexts, and synchronization issues that arise 
>>> there. Here's our suggested change to getContext.
>> 
>> This seems overly complex. I've gone for a somewhat simpler approach, 
>> which basically makes <canvas> fail getContext() if you call it with a 
>> context that isn't "compatible" with the last one that was used, as 
>> defined by a registry of contexts types. Currently, only '2d' and '3d' are 
>> defined in this registry, and they are not defined as compatible.
> 
> '3d'? We're calling it 'webgl'. Is there another 3D context registered somewhere? I don't have a problem with this simplification.

Sorry, in rereading this I realize that the last statement is confusing. I don't have a problem with hixie's simplification on when to fail getContext. The string passed for a WebGL context should be 'webgl', not '3d'.

-----
~Chris
cmarrin at apple.com





From ian at hixie.ch  Tue Aug  3 15:41:43 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 22:41:43 +0000 (UTC)
Subject: [whatwg] [canvas] getContext & multiple contexts
In-Reply-To: <52261811-47CC-4F65-AF96-8A3B9117CEBD@apple.com>
References: <4BD9A96C.4030909@pobox.com>
	<Pine.LNX.4.64.1007302259420.7470@ps20323.dreamhostps.com>
	<725B9739-2F18-47C6-9C85-BBAB9DC88187@apple.com>
	<52261811-47CC-4F65-AF96-8A3B9117CEBD@apple.com>
Message-ID: <Pine.LNX.4.64.1008032239370.5947@ps20323.dreamhostps.com>

On Tue, 3 Aug 2010, Chris Marrin wrote:
> On Aug 2, 2010, at 3:16 PM, Ian Hickson wrote:
> > On Thu, 29 Apr 2010, Vladimir Vukicevic wrote:
> >> 
> >> A while ago questions came up in the WebGL WG about using a canvas 
> >> with multiple rendering contexts, and synchronization issues that 
> >> arise there. Here's our suggested change to getContext.
> > 
> > This seems overly complex. I've gone for a somewhat simpler approach, 
> > which basically makes <canvas> fail getContext() if you call it with a 
> > context that isn't "compatible" with the last one that was used, as 
> > defined by a registry of contexts types. Currently, only '2d' and '3d' 
> > are defined in this registry, and they are not defined as compatible.
> 
> '3d'? We're calling it 'webgl'. Is there another 3D context registered 
> somewhere?

Sorry, typo in the e-mail. The spec correctly refers to a "webgl" context.

(I have to say, I'd rather we called it "3d". I hate it when we embed 
marketing names into the platform.)


>> [arguments on getContext]
>
> We feel it's more appropriate on the getContext() call because it 
> involves creation of the resources for the context. If it were a 
> separate call, you'd need to defer creation of those resources until the 
> attribute call is made or create them as needed. This not only involves 
> overhead in every call, but it requires you to provide specific rules on 
> which calls cause automatic resource creation. Making it a parameter to 
> getContext simplifies the definition. And it seems this would be a 
> useful parameter for many types of contexts, even the 2D context as Vlad 
> pointed out.

What happens if you call getContext with the same contextID but different 
attributes?

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

From ian at hixie.ch  Tue Aug  3 16:15:55 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:15:55 +0000 (UTC)
Subject: [whatwg] Paragraphs in blockquotes
In-Reply-To: <20100511174932.F253.C8DE7135@html5.jp>
References: <AANLkTikEQxBvKHmiLhuZ64z088skor2QcrUO-ufCU38K@mail.gmail.com>
	<20100511174932.F253.C8DE7135@html5.jp>
Message-ID: <Pine.LNX.4.64.1008032256470.7470@ps20323.dreamhostps.com>

On Tue, 11 May 2010, Richard Clark wrote:
> 
> We recently received an email from one of our readers on html5doctor.com 
> that went like this:
> 
> "Hi, in HTML 4.0 Strict & XHTML 1.0 Strict, text inside a blockquote 
> element is required to be nested inside another block-level element, 
> e.g. p. In HTML5 that requirement seems to have been relaxed, as the 
> following element validates successfully:
> 
> <blockquote>This is a blockquote.</blockquote>
> 
> The HTML5 spec uses the p element in the usage examples, but does not 
> mention whether it is required.
> 
> Can you please confirm if this requirement has now been deprecated?"
> 
> We tested the below which successfully validated:
> 
> <!doctype html>
> <meta charset=utf-8>
> <title>blockquote test</title>
> <blockquote>Tiger tiger burning bright</blockquote>
> 
> So the question is, are block level elements required in blockquotes or 
> can the p's be removed from the examples in the spec?

On Tue, 11 May 2010, Masataka Yakura wrote:
> 
> <blockquote> can take any flow content [...]
> 
> So in HTML5 <blockquote> doesn't require inline contents to be nested 
> inside another block elements (you may know but that was acceptable too 
> in HTML4 Transitional).

On Tue, 11 May 2010, Futomi Hatano wrote:
> 
> The content model for <blockquote> is Flow content.
> Flow content includes "text".
> So, the text as a child of <blockquote> is valid.
> 
> The spec says that a run of phrasing content (in this case, it is the 
> text.) is a paragraph. 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#paragraph 
> So, the examples below have same semantics.
> 
> <blockquote>This is a blockquote.</blockquote>
> <blockquote><p>This is a blockquote.</p></blockquote>
> 
> The former is valid, but, of course, authers are encouraged the latter 
> much more.

Indeed.

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

From chris at pearce.org.nz  Tue Aug  3 16:18:00 2010
From: chris at pearce.org.nz (Chris Pearce)
Date: Wed, 04 Aug 2010 11:18:00 +1200
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <Pine.LNX.4.64.1008022113330.3056@ps20323.dreamhostps.com>
References: <4C56245C.3080604@pearce.org.nz>	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>	<4C56DFEE.3040602@mit.edu>	<Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>	<4C571EF6.5010206@mit.edu>
	<Pine.LNX.4.64.1008022113330.3056@ps20323.dreamhostps.com>
Message-ID: <4C58A3A8.9090504@pearce.org.nz>

  On 3/08/2010 9:20 a.m., Ian Hickson wrote:
>
> The synchronous section would run as soon as the task span the event loop.
> Spinning the event loop is defined essentially as being equivalent to
> breaking the original task in two, one that does everything up to spinning
> the event loop, and one that does everything after spinning the event
> loop. You are effectively waiting for some condition to become true and
> then queueing a task to run the continuation of the algorithm. It's just
> more convenient to write the algorithms as one long set of steps rather
> than having split them up into multiple algorithms that invoke each other
> and pass state around.
>
>> Or does "stop the currently running task" in #spin-the-event-loop imply
>> a jump to step 2 of the algorithm under #processing-model2?
> Yes.
>

So the task spinning the event loop has run up to the point of spinning 
the event loop, then we run the synchronous section, and then the task 
which was spinning the event loop will resume after its goal is met at 
some later time?

In the case of a tasks which invokes an algorithm which has a 
synchronous section, and then pauses the event loop (such calling 
window.alert()), we should not run the synchronous section until the 
event loop pause has completed?

Thanks,
Chris Pearce.

From ian at hixie.ch  Tue Aug  3 16:32:02 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:32:02 +0000 (UTC)
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C58A3A8.9090504@pearce.org.nz>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C56DFEE.3040602@mit.edu>
	<Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>
	<4C571EF6.5010206@mit.edu>
	<Pine.LNX.4.64.1008022113330.3056@ps20323.dreamhostps.com>
	<4C58A3A8.9090504@pearce.org.nz>
Message-ID: <Pine.LNX.4.64.1008032329400.5947@ps20323.dreamhostps.com>

On Wed, 4 Aug 2010, Chris Pearce wrote:
> 
> So the task spinning the event loop has run up to the point of spinning 
> the event loop, then we run the synchronous section, and then the task 
> which was spinning the event loop will resume after its goal is met at 
> some later time?

Sounds right.


> In the case of a tasks which invokes an algorithm which has a 
> synchronous section, and then pauses the event loop (such calling 
> window.alert()), we should not run the synchronous section until the 
> event loop pause has completed?

Currently, yeah. We might want to make "pause" also trigger synchronous 
sections, if that's a problem.

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

From ian at hixie.ch  Tue Aug  3 16:35:25 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:35:25 +0000 (UTC)
Subject: [whatwg] [html5] A <ui> Tag?
In-Reply-To: <AANLkTikJUzbCDRTCAFGWFnpd0MSrdDJNUnSE7LkrJtjJ@mail.gmail.com>
References: <AANLkTikJUzbCDRTCAFGWFnpd0MSrdDJNUnSE7LkrJtjJ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008032333480.7470@ps20323.dreamhostps.com>

On Wed, 12 May 2010, Darcy Murphy wrote (on help@):
>
> Recently I came up with the idea of using a <ui> tag in order to 
> semantically separate my app's content from it's UI chrome. I could use 
> <form> but then even clicking a simple <button> submits the form's data 
> when what I'm creating is more of a stateful toolbar than a proper form.

(Note that you can work around that last problem by saying <form 
action="javascript:void(0)">, at least according to the spec.)


> To that end, is there something like <ui> already available, or in the 
> works, or a better solution that I'm not aware of?

I'm not clear on what you consider content vs chrome, so it's hard to 
really comment, but in general the <section> and <article> elements are 
available for this kind of thing. If you have a concrete example it would 
be easier to say whether the spec needs new elements to handle it.

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

From ian at hixie.ch  Tue Aug  3 16:38:18 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:38:18 +0000 (UTC)
Subject: [whatwg] The form attribute (Association of controls and forms)
In-Reply-To: <4BEC9F10.3060300@gmail.com>
References: <4BEC9F10.3060300@gmail.com>
Message-ID: <Pine.LNX.4.64.1008032337320.7470@ps20323.dreamhostps.com>

On Fri, 14 May 2010, Mounir Lamouri wrote:
> 
> "4.10.18 Association of controls and forms" explains the link between 
> forms and form-associated elements (and the form attribute). However, 
> I've the feeling the specifications go far over what should be done and 
> force the implementor how to do it. What I mean is, this could be 
> summarized like this: "If the form attribute is specified, the form 
> owner of the element is the first form in the Document with the id 
> corresponding of the form attribute value, if any. If the form attribute 
> content is not a form element id, the element has no form owner. If the 
> form attribute isn't specificed, the element form owner is the nearest 
> ancestor form."
> 
> However, the specification say (not only): "When a form-associated 
> element's ancestor chain changes, e.g. because it or one of its 
> ancestors was inserted or removed from a Document, then the user agent 
> must reset the form owner of that element.
> 
> When a form-associated element's form attribute is added, removed, or 
> has its value changed, then the user agent must reset the form owner of 
> that element.
> 
> When a form-associated element has a form attribute and the ID of any of 
> the elements in the Document changes, then the user agent must reset the 
> form owner of that form-associated element.
> 
> When a form-associated element has a form attribute and an element with 
> an ID is inserted into or removed from the Document, then the user agent 
> must reset the form owner of that form-associated element."
> 
> These sentences explain more than "what should be the form owner" but 
> explain how to implement it. It seems useless and maybe not needed 
> sometimes (I'm wondering if checking for the ID wouldn't be better than 
> observing all the element's ID change and insertion/removal).
> 
> In my opinion, the form attribute behaves more or less like the for 
> attribute for the label element so I'm wondering why the specification 
> is so different. Is there a reason I'm missing ?

This is unfortunately needed for historical reasons. It handles weird 
cases like:

   <div><form></div>
   <input>

...where the <input> or the <form> are later moved in the DOM.

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

From ian at hixie.ch  Tue Aug  3 16:39:11 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:39:11 +0000 (UTC)
Subject: [whatwg] HTML5 Offline web applications & file upload
In-Reply-To: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>
References: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008032338480.7470@ps20323.dreamhostps.com>

On Fri, 14 May 2010, Alexandre Thiel wrote:
> 
> I was wondering if HTML5 Offline mode and file upload can work together ?
> I can't find any reference in the online draft which covers only server
> resource caching.
> Let's imagine you're writing some kind of data editor that works in offline
> mode, can you ask the user to select a file to import from his filesystem
> that can be processed with javascript or directly transfered to the
> localStorage while being offline ?

Yes, using the input.files attribute and then storing the result in 
localStorage.

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

From ian at hixie.ch  Tue Aug  3 16:46:04 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:46:04 +0000 (UTC)
Subject: [whatwg] Element-related feedback; attribution element
In-Reply-To: <AANLkTikZMYV8zvlSkANFKL0DUZ5VEIghKhH9YQqtsbfv@mail.gmail.com>
References: <AANLkTikZMYV8zvlSkANFKL0DUZ5VEIghKhH9YQqtsbfv@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008032341290.7470@ps20323.dreamhostps.com>

On Fri, 14 May 2010, Jim Jewett wrote:
> >>
> >>     Evil Lawyer:  So, when did you stop beating your wife?
> >>     Defendant:  Never!
> >>
> >> "Evil Lawyer" and "Defendant" aren't pronounced.  Their meanings (and 
> >> silence) are deduced from English conventions about punctuation.  I 
> >> would prefer a semantic tag.
> >
> > Why? What problem would a semantic tag solve? The default styling here 
> > seems to not need any particular element; the above is perfectly 
> > understandable as is as far as I can tell.
> 
> For written output, yes, the convention works.
> 
> Ideally, a screen reader should *not* read the attribution labels -- but 
> it should use them to switch voices.

You can in theory do that today using classes and Speech CSS. Do people do 
it? If not, it's not clear that there's enough demand to add this yet.


> >> I'm expecting [scripts] to do something like increase the font size 
> >> or change the background for lines *I* have to memorize for *my* 
> >> character [based on the semantic marked in the page identifying the 
> >> character], or for cue lines that I have to recognize.
> > 
> > Are there any examples of this in the wild? Since this is technically 
> > possible today, if it's a use case important enough that we should 
> > address it, it should be easy enough to find examples of this.
> > 
> > I'm very reluctant to provide features for hypothetical problems that 
> > don't stem from a real market need. (If we start solving such 
> > problems, we would fast find ourselves on the path to feature bloat.)
> 
> I haven't acted much since finding the internet.  I have seen plenty of 
> printed scripts in which this was done manually with a highlighter for 
> rehearsals.  I would expect today's equivalent to be done at time of 
> printing, rather than by a helpful web site.

Highlighting someone's lines can be done using <mark>.


> So the need is there; the question is whether the need is too 
> specialized (like the various poetry elements) ... if the only use were 
> scripts, I would say that it was too specialized, but I would also use 
> it for photo credits (the italicized captions), etc.  Whether that then 
> makes it too much of a catchall element -- maybe.

Credit for a photograph and the name of the speaker in a script seem like 
wildly different use cases with very little, if any, overlap. I don't 
think it makes sense to consider them together.


> >> I would expect it to be used by some scrapers looking for stock 
> >> photos.
> > 
> > I'm not sure what you mean. Wouldn't fingerprinting the photos be more 
> > effective?
> 
> I was thinking of scrapers acting on behalf of a consumer -- collecting 
> a bunch of photos that you would be allowed to use.

This is a mostly solved problem today -- sites like Flickr and Google 
Image Search provide license filters in their search tools.


> Plenty of model and photographer websites are largely devoted to finding 
> each other; I assume that this is because photographers are looking to 
> find (and then contact) models with a particular look, while models are 
> looking to be photographed by photographers skilled in a certain style. 
> Again, this seems like a fairly specialized need, but I've seen in on 
> several sites, and it again gets met by an attribution or credits 
> element.

This seems like an incredibly specialised need that is best solved by 
special-purpose databases and tools than by the Web's markup language.

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

From ian at hixie.ch  Tue Aug  3 16:50:59 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:50:59 +0000 (UTC)
Subject: [whatwg] Java language bindings for HTML5
In-Reply-To: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>
References: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>
Message-ID: <Pine.LNX.4.64.1008032350000.7470@ps20323.dreamhostps.com>

On Mon, 17 May 2010, K?hn Wolfgang wrote:
> 
> I was wondering if there are any precompiled Java language bindings for HTML5?

There's nothing official; hopefully the links provided by other people on 
this thread are helpful though.


> As it is, i can't figure package names, for example for the WebSocket API.
> According the WebIDL specs, it should be org.w3c.WebSocket, right?
> 
> As for the html5 elements, will there be a new package org.w3c.dom.html5?

All the DOM stuff should end up in the same package, but I'm not sure 
what that is. That's probably binding-specific.

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

From chris at pearce.org.nz  Tue Aug  3 16:52:47 2010
From: chris at pearce.org.nz (Chris Pearce)
Date: Wed, 04 Aug 2010 11:52:47 +1200
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <Pine.LNX.4.64.1008032329400.5947@ps20323.dreamhostps.com>
References: <4C56245C.3080604@pearce.org.nz>	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>	<4C56DFEE.3040602@mit.edu>	<Pine.LNX.4.64.1008021910090.3056@ps20323.dreamhostps.com>	<4C571EF6.5010206@mit.edu>	<Pine.LNX.4.64.1008022113330.3056@ps20323.dreamhostps.com>	<4C58A3A8.9090504@pearce.org.nz>
	<Pine.LNX.4.64.1008032329400.5947@ps20323.dreamhostps.com>
Message-ID: <4C58ABCF.2070500@pearce.org.nz>

  On 4/08/2010 11:32 a.m., Ian Hickson wrote:
>
>> In the case of a tasks which invokes an algorithm which has a
>> synchronous section, and then pauses the event loop (such calling
>> window.alert()), we should not run the synchronous section until the
>> event loop pause has completed?
> Currently, yeah. We might want to make "pause" also trigger synchronous
> sections, if that's a problem.
>

Having "pause" trigger synchronous sections is definitely easier for us 
to implement, and would make pausing the event loop consistent with 
spinning the event loop WRT synchronous sections.

Chris P.

From ian at hixie.ch  Tue Aug  3 16:54:42 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Aug 2010 23:54:42 +0000 (UTC)
Subject: [whatwg] Window events that bubble?
In-Reply-To: <6E2E12742DEB4805838586B6784A935B@emea.inin.com>
References: <4BF1BE21.8000601@davidflanagan.com>
	<AANLkTik7OtQec-EMya1bcmWPyXjzQCQJFfqZV3vd32BC@mail.gmail.com>
	<6E2E12742DEB4805838586B6784A935B@emea.inin.com>
Message-ID: <Pine.LNX.4.64.1008032354110.7470@ps20323.dreamhostps.com>

On Mon, 17 May 2010, David Flanagan wrote:
>
> Section 6.5.9 "History Traversal" defines popstate and hashchange events 
> that are fired on the Window object. It specifies that these events 
> *must* bubble. Where should they bubble to?  What does it mean to bubble 
> up from a Window? These events aren't going across frames, are they?
> 
> Is the specification that they must bubble a formality because existing 
> implementations set the bubbles property of the Event object to true? Or 
> does it actually have some impact on event propagation?

On Mon, 17 May 2010, Jonas Sicking wrote:
> 
> My understanding is that the only noticable effect of defining that 
> these effects bubble is that their bubbles property is set to true. Same 
> thing happens to bubbling events fired at an XMLHttpRequest object.

Indeed.

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

From ian at hixie.ch  Tue Aug  3 17:03:25 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 00:03:25 +0000 (UTC)
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <4bf3ec37.e198d80a.29a8.380e@mx.google.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>
	<AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com>
	<4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
	<AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com>
	<4bf304a4.513dd80a.189a.1578@mx.google.com>
	<AANLkTimYMfwCc-FZqLSpIv2rqVD1Vvljazsh6Btobvzr@mail.gmail.com>
	<AANLkTim1o2OgWVyrIjQXcFpWSNe_2Rujf8SXSSq31H8S@mail.gmail.com>
	<4bf3ec37.e198d80a.29a8.380e@mx.google.com>
Message-ID: <Pine.LNX.4.64.1008032356060.7470@ps20323.dreamhostps.com>

On Tue, 18 May 2010, bjartur wrote:
> 
> First of all I think we should use <a rel="embed" href="uri-ref"> 
> instead of <source>.

What problem would this solve?


> Isn't interactive content not important enaugh? What about text? What if 
> one want's to link to interactive maps? svg at src? <a class="embed"..> 
> with .embed {content: url(attr(href)) }? AFAIK CSS doesn't support it, 
> and if it does <a rel="embed"..> could be used as well, even without 
> explicit browser support.
>
> Also someone wrote that one should use <object> for media-types that 
> aren't supported in HTML yet. If you insist on keeping <video> and 
> <audio>, think of this as a way for second-class media-types WHATWG 
> hasn't approved/haven't been implemented to use some of the features of 
> <video> and <audio>.

I don't understand these paragraphs at all.


On Wed, 19 May 2010, Bjartur Thorlacius wrote:
> 
> 	Is the existing syntax backwards compatible? When using <A>, you 
> get a nice link as fallback content automagically, not requiring any 
> special workarounds by the content author. AFAICT you don't even get 
> that when using a browser that doesn't support <audio> and <video>.

Indeed, with those you have to provide the fallback content (which could 
e.g. be flash) as a descendant of the <audio>/<video> element.


> 	What I'm trying to write is that not all browsers support 
> JavaScript, not all pages must be able to control playback more than 
> play, pause, seek etc and that a mechanism for linking to files and 
> alternative encodings thereof semantically. Currently, that seems to be 
> only possible with video and audio. But if you create a media element 
> that adds no extra interface, you get this for all other types as well 
> (albeit with a lesser scripting interface). Although the <include> 
> element won't be as good integration point between one media and 
> scripts, it will have a standard interface somewhat applicable to many 
> medias/mediums and at least provide something to all medias, versus 
> (close to) nothing.

I'm not sure I follow. If you're saying that we should also support other 
timed-based formats in the future even if they are not video, e.g. if you 
are saying we should support formats like SMIL, then there's no reason you 
can't do that with <video> itself. <video> really is just an API to 
time-based visual data, it doesn't have to be a sequence of bitmaps.


I didn't really follow the rest of your e-mail. It would be helpful if you 
could construct your feedback in the form of a problem faced by users, 
rather than in the form of a proposed solution. This would enable the 
proposal to be properly evaluated.


On Wed, 19 May 2010, bjartur wrote:
>
> Yeah, maybe my crazy idealism and tendency to reuse existing things 
> don't mix up in this case. The main purpose of <video> and <audio> is to 
> create a scripting interface to online video. But they also add new 
> linking capabilities which should be available to any content 
> whatsoever.

I don't really see how. In what sense do they add new linking 
capabilities?

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

From ian at hixie.ch  Tue Aug  3 17:19:45 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 00:19:45 +0000 (UTC)
Subject: [whatwg] Built-in image sprite support in HTML5
In-Reply-To: <AANLkTikE4BfL9bgmcJ-ljU4koBFD4toE075afEziw3pV@mail.gmail.com>
References: <AANLkTikmrUmpsdUN4Zq-NnB4WFfm65_v2iMhpIfd1SI6@mail.gmail.com> 
	<AANLkTilWEbME7LDk79YvsVAeqGZnMwFnPoxQUvdDOg4E@mail.gmail.com>
	<AANLkTikE4BfL9bgmcJ-ljU4koBFD4toE075afEziw3pV@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008040016000.7470@ps20323.dreamhostps.com>

On Fri, 21 May 2010, David Weitzman wrote:
>
> There are various approaches to using image sprites with HTML and CSS, 
> but at the end of the day they are all essentially hacks. A solution 
> that would be simpler than any existing approach would be to introduce 
> new attributes for <img> to specify x and y offsets and clipping on 
> images. With that you would get simpler markup for sprites and better 
> accessibility.
> 
> One downside of this approach is that with background image sprites you 
> can have a CSS class that abstracts away the name of the sprite image. 
> With <img> tags you would have to specify the URL and height/width 
> individually on every sprited image.

I think the right solution is a fragment identifier.


On Sat, 22 May 2010, Silvia Pfeiffer wrote:
> On Sat, May 22, 2010 at 3:23 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> >
> > The Media Fragments WG has a draft spec out for, well, Media 
> > Fragments, which let you specify which section of an image you want 
> > right in the url. ?The browser should then automatically cut it out 
> > and serve just the sprite you want.
> 
> Yes, I was going to suggest that spec, too, see
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
> 
> However, what exactly happens with a media fragment URI like
> http://example.com/picture.png#xywh=160,120,320,240 is not fully
> specified in the Media Fragment URI spec.

I would recommend fixing that. :-)

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

From justin.lebar at gmail.com  Tue Aug  3 17:31:43 2010
From: justin.lebar at gmail.com (Justin Lebar)
Date: Tue, 3 Aug 2010 17:31:43 -0700
Subject: [whatwg] HTML resource packages
Message-ID: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>

We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
and we wanted to get the WhatWG's feedback on the feature.

For the impatient, the spec is here:

    http://people.mozilla.org/~jlebar/respkg/

and the bug (complete with builds you can try and some preliminary
performance numbers) is here:

    https://bugzilla.mozilla.org/show_bug.cgi?id=529208


You can think of resource packages as image spriting 2.0.  A page
indicates in its <html> element that it uses one or more resource
packages (which are just zip files).  Then when that page requests a
resource (be it an image, a css file, a script, or whatever), the
browser first checks whether one of the packages contains the
requested resource.  If so, the browser uses the resource out of the
package instead of making a separate HTTP request for the resource.

There's of course more detail than that, of course.  Hopefully it's
(mostly) clear in the spec.

I envision two classes of users of resource packages.  I'll call the
first "resource-constrained developers".  These developers care about
how fast their page is (who doesn't?), but can't spend weeks speeding
up their page.  For these developers, resource packages are an easy
way to make their pages faster without going through the pain of
spriting their images and packaging their js/css.

The other class of users are the resource-unconstrained developers;
think Google or Facebook.  These developers have already put a huge
amount of effort into making their pages fast, and a naive application
of resource packages is unlikely to make them any faster.  But these
developers may be able to use resource packages cleverly to gain
speedups.  In particular, nobody (to my knowledge) currently sprites
content images, such as the results of an image search.  A determined
set of developers should be able to construct resource packages for
image search results on the fly and save some HTTP requests.


So we can avoid rehashing here the common objections to resource
packages, here's a brief overview of the arguments I've heard against
the feature and my responses.

* Argument: Packaging isn't the way forward.  When you change one
resource in a package you have to change the whole package and so the
user has to re-download all the bits when most of what was in their
cache would have been fine.

This is of course correct, but we don't think it eliminates the
utility of resource packages.  The resource-constrained developer is
probably happy with anything which speeds up page loads, even if it's
not optimal when one part of the page changes.  And the
resource-unconstrained developer probably won't find resource packages
too useful for non-dynamic content, so caching isn't an issue in that
case.

* Argument: We can already package things pretty well.  Mozilla should
instead be focusing on improving caching (or something else).

I'd contend that we don't package particularly well in general.  The
Facebook homepage loads 100 separate resources on a cold cache, and
they certainly care about speed.  But anyway, this is just one
project.  We're also looking at caching.  :)

* Argument: Isn't this subsumed by HTTP pipelining?

Mostly.  But we can't turn on HTTP pipelining because transparent
proxies break it.

Resource packages have the further benefit that they allow page
authors to explicitly set the order in which the UA will download the
resources -- with pipelining, an important resource might get stuck
behind a large, unimportant resource, while with resource packages,
the UA always downloads resources in the order they appear in the zip
file.

Last, my understanding is that the HTTP pipeline isn't particularly
deep, so perhaps resource packages fill the TCP pipe better on
high-latency connections.  I haven't looked into this, though.

* Argument: What about SPDY?

I think SPDY should subsume resource packages.  But its deployment
will require changes to both web clients and servers, so it will
probably take a while after it's released before it's available on all
web servers.  And we have no idea when to expect SPDY to be ready for
production.  Resource packages, in contrast, are something we can have
Right Now.

Additionally, since resource packages are backwards-compatible -- a
page which specifies resource packages should display just fine in a
browser which doesn't support them -- we should be able to turn off
resource packages in the future if we decide we don't want them
anymore.


We'd love to hear what you think of the specification and our implementation.

-Justin

From ian at hixie.ch  Tue Aug  3 17:55:40 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 00:55:40 +0000 (UTC)
Subject: [whatwg] CSS2 system colors in legacy color values
In-Reply-To: <AANLkTike9-yvKJnGyKrT7j716zx2wIftaxz0zvahXzMu@mail.gmail.com>
References: <20100522190653.GA27433@pickering.dbaron.org>
	<op.vc6hkps6idj3kv@simon-pieterss-macbook.local>
	<4C036BFA.2050203@emsai.net> <4C038692.6030901@emsai.net>
	<AANLkTike9-yvKJnGyKrT7j716zx2wIftaxz0zvahXzMu@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008040020370.7470@ps20323.dreamhostps.com>

On Sat, 22 May 2010, L. David Baron wrote:
>
> The "rules for parsing a legacy color value" in 
> http://www.whatwg.org/specs/web-apps/current-work/complete/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value 
> specify that CSS2 system colors should be accepted, and that they should 
> be converted to a simple color.
> 
> It seems like a substantial amount of work to get dynamic change 
> handling correct for this case, since system colors can change 
> dynamically when the user changes system appearance.  I'd really like to 
> avoid having to add dynamic change handling for this, and I'd also like 
> to avoid having to make system colors dynamic in CSS but static in HTML.
> 
> What was the motivation for adding support for CSS2 system colors (which 
> I would note are deprecated in css3-color) to legacy HTML color values?

On Sun, 23 May 2010, Simon Pieters wrote:
>
> IE compat.

On Sat, 22 May 2010, L. David Baron wrote:
>
> What implementations support them...

On Sun, 23 May 2010, Simon Pieters wrote:
> 
> I think WebKit and IE.

On Sat, 22 May 2010, L. David Baron wrote:
>
> and do they respond to dynamic changes properly?

WebKit on Mac responds to changes to the color "Highlight" by changing the 
colour to the default blue the next time it resolves style (as far as I 
can tell). Not exactly a success story. (Highlight is the only colour over 
which the user seems to have control on Mac.)

IE8 on Windows XP apparently updates automatically (thanks to wirepair on 
#whatwg for testing that).


On Sun, 23 May 2010, Simon Pieters wrote:
> 
> It appears that Opera and Gecko don't support system colors. I wouldn't 
> mind not supporting them, but it could be interesting to research how 
> many pages it affects.

I don't have such research, unfortunately.

I've removed the support for it for now.


On Mon, 31 May 2010, Roger H?gensen wrote:
> 
> I'm kinda surprised that there is no support for floating point colors though.
> Althought I guess that "rgb(x%, x%, x%) An RGB percentage value (e.g.
> rgb(100%,0%,0%))"
> is as close as you get to that... Does percentage rgb color support things
> like 85.41% though?
> I hope so as only rgb(x%, x%, x%) is tentatively gamut independent.

The legacy color values are just that, legacy, the less we support there 
the better.

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

From jackalmage at gmail.com  Tue Aug  3 18:06:07 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 3 Aug 2010 18:06:07 -0700
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
Message-ID: <AANLkTimZh84pGdGk1AMedW53f=hm=E-_bNYLSYx8NTV7@mail.gmail.com>

On Tue, Aug 3, 2010 at 5:31 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
> We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
> and we wanted to get the WhatWG's feedback on the feature.
>
> For the impatient, the spec is here:
>
> ? ?http://people.mozilla.org/~jlebar/respkg/
>
> and the bug (complete with builds you can try and some preliminary
> performance numbers) is here:
>
> ? ?https://bugzilla.mozilla.org/show_bug.cgi?id=529208
[snip]
> We'd love to hear what you think of the specification and our implementation.

I love it!  You guys seem to have hit all the big points while
sidestepping the obvious problems.

Resource packages as Sprites 2.0 makes me very, very happy (and also
more confident about removing any attempt at a spriting solution from
CSS - it's the wrong layer).

~TJ

From ian at hixie.ch  Tue Aug  3 18:06:42 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 01:06:42 +0000 (UTC)
Subject: [whatwg] Questions about the progress element
In-Reply-To: <4BFAD5CC.7020904@gmail.com>
References: <4BFAD5CC.7020904@gmail.com>
Message-ID: <Pine.LNX.4.64.1008040057100.7470@ps20323.dreamhostps.com>

On Mon, 24 May 2010, Mounir Lamouri wrote:
> 
> I'm wondering why the value and max IDL attributes have to reflect the 
> content attribute with zero as a default value instead of reflecting the 
> internal values used to calculate the position. Wouldn't that be easier 
> to know what is the internal value and max values by using the IDL 
> attributes ?

I've changed 'max' to default to 1 rather than 0, but in general I think 
we should avoid having "magic" in IDL attributes that reflect content 
attributes, as it leads to very strange behaviour.


> In addition, couldn't the position IDL attribute returns a double 
> instead of a float? As we are dividing two floats, the precision may be 
> helpful.

I don't really mind; what do implementors think makes most sense here?

If it was up to me we'd just have all the numeric types be infinite 
precision in the spec and have the UAs compete on how good a tradeoff they 
can offer between precision and performance. :-)

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

From darin at apple.com  Tue Aug  3 18:12:23 2010
From: darin at apple.com (Darin Adler)
Date: Tue, 03 Aug 2010 18:12:23 -0700
Subject: [whatwg] CSS2 system colors in legacy color values
In-Reply-To: <Pine.LNX.4.64.1008040020370.7470@ps20323.dreamhostps.com>
References: <20100522190653.GA27433@pickering.dbaron.org>
	<op.vc6hkps6idj3kv@simon-pieterss-macbook.local>
	<4C036BFA.2050203@emsai.net> <4C038692.6030901@emsai.net>
	<AANLkTike9-yvKJnGyKrT7j716zx2wIftaxz0zvahXzMu@mail.gmail.com>
	<Pine.LNX.4.64.1008040020370.7470@ps20323.dreamhostps.com>
Message-ID: <4D82B6DF-0F59-458D-8B40-5F961ECFAED0@apple.com>

On Aug 3, 2010, at 5:55 PM, Ian Hickson wrote:

> WebKit on Mac responds to changes to the color "Highlight" by changing the colour to the default blue the next time it resolves style (as far as I can tell). Not exactly a success story. (Highlight is the only colour over which the user seems to have control on Mac.)

I just tested this and it works perfectly. When I change the Highlight color using the Appearance pane of the Mac OS X System Preferences the color of highlighted text in Safari is immediately the right color as soon as I switch back to Safari.

Your comment, ?[WebKit changes] the colour to the default blue the next time it resolves style? makes it sound like the code doesn?t work, but it works well and it is a success story!

    -- Darin


From ian at hixie.ch  Tue Aug  3 18:33:30 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 01:33:30 +0000 (UTC)
Subject: [whatwg] CSS2 system colors in legacy color values
In-Reply-To: <4D82B6DF-0F59-458D-8B40-5F961ECFAED0@apple.com>
References: <20100522190653.GA27433@pickering.dbaron.org>
	<op.vc6hkps6idj3kv@simon-pieterss-macbook.local>
	<4C036BFA.2050203@emsai.net> <4C038692.6030901@emsai.net>
	<AANLkTike9-yvKJnGyKrT7j716zx2wIftaxz0zvahXzMu@mail.gmail.com>
	<Pine.LNX.4.64.1008040020370.7470@ps20323.dreamhostps.com>
	<4D82B6DF-0F59-458D-8B40-5F961ECFAED0@apple.com>
Message-ID: <Pine.LNX.4.64.1008040133060.5947@ps20323.dreamhostps.com>

On Tue, 3 Aug 2010, Darin Adler wrote:
> On Aug 3, 2010, at 5:55 PM, Ian Hickson wrote:
> 
> > WebKit on Mac responds to changes to the color "Highlight" by changing 
> > the colour to the default blue the next time it resolves style (as far 
> > as I can tell). Not exactly a success story. (Highlight is the only 
> > colour over which the user seems to have control on Mac.)
> 
> I just tested this and it works perfectly. When I change the Highlight 
> color using the Appearance pane of the Mac OS X System Preferences the 
> color of highlighted text in Safari is immediately the right color as 
> soon as I switch back to Safari.
> 
> Your comment, ?[WebKit changes] the colour to the default blue the next 
> time it resolves style? makes it sound like the code doesn?t work, but 
> it works well and it is a success story!

We're talking about <body bgcolor=Highlight> here, not about the colour of 
selected text.

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

From silviapfeiffer1 at gmail.com  Tue Aug  3 18:38:58 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 4 Aug 2010 11:38:58 +1000
Subject: [whatwg] Built-in image sprite support in HTML5
In-Reply-To: <Pine.LNX.4.64.1008040016000.7470@ps20323.dreamhostps.com>
References: <AANLkTikmrUmpsdUN4Zq-NnB4WFfm65_v2iMhpIfd1SI6@mail.gmail.com> 
	<AANLkTilWEbME7LDk79YvsVAeqGZnMwFnPoxQUvdDOg4E@mail.gmail.com> 
	<AANLkTikE4BfL9bgmcJ-ljU4koBFD4toE075afEziw3pV@mail.gmail.com> 
	<Pine.LNX.4.64.1008040016000.7470@ps20323.dreamhostps.com>
Message-ID: <AANLkTinmvNciXrkn7u=HzcSL5gB1Xov5OuiaC8Tty7WE@mail.gmail.com>

On Wed, Aug 4, 2010 at 10:19 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 21 May 2010, David Weitzman wrote:
> >
> > There are various approaches to using image sprites with HTML and CSS,
> > but at the end of the day they are all essentially hacks. A solution
> > that would be simpler than any existing approach would be to introduce
> > new attributes for <img> to specify x and y offsets and clipping on
> > images. With that you would get simpler markup for sprites and better
> > accessibility.
> >
> > One downside of this approach is that with background image sprites you
> > can have a CSS class that abstracts away the name of the sprite image.
> > With <img> tags you would have to specify the URL and height/width
> > individually on every sprited image.
>
> I think the right solution is a fragment identifier.
>
>
> On Sat, 22 May 2010, Silvia Pfeiffer wrote:
> > On Sat, May 22, 2010 at 3:23 AM, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
> > >
> > > The Media Fragments WG has a draft spec out for, well, Media
> > > Fragments, which let you specify which section of an image you want
> > > right in the url.  The browser should then automatically cut it out
> > > and serve just the sprite you want.
> >
> > Yes, I was going to suggest that spec, too, see
> >
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
> >
> > However, what exactly happens with a media fragment URI like
> > http://example.com/picture.png#xywh=160,120,320,240 is not fully
> > specified in the Media Fragment URI spec.
>
> I would recommend fixing that. :-)



Well, that goes into implementation issues and really has nothing to do with
the URI specification itself. The media fragment URI specification can
propose what is possible to happen for representing a media fragment URI and
it does so by now:
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-display.
But really, the application has to decide for itself what makes sense.

As we adopt media fragment URIs into the HTML5 spec, we should prescribe
what the user experience is meant to be, such that UAs can implement a
consistent handling.

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100804/bc61cf9d/attachment.htm>

From brettz9 at yahoo.com  Tue Aug  3 19:48:53 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Wed, 04 Aug 2010 10:48:53 +0800
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
Message-ID: <4C58D515.90002@yahoo.com>

  This is and was a great idea. A few points/questions:

1) I think it would be nice to see explicit confirmation in the spec 
that this works with offline caching.

2) Could data files such as .txt, .json, or .xml files be used as part 
of such a package as well?

3) Can XMLHttpRequest be made to reference such files and get them from 
the cache, and if so, when referencing only a zip in the packages 
attribute, can XMLHttpRequest access files in the zip not spelled out by 
a tag like <link/>? I think this would be quite powerful/avoid 
duplication, even if it adds functionality (like other HTML5 features) 
which would not be available to older browsers.

4) Could such a protocol also be made to accommodate profiles of 
packages, e.g., by a namespace being allowable somewhere for each package?

Thus, if a package is specified as say being under the XProc (XML 
Pipelining) namespace profile, the browser would know it could 
confidently look for a manifest file with a given name and act 
accordingly if the profile were eventually formalized through future 
specifications or implemented by general purpose scripting libraries or 
browser extensions, etc.

Another example would be if a file packaging format were referenced by a 
page, allowing, along with a set of files, a manifest format like METS 
to be specified and downloaded, describing a sitemap for a package of 
files (perhaps to be added immediately to the user's IndexedDB database, 
navigated Gopher-like, etc.) and then made navigable online or offline 
if the files were included in the zip, thus allowing a single HTTP 
request to download a whole site (e.g., if a site offered a collection 
of books).

And manifest files might be made to specify which files should be 
updated at a specific time independently of the package (e.g., checking 
periodically for an updated manifest file outside of a zip which could 
point to newer versions).

Note: the above is not asking browsers to implement any such additional 
complex functionality here and now; rather, it is just to allow for the 
possibility of automated discovery of package files having a particular 
structure (e.g., with specifically named manifest files to indicate how 
to interpret the package contents) by providing a programmatically 
accessible namespace for each package which could be unique per 
application and interpreted in particular ways, including by general 
purpose JavaScript libraries. This is not talking about adding 
namespaces to HTML itself, but rather for specifying package profiles.

Such extensibility would, as far as I can see it, allow for some very 
powerful declarative styles of programming in relation to handling of 
multiple files (whether resource files, data files, or complete pages), 
while piggybacking on the proposal's ability to minimize the HTTP 
requests needed to get them.

best wishes,
Brett


On 8/4/2010 8:31 AM, Justin Lebar wrote:
> We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
> and we wanted to get the WhatWG's feedback on the feature.
>
> For the impatient, the spec is here:
>
>      http://people.mozilla.org/~jlebar/respkg/
>
> and the bug (complete with builds you can try and some preliminary
> performance numbers) is here:
>
>      https://bugzilla.mozilla.org/show_bug.cgi?id=529208
>
>
> You can think of resource packages as image spriting 2.0.  A page
> indicates in its<html>  element that it uses one or more resource
> packages (which are just zip files).  Then when that page requests a
> resource (be it an image, a css file, a script, or whatever), the
> browser first checks whether one of the packages contains the
> requested resource.  If so, the browser uses the resource out of the
> package instead of making a separate HTTP request for the resource.
>
> There's of course more detail than that, of course.  Hopefully it's
> (mostly) clear in the spec.
>
> I envision two classes of users of resource packages.  I'll call the
> first "resource-constrained developers".  These developers care about
> how fast their page is (who doesn't?), but can't spend weeks speeding
> up their page.  For these developers, resource packages are an easy
> way to make their pages faster without going through the pain of
> spriting their images and packaging their js/css.
>
> The other class of users are the resource-unconstrained developers;
> think Google or Facebook.  These developers have already put a huge
> amount of effort into making their pages fast, and a naive application
> of resource packages is unlikely to make them any faster.  But these
> developers may be able to use resource packages cleverly to gain
> speedups.  In particular, nobody (to my knowledge) currently sprites
> content images, such as the results of an image search.  A determined
> set of developers should be able to construct resource packages for
> image search results on the fly and save some HTTP requests.
>
>
> So we can avoid rehashing here the common objections to resource
> packages, here's a brief overview of the arguments I've heard against
> the feature and my responses.
>
> * Argument: Packaging isn't the way forward.  When you change one
> resource in a package you have to change the whole package and so the
> user has to re-download all the bits when most of what was in their
> cache would have been fine.
>
> This is of course correct, but we don't think it eliminates the
> utility of resource packages.  The resource-constrained developer is
> probably happy with anything which speeds up page loads, even if it's
> not optimal when one part of the page changes.  And the
> resource-unconstrained developer probably won't find resource packages
> too useful for non-dynamic content, so caching isn't an issue in that
> case.
>
> * Argument: We can already package things pretty well.  Mozilla should
> instead be focusing on improving caching (or something else).
>
> I'd contend that we don't package particularly well in general.  The
> Facebook homepage loads 100 separate resources on a cold cache, and
> they certainly care about speed.  But anyway, this is just one
> project.  We're also looking at caching.  :)
>
> * Argument: Isn't this subsumed by HTTP pipelining?
>
> Mostly.  But we can't turn on HTTP pipelining because transparent
> proxies break it.
>
> Resource packages have the further benefit that they allow page
> authors to explicitly set the order in which the UA will download the
> resources -- with pipelining, an important resource might get stuck
> behind a large, unimportant resource, while with resource packages,
> the UA always downloads resources in the order they appear in the zip
> file.
>
> Last, my understanding is that the HTTP pipeline isn't particularly
> deep, so perhaps resource packages fill the TCP pipe better on
> high-latency connections.  I haven't looked into this, though.
>
> * Argument: What about SPDY?
>
> I think SPDY should subsume resource packages.  But its deployment
> will require changes to both web clients and servers, so it will
> probably take a while after it's released before it's available on all
> web servers.  And we have no idea when to expect SPDY to be ready for
> production.  Resource packages, in contrast, are something we can have
> Right Now.
>
> Additionally, since resource packages are backwards-compatible -- a
> page which specifies resource packages should display just fine in a
> browser which doesn't support them -- we should be able to turn off
> resource packages in the future if we decide we don't want them
> anymore.
>
>
> We'd love to hear what you think of the specification and our implementation.
>
> -Justin
>


From dpranke at chromium.org  Tue Aug  3 20:41:33 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Tue, 3 Aug 2010 20:41:33 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <29787D3B-7ACF-4E7C-92D8-2B91A3E53226@apple.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
	<3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>
	<Pine.LNX.4.64.1008030052250.7470@ps20323.dreamhostps.com>
	<AANLkTinX_GicC8YFTGaO74hvE+QT3ccCfxmpLr6OT8zd@mail.gmail.com>
	<Pine.LNX.4.64.1008030156220.3056@ps20323.dreamhostps.com>
	<AANLkTinQPasJ_H30CGisOFfUdQonX8B-yrWgo-zGU0ou@mail.gmail.com>
	<Pine.LNX.4.64.1008030207380.3056@ps20323.dreamhostps.com>
	<AANLkTi=YiiR-ueZ3x+8rTe=q+aRYajufZqKkZGb_5oYT@mail.gmail.com>
	<29787D3B-7ACF-4E7C-92D8-2B91A3E53226@apple.com>
Message-ID: <AANLkTimdEf3n0XSybCe3zwv2HtvHi6O5oms9hmj1bUck@mail.gmail.com>

On Tue, Aug 3, 2010 at 3:22 PM, Chris Marrin <cmarrin at apple.com> wrote:
>
> On Aug 2, 2010, at 7:20 PM, Dirk Pranke wrote:
>
>> On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson <ian at hixie.ch> wrote:
>>> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>>>> On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>>> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>>>>>>>
>>>>>>> Why would a user ever want anyone to disable their GPU acceleration?
>>>>>>
>>>>>> I believe I've heard people say that they might sometimes want this for
>>>>>> power management, i.e. performing the same computation on the GPU might
>>>>>> take more power than performing it more slowly on the CPU. I imagine
>>>>>> this would depend on the specific configuration and computations
>>>>>> involved, though.
>>>>>
>>>>> This seems like a matter for the user, not the Web page, though.
>>>>
>>>> Ah, I knew you were going to say this. I agree, but I can also imagine
>>>> that the way the user selects this is by choosing one of two different
>>>> resources from a page, just like we do today for videos of different
>>>> bandwidths.
>>>
>>> It seems better to have a way for the user agent to automaically negotiate
>>> the right bandwidth usage based on user preference, too.
>>>
>>> Any setting like this that we offer authors _will_ be misused, possibly as
>>> often as used correctly. Unless there's a really compelling reason to have
>>> it, it seems better to let the user be in control.
>>
>> If users can choose between two links on a page labelled "high FPS -
>> will destroy your battery" and "low FPS", they are in control, in a
>> way that is easily understood by the user and allows them to make the
>> choice at the point in time that it matters. Compare this with
>> changing the streaming settings on QT Player or Windows Media Player,
>> or even toggling the "use the video card" button on your laptop (and
>> hoping that the content is smart enough to degrade gracefully instead
>> of choking).
>
> But an author can't make that claim if it involves forcing the GPU on or off. If we were to do this, I'm sure there would be implementations where the exact opposite of the author's intent would be the result. Saying something like "turn off the GPU" can result in more or less battery usage, depending on the hardware, software and content. Preserving battery life should be the job of the system (possibly with "I care more about battery life than quality" input from the User Agent).

I think you're probably right that different systems can have
different performance profiles and you can't design a "one size
fits all" solution here. Perhaps instead of "enable GPU / disable GPU"
you need "high complexity / low complexity" as a hint to the user agent.

>
>>
>> We've seen this exact same argument play out over the last fifteen
>> years in video on the web. The technology for detecting and adjusting
>> bandwidth dynamically has been around forever (actually implemented,
>> even), and yet for every one multi-bitrate stream available on the
>> web, I imagine there are very many more that are single-bitrate. A big
>> part of the reason for this is because doing it this way is (in my
>> opinion) a better user experience.
>
> Sure, you might be able to say that a lower bitrate video will use less power than a higher bitrate one. So the author might want to provide two videos. But leave it up to the system to decide what hardware to use to play them.

Of course, you can also imagine a lower bitrate stream using more
power than a higher bitrate run (VP8 may be more efficient than MPEG-2,
but can't be decoded in hardware and hence is far more expensive).

Perhaps all this illustrates is that the problem is far from simple and
so no simple API is likely to be that helpful. I'm not sure ...

-- Dirk

From mjs at apple.com  Tue Aug  3 20:52:37 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 03 Aug 2010 20:52:37 -0700
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
Message-ID: <8F969D06-6E37-446A-A66D-5C5BB966F8EA@apple.com>


On Aug 3, 2010, at 5:31 PM, Justin Lebar wrote:

> We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
> and we wanted to get the WhatWG's feedback on the feature.
> 
> For the impatient, the spec is here:
> 
>    http://people.mozilla.org/~jlebar/respkg/
> 
> and the bug (complete with builds you can try and some preliminary
> performance numbers) is here:
> 
>    https://bugzilla.mozilla.org/show_bug.cgi?id=529208

Have you done any performance testing of this feature, and if so can you share any of that data?

I'm particularly interested in:

* Effect of using a resource package on page-load time, in the initial fully uncached case.
* Effect of using a resource package on page-load time, in the case where the resources in the package have expired but not have changed.
* Effect of using a resource package on page-load time, in the case where the resources in the package have expired and a subset of them have changed. (This could still be a win for packages.)
* Effect of using a resource package on page-load time, in the case where everything in the package is cached.

These are probably most interesting under high-latency network conditions (real or simulated). You address these points qualitatively in your comments but I'd love to see some numbers. That would make it easier to evaluate the performance tradeoffs.


Separately, I am curious to hear how http headers are handled; it's a TODO in the spec, and what the TODO says seems poor for the Content-Type header in particular. It would make it hard to use package resources in any context that looks at the MIME type rather than always sniffing. Any thoughts on this?


In general I am in favor of features that can improve page load times and which are 


Cheers,
Maciej


From darin at apple.com  Tue Aug  3 23:05:53 2010
From: darin at apple.com (Darin Adler)
Date: Tue, 03 Aug 2010 23:05:53 -0700
Subject: [whatwg] CSS2 system colors in legacy color values
In-Reply-To: <Pine.LNX.4.64.1008040133060.5947@ps20323.dreamhostps.com>
References: <20100522190653.GA27433@pickering.dbaron.org>
	<op.vc6hkps6idj3kv@simon-pieterss-macbook.local>
	<4C036BFA.2050203@emsai.net> <4C038692.6030901@emsai.net>
	<AANLkTike9-yvKJnGyKrT7j716zx2wIftaxz0zvahXzMu@mail.gmail.com>
	<Pine.LNX.4.64.1008040020370.7470@ps20323.dreamhostps.com>
	<4D82B6DF-0F59-458D-8B40-5F961ECFAED0@apple.com>
	<Pine.LNX.4.64.1008040133060.5947@ps20323.dreamhostps.com>
Message-ID: <6A7F21D1-268C-46BD-81C3-9BE572556D99@apple.com>

On Aug 3, 2010, at 6:33 PM, Ian Hickson wrote:

> We're talking about <body bgcolor=Highlight> here, not about the colour of selected text.

I see. And I can reproduce the bug you?re talking about. I?ll probably fix it, but point taken.

    -- Darin


From philipj at opera.com  Wed Aug  4 01:29:26 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Wed, 04 Aug 2010 10:29:26 +0200
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C583871.4020004@mit.edu>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C57495A.9020800@pearce.org.nz>
	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>
	<4C583871.4020004@mit.edu>
Message-ID: <op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>

On Tue, 03 Aug 2010 17:40:33 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/3/10 4:27 AM, Philip J?genstedt wrote:
>> For the record, here's how I interpreted "await a stable state":
>>
>> The only state that is not stable is a running script.
>
> I don't think that's true; for example you could be in an unstable state  
> if you're in the middle of the parser inserting some nodes into the DOM.

If the parser running in considered an unstable state, then we would have  
to wait until the whole document has finished parsing before running the  
resource selection algorithm. Thus, <video> would be unnecessarily delayed  
in a way that <img> isn't. The spec is certainly written in a way that  
makes good sense when triggering the resource selection algorithm when the  
parser first sets a src attribute or appends a child source element and  
then waiting in NETWORK_NO_SOURCE for more source elements. If this isn't  
the intention, I have really completely misunderstood what the spec is  
trying to do. Whatever the language used, I suggest letting the parser  
trigger the resource selection algorithm synchronously.

>> Therefore, when reaching that step, if the
>> resource selection algorithm was triggered by a script, wait until that
>> script has finished and then continue.
>
> Per spec as currently written, this will give the wrong behavior.  For  
> example, if the script in question calls showModalDialog, this is  
> supposed to interrupt the script task and spin the event loop, and so  
> your synchronous section would need to run while the modal dialog is up.  
>   It doesn't sound like your implementation does that.

That could be, but is this behavior actually useful for anything? It's  
certainly simpler to implement and more predictable for authors to always  
wait until the current script has finished executing.

-- 
Philip J?genstedt
Core Developer
Opera Software

From jorlow at chromium.org  Wed Aug  4 02:14:28 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Wed, 4 Aug 2010 10:14:28 +0100
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com> 
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com> 
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com>
Message-ID: <AANLkTim0CAQvhTzCMG-VGmFQoDR6HYFq5VyURQQa=BWw@mail.gmail.com>

On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
> wrote:
> > Yes, for IndexDB I think having a per-storage area expiration date
> completely makes sense. Do you expect that IndexedDB will become a successor
> to sessionStorage/localStorage?
>

No.  I think LocalStorage will stick around since it's just so simple to use
and a lot of people just need to store a tiny bit of data here or
there--much like cookies.  IndexedDB will be used for structured data, so I
don't see many people using it for things they one used (abused) cookies
for.


> My belief is that the simple key-value store paradigm would still end up
> being the default client-side data storage utility, and would therefore
> benefit from having a per-key expiration time to mimic cookie usage.
>
> I suspect it will be much easier to add to IndexedDB than to
> localStorage/sessionStorage. I don't expect the latter to go away,
> though generally it seems like people are disliking localStorage
> enough that it's hard to get any changes made to it.
>

Jonas, are you against the expiration feature proposal for LocalStorage?
 Because no one else has voiced the typical "we should just leave
LocalStorage alone" concerns.  So if you're not, I think we can assume that
such types (me included) aren't going to raise such a concern.

I'm actually much less enthusiastic about expiration for IndexedDB as I
don't see very compelling use cases.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100804/2b72cd27/attachment.htm>

From bzbarsky at MIT.EDU  Wed Aug  4 02:32:51 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 04 Aug 2010 05:32:51 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>
References: <4C56245C.3080604@pearce.org.nz>	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>	<4C57495A.9020800@pearce.org.nz>	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>	<4C583871.4020004@mit.edu>
	<op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>
Message-ID: <4C5933C3.20404@mit.edu>

On 8/4/10 4:29 AM, Philip J?genstedt wrote:
> That could be, but is this behavior actually useful for anything? It's
> certainly simpler to implement and more predictable for authors to
> always wait until the current script has finished executing.

1)  That requires defining "current script".
2)  Who said it will ever finish executing?

-Boris

From christoph.paeper at crissov.de  Wed Aug  4 03:08:40 2010
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Wed, 4 Aug 2010 12:08:40 +0200
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
Message-ID: <40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>

Justin Lebar:

> We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
>    http://people.mozilla.org/~jlebar/respkg/
| <html packages='[pkg1.zip img1.png script.js styles/style.css]
|                [static/pkg2.zip]'>
> A page indicates in its <html> element that it uses one or more resource packages (?).

Why do you want to put this on the HTML level (exclusively), not the HTTP level?
As far as I undestand it, authors would usually put stylesheets, scripts and decorative images, but not HTML files into a resource package. These are usually common to several pages or the entire site or domain. Images might be referenced from within HTML or CSS files.

Why did you decide against <link rel="resource-package" href="pkg1.zip#files='img1.png,?'"/> or something like that? (The hash part is just guesswork.)

* Argument: What about incremental rendering? 
If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough.

From whatwg at fowlsmurf.net  Wed Aug  4 03:11:27 2010
From: whatwg at fowlsmurf.net (James May)
Date: Wed, 4 Aug 2010 20:11:27 +1000
Subject: [whatwg] HTML resource packages
In-Reply-To: <40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com> 
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
Message-ID: <AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com>

On 4 August 2010 20:08, Christoph P?per <christoph.paeper at crissov.de> wrote:
> * Argument: What about incremental rendering?
> If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough.

ZIP files are progressively renderable, dependant on file order.

From diego.perini at gmail.com  Wed Aug  4 03:46:09 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Wed, 4 Aug 2010 12:46:09 +0200
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
	<AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com>
Message-ID: <AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com>

On Wed, Aug 4, 2010 at 12:11 PM, James May <whatwg at fowlsmurf.net> wrote:

> On 4 August 2010 20:08, Christoph P?per <christoph.paeper at crissov.de>
> wrote:
> > * Argument: What about incremental rendering?
> > If there are, for instance, lots of (content) images in the resource file
> I will see them all at once as soon as the ZIP has been downloaded
> completely and decompressed, but with single files I would have seen them
> appear one after the other, which might have been enough.
>
> ZIP files are progressively renderable, dependant on file order.
>

In my experience "gzip" compression is blocking browser rendering until the
compressed file has been received completely.

I believe this is the reason we should not compress the HTML source, just
its external binary components.

I don't think the browser can separately decompress each block of a chunked
transfer as it arrives, am I wrong ?


Diego Perini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100804/ebb221cf/attachment.htm>

From philipj at opera.com  Wed Aug  4 03:56:30 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Wed, 04 Aug 2010 12:56:30 +0200
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C5933C3.20404@mit.edu>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C57495A.9020800@pearce.org.nz>
	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>
	<4C583871.4020004@mit.edu> <op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>
	<4C5933C3.20404@mit.edu>
Message-ID: <op.vgwt0gcisr6mfa@philip-pc.gothenburg.osa>

On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/4/10 4:29 AM, Philip J?genstedt wrote:
>> That could be, but is this behavior actually useful for anything? It's
>> certainly simpler to implement and more predictable for authors to
>> always wait until the current script has finished executing.
>
> 1)  That requires defining "current script".

OK, but that's just a spec problem. It's trivial in implementation because  
when the resource selection algorithm was is triggered by a script, you  
can just pass along a reference to that very script.

> 2)  Who said it will ever finish executing?

If it doesn't, just don't ever continue with the synchronous section. Is  
there any valid case for a script never finishing? It would block all  
event handlers from running too, so in any case it's a broken page.

-- 
Philip J?genstedt
Core Developer
Opera Software

From excors+whatwg at gmail.com  Wed Aug  4 05:26:02 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 4 Aug 2010 13:26:02 +0100
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
Message-ID: <AANLkTik=_70_UXtbpoREiGf44-senVQp+R7EYvMS9LU5@mail.gmail.com>

On Wed, Aug 4, 2010 at 1:31 AM, Justin Lebar <justin.lebar at gmail.com> wrote:
> We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
> and we wanted to get the WhatWG's feedback on the feature.
>
> For the impatient, the spec is here:
>
> ? ?http://people.mozilla.org/~jlebar/respkg/

It seems a bit surprising that [pkg.zip img1.png img2.png] provides
more files than [pkg.zip img1.png] but *fewer* files than [pkg.zip]
(which includes all files). I can imagine people would write code
like:

  print "<html packages='[cached-image-thumbnails.zip " . (join " ",
@thumbnails_which_are_not_out_of_date) . "]'>";

(intending the package to be updated infrequently, and used only for
images that haven't been modified since the last package update), and
they would get completely the wrong behaviour when the list is empty.
So maybe "[pkg.zip]" should mean no files (vs "pkg.zip" which still
means all files).


Filenames in zips are byte-strings, not Unicode-character-strings.
What should happen with non-ASCII in the zip's list of contents?
People will use standard zip programs and frequently end up with
various random character encodings in their file - would browsers
guess or decode as CP437 or decode as UTF-8 or fail? would they look
at the zip header's language encoding flag? etc.


What happens if the document contains multiple <html> elements (not
all the root element)? (e.g. if it's XHTML, or the elements are added
by scripts). The packages spec seems to assume there is only ever one.


The note at the end of 4.1 seems to be about avoiding problems like
http://evil.com/ saying:

    <html packages="eviloverride.zip"> <!-- gets downloaded from evil.com -->
    <base href="http://bank.com/">
    <img src="http://bank.com/logo.png"> <!-- this shouldn't be
allowed to come from the .zip -->

Why is this particular example an important problem? If the attacker
wants to insert their own files into their own pages, they can just do
it directly without using packages. Since this is (I assume) only used
for resources like images and scripts and stylesheets, and not for <a
href>s or <iframe href>s, I don't see how it would let the attacker
circumvent any same-origin restrictions or do anything else dangerous.

The opposite way seems more dangerous, where evil.com says:

    <html packages="http://evil.com/redirect.cgi?http://secret-bank-intranet-server/packages.zip">
    <img src="http://evil.com/logo.png">
    <!-- now use canvas to read the pixel data of the secret logo,
since it was loaded from the evil.com origin -->

Is anything stopping that?

In 4.3 step 2: What is pkg-url initialised to? (The package href of p?)

-- 
Philip Taylor
excors at gmail.com

From kornel at geekhood.net  Wed Aug  4 05:28:11 2010
From: kornel at geekhood.net (=?utf-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Wed, 4 Aug 2010 13:28:11 +0100
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
	<AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com>
	<AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com>
Message-ID: <2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>

On 4 Aug 2010, at 11:46, Diego Perini wrote:

> > * Argument: What about incremental rendering?
> > If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough.
> 
> ZIP files are progressively renderable, dependant on file order.
> 
> In my experience "gzip" compression is blocking browser rendering until the compressed file has been received completely.
> 
> I believe this is the reason we should not compress the HTML source, just its external binary components.
> 
> I don't think the browser can separately decompress each block of a chunked transfer as it arrives, am I wrong ?

You are wrong. gzip compression is streamable and browsers can uncompress parts of gzipped file as it is downloaded. gzip only needs to buffer some data before returning uncompressed chunk, but it's only few KB. Chunks of gzipped data don't have to align with chunked HTTP encoding (those are independent layers).

-- 
regards, Kornel


From thomas.koetter at id-script.de  Wed Aug  4 05:56:23 2010
From: thomas.koetter at id-script.de (Thomas Koetter)
Date: Wed, 4 Aug 2010 14:56:23 +0200
Subject: [whatwg] [br] element should not be a line break
Message-ID: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>

Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though.


Currently, I'm writing a book on web programming and I stumbled over the specification of the br element for HTML5.
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element 

In the past, there has been a lot discussion about not using br just to insert line breaks everywhere. I'm fully aware that we have lots of elements that are often a better fit and that, of course, line breaks can be achieved by "blocking" inline elements.

What strikes me though is that according to the spec "The br element represents a line break". A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation.

Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer.


In addition, the appropriate uses (poems, addresses) and examples currently given are not convincing.

Consider this:
<p>P. Sherman<br>
42 Wallaby Way<br>
Sydney</p>

There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks.

<address>
	<dl>
		<dt>Name</dt><dd>P. Sherman</dd>
		<dt>Street</dt><dd>42 Wallaby Way</dd>
		<dt>City</dt><dd>Sydney</dd>
	</dl>
</address>

Or just:
<address>
	<dl>
		<dd>P. Sherman</dd>
		<dd>42 Wallaby Way</dd>
		<dd>Sydney</dd>
	</dl>
</address>

Regarding poems, line breaks have conventionally been used in Western literature to aid in manifesting the rhythm. And there surely are many poems that use formatting for artistic effect. But I think it would be hard to say that *line* breaks are an inherent part of poems per se. I'd say that breaks are important means to determine structure, but line breaks are just one of many possible manifestations of such breaks. Just like in a musical score where the bar is present in sheet music but not in the actual music being played.

Interestingly, the examples given for where not to use br look like great examples to actually use a break element (not necessarily a line break).

First example:
<p><a ...>34 comments.</a><br>
<a ...>Add a comment.</a></p>

There are two separate pieces of text that belong together (they are both related to comments). So using one paragraph to group them is fine. But they can benefit from a separation that is a bit stronger than just punctuation since one of them is purely informational and the other is a call to action. This is where a break element is perfect. One designer might want a line break. So he should be able to set a line break property on that break. Another designer doesn't like line breaks. So let her set the break to be generated as a green, medium-sized dot.

Second example:
<p><label>Name: <input name="name"></label><br>
<label>Address: <input name="address"></label></p>

Although I also prefer the version without the br element, I must say that a form is the one element where presentational markup does make sense. By its very nature a form has an explicit design, otherwise it would be called free-form. Granted, in web design there usually isn't and probably shouldn't be such a strong form character as in paper-based forms.


So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property.

I would love to hear your thoughts.

-- 
Thomas Koetter




From adamquaile at gmail.com  Wed Aug  4 06:45:32 2010
From: adamquaile at gmail.com (Adam Quaile)
Date: Wed, 4 Aug 2010 14:45:32 +0100
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
Message-ID: <AANLkTinwd+L2qUO1WC8zx_Bz9vY4+hRxcwDvLbh4yB3D@mail.gmail.com>

Hi..

I too am new to this discussion, but I thought I'd share my thoughts.

Personally, I agree with you on the topic.

I would dispute the use of the address tag in all circumstances, as if I
remember correctly this is for marking up contact information for an author
of the page?

But yes, I agree. For example we should be able to disable the line-breaks'
presentational effect easily through the use of a stylesheet (or indeed
enable it).

On 4 August 2010 13:56, Thomas Koetter <thomas.koetter at id-script.de> wrote:

> Disclaimer: I'm new to this discussion list, so please excuse me if this
> topic has been discussed before. A quick search didn't turn up anything
> though.
>
>
> Currently, I'm writing a book on web programming and I stumbled over the
> specification of the br element for HTML5.
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element
>
> In the past, there has been a lot discussion about not using br just to
> insert line breaks everywhere. I'm fully aware that we have lots of elements
> that are often a better fit and that, of course, line breaks can be achieved
> by "blocking" inline elements.
>
> What strikes me though is that according to the spec "The br element
> represents a line break". A *line* break is presentational in nature. The
> break is structural, but restricting it to a certain presentation of that
> break lacks the desired separation of structure and presentation.
>
> Wouldn't it make more sense to consider the br element to be just a minor
> logical break inside a paragraph? Just like hr represents a thematic break
> on the paragraph-level. How the break would be rendered is a different
> matter and should be left to the designer.
>
>
> In addition, the appropriate uses (poems, addresses) and examples currently
> given are not convincing.
>
> Consider this:
> <p>P. Sherman<br>
> 42 Wallaby Way<br>
> Sydney</p>
>
> There's no reason why line breaks should be part of an address. I've seen
> many addresses on one line with their parts separated just by dots or pipes.
> Given the inherent structure of an address, a definition list with
> name/value pairs would also be more semantically fitting than a paragraph of
> text with line breaks.
>
> <address>
>        <dl>
>                <dt>Name</dt><dd>P. Sherman</dd>
>                <dt>Street</dt><dd>42 Wallaby Way</dd>
>                <dt>City</dt><dd>Sydney</dd>
>        </dl>
> </address>
>
> Or just:
> <address>
>        <dl>
>                <dd>P. Sherman</dd>
>                <dd>42 Wallaby Way</dd>
>                <dd>Sydney</dd>
>        </dl>
> </address>
>
> Regarding poems, line breaks have conventionally been used in Western
> literature to aid in manifesting the rhythm. And there surely are many poems
> that use formatting for artistic effect. But I think it would be hard to say
> that *line* breaks are an inherent part of poems per se. I'd say that breaks
> are important means to determine structure, but line breaks are just one of
> many possible manifestations of such breaks. Just like in a musical score
> where the bar is present in sheet music but not in the actual music being
> played.
>
> Interestingly, the examples given for where not to use br look like great
> examples to actually use a break element (not necessarily a line break).
>
> First example:
> <p><a ...>34 comments.</a><br>
> <a ...>Add a comment.</a></p>
>
> There are two separate pieces of text that belong together (they are both
> related to comments). So using one paragraph to group them is fine. But they
> can benefit from a separation that is a bit stronger than just punctuation
> since one of them is purely informational and the other is a call to action.
> This is where a break element is perfect. One designer might want a line
> break. So he should be able to set a line break property on that break.
> Another designer doesn't like line breaks. So let her set the break to be
> generated as a green, medium-sized dot.
>
> Second example:
> <p><label>Name: <input name="name"></label><br>
> <label>Address: <input name="address"></label></p>
>
> Although I also prefer the version without the br element, I must say that
> a form is the one element where presentational markup does make sense. By
> its very nature a form has an explicit design, otherwise it would be called
> free-form. Granted, in web design there usually isn't and probably shouldn't
> be such a strong form character as in paper-based forms.
>
>
> So, in summary, I suggest changing the br element to just be a logical
> break element with the default rendition of a line break, but which could be
> adjusted via a new style property.
>
> I would love to hear your thoughts.
>
> --
> Thomas Koetter
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100804/6b1bb84a/attachment-0001.htm>

From timeless at gmail.com  Wed Aug  4 07:59:14 2010
From: timeless at gmail.com (timeless)
Date: Wed, 4 Aug 2010 17:59:14 +0300
Subject: [whatwg] HTML resource packages
In-Reply-To: <2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
	<AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com>
	<AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com>
	<2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>
Message-ID: <AANLkTi=_nvP3yiMS0kVTG8UCg6uhzdMBSYJSHa=QWRoc@mail.gmail.com>

People should probably consider reading the Web Apps Widgets working
group archives (they're public) about widget packaging.

There are long discussions about zip and gzip, etc.

http://www.w3.org/TR/widgets/#zip-archive

Especially http://www.w3.org/TR/widgets/#character-sets covers character sets.

As for zip streaming / gzip streaming...
Officially Zip technically has ways to construct archives which are
painful. In practice I don't think that's a real problem (beyond that
user agents would need to ensure to fail any packages which abuse
those features).
People tend to come late to the game and say "why didn't you use
gzip". The general short answer is that gzip doesn't cover a file
container format at all, and browsers tend to already support zip. So
the cost of using zip is negligible whereas adding something else
which is messy (e.g. tar, star, pax) is painful. And if you think that
tar is well specified, I have a bridge I'd like to sell you.

From timeless at gmail.com  Wed Aug  4 08:06:50 2010
From: timeless at gmail.com (timeless)
Date: Wed, 4 Aug 2010 18:06:50 +0300
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
References: <Acsz1HD2xLzk+DfLQ7ydwbecJD0Q7g==>
	<3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
Message-ID: <AANLkTi=6U3a=txs_zKnnhobyhHOR7FE9CXi5tc1wwyJH@mail.gmail.com>

On Wed, Aug 4, 2010 at 3:56 PM, Thomas Koetter
<thomas.koetter at id-script.de> wrote:
> Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though.

If you haven't taken the time to read the FAQ in its entirety, I'd
suggest that you take the time to do so.

http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F

The short form is that part of HTML5 is documenting how HTML1..4
works, so that browsers can support existing content by implementing
the HTML5 specification. Changing how an existing entity from HTML1..4
works would result in browsers which do not properly render content
from HTML1..4 which is not acceptable....

From cmarrin at apple.com  Wed Aug  4 08:16:55 2010
From: cmarrin at apple.com (Chris Marrin)
Date: Wed, 04 Aug 2010 08:16:55 -0700
Subject: [whatwg] [canvas] getContext & multiple contexts
In-Reply-To: <Pine.LNX.4.64.1008032239370.5947@ps20323.dreamhostps.com>
References: <4BD9A96C.4030909@pobox.com>
	<Pine.LNX.4.64.1007302259420.7470@ps20323.dreamhostps.com>
	<725B9739-2F18-47C6-9C85-BBAB9DC88187@apple.com>
	<52261811-47CC-4F65-AF96-8A3B9117CEBD@apple.com>
	<Pine.LNX.4.64.1008032239370.5947@ps20323.dreamhostps.com>
Message-ID: <4B387916-C1A6-48C9-8891-E6E1F313EDB5@apple.com>


On Aug 3, 2010, at 3:41 PM, Ian Hickson wrote:

> On Tue, 3 Aug 2010, Chris Marrin wrote:
>> On Aug 2, 2010, at 3:16 PM, Ian Hickson wrote:
>>> On Thu, 29 Apr 2010, Vladimir Vukicevic wrote:
>>>> 
>>>> A while ago questions came up in the WebGL WG about using a canvas 
>>>> with multiple rendering contexts, and synchronization issues that 
>>>> arise there. Here's our suggested change to getContext.
>>> 
>>> This seems overly complex. I've gone for a somewhat simpler approach, 
>>> which basically makes <canvas> fail getContext() if you call it with a 
>>> context that isn't "compatible" with the last one that was used, as 
>>> defined by a registry of contexts types. Currently, only '2d' and '3d' 
>>> are defined in this registry, and they are not defined as compatible.
>> 
>> '3d'? We're calling it 'webgl'. Is there another 3D context registered 
>> somewhere?
> 
> Sorry, typo in the e-mail. The spec correctly refers to a "webgl" context.
> 
> (I have to say, I'd rather we called it "3d". I hate it when we embed 
> marketing names into the platform.)

I generally agree. For me, I consider WebGL to be a clarifying name like HTML, rather than a marketing name.

> 
> 
>>> [arguments on getContext]
>> 
>> We feel it's more appropriate on the getContext() call because it 
>> involves creation of the resources for the context. If it were a 
>> separate call, you'd need to defer creation of those resources until the 
>> attribute call is made or create them as needed. This not only involves 
>> overhead in every call, but it requires you to provide specific rules on 
>> which calls cause automatic resource creation. Making it a parameter to 
>> getContext simplifies the definition. And it seems this would be a 
>> useful parameter for many types of contexts, even the 2D context as Vlad 
>> pointed out.
> 
> What happens if you call getContext with the same contextID but different 
> attributes?

Good question. It's addressed in https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#2.1. It says that subsequent calls ignore the attributes. There is a getContextAttributes call on the context to return what attributes were actually set.

-----
~Chris
cmarrin at apple.com





From jmcf at tid.es  Wed Aug  4 08:23:39 2010
From: jmcf at tid.es (JOSE MANUEL CANTERA FONSECA)
Date: Wed, 04 Aug 2010 17:23:39 +0200
Subject: [whatwg] Channel Messaging (is it broadcast allowed?)
Message-ID: <93AA9E47B82F684A868C217766F489058953EB3391@EXCLU2K7.hi.inet>

Hi,

I'm playing with Channel Messaging in Opera 10.60. I'm trying to connect to the same port more than one browsing context in order to do message broadcasting. It seems it is not working.

Are message ports intended to be used for broadcasting i.e. more than one browsing context listening to incoming messages?

best
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100804/06cd5cdb/attachment.htm>

From thomas.koetter at id-script.de  Wed Aug  4 09:04:06 2010
From: thomas.koetter at id-script.de (Thomas Koetter)
Date: Wed, 4 Aug 2010 18:04:06 +0200
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <AANLkTi=6U3a=txs_zKnnhobyhHOR7FE9CXi5tc1wwyJH@mail.gmail.com>
References: <Acsz1HD2xLzk+DfLQ7ydwbecJD0Q7g==>
	<3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<AANLkTi=6U3a=txs_zKnnhobyhHOR7FE9CXi5tc1wwyJH@mail.gmail.com>
Message-ID: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30F37@ECCR02PUBLIC.exchange.local>


-----Original Message-----
From: timeless.bmo2 at gmail.com [mailto:timeless.bmo2 at gmail.com] On Behalf Of timeless
Sent: Wednesday, August 04, 2010 5:07 PM
> If you haven't taken the time to read the FAQ in its entirety, I'd
suggest that you take the time to do so.

> http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F

> The short form is that part of HTML5 is documenting how HTML1..4
works, so that browsers can support existing content by implementing
the HTML5 specification. Changing how an existing entity from HTML1..4
works would result in browsers which do not properly render content
from HTML1..4 which is not acceptable....

Thanks for the hint about the FAQ.

Regarding the br element I believe that my suggestion does just that. It supports existing content by defaulting br to be displayed as a line break. But going forward br would be considered a minor logical break inside a paragraph. Presentation could be changed from the default line break to some generated content. Now seems to be a good time to implement such a change in the semantics. Correct me if I'm wrong, but hr went through a very similar change.


From bzbarsky at MIT.EDU  Wed Aug  4 10:19:35 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 04 Aug 2010 13:19:35 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <op.vgwt0gcisr6mfa@philip-pc.gothenburg.osa>
References: <4C56245C.3080604@pearce.org.nz>	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>	<4C57495A.9020800@pearce.org.nz>	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>	<4C583871.4020004@mit.edu>
	<op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>	<4C5933C3.20404@mit.edu>
	<op.vgwt0gcisr6mfa@philip-pc.gothenburg.osa>
Message-ID: <4C59A127.1020705@mit.edu>

On 8/4/10 6:56 AM, Philip J?genstedt wrote:
> On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>
>> On 8/4/10 4:29 AM, Philip J?genstedt wrote:
>>> That could be, but is this behavior actually useful for anything? It's
>>> certainly simpler to implement and more predictable for authors to
>>> always wait until the current script has finished executing.
>>
>> 1) That requires defining "current script".
>
> OK, but that's just a spec problem. It's trivial in implementation
> because when the resource selection algorithm was is triggered by a
> script, you can just pass along a reference to that very script.

It's not, in fact, trivial in implementation.  You're making assumptions 
about how implementations work that don't seem warranted (e.g. the 
concept of "reference to that very script" is not well-defined in some 
implementations).  In particular, what you're proposing is not at all 
trivial in Gecko.

>> 2) Who said it will ever finish executing?
>
> If it doesn't, just don't ever continue with the synchronous section.

I don't think that's reasonable.

> Is there any valid case for a script never finishing?

Yes, it could showModalDialog and the user could spend several hours 
interacting with it.

> It would block all event handlers from running too

I believe this is false in the case of showModalDialog.

-Boris

From jonas at sicking.cc  Wed Aug  4 10:25:54 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 4 Aug 2010 10:25:54 -0700
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <AANLkTim0CAQvhTzCMG-VGmFQoDR6HYFq5VyURQQa=BWw@mail.gmail.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com> 
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com> 
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com> 
	<AANLkTim0CAQvhTzCMG-VGmFQoDR6HYFq5VyURQQa=BWw@mail.gmail.com>
Message-ID: <AANLkTinvjs2Ft06_Z2rwh2gPDFNPi5FF09dXQWmbETCo@mail.gmail.com>

On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
>> wrote:
>> > Yes, for IndexDB I think having a per-storage area expiration date
>> > completely makes sense. Do you expect that IndexedDB will become a successor
>> > to sessionStorage/localStorage?
>
> No. ?I think LocalStorage will stick around since it's just so simple to use
> and a lot of people just need to store a tiny bit of data here or
> there--much like cookies. ?IndexedDB will be used for structured data, so I
> don't see many people using it for things they one used (abused) cookies
> for.
>
>>
>> My belief is that the simple key-value store paradigm would still end up
>> being the default client-side data storage utility, and would therefore
>> benefit from having a per-key expiration time to mimic cookie usage.
>>
>> I suspect it will be much easier to add to IndexedDB than to
>> localStorage/sessionStorage. I don't expect the latter to go away,
>> though generally it seems like people are disliking localStorage
>> enough that it's hard to get any changes made to it.
>
> Jonas, are you against the expiration feature proposal for LocalStorage?
> ?Because no one else has voiced the typical "we should just leave
> LocalStorage alone" concerns. ?So if you're not, I think we can assume that
> such types (me included) aren't going to raise such a concern.
> I'm actually much less enthusiastic about expiration for IndexedDB as I
> don't see very compelling use cases.

I'm definitely for expiration of localStorage values. Though I think
it also makes sense to do for IndexedDB. Especially if it can be done
on a per-objectStore basis as that makes it very low overhead.

/ Jonas

From slightlyoff at google.com  Wed Aug  4 11:10:15 2010
From: slightlyoff at google.com (Alex Russell)
Date: Wed, 4 Aug 2010 11:10:15 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com> 
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com> 
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com> 
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr> 
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com> 
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com> 
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com> 
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
Message-ID: <AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>

Sorry for the lagged response,

On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt <oliver at apple.com> wrote:
>
> On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
>
>> On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>>
>>>> The e-mails quoted below consist of the salient points of this thread:
>>>>
>>>> On Fri, 23 Apr 2010, David Bruant wrote:
>>>>>
>>>>> Make that HTMLCollection (and all HTML*Collection, as a consequence of
>>>>> inheritence of HTMLCollection) inherit from the ECMAScript Array
>>>>> prototype. This way, it will make available all Array extra methods
>>>>> (forEach, map, filter...) added in ECMAScript5 (and next versions which
>>>>> should go in the same direction).
>>>>>
>>>>> As far as I know, adding this won't break any existing code. The
>>>>> semantics of a Collection and the way it is used is very close from
>>>>> ECMAScript Arrays. I don't think that the notion of "live object" and
>>>>> ECMAScript Array are incompatible either. Once again, I am talking about
>>>>> ECMAScript binding. I have no intention to touch the HTMLCollection
>>>>> interface or other languages bindings.
>>>>
>>>> On Sun, 25 Apr 2010, J Z wrote:
>>>>>
>>>>> If HTMLCollection was inheriting from Array, and methods like `forEach`,
>>>>> `map`, etc. were to operate on a live object, there would definitely be
>>>>> undesired consequences. We can see this in, say, Firefox (which allows to
>>>>> set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
>>>>>
>>>>> HTMLCollection.prototype.__proto__ = Array.prototype;
>>>>>
>>>>> document.getElementsByTagName('div').forEach(function(el) {
>>>>> ? el.parentNode.removeChild(el); // doesn't work as expected
>>>>> });
>>>>>
>>>>> // turning live collection into static array fixes this
>>>>> Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
>>>>> ? el.parentNode.removeChild(el);
>>>>> });
>>>>
>>>> On Sat, 24 Apr 2010, David Bruant wrote:
>>>>>
>>>>> I think I can take your point as a "pro" more than a "con", because in
>>>>> ES5, right before the definition of each array extra method, a paragraph
>>>>> like the following can be found :
>>>>>
>>>>> "The range of elements processed by forEach is set before the first call
>>>>> to callbackfn. Elements which are appended to the array after the call
>>>>> to forEach begins will not be visited by callbackfn. If existing
>>>>> elements of the array are changed, their value as passed to callback
>>>>> will be the value at the time forEach visits them; elements that are
>>>>> deleted after the call to forEach begins and before being visited are
>>>>> not visited."
>>>>>
>>>>> This point is confirmed by every algorithm where the length is "saved"
>>>>> once for all before the loop and not got from the .length property each
>>>>> time.
>>>>
>>>> On Mon, 26 Apr 2010, Erik Arvidsson wrote:
>>>>> On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
>>>>>> Le 25/04/2010 00:39, J Z a ?crit :
>>>>>>>
>>>>>>> I have thought a lot about weirdnesses that people could think about
>>>>>>> like trying to assign a value to the HTMLCollection (divs[14] =
>>>>>>> myOtherDiv), but once again, it wouldn't be more allowed than it
>>>>>>> currently is (I have no idea of what happens today, but if an error
>>>>>>> is thrown in a for-loop, it should throw an error as well in a call
>>>>>>> within a forEach).
>>>>>>
>>>>>> How would destructive methods like `push` or `sort` behave? Would
>>>>>> `document.body.childNodes.push(document.createTextNode('foo'))` append
>>>>>> text node to a body element? Or would it be a noop?
>>>>>>
>>>>>> That is actually a very good point. It think that the behavior should
>>>>>> be exactly the same as "an equivalent without array methods". (this
>>>>>> point of my proposal would need to be made completly explicit for each
>>>>>> method)
>>>>>
>>>>> One way to solve this could be to split Array into two interfaces. One
>>>>> to be used with immutable array like objects and one to use to mutate
>>>>> objects. Then we could apply the immutable array like interface to
>>>>> NodeList and its related interfaces. The benefit of doing that is that
>>>>> NodeList.prototype.push would be undefined instead of failing when
>>>>> called.
>>>>
>>>> On Mon, 26 Apr 2010, David Flanagan wrote:
>>>>>
>>>>> Rather that trying to make DOM collections feel like arrays, how about
>>>>> just giving them a toArray() method? ?This makes it clear that a
>>>>> collection is not an array, but clearly defines a way to obtain an
>>>>> array. ?Clever implementors might even be able to optimize common
>>>>> uses-cases using some kind of copy-on-write strategy so that toArray()
>>>>> doesn't involve memory allocation and copying.
>>>>>
>>>>> Of course, trying to teach programmers when they ought to call toArray()
>>>>> and when it is not necessary is another matter. ?Perhaps calling the
>>>>> method snapshot() and focusing on the live vs. static distinction
>>>>> instead of the fake array vs. true array distinction would invite less
>>>>> misuse.
>>>>>
>>>>> Or we can just leave the DOM as it is and get used to calling the
>>>>> equivalent of Prototype's $A() function.
>>>>
>>>> Before changing something this substantial, I'd like to have implementor
>>>> feedback regarding what the best way to address this is:
>>>>
>>>> ?- somehow make HTMLCollections and NodeLists inherit from Array?
>>>>
>>>> ?- define a bunch of feature on HTMLCollections and NodeLists so that
>>>> ? they're like arrays?
>>>
>>> I don't think this makes sense given the immutability of NodeLists.
>>
>> Wait...what? Shouldn't some sort of NodeList be mutable? And shouldn't
>> JS support immutable Arrays? We need to fix both of these APIs, and we
>> keep heaping back-pressure on JavaScript's Array without any
>> reasonable resolution because we're not exploring how to make Array
>> subtypes work as we want them to for all the use cases (like this)
>> that we care to express.
>
> What would you expect a mutable NodeList to be?

A good example would be the result of document.querySelectorAll().

> A lot of the common ones are live and always reflect the true state of the document -- they can change on their own but how would they respond to mutation?

The APIs that generate the stateful representations of order should
obviously not allow arbitrary mutation. That's why we need multiple
variants.

> Why do you think you need to put pressure on ES Arrays?

I don't, I think the pressure is already there and we're dealing with
it badly (TypedArray, NodeList, etc.).

> All the Array prototype functions are generic and work on anything array like, some of them don't make sense when applied to immutable types, but the majority Just Work. ?It's not the fault of EcmaScript if the browsers made a decision years ago to use a distinct type from Array, and to not make that type pick up the Array prototype.

It's ES's fault for not allowing useful Array subclassing sooner.
We'll get there in Harmony, but we need those fixes to say what we
"mean" here.

>>>> ?- something else?
>>>
>>> John Resig has been working on something in this area. I don't know if
>>> that's ready to publish yet though.
>>
>> I'd like to see any proposal in this area include NodeLists that are
>> *real* Array subtypes. Anything that's not is a missed opportunity
>> both for this list and for TC39.
>
> Do you really want NodeList to be an Array subtype, or do you just want NodeLists to not be a special magical type in the first place? ?And ocne again how does TC39 help? TC39 doesn't control HTML5.

I think you nailed it: the fact that these things are magical host
types is really just sort of offensive when we consider how much work
goes into toolkits to re-build APIs that should just be subsumed by a
"better" NodeList that's a "regular" Array (for some modified
definition of "regular").

Regards

From ian at hixie.ch  Wed Aug  4 11:24:35 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 18:24:35 +0000 (UTC)
Subject: [whatwg] Channel Messaging (is it broadcast allowed?)
In-Reply-To: <93AA9E47B82F684A868C217766F489058953EB3391@EXCLU2K7.hi.inet>
References: <93AA9E47B82F684A868C217766F489058953EB3391@EXCLU2K7.hi.inet>
Message-ID: <Pine.LNX.4.64.1008041823160.5947@ps20323.dreamhostps.com>

On Wed, 4 Aug 2010, JOSE MANUEL CANTERA FONSECA wrote:
> 
> I'm playing with Channel Messaging in Opera 10.60. I'm trying to connect 
> to the same port more than one browsing context in order to do message 
> broadcasting. It seems it is not working.
> 
> Are message ports intended to be used for broadcasting i.e. more than 
> one browsing context listening to incoming messages?

More than one browsing context can listen to a specific MessagePort 
object, but if you clone the MessagePort object, the original one becomes 
orphaned and stops receiving messages.

If you would like more help, I recommend sending a link to the page in 
question to the help at whatwg.org mailing list:

   http://www.whatwg.org/mailing-list#help

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

From svartman95 at gmail.com  Wed Aug  4 11:26:45 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Wed, 04 Aug 2010 18:26:45 +0000
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
	<0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
	<AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com>
Message-ID: <4c59b0fc.d908e30a.3490.5535@mx.google.com>

On Mon, 02 Aug 2010, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich
> <mkozakewich at icosidodecahedron.com> wrote:
> > I see where you're coming from, but we try not to force users to do things.
> 
> Let's say you have an image editor, written using canvas and whatnot.
> You want to have similar UI to native image editors, and that includes
> a "Save" button (probably adorned with a little picture of a 3.5"
> floppy, which is amusing when you think about it).  Clicking the
> "Save" button should pop up a dialog like in a native app, asking you
> where to save it.  Currently this can be done, but you have to send a
> request to the server and get a Content-Disposition: attachment
> response.  Probably you have to do it in a hidden iframe so it doesn't
> navigate the whole page, etc.  The request is for some feature to do
> this without the rigamarole.
> 
OK, lets assume this is a worthy use case for a moment (it propably
is). How do we know that a entity body (in HTTP parlance) should be
saved to permament storage rather than presented to the user?

A) Per resource metadata:
	Some resource is inherently insuitable for immediate
	presentation. Metadata regarding this can be provided by e.g. the
	Content-Disposation header of RFC 2076 (MIME).
B) By media type:
	A UA may decide that a resources of certain media subtype
	cannot be immediately processed or presented to the user. Think
	application/octet-stream, executables and likely all subtypes
	not present in mailcap (or equivalent).
C) Context:
	Due to the context of the link, such as per link metadata.
	The straightforward solution is registering a JavaScript callback
	to the click event on the relevant <A> element. This though is
	highly problematic as the "click" event isn't always fired when a
	link is activated (thus possibly resulting in normal navigation to
	the destination), UAs currently don't restyle <A>s with listeners
	on click (nor any elements with attached listeners). A (or AREA)
	with @action, @method or @rel~=save would allow easy styling
	with CSS and ignoring.

> If you don't agree that this use-case is worth adding the feature for,
> do you think that:
> 
> 1) The status quo is fine: you should have to send a request to the
> server to implement a "Save" button.  Offline image-editing apps don't
> matter.  Probably not a popular attitude here.
> 
> 2) You (the app author) shouldn't even be able to do that.  You should
> have to say "Right-click and choose 'Save As'".  Except that of course
> this is less convenient for the user, it takes up more space in the
> UI, the option might not be named the same thing in all browsers, apps
> might want to make right-click do something else so that context menus
> don't work, there are plenty of platforms (like phones) where "right
> click" doesn't even make sense, and in general the web platform makes
> no UI guarantees at all.  So then we get multipage guides explaining
> how to do it in a handful of popular browsers, with images and
> step-by-step instructions like
> <http://www.wikihow.com/Clear-Your-Browser's-Cache>, and unpopular
> browser users get to figure it out themselves.
> 
IMO image-filled step-by-step guides should be replaced by scripts
(runnable by lusers and readable by techies). But that's another topic.

> 3) Something else?
> 
> All in all, this seems like a very straightforward, useful thing to
> ask for.  Yes, users can do it through browser UI, but that doesn't
> permit authors to present it in a consistent way, draw the user's
> attention to it, put it where the user will expect it in context, etc.
> It's very similar to print(): of course the user can just hit Ctrl-P,
> but some people are used to clicking "Print" buttons and will be
> puzzled and unhappy if they don't find one.
> 
If the browsers UI doesn't have a "Print" button where the user expects
one to be the UI is broken, not the document to be printed.

> Not everyone will try to think of alternative ways to perform a task
> when their initial expectation fails.  That's the point where a lot of
> people give up, or call their techy friends or relatives for help.
> Many people use computers by rote, and don't know what to do when the
> usual incantation fails.  Even for those of us who know better, it's
> can be more convenient if the application has more control, so they we
> don't *have* to manually click through menus when the app can do it
> for us.
True. That's why web pages should provide lots of semantic metadata to
applications that may use that data to make informed decisions. I propose
the "method" attribute on <link>, <a> and <area> that MUST contain
a case insensitive space-seperated list of methods. A list of valid
methods should be obtainable from the WHATWG wiki. Note in particular
that methods are not limited to HTTP methods and neet not alter the
retrieval or submission of resources, though they most certainly can.
Valid methods might include:
GET (retrieve resource without presenting it to the user), PUT (alter
or create, akin to comp(ose) in run-mailcap), HEAD (retrieve metadata
about resource), navigate (present the resource to the user).

It's not clear to me what daemonized user-agents should do with these hints.

From timeless at gmail.com  Wed Aug  4 12:12:46 2010
From: timeless at gmail.com (timeless)
Date: Wed, 4 Aug 2010 22:12:46 +0300
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30F37@ECCR02PUBLIC.exchange.local>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<AANLkTi=6U3a=txs_zKnnhobyhHOR7FE9CXi5tc1wwyJH@mail.gmail.com>
	<3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30F37@ECCR02PUBLIC.exchange.local>
Message-ID: <AANLkTim-XN6GCxD=Cjx5fR1NzYHhZ7fogGo2OU4rBckm@mail.gmail.com>

data:text/html,%3Cstyle%3Ebr%20,%20b%20{display:inline;%20content:%22x%22}b:after,br:after{content:%22%20|%20%22}%20%3C/style%3Ea%3Cbr%3Eb%3Cb%3E%3C/b%3Ec

So, in Safari, the above actually lets me replace <br> w/ whatever I like.

bz indicates that I can't do that in Gecko because <br> is a replaced something.

From jonas at sicking.cc  Wed Aug  4 12:23:21 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 4 Aug 2010 12:23:21 -0700
Subject: [whatwg] Questions about the progress element
In-Reply-To: <Pine.LNX.4.64.1008040057100.7470@ps20323.dreamhostps.com>
References: <4BFAD5CC.7020904@gmail.com>
	<Pine.LNX.4.64.1008040057100.7470@ps20323.dreamhostps.com>
Message-ID: <AANLkTimYdbY6BfS2eFpZEUCudwF=1O085q07=vmRvjWY@mail.gmail.com>

On Tue, Aug 3, 2010 at 6:06 PM, Ian Hickson <ian at hixie.ch> wrote:
> If it was up to me we'd just have all the numeric types be infinite
> precision in the spec and have the UAs compete on how good a tradeoff they
> can offer between precision and performance. :-)

That sounds like an interoperability nightmare. You'd get all sorts of
edge cases where x/y == z tests true or false depending on how much
precision the implementation uses.

/ Jonas

From justin.lebar at gmail.com  Wed Aug  4 13:01:51 2010
From: justin.lebar at gmail.com (Justin Lebar)
Date: Wed, 4 Aug 2010 13:01:51 -0700
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTi=_nvP3yiMS0kVTG8UCg6uhzdMBSYJSHa=QWRoc@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com> 
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
	<AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com> 
	<AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com> 
	<2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>
	<AANLkTi=_nvP3yiMS0kVTG8UCg6uhzdMBSYJSHa=QWRoc@mail.gmail.com>
Message-ID: <AANLkTinhermnJb+pjTpdkz4xKq3GgMBATmpDu_PxGoLV@mail.gmail.com>

> Brett Zamir <brettz9 at yahoo.com> wrote:
> 1) I think it would be nice to see explicit confirmation in the spec that this works with offline caching.

Yes.  I'll do that.

> 2) Could data files such as .txt, .json, or .xml files be used as part of
> such a package as well?

> 3) Can XMLHttpRequest be made to reference such files and get them from the
> cache, and if so, when referencing only a zip in the packages attribute, can
> XMLHttpRequest access files in the zip not spelled out by a tag like <link/>?
> I think this would be quite powerful/avoid duplication, even if it adds
> functionality (like other HTML5 features) which would not be available to
> older browsers.

This is tricky.  The problem is: If you have an <img> on a page which might be
able to be served from a resource package, we'll block the download of the
image until can either serve the request from a resource package or can be sure
that no package contains the image.

I can imagine this behavior being confusing with XMLHttpRequests.  On the other
hand, it could certainly be powerful when used correctly.

I think the natural thing is go ahead and treat things requested by an
XMLHttpRequest the same as anything else on a page and retrieve them from
packages as possible.  If you really don't want your XMLHttpRequest to block on
a resource package, you can always use a POST.  But I need to investigate more
to determine whether this makes sense.

> 4) Could such a protocol also be made to accommodate profiles of packages,
> e.g., by a namespace being allowable somewhere for each package?

This sounds way outside the scope of what we're trying to do with resource
packages.  I'm all for designing for the future, but I don't think we want to
introduce the complexity even of these namespaces unless we intend to use them
immediately.

> Maciej Stachowiak <mjs at apple.com> wrote:
>
> Have you done any performance testing of this feature, and if so can you share any of that data?

There's a document (PDF) with some rough performance numbers in the bug:

    https://bugzilla.mozilla.org/attachment.cgi?id=455820

Although the results are preliminary, I think doing much more than this on a
simulated network for a test page might be going a bit overboard.  Results from
real pages over real networks would be much more meaningful at this point.

> Separately, I am curious to hear how http headers are handled; it's a TODO in
> the spec, and what the TODO says seems poor for the Content-Type header in
> particular. It would make it hard to use package resources in any context
> that looks at the MIME type rather than always sniffing. Any thoughts on
> this?

The intent is for UAs to sniff the content-type of anything coming from a
resource package, so I think that TODO needs to be turned on its head: The UA
shouldn't apply any of the response headers from the resource package to its
elements.

> Christoph P?per <christoph.paeper at crissov.de> wrote:
>> A page indicates in its <html> element that it uses one or more resource packages (?).
>
> Why do you want to put this on the HTML level (exclusively), not the HTTP level?
> ...
> Images might be referenced from within HTML or CSS files.

If you reference an image from a CSS file and include that CSS file in an HTML
file which uses resource packages, the image can be loaded from the resource
package.

> Why did you decide against <link rel="resource-package"
> href="pkg1.zip#files='img1.png,?'"/> or something like that? (The hash part
> is just guesswork.)

We actually originally spec'ed resource packages with the <link> tag, but we
encountered some difficulties with this.  For example, it led to confusing
behavior when a resource package was defined after a <link rel='javascript'>.
Do we load the script from the network, or do we wait until we've received the
whole <head> before loading any scripts?

Resource packages as a <link> also interacted poorly with Mozilla's speculative
parsing algorithm, which tries to download resources before we run the page's
scripts.  We probably could have come up with semantics which didn't run into
problems with our own speculative parsing implementation, but we realized it
would be difficult to spec it in such a way that we didn't make things very
difficult for *someone*.

> * Argument: What about incremental rendering?

The spec (and our implementation in Firefox) cares deeply about incremental
rendering.  Although the zip format isn't strictly suitable for incremental
extraction, I defined alternate semantics in the spec which should work.

Zip is better than tar-gz for this kind of thing for two reasons:

 * Zip file headers are uncompressed, so you don't have to extract the whole
   file in order to tell what's inside.

 * Entries in a zip file are individually compressed.  Although this might
   cause you to compress less effectively, you can compress all your files
   ahead of time and construct a zip file on the fly pretty very cheaply.

> Philip Taylor <excors+whatwg at gmail.com> wrote:
> It seems a bit surprising that [pkg.zip img1.png img2.png] provides
> more files than [pkg.zip img1.png] but *fewer* files than [pkg.zip]
> (which includes all files). I can imagine people would write code
> like:
>
>  print "<html packages='[cached-image-thumbnails.zip " . (join " ",
> @thumbnails_which_are_not_out_of_date) . "]'>";
>
> (intending the package to be updated infrequently, and used only for
> images that haven't been modified since the last package update), and
> they would get completely the wrong behaviour when the list is empty.
> So maybe "[pkg.zip]" should mean no files (vs "pkg.zip" which still
> means all files).

I think this is a good idea.  I'll change the spec.

> Filenames in zips are byte-strings, not Unicode-character-strings.
> What should happen with non-ASCII in the zip's list of contents?
> People will use standard zip programs and frequently end up with
> various random character encodings in their file - would browsers
> guess or decode as CP437 or decode as UTF-8 or fail? would they look
> at the zip header's language encoding flag? etc.

I guess we need something in the resource packages spec like what timeless
pointed to in the web widgets spec.

> What happens if the document contains multiple <html> elements (not
> all the root element)? (e.g. if it's XHTML, or the elements are added
> by scripts). The packages spec seems to assume there is only ever one.

The packages attribute should work like the manifest attribute currently works.
I don't see language in the cache manifest section of HTML5 (6.6) specifying
what happens when there are multiple <html> elements, so I hope I don't need to
specify this either.  :)

> The note at the end of 4.1 seems to be about avoiding problems like
> http://evil.com/ saying:
>
>    <html packages="eviloverride.zip"> <!-- gets downloaded from evil.com -->
>    <base href="http://bank.com/">
>    <img src="http://bank.com/logo.png"> <!-- this shouldn't be
> allowed to come from the .zip -->
>
> Why is this particular example an important problem?

This was mostly a matter of hygiene: A page shouldn't be able to claim that
it's loaded one domain's resource when it's actually loaded another.  This
would be significant if the user inquired as to the origin of the resource.
But it certainly wouldn't be the end of the world

> If the attacker
> wants to insert their own files into their own pages, they can just do
> it directly without using packages. Since this is (I assume) only used
> for resources like images and scripts and stylesheets, and not for <a
> href>s or <iframe href>s, I don't see how it would let the attacker
> circumvent any same-origin restrictions or do anything else dangerous.

> The opposite way seems more dangerous, where evil.com says:
>
>    <html packages="http://evil.com/redirect.cgi?http://secret-bank-intranet-server/packages.zip">
>    <img src="http://evil.com/logo.png">
>    <!-- now use canvas to read the pixel data of the secret logo,
> since it was loaded from the evil.com origin -->

Ah, this is much more incisive.  I guess we'd need to outlaw cross-origin
redirects in packages hrefs.

> In 4.3 step 2: What is pkg-url initialised to? (The package href of p?)

Ouch.  Yes, it should be p's package href.

-Justin

From ian at hixie.ch  Wed Aug  4 13:07:13 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 20:07:13 +0000 (UTC)
Subject: [whatwg] "entry script"
In-Reply-To: <op.vdob43q7idj3kv@simon-pieterss-macbook.local>
References: <7E4DFDD5-C9CC-4E90-98A2-80D93C1FD409@gmail.com>
	<op.vdob43q7idj3kv@simon-pieterss-macbook.local>
Message-ID: <Pine.LNX.4.64.1008042004210.7470@ps20323.dreamhostps.com>

On Sun, 30 May 2010, Perry Smith wrote:
>
> I don't see how "entry script" is set, when it is set, or what it is set 
> to.  "Initially, there is no entry script". [1]
> 
> Can someone help me out?

On Wed, 2 Jun 2010, Simon Pieters wrote:
> 
> The spec should probably make this clearer at the definition of 'entry 
> script'.

I've added a link to the algorithm that modifies the value of this state.

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

From ian at hixie.ch  Wed Aug  4 13:25:39 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 20:25:39 +0000 (UTC)
Subject: [whatwg] the HTML-to-Atom mapping definition
In-Reply-To: <4C12404D.3000204@gmx.de>
References: <20100602042010.512582BCC3@toro.w3.mag.keio.ac.jp>
	<4C05EAC0.3020506@gmx.de> <4C09FC18.9070605@gmx.de>
	<4C12404D.3000204@gmx.de>
Message-ID: <Pine.LNX.4.64.1008042008270.7470@ps20323.dreamhostps.com>

On Wed, 2 Jun 2010, Julian Reschke wrote:
> 
> Various problems have been reported with respect to the mapping [...] 
> Please consider them raised (and still open) as per the WHATWG issue 
> tracking rules.
>
>   <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7806>

This seems to have already been resolved (see comment 23).


>   <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546>

There is already a note to this effect below the algorithm.


>   <http://www.w3.org/html/wg/tracker/issues/86>

It's unclear what needs changing for this.


On Sat, 5 Jun 2010, Julian Reschke wrote:
> 
>   <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7545>

It's unclear how to support this. We could use the sizes="" attribute with 
rel=icon, or reintroduce the reliance on microdata vocabularies, but in 
both cases it seems better to wait for evidence that those mechanisms are 
beign adopted by authors before relying on them for this feature.


On Fri, 11 Jun 2010, Julian Reschke wrote:
> 
> <http://www.xn--8ws00zhy3a.com/blog/2010/06/html5-atom-gone-wrong>

I've fixed the atom:link issue and changed "xml" to "xhtml". I couldn't 
work out what the other complaints were about. If there are other 
problems, please raise them on the mailing list in a clear fashion and I'd 
be glad to update the spec.

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

From excors+whatwg at gmail.com  Wed Aug  4 13:32:27 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 4 Aug 2010 21:32:27 +0100
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTinhermnJb+pjTpdkz4xKq3GgMBATmpDu_PxGoLV@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
	<AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com>
	<AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com>
	<2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>
	<AANLkTi=_nvP3yiMS0kVTG8UCg6uhzdMBSYJSHa=QWRoc@mail.gmail.com>
	<AANLkTinhermnJb+pjTpdkz4xKq3GgMBATmpDu_PxGoLV@mail.gmail.com>
Message-ID: <AANLkTi=nhVELr4Y2ZmTm-_JWuGvCKMfM8ssvj9oGq5Rh@mail.gmail.com>

On Wed, Aug 4, 2010 at 9:01 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
>> What happens if the document contains multiple <html> elements (not
>> all the root element)? (e.g. if it's XHTML, or the elements are added
>> by scripts). The packages spec seems to assume there is only ever one.
>
> The packages attribute should work like the manifest attribute currently works.
> I don't see language in the cache manifest section of HTML5 (6.6) specifying
> what happens when there are multiple <html> elements, so I hope I don't need to
> specify this either. ?:)

http://whatwg.org/html#attr-html-manifest says:

  "The manifest attribute only has an effect during the early stages
of document load. Changing the attribute dynamically thus has no
effect (and thus, no DOM API is provided for this attribute)."

Its effect is triggered from http://whatwg.org/html#parser-appcache
("html" token in the "before html" insertion mode) or from
http://whatwg.org/html#read-xml , so it will only ever run for the
root <html> element of the document.

The packages attribute is defined as running "Whenever the packages
attribute is changed (including when the document is first loaded, if
its <html> element has a packages attribute)", so it's not the same.
If you do want it to work the same then you'll need to hook into the
parser and ignore dynamic updates.

-- 
Philip Taylor
excors at gmail.com

From ian at hixie.ch  Wed Aug  4 13:55:42 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 20:55:42 +0000 (UTC)
Subject: [whatwg] Why there is no wrap="off", intentional or forgotten?
In-Reply-To: <4C06BE4F.8070301@mit.edu>
References: <op.vdn5shx5o84pey@pc08.ebrana.cz>
	<1275476737.2933.83.camel@localhost>
	<4C06665F.6030205@lachy.id.au> <4C06BE4F.8070301@mit.edu>
Message-ID: <Pine.LNX.4.64.1008042026050.7470@ps20323.dreamhostps.com>

On Wed, 2 Jun 2010, Old?ich Vete?n?k wrote:
> 
> I'm missing the wrap="off" value for textarea wrap attribute; is there 
> any particular reason why this is not part of HTML5? Currently the only 
> values mentioned are "soft" and "hard":
> 
> http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap

What would "off" mean? (In particular, how would it be different from 
"soft"?)


> However, I'd like to use wrap=off because I don't want the lines to wrap.

They don't wrap (in the submission, that is) with wrap=soft either. Do you 
mean in the presentation? If so, that's a CSS issue.


> There is also no mention in the spec about wrap=virtual and wrap=physical back
> from the days.
> http://www.htmlcodetutorial.com/forms/_TEXTAREA_WRAP.html

Are they needed for interoperability with existing content? If not, then 
it's not clear what the spec would say about them.


On Wed, 2 Jun 2010, Boris Zbarsky wrote:
> On 6/2/10 10:10 AM, Lachlan Hunt wrote:
> > In theory, you can achieve the same effect by using CSS.
> > 
> > textarea { white-space: nowrap; }
> > 
> > This works fine in Opera, WebKit and IE. Doesn't work in Gecko though.
> 
> If you think that the above style should do something to <textarea>, 
> then the HTML spec needs to explicitly say so, since it's what defines 
> how the inside of a textarea is rendered, not CSS per se.

Done.

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

From justin.lebar at gmail.com  Wed Aug  4 14:05:57 2010
From: justin.lebar at gmail.com (Justin Lebar)
Date: Wed, 4 Aug 2010 14:05:57 -0700
Subject: [whatwg] HTML resource packages
In-Reply-To: <AANLkTi=nhVELr4Y2ZmTm-_JWuGvCKMfM8ssvj9oGq5Rh@mail.gmail.com>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com> 
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
	<AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com> 
	<AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com> 
	<2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>
	<AANLkTi=_nvP3yiMS0kVTG8UCg6uhzdMBSYJSHa=QWRoc@mail.gmail.com> 
	<AANLkTinhermnJb+pjTpdkz4xKq3GgMBATmpDu_PxGoLV@mail.gmail.com> 
	<AANLkTi=nhVELr4Y2ZmTm-_JWuGvCKMfM8ssvj9oGq5Rh@mail.gmail.com>
Message-ID: <AANLkTinxqCu_uTgWQ=WFhw8Qyg5PE0TCTaR01U34YrsM@mail.gmail.com>

> If you do want it to work the same then you'll need to hook into the
> parser and ignore dynamic updates.

Indeed.  And since I explicitly *do* want dynamic updates, it'll need to change.

Thanks.

On Wed, Aug 4, 2010 at 1:32 PM, Philip Taylor <excors+whatwg at gmail.com> wrote:
> On Wed, Aug 4, 2010 at 9:01 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
>>> What happens if the document contains multiple <html> elements (not
>>> all the root element)? (e.g. if it's XHTML, or the elements are added
>>> by scripts). The packages spec seems to assume there is only ever one.
>>
>> The packages attribute should work like the manifest attribute currently works.
>> I don't see language in the cache manifest section of HTML5 (6.6) specifying
>> what happens when there are multiple <html> elements, so I hope I don't need to
>> specify this either. ?:)
>
> http://whatwg.org/html#attr-html-manifest says:
>
> ?"The manifest attribute only has an effect during the early stages
> of document load. Changing the attribute dynamically thus has no
> effect (and thus, no DOM API is provided for this attribute)."
>
> Its effect is triggered from http://whatwg.org/html#parser-appcache
> ("html" token in the "before html" insertion mode) or from
> http://whatwg.org/html#read-xml , so it will only ever run for the
> root <html> element of the document.
>
> The packages attribute is defined as running "Whenever the packages
> attribute is changed (including when the document is first loaded, if
> its <html> element has a packages attribute)", so it's not the same.
> If you do want it to work the same then you'll need to hook into the
> parser and ignore dynamic updates.
>
> --
> Philip Taylor
> excors at gmail.com
>

From Simetrical+w3c at gmail.com  Wed Aug  4 14:16:09 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 4 Aug 2010 17:16:09 -0400
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <4c59b0fc.d908e30a.3490.5535@mx.google.com>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com>
	<op.vgtiz3g048yz2f@dennis>
	<0097F4E418EA47BBAF9C9433340158C6@NETBOOK>
	<AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com>
	<4c59b0fc.d908e30a.3490.5535@mx.google.com>
Message-ID: <AANLkTinYyX9sKWLwPHVzvqQURtdqt3wxfKYFhzjkoFK=@mail.gmail.com>

On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius <svartman95 at gmail.com> wrote:
> A) Per resource metadata:
> ? ? ? ?Some resource is inherently insuitable for immediate
> ? ? ? ?presentation. Metadata regarding this can be provided by e.g. the
> ? ? ? ?Content-Disposation header of RFC 2076 (MIME).

Not all resources have a place to put such metadata, and different
resource types will require the metadata to be in different formats,
and it shouldn't stick around if the user downloads and then uploads
it someplace else, so I don't think this is suitable.

> B) By media type:
> ? ? ? ?A UA may decide that a resources of certain media subtype
> ? ? ? ?cannot be immediately processed or presented to the user. Think
> ? ? ? ?application/octet-stream, executables and likely all subtypes
> ? ? ? ?not present in mailcap (or equivalent).

This doesn't address the use-case at all.  Images can be immediately
processed and presented to the user.

> C) Context:
> ? ? ? ?Due to the context of the link, such as per link metadata.
> ? ? ? ?The straightforward solution is registering a JavaScript callback
> ? ? ? ?to the click event on the relevant <A> element. This though is
> ? ? ? ?highly problematic as the "click" event isn't always fired when a
> ? ? ? ?link is activated (thus possibly resulting in normal navigation to
> ? ? ? ?the destination), UAs currently don't restyle <A>s with listeners
> ? ? ? ?on click (nor any elements with attached listeners). A (or AREA)
> ? ? ? ?with @action, @method or @rel~=save would allow easy styling
> ? ? ? ?with CSS and ignoring.

One proposal was a new "download" attribute.  Or a parameter to data:
URLs.  These seem practical, as does a new rel value.  A parameter to
data: URLs would be a bit weird -- what if it were present in an <img
src>, or if the user typed such a URL directly into the location bar?

> If the browsers UI doesn't have a "Print" button where the user expects
> one to be the UI is broken, not the document to be printed.

An amazing number of users expect a "print" button inside the webpage
itself.  Whatever your opinion of this is, it's a fact.  Many authors
want to add print buttons inside the page to satisfy user demand, and
it doesn't harm anything beyond what the page can already do (since
the user can always dismiss the dialog), so it's a useful feature.

> True. That's why web pages should provide lots of semantic metadata to
> applications that may use that data to make informed decisions.

Yes, like <a rel="download"> or such, as is being proposed.

> I propose
> the "method" attribute on <link>, <a> and <area> that MUST contain
> a case insensitive space-seperated list of methods. A list of valid
> methods should be obtainable from the WHATWG wiki. Note in particular
> that methods are not limited to HTTP methods and neet not alter the
> retrieval or submission of resources, though they most certainly can.
> Valid methods might include:
> GET (retrieve resource without presenting it to the user), PUT (alter
> or create, akin to comp(ose) in run-mailcap), HEAD (retrieve metadata
> about resource), navigate (present the resource to the user).

If I understand correctly, I don't think this is likely to be
implemented or used enough to justify specifying it.  It doesn't have
clear enough use-cases.

From Simetrical+w3c at gmail.com  Wed Aug  4 14:31:02 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 4 Aug 2010 17:31:02 -0400
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
Message-ID: <AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com>

On Wed, Aug 4, 2010 at 8:56 AM, Thomas Koetter
<thomas.koetter at id-script.de> wrote:
> What strikes me though is that according to the spec "The br element represents a line break". A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation.

Anything else is impossible in this case.  <b> and <i> are also
presentational, but the presentation cannot be separated from the
semantics.

> Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer.

Line breaks are not used for minor logical breaks inside paragraphs.
Those are typically represented by a period.

> Consider this:
> <p>P. Sherman<br>
> 42 Wallaby Way<br>
> Sydney</p>
>
> There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks.

That would either be incorrect use of <dl>, or would not display as
desired, or would require hiding some elements arbitrarily.

> <address>
> ? ? ? ?<dl>
> ? ? ? ? ? ? ? ?<dt>Name</dt><dd>P. Sherman</dd>
> ? ? ? ? ? ? ? ?<dt>Street</dt><dd>42 Wallaby Way</dd>
> ? ? ? ? ? ? ? ?<dt>City</dt><dd>Sydney</dd>
> ? ? ? ?</dl>
> </address>

That requires hiding all the <dt> elements to achieve the same
display, which is kind of ridiculous.

> <address>
> ? ? ? ?<dl>
> ? ? ? ? ? ? ? ?<dd>P. Sherman</dd>
> ? ? ? ? ? ? ? ?<dd>42 Wallaby Way</dd>
> ? ? ? ? ? ? ? ?<dd>Sydney</dd>
> ? ? ? ?</dl>
> </address>

That's invalid markup.  The first child of a <dl> (if any) must be a
<dt>.  I don't know what the semantics of <dl> are supposed to be with
no <dt>.  <ul> would work, if you really wanted, but I don't see how
it's any more semantic.

> So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property.

It should already be adjustable using existing style properties, so no
change is needed except possibly saying it represents a logical break
instead of a line break.  This is basically wrong, though, since there
are lots of ways to mark up minor logical breaks, and <br> refers to
one particular way, no other.

Look at it this way: <br> is just a workaround for the fact that HTML
ignores newlines in markup.  It could have just been &#10; in an
alternate history.  It's presentational, yes, but so are periods and
commas.  When I type a period, I don't want the browser to interpret
that as some generic separator that it might hopefully decide to
render as a period, I want *a period*.  Exactly that, nothing else.
Likewise for newlines.  We don't need to impose some abstract semantic
meaning on *everything*.  Some presentation is so closely tied to the
meaning of the document that it can't reasonably be abstracted away.
This is true for <b>, <i>, <sup>, <sub>, and <br>, among others.

From ian at hixie.ch  Wed Aug  4 14:32:46 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 21:32:46 +0000 (UTC)
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTimvghWo1OWZ6aFaK_HraRirZXUMqQDMblZIbCnW@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com> 
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com> 
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com> 
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
	<Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>
	<DD63BEE9-CEF1-43F8-AF3A-EA76402027A7@apple.com>
	<AANLkTimvghWo1OWZ6aFaK_HraRirZXUMqQDMblZIbCnW@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008042111080.7470@ps20323.dreamhostps.com>


On Fri, 4 Jun 2010, TAMURA, Kent wrote:
> > > 
> > > An element is a "candidate for constraint validation" if
> > > 1. it is a validatable type,
> > >    e.g. true if <input type=number>, false if <input type=reset>
> > > 2. has no "disabled" attribute,
> > > 3. has no "readonly" attribute,
> > > 4. inside of a <form> element,
> > > 5. has non-empty "name" attribute, and
> > > 6. not inside of a <datalist> element.
> > > 
> > > I hope ValidityState and the pseudo classes ignores 2-6.
> >
> > The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)
> 
> I'd like to propose to add another condition:
> 7. it is visible (computed 'display' property of CSS isn't 'none' and no
> 'hidden' content attribute)

The problem with that is that they still get submitted, so it seems weird 
to not validate them. It seems authors should be careful not to make the 
hidden controls be invalid.


On Thu, 3 Jun 2010, Tab Atkins Jr. wrote:
> 
> Adding @hidden to the list of things that skip validation is good.

I considered it, but really we should also also stop submission in that 
case, and that seems like it's starting to make things a little less 
intuitive than I'd like. It's really up to the author to make sure that 
something that's irrelevant (hidden="") is not part of a form that is 
user-submittable.


> Adding display:none is not.  That's a big layering violation that we 
> authors have to suffer through with screen readers already.  I'd greatly 
> prefer not muddying the waters there.

Indeed.


On Fri, 4 Jun 2010, TAMURA, Kent wrote:
>
> Oh, I'm sorry.  I have found a sentence about visibility in the draft.
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
> >
> > If one of the controls is not being rendered (e.g. it has the hidden 
> > attribute set) then user agents may report a script error.
> 
> This sentence is about process against controls of which validation 
> result is invalid.
>
> I think UA doesn't need to validate such controls.

I think, as the sentence above suggests, it's better to report this as a 
page error than to not validate the control. Chrome already reports this 
problem in the console.


> The Chrome bug report is here:
> http://code.google.com/p/chromium/issues/detail?id=45640

The bug there is that Chrome is filling in a control that isn't visible, 
and, even worse, that it is filling it with a value that the user couldn't 
himself enter manually. That's a bug (two bugs in fact), but it has 
nothing to do with reporting validation errors -- the error should not be 
able to occur.


On Thu, 3 Jun 2010, Peter Kasting wrote:
> 
> I posted this on the Chromium bug, but I take the sentence Kent quotes 
> to affect only the UI shown on a validation failure, not the actual 
> results of validation.  That is, if a control fails validation and has 
> the "hidden" attribute, validation still fails, but the UA may display a 
> message indicating the page has an error in addition to/instead of the 
> normal validation failure message.

Indeed.


On Mon, 14 Jun 2010, TAMURA, Kent wrote:
>
> There are some objections against omitting invisible controls from form 
> validation. However, it is a real issue with existing sites and users 
> can't submit such forms at all though they can submit it with non-HTML5 
> browsers.
> 
> My conclusion is it's better to disable interactive form validation for 
> existing sites as possible. e.g. disabling interactive form validation 
> for documents without "<!DOCTYPE html>".

Just don't autofill controls with invalid values, and don't autofill 
hidden controls. :-)


On Mon, 14 Jun 2010, Ola P. Kleiven wrote:
> 
> The following sites have workarounds in Opera's browser.js to allow form
> submit:
> 
> airgreenland.com (using required on hidden elements)
> barnesandnoble.com (using required on visible elements that are supposed to be
> empty on submit...)
> bookryanair.com (using required=false - this usage has also been found in JS
> libraries)
> ingdirect.com.au (using required on a visible field, but then emptying the
> field with JS before submit)
> usairways.com (using required on hidden elements)
> 
> Most of these have been using it for several years and have not 
> responded to change requests from our side.

Do you have more specific URLs I could look at for these?

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

From ian at hixie.ch  Wed Aug  4 14:34:02 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 21:34:02 +0000 (UTC)
Subject: [whatwg] Sort child nodes of a DOM node.
In-Reply-To: <AANLkTimNLX_rDFNIu85EOxmaguL7E2E0pOU0CMqjvIfN@mail.gmail.com>
References: <AANLkTimNLX_rDFNIu85EOxmaguL7E2E0pOU0CMqjvIfN@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008042133370.7470@ps20323.dreamhostps.com>

On Fri, 4 Jun 2010, Biju wrote:
>
> There are many cases where we want to sort child nodes of a DOM node.
> Many times it is TR nodes of a TBODY
> 
> Right now user writes javascript code to achive that.
> Dont you think it is better if there was built DOM method for each node.
> Additionally the method will have a sort function parameter to compare elements
> the same way as in JavaScript Array.sort(compare_func)
> 
> function compare_func(a,b){
>  if(isHeaderRow(a))  return -1;
>  if(isHeaderRow(b))  return 1;
>  if(a.textContent == b.textContent) return 0;
>  if(a.textContent < b.textContent) return -1;
>  return 1;
> }
> tablebody.sortChildNodes(compare_func)
> 
> Use cases:-
> Example 1: column sorting in yahoo mail
> 
> Example 2: you can sort this listing by clicking the column headers
> https://bugzilla.mozilla.org/buglist.cgi?short_desc=sort&short_desc_type=allwordssubstr&resolution=---
> 
> Example 2: there are bug report in mozilla asking sorting in XUL grids
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890&hide_resolved=1

This would indeed be useful. It seems like something that should be in DOM 
Core, though, rather than HTML. Do we have anyone editing Web DOM Core 
these days?

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

From jonas at sicking.cc  Wed Aug  4 14:40:54 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 4 Aug 2010 14:40:54 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com> 
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com> 
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com> 
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr> 
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com> 
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com> 
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com> 
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
Message-ID: <AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>

On Wed, Aug 4, 2010 at 11:10 AM, Alex Russell <slightlyoff at google.com> wrote:
> Sorry for the lagged response,
>
> On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt <oliver at apple.com> wrote:
>>
>> On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
>>
>>> On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>>>
>>>>> The e-mails quoted below consist of the salient points of this thread:
>>>>>
>>>>> On Fri, 23 Apr 2010, David Bruant wrote:
>>>>>>
>>>>>> Make that HTMLCollection (and all HTML*Collection, as a consequence of
>>>>>> inheritence of HTMLCollection) inherit from the ECMAScript Array
>>>>>> prototype. This way, it will make available all Array extra methods
>>>>>> (forEach, map, filter...) added in ECMAScript5 (and next versions which
>>>>>> should go in the same direction).
>>>>>>
>>>>>> As far as I know, adding this won't break any existing code. The
>>>>>> semantics of a Collection and the way it is used is very close from
>>>>>> ECMAScript Arrays. I don't think that the notion of "live object" and
>>>>>> ECMAScript Array are incompatible either. Once again, I am talking about
>>>>>> ECMAScript binding. I have no intention to touch the HTMLCollection
>>>>>> interface or other languages bindings.
>>>>>
>>>>> On Sun, 25 Apr 2010, J Z wrote:
>>>>>>
>>>>>> If HTMLCollection was inheriting from Array, and methods like `forEach`,
>>>>>> `map`, etc. were to operate on a live object, there would definitely be
>>>>>> undesired consequences. We can see this in, say, Firefox (which allows to
>>>>>> set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
>>>>>>
>>>>>> HTMLCollection.prototype.__proto__ = Array.prototype;
>>>>>>
>>>>>> document.getElementsByTagName('div').forEach(function(el) {
>>>>>> ? el.parentNode.removeChild(el); // doesn't work as expected
>>>>>> });
>>>>>>
>>>>>> // turning live collection into static array fixes this
>>>>>> Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
>>>>>> ? el.parentNode.removeChild(el);
>>>>>> });
>>>>>
>>>>> On Sat, 24 Apr 2010, David Bruant wrote:
>>>>>>
>>>>>> I think I can take your point as a "pro" more than a "con", because in
>>>>>> ES5, right before the definition of each array extra method, a paragraph
>>>>>> like the following can be found :
>>>>>>
>>>>>> "The range of elements processed by forEach is set before the first call
>>>>>> to callbackfn. Elements which are appended to the array after the call
>>>>>> to forEach begins will not be visited by callbackfn. If existing
>>>>>> elements of the array are changed, their value as passed to callback
>>>>>> will be the value at the time forEach visits them; elements that are
>>>>>> deleted after the call to forEach begins and before being visited are
>>>>>> not visited."
>>>>>>
>>>>>> This point is confirmed by every algorithm where the length is "saved"
>>>>>> once for all before the loop and not got from the .length property each
>>>>>> time.
>>>>>
>>>>> On Mon, 26 Apr 2010, Erik Arvidsson wrote:
>>>>>> On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
>>>>>>> Le 25/04/2010 00:39, J Z a ?crit :
>>>>>>>>
>>>>>>>> I have thought a lot about weirdnesses that people could think about
>>>>>>>> like trying to assign a value to the HTMLCollection (divs[14] =
>>>>>>>> myOtherDiv), but once again, it wouldn't be more allowed than it
>>>>>>>> currently is (I have no idea of what happens today, but if an error
>>>>>>>> is thrown in a for-loop, it should throw an error as well in a call
>>>>>>>> within a forEach).
>>>>>>>
>>>>>>> How would destructive methods like `push` or `sort` behave? Would
>>>>>>> `document.body.childNodes.push(document.createTextNode('foo'))` append
>>>>>>> text node to a body element? Or would it be a noop?
>>>>>>>
>>>>>>> That is actually a very good point. It think that the behavior should
>>>>>>> be exactly the same as "an equivalent without array methods". (this
>>>>>>> point of my proposal would need to be made completly explicit for each
>>>>>>> method)
>>>>>>
>>>>>> One way to solve this could be to split Array into two interfaces. One
>>>>>> to be used with immutable array like objects and one to use to mutate
>>>>>> objects. Then we could apply the immutable array like interface to
>>>>>> NodeList and its related interfaces. The benefit of doing that is that
>>>>>> NodeList.prototype.push would be undefined instead of failing when
>>>>>> called.
>>>>>
>>>>> On Mon, 26 Apr 2010, David Flanagan wrote:
>>>>>>
>>>>>> Rather that trying to make DOM collections feel like arrays, how about
>>>>>> just giving them a toArray() method? ?This makes it clear that a
>>>>>> collection is not an array, but clearly defines a way to obtain an
>>>>>> array. ?Clever implementors might even be able to optimize common
>>>>>> uses-cases using some kind of copy-on-write strategy so that toArray()
>>>>>> doesn't involve memory allocation and copying.
>>>>>>
>>>>>> Of course, trying to teach programmers when they ought to call toArray()
>>>>>> and when it is not necessary is another matter. ?Perhaps calling the
>>>>>> method snapshot() and focusing on the live vs. static distinction
>>>>>> instead of the fake array vs. true array distinction would invite less
>>>>>> misuse.
>>>>>>
>>>>>> Or we can just leave the DOM as it is and get used to calling the
>>>>>> equivalent of Prototype's $A() function.
>>>>>
>>>>> Before changing something this substantial, I'd like to have implementor
>>>>> feedback regarding what the best way to address this is:
>>>>>
>>>>> ?- somehow make HTMLCollections and NodeLists inherit from Array?
>>>>>
>>>>> ?- define a bunch of feature on HTMLCollections and NodeLists so that
>>>>> ? they're like arrays?
>>>>
>>>> I don't think this makes sense given the immutability of NodeLists.
>>>
>>> Wait...what? Shouldn't some sort of NodeList be mutable? And shouldn't
>>> JS support immutable Arrays? We need to fix both of these APIs, and we
>>> keep heaping back-pressure on JavaScript's Array without any
>>> reasonable resolution because we're not exploring how to make Array
>>> subtypes work as we want them to for all the use cases (like this)
>>> that we care to express.
>>
>> What would you expect a mutable NodeList to be?
>
> A good example would be the result of document.querySelectorAll().

Why couldn't querySelectorAll return a normal Array?

/ Jonas

From mjs at apple.com  Wed Aug  4 15:01:15 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 04 Aug 2010 15:01:15 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com>
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr>
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
Message-ID: <BE55939B-7082-452E-8341-7AAB704035F5@apple.com>


On Aug 4, 2010, at 2:40 PM, Jonas Sicking wrote:

> On Wed, Aug 4, 2010 at 11:10 AM, Alex Russell <slightlyoff at google.com> wrote:
>> Sorry for the lagged response,
>> 
>> On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt <oliver at apple.com> wrote:
>>> 
>>> On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
>>> 
>>>> Wait...what? Shouldn't some sort of NodeList be mutable? And shouldn't
>>>> JS support immutable Arrays? We need to fix both of these APIs, and we
>>>> keep heaping back-pressure on JavaScript's Array without any
>>>> reasonable resolution because we're not exploring how to make Array
>>>> subtypes work as we want them to for all the use cases (like this)
>>>> that we care to express.
>>> 
>>> What would you expect a mutable NodeList to be?
>> 
>> A good example would be the result of document.querySelectorAll().
> 
> Why couldn't querySelectorAll return a normal Array?

I think in principle it could, but it might be too much compat risk to do now.

Returning a fully mutable array would also remove the opportunities to cache and reuse the return value, since each result would really need to be distinct if they are mutable.

Regards,
Maciej

From dhtmlkitchen at gmail.com  Wed Aug  4 15:27:35 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 4 Aug 2010 15:27:35 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com>
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr>
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
Message-ID: <AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>

On 8/4/10, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Aug 4, 2010 at 11:10 AM, Alex Russell <slightlyoff at google.com>
> wrote:
>> Sorry for the lagged response,
>>
>> On Fri, Jul 30, 2010 at 2:56 PM, Oliver Hunt <oliver at apple.com> wrote:
>>>
>>> On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
>>>
>>>> On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>>> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>>>>
>>>>>> The e-mails quoted below consist of the salient points of this thread:
>>>>>>
>>>>>> On Fri, 23 Apr 2010, David Bruant wrote:
>>>>>>>
>>>>>>> Make that HTMLCollection (and all HTML*Collection, as a consequence
>>>>>>> of
>>>>>>> inheritence of HTMLCollection) inherit from the ECMAScript Array
>>>>>>> prototype. This way, it will make available all Array extra methods
>>>>>>> (forEach, map, filter...) added in ECMAScript5 (and next versions
>>>>>>> which
>>>>>>> should go in the same direction).
>>>>>>>
>>>>>>> As far as I know, adding this won't break any existing code. The
>>>>>>> semantics of a Collection and the way it is used is very close from
>>>>>>> ECMAScript Arrays. I don't think that the notion of "live object" and
>>>>>>> ECMAScript Array are incompatible either. Once again, I am talking
>>>>>>> about
>>>>>>> ECMAScript binding. I have no intention to touch the HTMLCollection
>>>>>>> interface or other languages bindings.
>>>>>>
>>>>>> On Sun, 25 Apr 2010, J Z wrote:
>>>>>>>
>>>>>>> If HTMLCollection was inheriting from Array, and methods like
>>>>>>> `forEach`,
>>>>>>> `map`, etc. were to operate on a live object, there would definitely
>>>>>>> be
>>>>>>> undesired consequences. We can see this in, say, Firefox (which
>>>>>>> allows to
>>>>>>> set [[Prototype]] of `HTMLCollection` to `Array.prototype`):
>>>>>>>
>>>>>>> HTMLCollection.prototype.__proto__ = Array.prototype;
>>>>>>>
>>>>>>> document.getElementsByTagName('div').forEach(function(el) {
>>>>>>>   el.parentNode.removeChild(el); // doesn't work as expected
>>>>>>> });
>>>>>>>
>>>>>>> // turning live collection into static array fixes this
>>>>>>> Array.slice(document.getElementsByTagName('div')).forEach(function(el)
>>>>>>> {
>>>>>>>   el.parentNode.removeChild(el);
>>>>>>> });
>>>>>>
>>>>>> On Sat, 24 Apr 2010, David Bruant wrote:
>>>>>>>
>>>>>>> I think I can take your point as a "pro" more than a "con", because
>>>>>>> in
>>>>>>> ES5, right before the definition of each array extra method, a
>>>>>>> paragraph
>>>>>>> like the following can be found :
>>>>>>>
>>>>>>> "The range of elements processed by forEach is set before the first
>>>>>>> call
>>>>>>> to callbackfn. Elements which are appended to the array after the
>>>>>>> call
>>>>>>> to forEach begins will not be visited by callbackfn. If existing
>>>>>>> elements of the array are changed, their value as passed to callback
>>>>>>> will be the value at the time forEach visits them; elements that are
>>>>>>> deleted after the call to forEach begins and before being visited are
>>>>>>> not visited."
>>>>>>>
>>>>>>> This point is confirmed by every algorithm where the length is
>>>>>>> "saved"
>>>>>>> once for all before the loop and not got from the .length property
>>>>>>> each
>>>>>>> time.
>>>>>>
>>>>>> On Mon, 26 Apr 2010, Erik Arvidsson wrote:
>>>>>>> On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
>>>>>>>> Le 25/04/2010 00:39, J Z a ?crit :
>>>>>>>>>
>>>>>>>>> I have thought a lot about weirdnesses that people could think
>>>>>>>>> about
>>>>>>>>> like trying to assign a value to the HTMLCollection (divs[14] =
>>>>>>>>> myOtherDiv), but once again, it wouldn't be more allowed than it
>>>>>>>>> currently is (I have no idea of what happens today, but if an error
>>>>>>>>> is thrown in a for-loop, it should throw an error as well in a call
>>>>>>>>> within a forEach).
>>>>>>>>
>>>>>>>> How would destructive methods like `push` or `sort` behave? Would
>>>>>>>> `document.body.childNodes.push(document.createTextNode('foo'))`
>>>>>>>> append
>>>>>>>> text node to a body element? Or would it be a noop?
>>>>>>>>
>>>>>>>> That is actually a very good point. It think that the behavior
>>>>>>>> should
>>>>>>>> be exactly the same as "an equivalent without array methods". (this
>>>>>>>> point of my proposal would need to be made completly explicit for
>>>>>>>> each
>>>>>>>> method)
>>>>>>>
>>>>>>> One way to solve this could be to split Array into two interfaces.
>>>>>>> One
>>>>>>> to be used with immutable array like objects and one to use to mutate
>>>>>>> objects. Then we could apply the immutable array like interface to
>>>>>>> NodeList and its related interfaces. The benefit of doing that is
>>>>>>> that
>>>>>>> NodeList.prototype.push would be undefined instead of failing when
>>>>>>> called.
>>>>>>
>>>>>> On Mon, 26 Apr 2010, David Flanagan wrote:
>>>>>>>

[snip]

To all, please trim quotes to a minimum - thanks.

>>> What would you expect a mutable NodeList to be?
>>
>> A good example would be the result of document.querySelectorAll().
>
> Why couldn't querySelectorAll return a normal Array?
>

It could have done that. It would not be immutable. How much
interoperability issue would changing it now cause? Array could be an
ECMA binding as a potential consideration as an idea for alternative
to non-live static nodelist.

Changing live collections to be Arrays would cause severe
interoperability problems. It would be very complicated.

Then if you're going to get an array, it should be possible to set an
array. I suppose in this sort of situation a setItems method could be
useful:

  var cells = Array.prototype.slice.call(row.cells).sort( comparator );
  row.childNodes.setItems( cells );

The first line is a bit ugly and so it would be nice to have it a more
succinct, not to save typing, per se, but to be clearer:

  var cells = row.cells.toArray().sort( comparator );
  row.childNodes.setItems( cells );

Then again, if ECMA provides top level static Array generics, it's
about the same:

  var cells = Array.slice(row.cells).sort( comparator );
  row.childNodes.setItems( cells );

But that doesn't still address the more fundamental problem of
explaining existing collections. Should they be implemented as native
ES object? Should property access operations ([[Get]]) or
[[HasProperty]] checks be defined more precisely? What are "string
index" and "integer index" with property accessor operators? These
constructs are all used today and without clear definition of what is
to be expected by:

  "submitButton" in form.elements

Existing implementations vary on when they use catchalls. I'd like to
see standardization for this behavior and codification so that
implementations behave similarly -- either use a catchall for a
particular type of collection or use a native object. If a catchall is
used, it would be nice to get "has" checks working with desirable
results.  For example, it would be nice to see - "submitButton" in
elements - result true iff `elements` can [[Get]] a "submitButton"
property.

Garrett

From dhtmlkitchen at gmail.com  Wed Aug  4 15:32:49 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 4 Aug 2010 15:32:49 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com>
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr>
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
	<AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>
Message-ID: <AANLkTimrrvhHj0dy8wZhO761BpXuh5831wTVX2fN6m-+@mail.gmail.com>

On 8/4/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

[...]
>   "submitButton" in form.elements
>
> Existing implementations vary on when they use catchalls. I'd like to
> see standardization for this behavior and codification so that
> implementations behave similarly -- either use a catchall for a
> particular type of collection or use a native object. If a catchall is

Native object either way, but either with a new ES catchall behavior
or with a native ES object, as specified today.

Garrett

From ian at hixie.ch  Wed Aug  4 15:46:43 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 22:46:43 +0000 (UTC)
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTinZEDxBpd4EBY4j0L6ftN4JdGdLleO1T2ZDu_2t@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<4C095AE0.6060504@emsai.net>
	<AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
	<AANLkTinZEDxBpd4EBY4j0L6ftN4JdGdLleO1T2ZDu_2t@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008042224240.7470@ps20323.dreamhostps.com>

On Fri, 4 Jun 2010, Smylers wrote:
>
> The HTML5 spec should define how to mark up the main content on a page 
> (even if the answer is "by omission"). This is something that many 
> authors ask about, the latest example being today's thread on the help 
> mailing list: 
> http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
> 
> Please could this be added to the 'idioms' section, perhaps giving 
> examples of when <article> or <section> might be appropriate as well as 
> one in which the main content is simply that which isn't in <header>, 
> <aside>, etc.

Done.


On Fri, 4 Jun 2010, Daniel Persson wrote:
>
> I am the one posting the question on the help list. To me, the lack of 
> html5 definition of main content, ie body copy in paper publishing, is a 
> big mistake. Imagine the amount of sites where "everything else" 
> includes a lot of unimportant extra, or peripheral, content. Content 
> which is not necessarily hierarchically legible by a machine. Getting 
> authors to be disciplined about defining main content is more important 
> than being disciplined about <nav>, <footer>, <header>, <section> etc, 
> in order not to negate the meaning of html5 structural mark-up.
> 
> Suggestion <bodycopy>... or, preferred, <bread>.

Getting authors to be disciplined about defining main content is in fact 
the same as being disciplined about <nav>, <footer>, <header>, etc, 
because the main content is anything not in those elements.


On Fri, 4 Jun 2010, Daniel Persson wrote:
>
> Some websites are very crowded. I have no particular example. Blogs and 
> easily accessible CMS's, people trying to make a buck from excessive 
> advertising on their site, people cramming a lot of info/screen unit. 
> Companies too, old media: http://www.aftonbladet.se/ (major Swedish 
> paper, watch your eyes) . <body> will hold a lot of stuff that is not 
> main content, other content will spill over into <body> (unless there is 
> a conscious author, and vast use of <aside>).
>
> It should be easy for authors to define main content. It s a pedagogical 
> issue, where authors not too concerned with standards compliance, should 
> have an easy escape of at least defining the most important on the site.

We could either mark up what's the main content, implying that everything 
else is not the main content, or mark up what's not the main content, 
implying that everything else is the main content. We've gone with the 
latter, because it turns out that the main content's presentation is 
usually just the default, whereas everything else needs to be styled 
specially, so people usually want to wrap the non-main-content.

However, there are cases where you also want to wrap the main content. For 
those cases, we have <article>, <section>, and <div> (in increasing order 
of vagueness).


On Fri, 4 Jun 2010, Tab Atkins Jr. wrote:
> 
> Authors can either use <aside> to mark up all the irrelevant stuff on 
> their page that isn't main content, or they can wrap the main content in 
> an <article> (not ideal, but workable).

Actually it's pretty much what <article> was meant for.


On Mon, 7 Jun 2010, Daniel Persson wrote:
> 
> What I am taking about is that it is upside down to expect honest people 
> to define everything except the main content. Pedagogically and 
> methodologically. Main content is main content, the most important to 
> define. That should be the starting point for the structure.

I don't understand why.

Think of a sentence:

   I like kittens (and cats).

The important content is "I like kittens". The less important content is 
"and cats". We mark up the less important content.


> The simplest tutorial on html5 authoring should be: Getting doctype and 
> charset right, html, head, body. Then define main content. Finished. 
> Ready to be indexed.

I don't see why the "define main content" step is useful. What problem 
does it solve?


> ...bu at least the main content (as defined by the author) can be 
> reached, indexed, sorted or stacked by machines.

This seems to be a solved problem today, without any markup.


On Fri, 4 Jun 2010, Aryeh Gregor wrote:
> 
> It's unwise to omit <body> unless you can guarantee that the first 
> element in the body will actually trigger the end of the head.  In your 
> case, I believe that at least IE will put <aside> and <article> in the 
> head, because it doesn't recognize them as only belonging in the body.  
> (It seems like the HTML5 parser does put it in the body -- although as 
> far as I can tell, this means we can never introduce new elements that 
> can go in the head.)

We just add them to the list of elements that go in head, and wait a few 
years.

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

From jonbarnett at gmail.com  Wed Aug  4 15:56:16 2010
From: jonbarnett at gmail.com (Jon Barnett)
Date: Wed, 4 Aug 2010 17:56:16 -0500
Subject: [whatwg] Sort child nodes of a DOM node.
In-Reply-To: <AANLkTimNLX_rDFNIu85EOxmaguL7E2E0pOU0CMqjvIfN@mail.gmail.com>
References: <AANLkTimNLX_rDFNIu85EOxmaguL7E2E0pOU0CMqjvIfN@mail.gmail.com>
Message-ID: <AANLkTi=tG9n+vNpanuSLnh+dVMkcCR+zfZzJrqzGqLUq@mail.gmail.com>

On Fri, Jun 4, 2010 at 1:49 AM, Biju <bijumaillist at gmail.com> wrote:

> There are many cases where we want to sort child nodes of a DOM node.
> Many times it is TR nodes of a TBODY
>
> Right now user writes javascript code to achive that.
> Dont you think it is better if there was built DOM method for each node.
> Additionally the method will have a sort function parameter to compare
> elements
> the same way as in JavaScript Array.sort(compare_func)
>
> function compare_func(a,b){
>  if(isHeaderRow(a))  return -1;
>  if(isHeaderRow(b))  return 1;
>  if(a.textContent == b.textContent) return 0;
>  if(a.textContent < b.textContent) return -1;
>  return 1;
> }
> tablebody.sortChildNodes(compare_func)
>
> Use cases:-
> Example 1: column sorting in yahoo mail
>
> Example 2: you can sort this listing by clicking the column headers
>
> https://bugzilla.mozilla.org/buglist.cgi?short_desc=sort&short_desc_type=allwordssubstr&resolution=---
>
> Example 2: there are bug report in mozilla asking sorting in XUL grids
>
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890&hide_resolved=1
>

This sounds more akin to the thread with the subject line "Adding ECMAScript
5 array extras to HTMLCollection"
It's already easy enough to do once you've copied the nodes into an array:

var rowsArray = convertNodeListIntoJSArray(tBody.rows); // assuming you've
written such a function
rowsArray.sort(compare_func);
tBody.innerHTML = "";
rowsArray.forEach(function(row) { tBody.appendChild(row) });

I'd rather just see some kind of resolution to mixing in Array methods into
the HTMLCollection object.  Since HTMLCollection objects are often 'live' it
would just be:

tBody.rows.sort(compare_func);

I have no opinion on how Array methods should be mixed into HTMLCollection
objects, since the difficulty seems to be more in implementation than
devising a web authors' wishlist, but that's what I'd rather see.

-- 
Jon Barnett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100804/4b885c5a/attachment-0001.htm>

From ian at hixie.ch  Wed Aug  4 16:03:19 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 23:03:19 +0000 (UTC)
Subject: [whatwg] bubbling events on labels
In-Reply-To: <AANLkTilReb_ZKVZxdI9zqrkSv4ntZXlC9vTjAeqobOI_@mail.gmail.com>
References: <AANLkTilf7RXLyJ4UVVGsp2thSDrIFgZ0Ttusg3K5Wqbo@mail.gmail.com>
	<AANLkTiml8gcR2XHYiJI5uOvENPseY2LY2iPZ1kD0I4DO@mail.gmail.com>
	<1275690246.2217.87.camel@localhost>
	<AANLkTikLB1FobS3LMl957M4BoBjGxj9hVDTXo5UW6MjK@mail.gmail.com>
	<AANLkTilReb_ZKVZxdI9zqrkSv4ntZXlC9vTjAeqobOI_@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008042254540.7470@ps20323.dreamhostps.com>

On Fri, 4 Jun 2010, Diego Perini wrote:
>
> I have different behavior in browsers with the "checked" state of a 
> checkbox input element.
> 
> I have filed a ticket in Webkit and I am looking after some 
> advice/suggestion about the correct behavior expected from this HTML:
> 
>    <label>
>      <input type="checkbox">
>      <a href="#">Enable</a>
>    </label>
> 
> It seems Safari/Chrome are discarding the click bubbling at the link 
> level, thus never reaching the label and not toggling the checkbox.
> 
> The behavior in Firefox/Opera and in Safari/Chrome is different and the 
> checkbox is correctly "checked" (as I would have expected).
> 
> Should a click on the link make the input checked ?

On Fri, 4 Jun 2010, Tab Atkins Jr. wrote:
> 
> As far as I can tell, section 3.5.2.1.7 (Interactive Content) specifies 
> that clicking the link in that situation should activate the link and 
> not toggle the checkbox.

Indeed.

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

From jeremy at adactio.com  Wed Aug  4 16:03:32 2010
From: jeremy at adactio.com (Jeremy Keith)
Date: Thu, 5 Aug 2010 00:03:32 +0100
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
Message-ID: <C91F41D6-9316-47ED-93B4-DF73DF028375@adactio.com>

Thomas wrote:
> What strikes me though is that according to the spec "The br element represents a line break". A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation.

I agree. Other elements have been redefined to remove medium-specific descriptions from their definitions (<b>, <i>, and <hr>, specifically). It seems logical to me that <br> should get the same treatment.

timeless wrote:
> The short form is that part of HTML5 is documenting how HTML1..4
> works, so that browsers can support existing content by implementing
> the HTML5 specification.

The suggestion, as far as I understand it, is not to change how the element *works* in browsers, but merely to redefine its meaning as "a minor logical break" rather than "a line break." The default browser styling would not change.

Aryeh wrote:
> Anything else is impossible in this case.  <b> and <i> are also
> presentational, but the presentation cannot be separated from the
> semantics.

This is no longer true. The semantics of <b> and <i> have been changed in HTML5, specifically to separate the presentation from the meaning. Specifically, any reference to screen- or page-specific styling like "bold" and "italic" have been removed (allowing the elements to still have meaning in a medium such as audio).

I like Thomas's suggestion (or, at least, I like it as much as any of the semantic redefinitions being applied to formerly-presentational elements).

The <hr> element is currently defined as "a paragraph-level thematic break." I think <br> could be defined as "a text-level thematic break."

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From ian at hixie.ch  Wed Aug  4 16:07:04 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 23:07:04 +0000 (UTC)
Subject: [whatwg] Why is DOMContentLoaded event not bubbling?
In-Reply-To: <AANLkTinR6WxtAUw50HlKYxOWYsfYCGq5T1V98tqWfesc@mail.gmail.com>
References: <AANLkTinR6WxtAUw50HlKYxOWYsfYCGq5T1V98tqWfesc@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008042305070.7470@ps20323.dreamhostps.com>

On Sun, 6 Jun 2010, Nickolay Ponomarev wrote:
> 
> Currently DOMContentLoaded is specified [1] with this sentence:
> > Queue a task to fire a simple event named DOMContentLoaded at the
> Document.
> 
> and "fire a simple event" is defined [2] as "does not bubble (except 
> where otherwise stated) and is not cancelable (except where otherwise 
> stated)". So it's not bubbling and, as far as I understand, per [3] it 
> means it doesn't bubble to Window.
> 
> I checked Gecko (trunk), Safari (4), Chrome (6) and in all of them it 
> bubbles to window and reports itself as bubbling.

Fixed.

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

From ian at hixie.ch  Wed Aug  4 16:14:34 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Aug 2010 23:14:34 +0000 (UTC)
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <4C2370E2.5020307@gmx.de>
References: <AANLkTik30dn_11h4igbNV6XCH0uJKWp7e59gRTSvTPpJ@mail.gmail.com>
	<AANLkTimg2AxmvNLuCJIYW1K7oUxG4j9y_J4JoChXx2WI@mail.gmail.com>
	<4C2370E2.5020307@gmx.de>
Message-ID: <Pine.LNX.4.64.1008042309370.7470@ps20323.dreamhostps.com>

On Mon, 7 Jun 2010, narendra sisodiya wrote:
>
> For example video telephony in browser is possible?

I sent some comments regarding this topic recently:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027129.html


On Mon, 7 Jun 2010, narendra sisodiya wrote:
> 
> I clearly see the huge market in Virtual worlds like second life and 
> augmented reality in mobile phones. WebGL is a rendering specification. 
> I think , on top of webGL , we may need some higher order specification 
> for 3D web. Who know, HTMLx may include <3dwall orientation='right' 
> id='facebook-wall' /> type of tags,
> 
> Anyway , I am a strong believer of Matrix. We will be having a similar 
> sort of Matrix is future. So It is the question of future that - 'will 
> Matrix us flash/sliverlight or Open Standards'
> 
> If All of sudden we got huge bandwidth and second life will be most 
> popular web browser. in second life one can have a 2D browser and other 
> technologies. I was just trying to have a discussion of future version 
> of HTMLx , open standards and future technologies...
> 
> I have seen a 'lazy web' nature. first close standards comes and then we 
> fight for an equivilant open standard.

That's one way to put it, though I would personally describe it as 
allowing innovation to happen and then standardising what is successful. 
Another way to put it is in the FAQ:

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


On Thu, 24 Jun 2010, Julian Reschke wrote:
> On 24.06.2010 16:03, Marques Johansson wrote:
> > I would like to see a standardization of HTTP streaming, not 
> > necessarily "adaptive streaming" - but that could also be useful.
> > 
> > The HTTP spec is vague or incomplete on behaviors related to partial 
> > requests. ...
> 
> If you think that there is a bug in the HTTP spec then by all means 
> check out the latest drafts, and in doubt report this on the HTTPbis 
> WG's mailing list (pointers: <http://tools.ietf.org/wg/httpbis/>).

Indeed.

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

From oliver at apple.com  Wed Aug  4 16:47:41 2010
From: oliver at apple.com (Oliver Hunt)
Date: Wed, 4 Aug 2010 16:47:41 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTimrrvhHj0dy8wZhO761BpXuh5831wTVX2fN6m-+@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<4BD5D280.30706@doxdesk.com> <4BD6C264.7070805@opera.com>
	<4BD72BBE.80106@enseirb-matmeca.fr> <4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
	<AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>
	<AANLkTimrrvhHj0dy8wZhO761BpXuh5831wTVX2fN6m-+@mail.gmail.com>
Message-ID: <D7F43572-46DE-4374-B100-6C6976012416@apple.com>


On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:

> On 8/4/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> 
> [...]
>>  "submitButton" in form.elements
>> 
>> Existing implementations vary on when they use catchalls. I'd like to
>> see standardization for this behavior and codification so that
>> implementations behave similarly -- either use a catchall for a
>> particular type of collection or use a native object. If a catchall is
> 
> Native object either way, but either with a new ES catchall behavior
> or with a native ES object, as specified today.
> 
> Garrett
As a question, if the node lists were implemented as catchalls, how would the behaviour differ from current NodeLists?  The only change I can see would be the loss of the host object exceptions in the ES spec, but that just puts you in the position of having semantics that match the current host object behavior in those implementations that already allow array functions to operate on host objects.

--Oliver


From svartman95 at gmail.com  Wed Aug  4 17:09:16 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 05 Aug 2010 00:09:16 +0000
Subject: [whatwg] [URL] Starting work on a URL spec
In-Reply-To: <AANLkTimZj4gBPHyP13cUZZem8BCbqjEqY79GD2U6g5c7@mail.gmail.com>
References: <AANLkTikBCEGJC4PNVB=m09GxSHAr4H=frYUcgXax9_AN@mail.gmail.com>
	<AANLkTi=DDow5fP-+-fvaZNdK0afitkigZtHBEyS9Dod=@mail.gmail.com>
	<4C4A65D5.2000000@mit.edu>
	<AANLkTi=88AtQTJroZUuC5ihX5jqOuj5RL4nop7Cm5eSr@mail.gmail.com>
	<AANLkTi=7-oMG9g43cC0E0ee_TrOQf2L4ZBvE-Y=tDsUi@mail.gmail.com>
	<083933CF-BEA0-4DE7-91CC-F1E41593F7EA@apple.com>
	<AANLkTi=g3jrC8bvoigrQBY-SQ-4GeoM+mZtasp2V-Rmf@mail.gmail.com>
	<4C4C3F87.6050408@mit.edu>
	<4c583416.0315e30a.5b04.0af7@mx.google.com>
	<AANLkTimZj4gBPHyP13cUZZem8BCbqjEqY79GD2U6g5c7@mail.gmail.com>
Message-ID: <4c5a0142.1207e30a.3f55.5e32@mx.google.com>

On Tue, 03 Aug 2010, Adam Barth <w3c at adambarth.com> wrote:
> On Tue, Aug 3, 2010 at 8:21 AM, bjartur <svartman95 at gmail.com> wrote:
> >> On 7/25/10 8:57 AM, Adam Barth wrote:
> >> It may not be an _html_ interoperability problem, but it's certainly a
> >> _web_ interoperability problem.
> >
> > It's a question of how HTTP messages are encoded (and in special the enco=
> ding of the IRI).
> > WHATWG does not specify HTTP, these concerns should be directed to IETF.
> 
> There are various ways to spec lawyer things so you can make this work
> appear to be the responsibility of various folks.  The work needs to
> be done.  I'm inclined to do the work first and worry about what >
organization (if any) has "jurisdiction" later.
Yeah, true. I've been through a repetive "ask the county" "ask school
authorities", "ask the county" when asking my school to implement a
SHOULD from national gov. *shrugs*

But really, you should discuss this with the HTTP WG of IETF by raising
the issue in <http-wg at hplb.hp.com>. I recommend searching the archives,
http://www.ics.uci.edu/pub/ietf/http/hypermail, for counter-arguments
before posting as this issue has probably be raised before. Then
someone should fork RFC 2616 (or the latest working draft, if there's
a current one).

Patching the RFC == doing the work (good lucking getting consensus on
your side if you don't provide rationale, don't defend your decisions
and ignore the IETF though)

From diego.perini at gmail.com  Wed Aug  4 17:34:03 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Thu, 5 Aug 2010 02:34:03 +0200
Subject: [whatwg] HTML resource packages
In-Reply-To: <2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>
References: <AANLkTinOnS+dWztmjYg7AzeQkcq=B8b768Ra8eN=aMdQ@mail.gmail.com>
	<40F83A3B-F20D-4C59-A350-46B968C8CCF8@crissov.de>
	<AANLkTikp+_V5n7VqikSZqo57Guvgz0BKNcHBgAAJG2BY@mail.gmail.com>
	<AANLkTinc=Rcyaa+8=1bw0fNUQfanVsO=C+VLPu+-Mno_@mail.gmail.com>
	<2272B7C5-6BE8-402C-A491-A7A0D23B2934@geekhood.net>
Message-ID: <AANLkTi=7m-G8e-Svn3sjwXDK5feCO+_Kik6Bafo5ODX6@mail.gmail.com>

2010/8/4 Kornel Lesi?ski <kornel at geekhood.net>

> On 4 Aug 2010, at 11:46, Diego Perini wrote:
>
> > > * Argument: What about incremental rendering?
> > > If there are, for instance, lots of (content) images in the resource
> file I will see them all at once as soon as the ZIP has been downloaded
> completely and decompressed, but with single files I would have seen them
> appear one after the other, which might have been enough.
> >
> > ZIP files are progressively renderable, dependant on file order.
> >
> > In my experience "gzip" compression is blocking browser rendering until
> the compressed file has been received completely.
> >
> > I believe this is the reason we should not compress the HTML source, just
> its external binary components.
> >
> > I don't think the browser can separately decompress each block of a
> chunked transfer as it arrives, am I wrong ?
>
> You are wrong. gzip compression is streamable and browsers can uncompress
> parts of gzipped file as it is downloaded. gzip only needs to buffer some
> data before returning uncompressed chunk, but it's only few KB. Chunks of
> gzipped data don't have to align with chunked HTTP encoding (those are
> independent layers).
>
>
Tank you for the informations and correcting my statements. I just tried and
definitely "chunked" and "gzip" compression can happen at the same time.

The problem is I have a strange effect on my pages if I enable Apache
"SetOutputFilter DEFLATE", the pages progress and rendering are different.

It works well with "zlib.output_compression", more or less with no visible
changes from non compressed. I will have to dig what makes this difference.

Diego Perini



> --
> regards, Kornel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100805/894ea201/attachment-0001.htm>

From nzakas at yahoo-inc.com  Wed Aug  4 17:55:14 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Wed, 4 Aug 2010 17:55:14 -0700
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <AANLkTinvjs2Ft06_Z2rwh2gPDFNPi5FF09dXQWmbETCo@mail.gmail.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com>
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com>
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com>
	<B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com>
	<AANLkTim0CAQvhTzCMG-VGmFQoDR6HYFq5VyURQQa=BWw@mail.gmail.com>
	<AANLkTinvjs2Ft06_Z2rwh2gPDFNPi5FF09dXQWmbETCo@mail.gmail.com>
Message-ID: <B66541E954ECF146AD8CA69D34A283FF12CD835A9C@SP2-EX07VS02.ds.corp.yahoo.com>

So given no strenuous objections, can we make expiration for Web Storage real? :)

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: Jonas Sicking [mailto:jonas at sicking.cc] 
Sent: Wednesday, August 04, 2010 10:26 AM
To: Jeremy Orlow
Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
>> wrote:
>> > Yes, for IndexDB I think having a per-storage area expiration date
>> > completely makes sense. Do you expect that IndexedDB will become a successor
>> > to sessionStorage/localStorage?
>
> No. ?I think LocalStorage will stick around since it's just so simple to use
> and a lot of people just need to store a tiny bit of data here or
> there--much like cookies. ?IndexedDB will be used for structured data, so I
> don't see many people using it for things they one used (abused) cookies
> for.
>
>>
>> My belief is that the simple key-value store paradigm would still end up
>> being the default client-side data storage utility, and would therefore
>> benefit from having a per-key expiration time to mimic cookie usage.
>>
>> I suspect it will be much easier to add to IndexedDB than to
>> localStorage/sessionStorage. I don't expect the latter to go away,
>> though generally it seems like people are disliking localStorage
>> enough that it's hard to get any changes made to it.
>
> Jonas, are you against the expiration feature proposal for LocalStorage?
> ?Because no one else has voiced the typical "we should just leave
> LocalStorage alone" concerns. ?So if you're not, I think we can assume that
> such types (me included) aren't going to raise such a concern.
> I'm actually much less enthusiastic about expiration for IndexedDB as I
> don't see very compelling use cases.

I'm definitely for expiration of localStorage values. Though I think
it also makes sense to do for IndexedDB. Especially if it can be done
on a per-objectStore basis as that makes it very low overhead.

/ Jonas

From dhtmlkitchen at gmail.com  Wed Aug  4 18:26:56 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 4 Aug 2010 18:26:56 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <D7F43572-46DE-4374-B100-6C6976012416@apple.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com>
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr>
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
	<AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>
	<AANLkTimrrvhHj0dy8wZhO761BpXuh5831wTVX2fN6m-+@mail.gmail.com>
	<D7F43572-46DE-4374-B100-6C6976012416@apple.com>
Message-ID: <AANLkTi=GrTYVeu2L0NMzKSypWGyLw8LV-zjHNp=KvhgM@mail.gmail.com>

On 8/4/10, Oliver Hunt <oliver at apple.com> wrote:
>
> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:
>
>> On 8/4/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>
>> [...]
>>>  "submitButton" in form.elements
>>>
>>> Existing implementations vary on when they use catchalls. I'd like to
>>> see standardization for this behavior and codification so that
>>> implementations behave similarly -- either use a catchall for a
>>> particular type of collection or use a native object. If a catchall is
>>
>> Native object either way, but either with a new ES catchall behavior
>> or with a native ES object, as specified today.
>>
>> Garrett
> As a question, if the node lists were implemented as catchalls, how would
> the behaviour differ from current NodeLists?

The externally observable behavior wouldn't have to change.

[[HasProperty]] checks (using `in`) with catchalls have sometimes
unexpected results, so I wouldn't want to see that kind of change.

Try some of the tests here:
<http://jibbering.com/faq/names/extra_props.html>

The article needs a little updating but the examples I'm referring to
demonstrate disparity with `in` operator:
FF3.6
  'test' in this.form true
  'test' in this.form.elements false

A catchall should possible for a result of `null` for indexed access.
This probably isn't adding any value over returning `undefined`
because many implementations will result `undefined` for property
access and most programs won't care one way or the other (and if they
do, they're not interoperable with existing browsers).

I want the specs to codify behavior of existing various collections
and to do that, I want to figure out where and why catchall is used.

I can't answer as to why Gecko uses a catchall; perhaps some of the
Mozilla devs on this list can give further info. Perhaps there is
behavior for "past names map" that requires catchall (I don't think
anybody is a big fan of past names map).

The only change I can see
> would be the loss of the host object exceptions in the ES spec, but that
> just puts you in the position of having semantics that match the current
> host object behavior in those implementations that already allow array
> functions to operate on host objects.
>

The semantics for native object are defined by ECMA-262.

If collection is required to be implemented as a native ECMAScript
object, then it would still be considered a host as a native object,
would be indistinguishable from other native objects, both internally
and externally, and so would not be subject to ES "whether or not the
xxx method may be applied to a host object" loopholes. Thus,

  [].slice.call( ho )

could be expected work. It would have to work because
Array.prototype.slice would have no way of determining that `ho` is a
host object; it would simply see that it is passed in a native object.
It would not be able to differentiate or discriminate between that and
a user-defined object.

All that would be necessary to make that happen would be to state that
the collection -- NodeList, for example -- is implemented as a native
ECMAScript object. That alone would be enough to guarantee that any
native operation would have results that could be expected.

Again, from ES point of view, there are two types of host objects:
1) host object implemented as a native object
2) host object implemented with other semantics

Garrett

From tkent at chromium.org  Wed Aug  4 19:13:31 2010
From: tkent at chromium.org (TAMURA, Kent)
Date: Thu, 5 Aug 2010 11:13:31 +0900
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <Pine.LNX.4.64.1008042111080.7470@ps20323.dreamhostps.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com> 
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com> 
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com> 
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
	<Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com> 
	<DD63BEE9-CEF1-43F8-AF3A-EA76402027A7@apple.com>
	<AANLkTimvghWo1OWZ6aFaK_HraRirZXUMqQDMblZIbCnW@mail.gmail.com> 
	<Pine.LNX.4.64.1008042111080.7470@ps20323.dreamhostps.com>
Message-ID: <AANLkTikiRzpbLnP4ni4+mKs+0m=Vxp2GCNDpWz=iKSo-@mail.gmail.com>

>> The Chrome bug report is here:
>> http://code.google.com/p/chromium/issues/detail?id=45640

> The bug there is that Chrome is filling in a control that isn't visible,
> and, even worse, that it is filling it with a value that the user couldn't
> himself enter manually. That's a bug (two bugs in fact), but it has
> nothing to do with reporting validation errors -- the error should not be
> able to occur.

Please look at the original report and Comment #4.  It is not an auto-fill
issue.
Comment #2 is an auto-fill bug and it was moved to another bug entry.

Regardless of the auto-fill bug, we still have compatibility issues and we
can't force authors to update their web pages.  I'm wondering UA should
show a dialog with "The web page has invisible invalid form fields.  Do you
want to submit the form? [Yes] [No]".


-- 
TAMURA Kent
Software Engineer, Google

From svartman95 at gmail.com  Wed Aug  4 19:25:53 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 05 Aug 2010 02:25:53 +0000
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <Pine.LNX.4.64.1008032356060.7470@ps20323.dreamhostps.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>
	<AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com>
	<4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
	<AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com>
	<4bf304a4.513dd80a.189a.1578@mx.google.com>
	<AANLkTimYMfwCc-FZqLSpIv2rqVD1Vvljazsh6Btobvzr@mail.gmail.com>
	<AANLkTim1o2OgWVyrIjQXcFpWSNe_2Rujf8SXSSq31H8S@mail.gmail.com>
	<4bf3ec37.e198d80a.29a8.380e@mx.google.com>
	<Pine.LNX.4.64.1008032356060.7470@ps20323.dreamhostps.com>
Message-ID: <4c5a2147.d908e30a.2998.6700@mx.google.com>

> On Tue, 18 May 2010, bjartur wrote:
> >
> > First of all I think we should use <a rel="embed" href="uri-ref">
> > instead of <source>.
> 
> What problem would this solve?
> 
It would tell UAs that don't implement HTML 5 that the value of @href is
an URI. Then it can provide means for the user to retrieve the identified
resource (and do something useful with it).

For authors it would unnecessiate constructs such as (excerpt from spec):
<video controls src="http://video.example.com/vids/315981">
   <a href="http://video.example.com/vids/315981">View video</a>.
</video>

In fact, having the ability to follow this link is useful even though
my browser supports <video>. But that's an UI issue.

> On Wed, 19 May 2010, Bjartur Thorlacius wrote:
> >
> > 	Is the existing syntax backwards compatible? When using <A>, you
> > get a nice link as fallback content automagically, not requiring any
> > special workarounds by the content author. AFAICT you don't even get
> > that when using a browser that doesn't support <audio> and <video>.
> 
> Indeed, with those you have to provide the fallback content (which could
> e.g. be flash) as a descendant of the <audio>/<video> element.
> 
As a user of a browser that doesn't fully support <video> I'd prefer
getting a hyperlink to the resource to a Flash program. Just sayin'.

> > 	What I'm trying to write is that not all browsers support
> > JavaScript, not all pages must be able to control playback more than
> > play, pause, seek etc and that a mechanism for linking to files and
> > alternative encodings thereof semantically. Currently, that seems to be
> > only possible with video and audio. But if you create a media element
> > that adds no extra interface, you get this for all other types as well
> > (albeit with a lesser scripting interface). Although the <include>
> > element won't be as good integration point between one media and
> > scripts, it will have a standard interface somewhat applicable to many
> > medias/mediums and at least provide something to all medias, versus
> > (close to) nothing.
> 
> I'm not sure I follow. If you're saying that we should also support other
> timed-based formats in the future even if they are not video, e.g. if you
> are saying we should support formats like SMIL, then there's no reason you
> can't do that with <video> itself. <video> really is just an API to
> time-based visual data, it doesn't have to be a sequence of bitmaps.
> 
Oh, the following quote confused me.
> The video element is a media element whose media data is ostensibly
> video data

I'm not just talking about SMIL. I'm talking about using a secondary
feature of media elements (the ability to link to multiple alternative
resources) even if the main feature (the API) is irrelevant.

<video>
	<source src=f.utf8 charset=utf8>
	<source src=f.latin1 charset=latin1>
</video>
<video>
	<source src=img.png type="image/png">
	<source src=img.svg type="image/svg+xml">
</video>

I don't need to know the duration of an unanimated PNG.

> On Wed, 19 May 2010, bjartur wrote:
> >
> > Yeah, maybe my crazy idealism and tendency to reuse existing things
> > don't mix up in this case. The main purpose of <video> and <audio> is to
> > create a scripting interface to online video. But they also add new
> > linking capabilities which should be available to any content
> > whatsoever.
> 
> I don't really see how. In what sense do they add new linking
> capabilities?
> 
In the sense of multiple alternative (media) resources.

This could possibly be done with <object> but its fallback mechanism
seems inferior.

From jorlow at chromium.org  Thu Aug  5 02:11:15 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Thu, 5 Aug 2010 10:11:15 +0100
Subject: [whatwg] Proposal for Web Storage expiration
In-Reply-To: <B66541E954ECF146AD8CA69D34A283FF12CD835A9C@SP2-EX07VS02.ds.corp.yahoo.com>
References: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikom7_xL4Urru9kQ01YdOT_c-3jam3kcXcTmyA4@mail.gmail.com> 
	<AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com> 
	<53561CCC-F492-4BE8-8478-2747F3F7B5CE@4d.com>
	<AANLkTiktReM7nGrXm+W2SPM6o3rmatrfVwZiqnv92f=+@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD835393@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTiniabyMSxTY8QKJDz1syRLmqYb_xqgah8erypBf@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8355DA@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTimUmn5+8UYuoX-QMGQt=Vmfppt0ZVR-ireebp9x@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
	<AANLkTikX+XouMNmQNP=N=HO=u1p4VO8Kn=7Yo5+dggZs@mail.gmail.com> 
	<AANLkTim0CAQvhTzCMG-VGmFQoDR6HYFq5VyURQQa=BWw@mail.gmail.com> 
	<AANLkTinvjs2Ft06_Z2rwh2gPDFNPi5FF09dXQWmbETCo@mail.gmail.com> 
	<B66541E954ECF146AD8CA69D34A283FF12CD835A9C@SP2-EX07VS02.ds.corp.yahoo.com>
Message-ID: <AANLkTi=MFiXUKqmqGPGWNt=W-HtumPrHWr2ONXmTeaMY@mail.gmail.com>

As far as I can see, the next steps are (roughly in order):
1) Figure out whether it should be an origin wide setting or not.  In order
to prove that it needs to be a per LocalStorage bucket setting, its on you
to come up with use cases where an origin wide setting is not enough.  By
use cases, we mean specific examples of stuff that clearly happens in
reality today or would happen in reality if this was added.
2) Come up with a concrete proposal for what be added to the spec.
3) Find a UA willing to prototype such a new feature.

At any point, it's possible Ian may be interested in adding it to the
WebStorage spec and/or others could follow your lead.  But if I were you,
I'd start down the road I just described.

J

On Thu, Aug 5, 2010 at 1:55 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:

> So given no strenuous objections, can we make expiration for Web Storage
> real? :)
>
> -Nicholas
>
> ______________________________________________
> Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
> Morpheus: "My beliefs do not require them to."
>
> -----Original Message-----
> From: Jonas Sicking [mailto:jonas at sicking.cc]
> Sent: Wednesday, August 04, 2010 10:26 AM
> To: Jeremy Orlow
> Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal for Web Storage expiration
>
> On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> > On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
> >> wrote:
> >> > Yes, for IndexDB I think having a per-storage area expiration date
> >> > completely makes sense. Do you expect that IndexedDB will become a
> successor
> >> > to sessionStorage/localStorage?
> >
> > No.  I think LocalStorage will stick around since it's just so simple to
> use
> > and a lot of people just need to store a tiny bit of data here or
> > there--much like cookies.  IndexedDB will be used for structured data, so
> I
> > don't see many people using it for things they one used (abused) cookies
> > for.
> >
> >>
> >> My belief is that the simple key-value store paradigm would still end up
> >> being the default client-side data storage utility, and would therefore
> >> benefit from having a per-key expiration time to mimic cookie usage.
> >>
> >> I suspect it will be much easier to add to IndexedDB than to
> >> localStorage/sessionStorage. I don't expect the latter to go away,
> >> though generally it seems like people are disliking localStorage
> >> enough that it's hard to get any changes made to it.
> >
> > Jonas, are you against the expiration feature proposal for LocalStorage?
> >  Because no one else has voiced the typical "we should just leave
> > LocalStorage alone" concerns.  So if you're not, I think we can assume
> that
> > such types (me included) aren't going to raise such a concern.
> > I'm actually much less enthusiastic about expiration for IndexedDB as I
> > don't see very compelling use cases.
>
> I'm definitely for expiration of localStorage values. Though I think
> it also makes sense to do for IndexedDB. Especially if it can be done
> on a per-objectStore basis as that makes it very low overhead.
>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100805/e1a13c5a/attachment-0001.htm>

From philipj at opera.com  Thu Aug  5 02:14:31 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Thu, 05 Aug 2010 11:14:31 +0200
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C59A127.1020705@mit.edu>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C57495A.9020800@pearce.org.nz>
	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>
	<4C583871.4020004@mit.edu> <op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>
	<4C5933C3.20404@mit.edu> <op.vgwt0gcisr6mfa@philip-pc.gothenburg.osa>
	<4C59A127.1020705@mit.edu>
Message-ID: <op.vgyjyhrasr6mfa@philip-pc.gothenburg.osa>

On Wed, 04 Aug 2010 19:19:35 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/4/10 6:56 AM, Philip J?genstedt wrote:
>> On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky <bzbarsky at mit.edu>  
>> wrote:
>>
>>> On 8/4/10 4:29 AM, Philip J?genstedt wrote:
>>>> That could be, but is this behavior actually useful for anything? It's
>>>> certainly simpler to implement and more predictable for authors to
>>>> always wait until the current script has finished executing.
>>>
>>> 1) That requires defining "current script".
>>
>> OK, but that's just a spec problem. It's trivial in implementation
>> because when the resource selection algorithm was is triggered by a
>> script, you can just pass along a reference to that very script.
>
> It's not, in fact, trivial in implementation.  You're making assumptions  
> about how implementations work that don't seem warranted (e.g. the  
> concept of "reference to that very script" is not well-defined in some  
> implementations).  In particular, what you're proposing is not at all  
> trivial in Gecko.

 From <https://bugzilla.mozilla.org/show_bug.cgi?id=485288#c7> it sounds  
like Gecko actually has pretty much the same tools to work with as Opera:  
a nsIThreadObserver that allows you to wait until you've "finished the  
task in which some JS called load()". This is exactly what Opera does.

(It's difficult for Opera to rely on the message loop to resume the  
synchronous section, because our script engine can suspend and continue  
executing on a later message. Therefore, waiting for a script to finish  
executing is the best solution.)

>>> 2) Who said it will ever finish executing?
>>
>> If it doesn't, just don't ever continue with the synchronous section.
>
> I don't think that's reasonable.

A script that's stuck in an infinite loop is broken and video then not  
working would be fine as long as all browsers break in the same way. If a  
script is showing a modal dialog, not loading a video in the background  
seems fine. Other than possible implementation difficulties, why would it  
matter?

>> Is there any valid case for a script never finishing?
>
> Yes, it could showModalDialog and the user could spend several hours  
> interacting with it.
>
>> It would block all event handlers from running too
>
> I believe this is false in the case of showModalDialog.

It sounds like we're going to end up with slightly incompatible  
implementations. Is there anything that sites actually use that could make  
the difference in implementation visible? I truly doubt we'll see any  
serious compat issues because of showModalDialog...

A far more important issue is still what to do while the parser is running  
and we should "await a stable state". It can't possibly mean waiting until  
the parser has completely finished running, because that would slow down  
the time to load <video> considerably. If it just means letting the parser  
finish its current batch of input, I can't see how black-box testing could  
tell the difference between this and always ignoring the "await a stable  
state" step, as the parser could just happen to run for exactly that long.  
Always triggering the steps of the resource selection algorithm  
immediately is certainly more predictable, and the spec as written works  
well when doing so.

-- 
Philip J?genstedt
Core Developer
Opera Software

From thomas.koetter at id-script.de  Thu Aug  5 02:24:42 2010
From: thomas.koetter at id-script.de (Thomas Koetter)
Date: Thu, 5 Aug 2010 11:24:42 +0200
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com>
Message-ID: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30FE4@ECCR02PUBLIC.exchange.local>

I wrote:
>> Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks.

Aryeh wrote;
>That would either be incorrect use of <dl>, or would not display as
>desired, or would require hiding some elements arbitrarily.

That's not correct. Actually, I shouldn't have used the term "definition list" as such a list type does not exist in HTML5. The meaning of the dl element has been changed to that of an association list (name/value pairs). So, it can and should be used for addresses. I maintain that it is the most semantically rich HTML5 element for addresses.

If you take a look at most forms where you enter an address, you'll see that there's an association between a label and an input field for the different parts of the address. It's rare that you have just a textarea to enter the entire address (which would be the equivalent of the <p>Name<br>Street<br>City</p> example). So why should the semantics change from input to output?

>> <address>
>>        <dl>
>>                <dt>Name</dt><dd>P. Sherman</dd>
>>                <dt>Street</dt><dd>42 Wallaby Way</dd>
>>                <dt>City</dt><dd>Sydney</dd>
>>        </dl>
>> </address>

Aryeh wrote:
> That requires hiding all the <dt> elements to achieve the same
> display, which is kind of ridiculous.

The first example was meant to underline the association. You're right that it would be ridiculous to insert the dt elements only to hide them (unless there was some accessibility advantage). And as Adam pointed out, following the spec the address element would not be appropriate in many cases.

>> <address>
>> ? ? ? ?<dl>
>> ? ? ? ? ? ? ? ?<dd>P. Sherman</dd>
>> ? ? ? ? ? ? ? ?<dd>42 Wallaby Way</dd>
>> ? ? ? ? ? ? ? ?<dd>Sydney</dd>
>> ? ? ? ?</dl>
>> </address>

Aryeh wrote:
>That's invalid markup.  The first child of a <dl> (if any) must be a
><dt>.  I don't know what the semantics of <dl> are supposed to be with
>no <dt>.

According to the spec it is perfectly acceptable to leave out all dt elements:
"If a dl element contains only dd elements, then it consists of one group with values but no names."

Aryeh wrote:
>It should already be adjustable using existing style properties, so no
>change is needed except possibly saying it represents a logical break
>instead of a line break.

That's all I'm suggesting. Make it a logical/thematic not a presentational break in the spec. The default rendering should still be a line break to support existing content.

Aryeh wrote:
>This is basically wrong, though, since there
>are lots of ways to mark up minor logical breaks, and <br> refers to
>one particular way, no other.

Which elements currently let me logically break up a paragraph? I can't think of any. There are only a handful of empty elements (like br, wbr, hr, img, input, param, embed). Except br none of them would be appropriate in such a case.

Aryeh wrote:
>Look at it this way: <br> is just a workaround for the fact that HTML
>ignores newlines in markup.  It could have just been &#10; in an
>alternate history.  It's presentational, yes, but so are periods and
>commas.

I would disagree here because I don't consider punctuation to be presentational. I'd say it's content because leaving punctuation out can change the meaning.



From thomas.koetter at id-script.de  Thu Aug  5 04:56:07 2010
From: thomas.koetter at id-script.de (Thomas Koetter)
Date: Thu, 5 Aug 2010 13:56:07 +0200
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <bb28acfed70555d6d808088c23463d30.squirrel@webmail.gradwell.com>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com>
	<3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30FE4@ECCR02PUBLIC.exchange.local>
	<bb28acfed70555d6d808088c23463d30.squirrel@webmail.gradwell.com>
Message-ID: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D3105E@ECCR02PUBLIC.exchange.local>

Andy wrote:
>Far greater semantic richness is obtained by using the ADR microformat

Absolutely! Good point.
As I was talking about HTML5 elements, I didn't take that into consideration.

But then I suggest a combination of the two is even better.

<address class="vcard">
	<dl class="adr">
		<dd class="fn">P. Sherman</dd>
		<dd class="street-address">42 Wallaby Way</dd>
		<dd class="locality">Sydney</dd>
	</dl>
</address>

This way there are some semantics even if the user agent doesn't support microformats.

But this seems to be a separate discussion from the br element.


From olak at opera.com  Thu Aug  5 05:20:53 2010
From: olak at opera.com (Ola P. Kleiven)
Date: Thu, 05 Aug 2010 14:20:53 +0200
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <Pine.LNX.4.64.1008042111080.7470@ps20323.dreamhostps.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
	<Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>
	<DD63BEE9-CEF1-43F8-AF3A-EA76402027A7@apple.com>
	<AANLkTimvghWo1OWZ6aFaK_HraRirZXUMqQDMblZIbCnW@mail.gmail.com>
	<Pine.LNX.4.64.1008042111080.7470@ps20323.dreamhostps.com>
Message-ID: <op.vgysk3cgnw228i@id-c0814.oslo.osa>

On Wed, 04 Aug 2010 23:32:46 +0200, Ian Hickson <ian at hixie.ch> wrote:

>
> On Fri, 4 Jun 2010, TAMURA, Kent wrote:
>> > >
>> > > An element is a "candidate for constraint validation" if
>> > > 1. it is a validatable type,
>> > >    e.g. true if <input type=number>, false if <input type=reset>
>> > > 2. has no "disabled" attribute,
>> > > 3. has no "readonly" attribute,
>> > > 4. inside of a <form> element,
>> > > 5. has non-empty "name" attribute, and
>> > > 6. not inside of a <datalist> element.
>> > >
>> > > I hope ValidityState and the pseudo classes ignores 2-6.
>> >
>> > The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now  
>> removed.)
>>
>> I'd like to propose to add another condition:
>> 7. it is visible (computed 'display' property of CSS isn't 'none' and no
>> 'hidden' content attribute)
>
> The problem with that is that they still get submitted, so it seems weird
> to not validate them. It seems authors should be careful not to make the
> hidden controls be invalid.
>
>
> On Thu, 3 Jun 2010, Tab Atkins Jr. wrote:
>>
>> Adding @hidden to the list of things that skip validation is good.
>
> I considered it, but really we should also also stop submission in that
> case, and that seems like it's starting to make things a little less
> intuitive than I'd like. It's really up to the author to make sure that
> something that's irrelevant (hidden="") is not part of a form that is
> user-submittable.
>
>
>> Adding display:none is not.  That's a big layering violation that we
>> authors have to suffer through with screen readers already.  I'd greatly
>> prefer not muddying the waters there.
>
> Indeed.
>
>
> On Fri, 4 Jun 2010, TAMURA, Kent wrote:
>>
>> Oh, I'm sorry.  I have found a sentence about visibility in the draft.
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
>> >
>> > If one of the controls is not being rendered (e.g. it has the hidden
>> > attribute set) then user agents may report a script error.
>>
>> This sentence is about process against controls of which validation
>> result is invalid.
>>
>> I think UA doesn't need to validate such controls.
>
> I think, as the sentence above suggests, it's better to report this as a
> page error than to not validate the control. Chrome already reports this
> problem in the console.
>
>
>> The Chrome bug report is here:
>> http://code.google.com/p/chromium/issues/detail?id=45640
>
> The bug there is that Chrome is filling in a control that isn't visible,
> and, even worse, that it is filling it with a value that the user  
> couldn't
> himself enter manually. That's a bug (two bugs in fact), but it has
> nothing to do with reporting validation errors -- the error should not be
> able to occur.
>
>
> On Thu, 3 Jun 2010, Peter Kasting wrote:
>>
>> I posted this on the Chromium bug, but I take the sentence Kent quotes
>> to affect only the UI shown on a validation failure, not the actual
>> results of validation.  That is, if a control fails validation and has
>> the "hidden" attribute, validation still fails, but the UA may display a
>> message indicating the page has an error in addition to/instead of the
>> normal validation failure message.
>
> Indeed.
>
>
> On Mon, 14 Jun 2010, TAMURA, Kent wrote:
>>
>> There are some objections against omitting invisible controls from form
>> validation. However, it is a real issue with existing sites and users
>> can't submit such forms at all though they can submit it with non-HTML5
>> browsers.
>>
>> My conclusion is it's better to disable interactive form validation for
>> existing sites as possible. e.g. disabling interactive form validation
>> for documents without "<!DOCTYPE html>".
>
> Just don't autofill controls with invalid values, and don't autofill
> hidden controls. :-)
>
>
> On Mon, 14 Jun 2010, Ola P. Kleiven wrote:
>>
>> The following sites have workarounds in Opera's browser.js to allow form
>> submit:
>>
>> airgreenland.com (using required on hidden elements)

site has now changed.

>> barnesandnoble.com (using required on visible elements that are  
>> supposed to be
>> empty on submit...)

https://cart4.barnesandnoble.com/account/request.aspx?stage=mainStage -  
click "Create an Account". Will fail unless you fill in the fields in the  
form to the left (which is really unrelated)

>> bookryanair.com (using required=false - this usage has also been found  
>> in JS
>> libraries)

site changed

>> ingdirect.com.au (using required on a visible field, but then emptying  
>> the
>> field with JS before submit)

https://www.ingdirect.com.au/client/index.aspx - type any "client number"  
and a 4 digit access code. Click log in. The client number field is then  
emptied by js before submitting but has required=true, causing error

>> usairways.com (using required on hidden elements)

The original issue seems to be gone (unable to search for flights from  
front page), but there is another one also related to WF2. Enter jfk in  
 from or to fields, wait for the autocompletion and select "New York, NY  
(JFK) (John F. Kennedy International Airport)" by hitting enter. Then you  
will get a maxlength error.

>> Most of these have been using it for several years and have not
>> responded to change requests from our side.
>
> Do you have more specific URLs I could look at for these?

See above. If testing in Opera, set  
opera:config#UserPrefs|BrowserJavaScript to 0.

-- 
Ola P. Kleiven, Core Compatibility, Opera Software

From silviapfeiffer1 at gmail.com  Thu Aug  5 08:01:47 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 6 Aug 2010 01:01:47 +1000
Subject: [whatwg] Discussing WebSRT and alternatives/improvements
Message-ID: <AANLkTinZERZa_aT_kkFqBFP1xRN7YUnwLZjKdeExRM9g@mail.gmail.com>

Hi Ian, all,

I'd like to pick up again on the discussion about what file format should be
supported as baseline in HTML5 for providing time-synchronized text for
media resources. This is particularly important now that we have the WebSRT
proposal http://www.whatwg.org/specs/web-apps/current-work/websrt.html and
decisions need to be made about implementations.

My intention with this discussion is to clearly understand our reasons for
going with the specifications that we will implement. I'd rather have the
discussions now than later when implementations exist and changes are
difficult.

So, I want to make sure we have good reasons not to go with an alternative
existing format.
And I want to make sure we also have good reasons for the decision not to go
with an xml-based format, in particular given that so much of HTML could be
reused if we went with a markup language.
Finally, I want to point out some limitations of WebSRT that I've come
across and that we can improve, should we really decide to stick with
WebSRT.


CONSIDERING EXISTING FORMATS

The question about re-using existing formats has thus far led us to the
following conclusions:
* SRT is nice and simple, but insufficient for most advanced use cases,
including captions and subtitles
* DFXP/TTML is problematic since it uses XML namespaces, XSL-FO for styling
(which conflicts with CSS), and doesn't support <ruby> and several other
expressed needs.

There are many other formats, that have been considered (see
http://wiki.whatwg.org/wiki/Timed_track_formats) and dismissed for one
reason or another.

The formats that have been (and others that could still be) inspected
broadly fall into the following classes:
* non-xml text formats developed by applications to store subtitles (or
captions), e.g. SRT, MicroDVD, DVD Studio Pro, SSA/ASS, Subsonic, Subviewer
* xml-based text formats developed by applications to store subtitles or
captions, e.g. RealText, SAMI, USF, Structured Subtitle Format
* binary formats that encode text to go into media files, e.g. 3GPP in MPEG,
QTText in Quicktime, Kate in Ogg
* legacy binary formats that were used to exchange subtitles and teletext
between software/hardware in the pre-digital age, e.g. EBU-STL, PAC

The problem with looking at these existing formats is that they are all
built for a particular purpose that almost exclusively does not apply to our
problem at hand. Also, if we look at their capabilities, we find that the
overlapping functionality that all share is captured in simple SRT, while
the combined functionality of them all is so encompassing that not even TTML
- which has been developed as an exchange format for such files formats -
provides for them all.

Note that the subtitling community has traditionally been using the Subrip
(srt) or SubViewer (sub) formats as a simple format and SubStation alpha
(ssa/ass) as the comprehensive format. Aegisub, the successor of SubStation
Alpha, is still the most popular subtitling software and ASS is the
currently dominant format. However, even this community is right now
developing a new format called AS6. This shows that the subtitling community
also hasn't really converged on a "best" format yet.

So, given this background and the particular needs that we have with
implementing support for a time-synchronized text format in the Web context,
it would probably be best to start a new format from a clean slate rather
than building it on an existing format. Learn from what exists, but make
something completely new that works best for the Web environment. If others
pick it up - good - but it's not a requirement.


A BRIEF OVERVIEW OF WMML

Given that WebSRT is basically an effort at creating a new format that is
not using markup (or at least: not much), I took the step to experiment with
a new markup-based format which I call WMML (Web Media Markup Language) to
be able to refer to it. It is specified at
https://wiki.mozilla.org/Accessibility/Video_Text_Format .

XML-based formats for subtitles have been successful in the past, e.g. SAMI,
RealText, 3GPP. Also, many other successful formats on the Web are
XML-based, e.g. RSS, XSPF and there are plenty of parsers around to tokenize
such formats. Also, authors already know how to write HTML, so if our
time-synchronized text format does not require a steep learning curve, we
will end up with more captions and subtitles faster, both hand-made and from
authoring applications. So, even though such a format will be more verbose
than a plain text format, there are a lot of good reasons to build a new
format with markup rather than without.

I developed WMML as a xml-based caption format that will not have the
problems that have been pointed out for DFXP/TTML, namely: there are no
namespaces, it doesn't use XSL-FO but instead fully reuses CSS, and it
supports innerHTML markup in the cues instead of inventing its own markup.
Check out the examples at
https://wiki.mozilla.org/Accessibility/Video_Text_Format .

WMML's root element contains some attributes that are important for
specifying how to use the resource:
* a @lang attribute which specifies what language the resource is written
for
* a @kind attribute which specifies the intended use of the resource, e.g.
caption, subtitle, chapter, description
* a @profile attribute which specifies the format used in the cues and thus
the parser that should be chosen, including "plainText", "minimalMarkup",
"innerHTML", "JSON", "any" (other formats can be developed)

WMML completely reuses the HTML <head> element. This has the following
advantages:
* there is a means to associate metadata in the form of name-value pairs
with the time-synchronized text resource. There is a particular need to be
able to manage at least the following metadata for time-synchronized text
resources:
  ** the association with the media resource and its metadata, such as
title, actors, url, duration
  ** the author, authoring date, copyright, ownership, license and usage
rights for the time-synchronized text resource
* there is a means to include in-line styles and a means to include a link
to an external style sheet
* there is a possibility to provide script that just affects the
time-synchronized text resource

WMML doesn't have a <body> element, but instead has a <cuelist> element. It
was important not to reuse <body> in order to allow only <cue> elements
inside the main part of the WMML resource. This makes it a document that can
also easily be encapsulated in binary media resources such as WebM, Ogg or
MPEG-4 because each cue is essentially a "codec data page" associated with a
given timeline, while anything in the root and head element are "codec
headers". In this way, the hierarchical document structure is easily
flattened.

The <cue> elements have a start and end time attribute and contain
innerHTML, thus there is already parsing code available in Web browsers to
deal with this content. Any Web content can be introduced into a <cue> and
the Web browsers will already be able to render it.

A single addition has been made to WMML cue elements in the form of a <t>
element, which enables Karaoke, but this is not strictly necessary since we
already have the CSS3 transition-delay property which can provide for this
need.



COMPARING WebSRT and WMML

Examples that I experimented with are at
https://wiki.mozilla.org/Accessibility/Video_Text_Format_Comparison .

There are a few things I like about WebSRT.

1. First and foremost I believe that the ability to put different types of
content into a cue is really powerful.
It turns WebSRT into a platform for delivering time-synchronized text rather
than just markup for a particular application of time-synchronized text. It
makes it future-proof to allow absolutely anything in cues.

2. There is a natural mapping of WebSRT into in-band text tracks.
Each cue naturally maps into a encoding page (just like a WMML cue does,
too). But in WebSRT, because the setup information is not brought in a
hierarchical element surrounding all cues, it is easier to just chuck
anything that comes before the first cue into an encoding header page. For
WMML, this problem can be solved, but it is less natural.

3. I am not too sure, but the "voice" markup may be useful.
At this point I do wonder whether it has any further use than a @class
attribute has in normal markup, but the idea of providing some semantic
information about the content in cues is interesting. Right now it's only
used to influence styling but it could have a semantic use, too - uses that
microformats or RDFa are also targeting.

4. It's a light-weight format in that it is not very verbose.
It is nice for hand-authoring if you don't have to write so much. This is
particularly true for the simple case. E.g. if new-lines that you author are
automatically kept as newlines when interpreted. The drawbacks here are that
as soon as you include more complicated markup into the cues (e.g. HTML
markup or a SVG image), you're not allowed to put empty lines into it
because they have a special meaning. So, while it is true that the number of
characters for WebSRT will always be less than for any markup-based format,
this may be really annoying in any of the cases that need more than plain
text.

Now, I've tried to include point 1 into WMML, but because WMML is xml-based,
the ability to include any kind of markup into cues is not so elegant. It
is, however, controlled by the @profile attribute on the <wmml> element, so
applications should be able to deal with it.

Point 2 is possible in WMML through "encoding" all outer markup in a header
and the cues in the data packets.

Point 3 is also possible in WMML through the use of the @class attribute on
cues.

Point 4 really is something where WMML cannot compete with WebSRT - it will
always be more verbose. However, authors are able to author nicely formatted
WMML files that contain innerHTML in cues without having to worry about the
newlines that they use, so this is a double-edged sword.


Now to the things that WMML provides where WebSRT needs to improve.


1. Extensibility with header data.

In contrast to being flexible about what goes into the cues, WebSRT is
completely restrictive and non-extensible in all the content that is outside
the cues. In fact, no content other than comments are allowed outside the
cues. This creates the following problems:

* there is no possibility to add file-wide metadata to WebSRT; things about
authoring and usage rights as well as information about the media resource
that the file relates to should be kept within the file. Almost all subtitle
and caption format have the possibility for such metadata and we know from
image, music and video resources how important it is to have the ability to
keep such metadata inside the resource.

* there is no language specification for a WebSRT resource; while this will
not be a problem when used in conjunction with a <track> element, it still
is a problem when the resource is used just by itself, in particular as a
hint for font selection and speech synthesis.

* there is no style sheet association for a WebSRT resource; this can be
resolved by having the style sheet linked into the Web page where the
resource is used with the video, but that's not possible when the resource
is used by itself. It needs something like a <link> to a CSS resource inside
the WebSRT file.

* there is no magic identifier for a WebSRT resource, i.e. what the <wmml>
element is for WMML. This makes it almost impossible to create a program to
tell what file type this is, in particular since we have made the line
numbers optional. We could use "-->" as an indicator, but it's not a good
signature.

* there is no means to identify which parser is required in the cues (is it
"plain text", "minimal markup", or "anything"?) and therefore it is not
possible for an application to know how it should parse the cues.

* there is no version number on the format, thus it will be difficult to
introduce future changes.

I believe the fundamental issue with the lack of such markup on the
header-level is that we are trying hard to stay backwards compatible with
SRT. If we were to just break away from that, it can give us the opportunity
to create solutions for all these issues. But let me address this issue
properly.


2. Break the SRT link.

I can understand that the definition of WebSRT took inspiration from SRT for
creating a simple format. But realistically most SRT files will not be
conformant WebSRT files because they are not written in UTF-8. Further,
realistically, all WebSRT files that use more than just the plain text
markup are not conformant SRT files. So, let's stop pretending there is
compatibility and just call WebSRT a new format. In fact, the subtitling
community itself has already expressed their objections to building an
extension of SRT, see http://forum.doom9.org/showthread.php?p=1396576 , so
we shouldn't try to enforce something that those for whom it was done don't
want. A clean slate will be better for all.

* the mime type of WebSRT resources should be a different mime type to SRT
files, since they are so fundamentally different; e.g. text/websrt

* the file extension of WebSRT resources should be different from SRT files,
e.g. wsrt


3. Introduce a innerHTML type for cues

Right now, there is "plain text", "minimum markup" and "anything" allowed in
the cues. Seeing as WebSRT is built with the particular purpose of bringing
time-synchronized text for HTML5 media elements, it makes no sense to
exclude all the capabilities of HTML. Also, with all the typical parsers and
renderers available in UAs, support of innerHTML in cues should be simple to
implement. The argument that offline applications don't support it is not
relevant since we have no influence on whether standalone media applications
will actually follow the HTML5 format choice. That WebSRT with "plain text"
and "minimal markup" can be supported easily in standalone media
applications is a positive side effect, but not an aim in itself for HTML5
and it should have no influence on our choices.


4. Make full use of CSS

In the current form, WebSRT only makes limited use of existing CSS. I see
particularly the following limitations:

* no use of the positioning functionality is made and instead a new means of
positioning is introduced; it would be nicer to just have this reuse CSS
functionality. It would also avoid having to repeat the positioning
information on every single cue.
* little use of formatting functionality is made by restricting it to only
use 'color', 'text-shadow', 'text-outline', 'background', 'outline' and
'font'
* cue-related metadata ("voice") could be made more generic; why not reuse
"class"?
* there is no definition of the "canvas" dimensions that the cues are
prepared for (width/height) and expected to work with other than saying it
is the video dimensions - but these can change and the proportions should be
changed with that
* it is not possible to associate CSS styles with segments of text, but only
with a whole cue using ::cue-part; it's thus not possible to just highlight
a single word in a cue
* when HTML markup is used in cues, as the specification stands, that markup
is not parsed and therefore cannot be associated with CSS; again, this can
be fixed by making innerHTML in cues valid


5. Other issues

* I noticed that it is not possible to make a language association with
segments of text and thus it is not possible to have text with mixed
languages.
* Is it possible to reuse the HTML font systems?


IN SUMMARY

Having proposed a xml-based format, it would be good to understand reasons
for why it is not a good idea and why a plain text format that has no
structure other than that provided through newlines and start/end time
should be better and more extensible.

Also, if we really are to go with WebSRT, I am looking for a discussion on
those suggested improvements.


Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100806/54f3db56/attachment-0001.htm>

From bzbarsky at MIT.EDU  Thu Aug  5 08:22:17 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 05 Aug 2010 11:22:17 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <op.vgyjyhrasr6mfa@philip-pc.gothenburg.osa>
References: <4C56245C.3080604@pearce.org.nz>	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>	<4C57495A.9020800@pearce.org.nz>	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>	<4C583871.4020004@mit.edu>
	<op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>	<4C5933C3.20404@mit.edu>
	<op.vgwt0gcisr6mfa@philip-pc.gothenburg.osa>	<4C59A127.1020705@mit.edu>
	<op.vgyjyhrasr6mfa@philip-pc.gothenburg.osa>
Message-ID: <4C5AD729.2050501@mit.edu>

On 8/5/10 5:14 AM, Philip J?genstedt wrote:
>> It's not, in fact, trivial in implementation. You're making
>> assumptions about how implementations work that don't seem warranted
>> (e.g. the concept of "reference to that very script" is not
>> well-defined in some implementations). In particular, what you're
>> proposing is not at all trivial in Gecko.
>
>  From <https://bugzilla.mozilla.org/show_bug.cgi?id=485288#c7> it sounds
> like Gecko actually has pretty much the same tools to work with as
> Opera: a nsIThreadObserver that allows you to wait until you've
> "finished the task in which some JS called load()". This is exactly what
> Opera does.

No, what Gecko has is an nsIThreadObserver which is notified when an 
event is processed.  This as nothing with any particular event 
finishing, and will get called in the "pause" and "spin event loop" 
states that are defined in the spec.  It does not allow you to wait for 
a particular task to finish.

Furthemore, tasks do not map to "scripts" very well, either in Gecko or 
in general.

> (It's difficult for Opera to rely on the message loop to resume the
> synchronous section, because our script engine can suspend and continue
> executing on a later message. Therefore, waiting for a script to finish
> executing is the best solution.)

See, this concept of "a script" is a funny one, given that scripts are 
reentrant, and that multiple different scripts can all be running at the 
same time, possibly with event loops nested in between on the conceptual 
callstack

>>> If it doesn't, just don't ever continue with the synchronous section.
>>
>> I don't think that's reasonable.
>
> A script that's stuck in an infinite loop is broken

Who said anything about infinite loops?

> If a script is showing a modal dialog, not loading a video in the
> background seems fine.

Why?  It doesn't seem fine to me at all.

>>> It would block all event handlers from running too
>>
>> I believe this is false in the case of showModalDialog.
>
> It sounds like we're going to end up with slightly incompatible
> implementations.

Well, neither one of us is implementing what the spec calls for (in 
different ways), so... ;)

> A far more important issue is still what to do while the parser is
> running and we should "await a stable state". It can't possibly mean
> waiting until the parser has completely finished running

Indeed, no.  However I would assume that a "stable state" in that 
situation would, for example, imply that the DOM is in a self-consistent 
state.  So if you start the load algorithm when a <video> is inserted in 
the document, it has to be after the insertion is fully processed or 
some such...

In practice, what Gecko would likely do here is to treat "stable state" 
as "the event loop is spinning", just like we would for the other case. 
  This means that while a modal dialog is up, or a sync XHR is running 
or whatnot is a stable state.

> If it just means
> letting the parser finish its current batch of input

I would assume it does.

> I can't see how
> black-box testing could tell the difference between this and always
> ignoring the "await a stable state" step

It's possible that it can't.  It would depend on the exact steps that 
run in the synchronous section, but since synchronous sections can't 
trigger script it might not be detectable at all.

-Boris

From kit at iqmultimedia.com.au  Thu Aug  5 08:24:54 2010
From: kit at iqmultimedia.com.au (Kit Grose)
Date: Thu, 5 Aug 2010 15:24:54 +0000
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D3105E@ECCR02PUBLIC.exchange.local>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com>
	<3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30FE4@ECCR02PUBLIC.exchange.local>
	<bb28acfed70555d6d808088c23463d30.squirrel@webmail.gradwell.com>
	<3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D3105E@ECCR02PUBLIC.exchange.local>
Message-ID: <4D8F4120-1B6C-44E4-BBD4-125DB75CC773@iqmultimedia.com.au>

I do see an advantage to permitting the arbitrary styling of the BR element.

Often a series of links shown inline are separated by a pipe (|) character. In the past I've produced this effect using border-right and other such malarky on the anchors or inline LIs with the same, but I think semantically the symbol does indeed represent a break between the links and that having the ability to style the break accordingly would be terrific.

?Kit

On 05/08/2010, at 9:56 PM, Thomas Koetter wrote:

> Andy wrote:
>> Far greater semantic richness is obtained by using the ADR microformat
> 
> Absolutely! Good point.
> As I was talking about HTML5 elements, I didn't take that into consideration.
> 
> But then I suggest a combination of the two is even better.
> 
> <address class="vcard">
> 	<dl class="adr">
> 		<dd class="fn">P. Sherman</dd>
> 		<dd class="street-address">42 Wallaby Way</dd>
> 		<dd class="locality">Sydney</dd>
> 	</dl>
> </address>
> 
> This way there are some semantics even if the user agent doesn't support microformats.
> 
> But this seems to be a separate discussion from the br element.
> 


From jackalmage at gmail.com  Thu Aug  5 09:16:46 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 5 Aug 2010 09:16:46 -0700
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <4c5a2147.d908e30a.2998.6700@mx.google.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com> 
	<AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com> 
	<4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
	<AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com> 
	<4bf304a4.513dd80a.189a.1578@mx.google.com>
	<AANLkTimYMfwCc-FZqLSpIv2rqVD1Vvljazsh6Btobvzr@mail.gmail.com> 
	<AANLkTim1o2OgWVyrIjQXcFpWSNe_2Rujf8SXSSq31H8S@mail.gmail.com> 
	<4bf3ec37.e198d80a.29a8.380e@mx.google.com>
	<Pine.LNX.4.64.1008032356060.7470@ps20323.dreamhostps.com> 
	<4c5a2147.d908e30a.2998.6700@mx.google.com>
Message-ID: <AANLkTimcQ4LJRGaQBEmVKoiHQPrHv7AYKbJFi85WYcxr@mail.gmail.com>

On Wed, Aug 4, 2010 at 7:25 PM, Bjartur Thorlacius <svartman95 at gmail.com> wrote:
>> On Tue, 18 May 2010, bjartur wrote:
>> >
>> > First of all I think we should use <a rel="embed" href="uri-ref">
>> > instead of <source>.
>>
>> What problem would this solve?
>>
> It would tell UAs that don't implement HTML 5 that the value of @href is
> an URI. Then it can provide means for the user to retrieve the identified
> resource (and do something useful with it).

If this is useful, browsers can do it today.  @src and @href are
consistent in having their values be urls.


> For authors it would unnecessiate constructs such as (excerpt from spec):
> <video controls src="http://video.example.com/vids/315981">
> ? <a href="http://video.example.com/vids/315981">View video</a>.
> </video>

I'll note, though, that that isn't a very useful pattern for users in
the first place.  Most users won't have any idea what to do with a
video file, especially if it doesn't come with an identifying
extension.


> In fact, having the ability to follow this link is useful even though
> my browser supports <video>. But that's an UI issue.

Does your browser somehow not offer an "Open Video in New Tab" or
similar option in the context menu?


>> On Wed, 19 May 2010, Bjartur Thorlacius wrote:
>> >
>> > ? ? Is the existing syntax backwards compatible? When using <A>, you
>> > get a nice link as fallback content automagically, not requiring any
>> > special workarounds by the content author. AFAICT you don't even get
>> > that when using a browser that doesn't support <audio> and <video>.
>>
>> Indeed, with those you have to provide the fallback content (which could
>> e.g. be flash) as a descendant of the <audio>/<video> element.
>>
> As a user of a browser that doesn't fully support <video> I'd prefer
> getting a hyperlink to the resource to a Flash program. Just sayin'.

I can assure you that you are a tiny, tiny minority.  Almost no one
wants the video resource itself, because almost no one understands
video playback, codecs, etc.  If they're lucky, the format is just
right and they can just doubleclick it to play it in Windows Media
Player.

Doing a Flash or similar fallback that still plays the video is
virtually always the best choice for the user.


>> > ? ? What I'm trying to write is that not all browsers support
>> > JavaScript, not all pages must be able to control playback more than
>> > play, pause, seek etc and that a mechanism for linking to files and
>> > alternative encodings thereof semantically. Currently, that seems to be
>> > only possible with video and audio. But if you create a media element
>> > that adds no extra interface, you get this for all other types as well
>> > (albeit with a lesser scripting interface). Although the <include>
>> > element won't be as good integration point between one media and
>> > scripts, it will have a standard interface somewhat applicable to many
>> > medias/mediums and at least provide something to all medias, versus
>> > (close to) nothing.
>>
>> I'm not sure I follow. If you're saying that we should also support other
>> timed-based formats in the future even if they are not video, e.g. if you
>> are saying we should support formats like SMIL, then there's no reason you
>> can't do that with <video> itself. <video> really is just an API to
>> time-based visual data, it doesn't have to be a sequence of bitmaps.
>>
> Oh, the following quote confused me.
>> The video element is a media element whose media data is ostensibly
>> video data
>
> I'm not just talking about SMIL. I'm talking about using a secondary
> feature of media elements (the ability to link to multiple alternative
> resources) even if the main feature (the API) is irrelevant.
>
> <video>
> ? ? ? ?<source src=f.utf8 charset=utf8>
> ? ? ? ?<source src=f.latin1 charset=latin1>
> </video>
> <video>
> ? ? ? ?<source src=img.png type="image/png">
> ? ? ? ?<source src=img.svg type="image/svg+xml">
> </video>

I don't understand what either of these examples could possibly mean.
What is the charset of a video?  Why are you trying to use <video> to
show an image?


> I don't need to know the duration of an unanimated PNG.

Correct, so why are you using <video>?  If you want image fallback,
agitate for a solution to solve that problem.  Overloading <video>
isn't a good idea.


>> On Wed, 19 May 2010, bjartur wrote:
>> >
>> > Yeah, maybe my crazy idealism and tendency to reuse existing things
>> > don't mix up in this case. The main purpose of <video> and <audio> is to
>> > create a scripting interface to online video. But they also add new
>> > linking capabilities which should be available to any content
>> > whatsoever.
>>
>> I don't really see how. In what sense do they add new linking
>> capabilities?
>>
> In the sense of multiple alternative (media) resources.
>
> This could possibly be done with <object> but its fallback mechanism
> seems inferior.

What media do you want to do fallback on?  audio and video are already
covered.  Images aren't, but I think the image space is pretty stable.
 If we have codec fights in the future surrounding images, we can
solve the problem then.

~TJ

From jackalmage at gmail.com  Thu Aug  5 09:21:51 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 5 Aug 2010 09:21:51 -0700
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30FE4@ECCR02PUBLIC.exchange.local>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com> 
	<3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30FE4@ECCR02PUBLIC.exchange.local>
Message-ID: <AANLkTikKqzwWQ47dJLeYGBt0-Z_Ww0XCm2-2M24hefKT@mail.gmail.com>

On Thu, Aug 5, 2010 at 2:24 AM, Thomas Koetter
<thomas.koetter at id-script.de> wrote:
> Aryeh wrote:
>>That's invalid markup. ?The first child of a <dl> (if any) must be a
>><dt>. ?I don't know what the semantics of <dl> are supposed to be with
>>no <dt>.
>
> According to the spec it is perfectly acceptable to leave out all dt elements:
> "If a dl element contains only dd elements, then it consists of one group with values but no names."

That's error-recovery behavior, just defining how to interpret invalid
markup.  The first paragraph gives the actual MUST requirements - each
group must consist of one or more <dt>s and one or more <dd>s.


On Thu, Aug 5, 2010 at 8:24 AM, Kit Grose <kit at iqmultimedia.com.au> wrote:
> Often a series of links shown inline are separated by a pipe (|) character. In the past I've produced this effect using border-right and other such malarky on the anchors or inline LIs with the same, but I think semantically the symbol does indeed represent a break between the links and that having the ability to style the break accordingly would be terrific.

Bug the browsers that don't let you do so.  Ideally you should be able
to style it however you want.  That's separate from this discussion,
though.

~TJ

From christoph.paeper at crissov.de  Thu Aug  5 10:24:15 2010
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Thu, 5 Aug 2010 19:24:15 +0200
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <C91F41D6-9316-47ED-93B4-DF73DF028375@adactio.com>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<C91F41D6-9316-47ED-93B4-DF73DF028375@adactio.com>
Message-ID: <1E2FACFB-9538-4AD3-9974-64D3E6F9DDA6@crissov.de>

Jeremy Keith:
> 
> The <hr> element is currently defined as "a paragraph-level thematic break." I think <br> could be defined as "a text-level thematic break."

That makes perfect sense. The only problem I see is existing content which relies on consecutive ?br?s producing multiple line breaks, i.e. often a paragraph-like appearance. (Although ?br?s were always intended to be collapsed, browsers never did this.)

From oliver at apple.com  Thu Aug  5 10:37:41 2010
From: oliver at apple.com (Oliver Hunt)
Date: Thu, 5 Aug 2010 10:37:41 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTi=GrTYVeu2L0NMzKSypWGyLw8LV-zjHNp=KvhgM@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com>
	<4BD5D280.30706@doxdesk.com> <4BD6C264.7070805@opera.com>
	<4BD72BBE.80106@enseirb-matmeca.fr> <4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
	<AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>
	<AANLkTimrrvhHj0dy8wZhO761BpXuh5831wTVX2fN6m-+@mail.gmail.com>
	<D7F43572-46DE-4374-B100-6C6976012416@apple.com>
	<AANLkTi=GrTYVeu2L0NMzKSypWGyLw8LV-zjHNp=KvhgM@mail .gmail.com>
Message-ID: <56C08488-5AD7-49D0-8EB9-4C4BB7D37744@apple.com>


On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote:

> On 8/4/10, Oliver Hunt <oliver at apple.com> wrote:
>> 
>> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:
>> 
>>> On 8/4/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>> 
>>> [...]
>>>> "submitButton" in form.elements
>>>> 
>>>> Existing implementations vary on when they use catchalls. I'd like to
>>>> see standardization for this behavior and codification so that
>>>> implementations behave similarly -- either use a catchall for a
>>>> particular type of collection or use a native object. If a catchall is
>>> 
>>> Native object either way, but either with a new ES catchall behavior
>>> or with a native ES object, as specified today.
>>> 
>>> Garrett
>> As a question, if the node lists were implemented as catchalls, how would
>> the behaviour differ from current NodeLists?
> 

So your only desire is to have NodeLists lose the host object issues?

> 
> The only change I can see
>> would be the loss of the host object exceptions in the ES spec, but that
>> just puts you in the position of having semantics that match the current
>> host object behavior in those implementations that already allow array
>> functions to operate on host objects.
>> 
> 
> The semantics for native object are defined by ECMA-262.
> 
> If collection is required to be implemented as a native ECMAScript
> object, then it would still be considered a host as a native object,
> would be indistinguishable from other native objects, both internally
> and externally, and so would not be subject to ES "whether or not the
> xxx method may be applied to a host object" loopholes. Thus,
> 
>  [].slice.call( ho )

It sounds like all you want is for the array (and other similar) methods to work on NodeLists, etc but currently some implementations make use of the ES5 text saying the they don't need to support host objects, correct?

An ES definition for the type would merely be for the purpose of removing the ability for an implementation to make use of the "we don't need to support operation X on host objects"?

--Oliver



From ryosuke.niwa at gmail.com  Thu Aug  5 10:48:59 2010
From: ryosuke.niwa at gmail.com (Ryosuke Niwa)
Date: Thu, 5 Aug 2010 10:48:59 -0700
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<AANLkTi=P8re03ZZEF4g6bzWE2JftJc438tiBwqTZE2M7@mail.gmail.com>
Message-ID: <AANLkTinv6ygv11u5c-vss0cuAOm3waLbHsp5VeJvw=w4@mail.gmail.com>

On Wed, Aug 4, 2010 at 2:31 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Wed, Aug 4, 2010 at 8:56 AM, Thomas Koetter
> <thomas.koetter at id-script.de> wrote:
> > What strikes me though is that according to the spec "The br element
> represents a line break". A *line* break is presentational in nature. The
> break is structural, but restricting it to a certain presentation of that
> break lacks the desired separation of structure and presentation.
>
> Anything else is impossible in this case.  <b> and <i> are also
> presentational, but the presentation cannot be separated from the
> semantics.
>

That's totally incorrect in HTML5 as Thomas has pointed out.  Let me ask you
a question.  What do you suppose non-visual user agent should do when they
encounter br?  Simply ignore them because it only signifies a line break?
 Or read out that there's a line break?  Neither seems user friendly to me.
 If anything, a momentary pause will be appropriate because what's what we
usually do when reading a book and a line break appears.  This clearly isn't
*line break*.

Best,
Ryosuke Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100805/86705ad1/attachment-0001.htm>

From eric.carlson at apple.com  Thu Aug  5 11:24:31 2010
From: eric.carlson at apple.com (Eric Carlson)
Date: Thu, 5 Aug 2010 11:24:31 -0700
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <4C5AD729.2050501@mit.edu>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C57495A.9020800@pearce.org.nz>
	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>
	<4C583871.4020004@mit.edu>
	<op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>
	<4C5933C3.20404@mit.edu>
	<op.vgwt0gcisr6mfa@philip-pc.gothenburg.osa>
	<4C59A127.1020705@mit.edu>
	<op.vgyjyhrasr6mfa@philip-pc.gothenburg.osa>
	<4C5AD729.2050501@mit.edu>
Message-ID: <303D63D7-01DC-4946-B7E1-FF1E524CADAE@apple.com>


On Aug 5, 2010, at 8:22 AM, Boris Zbarsky wrote:

> In practice, what Gecko would likely do here is to treat "stable state" as "the event loop is spinning", just like we would for the other case.  This means that while a modal dialog is up, or a sync XHR is running or whatnot is a stable state.
> 

  FWIW this is what WebKit does now, assuming you mean *asynch* XHR.

eric


From bzbarsky at MIT.EDU  Thu Aug  5 11:34:05 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 05 Aug 2010 14:34:05 -0400
Subject: [whatwg] Race condition in media load algorithm
In-Reply-To: <303D63D7-01DC-4946-B7E1-FF1E524CADAE@apple.com>
References: <4C56245C.3080604@pearce.org.nz>
	<Pine.LNX.4.64.1008020908200.3056@ps20323.dreamhostps.com>
	<4C57495A.9020800@pearce.org.nz>
	<op.vgusfkqhsr6mfa@philip-pc.gothenburg.osa>
	<4C583871.4020004@mit.edu>
	<op.vgwm7cpfsr6mfa@philip-pc.gothenburg.osa>
	<4C5933C3.20404@mit.edu>
	<op.vgwt0gcisr6mfa@philip-pc.gothenburg.osa>
	<4C59A127.1020705@mit.edu>
	<op.vgyjyhrasr6mfa@philip-pc.gothenburg.osa>
	<4C5AD729.2050501@mit.edu>
	<303D63D7-01DC-4946-B7E1-FF1E524CADAE@apple.com>
Message-ID: <4C5B041D.5080909@mit.edu>

On 8/5/10 2:24 PM, Eric Carlson wrote:
>
> On Aug 5, 2010, at 8:22 AM, Boris Zbarsky wrote:
>
>> In practice, what Gecko would likely do here is to treat "stable state" as "the event loop is spinning", just like we would for the other case.  This means that while a modal dialog is up, or a sync XHR is running or whatnot is a stable state.
>>
>
>    FWIW this is what WebKit does now, assuming you mean *asynch* XHR.

No, I meant what I said.  Async XHR is clearly going to go back to the 
event loop, etc.  In Gecko, sync XHR does as well, by manually spinning 
the event loop under the Send() call (and blocking delivery of certain 
classes of events to the web page that triggered the send).

This isn't at all like the "pause" state the spec describes, which I 
also mentioned.

On the other hand, I think the spec's "pause" state can have some really 
undesirable interactions whereby a sync XHR on one page can affect 
behavior of other pages, which is why I have problems with it...

-Boris

From royalrodent at gmail.com  Thu Aug  5 11:53:20 2010
From: royalrodent at gmail.com (Bryce Fields)
Date: Thu, 5 Aug 2010 14:53:20 -0400
Subject: [whatwg] [br] element should not be a line break
In-Reply-To: <1E2FACFB-9538-4AD3-9974-64D3E6F9DDA6@crissov.de>
References: <3597AE56FA7BDA4990F0BC56D7FA79CE014BC5D30EE6@ECCR02PUBLIC.exchange.local>
	<C91F41D6-9316-47ED-93B4-DF73DF028375@adactio.com>
	<1E2FACFB-9538-4AD3-9974-64D3E6F9DDA6@crissov.de>
Message-ID: <AANLkTimF7fQw0-Cu4=H6=DjydWoEwhSLwFYH-XcN+BY-@mail.gmail.com>

On Thu, Aug 5, 2010 at 1:24 PM, Christoph P?per <christoph.paeper at crissov.de
> wrote:

> Jeremy Keith:
> >
> > The <hr> element is currently defined as "a paragraph-level thematic
> break." I think <br> could be defined as "a text-level thematic break."
>
> That makes perfect sense. The only problem I see is existing content which
> relies on consecutive ?br?s producing multiple line breaks, i.e. often a
> paragraph-like appearance. (Although ?br?s were always intended to be
> collapsed, browsers never did this.)


Why not just list <br> along with the other obsolete elements instead of
trying to rebrand it semantically?  Let's face it.  <br> is a pain to try to
rationalize as a purely semantic element and any use you have for the
element could probably easily be accomplished w/ other semantic code.  Why
not just call it obsolete and discourage authors and vendors from using it?

(first post...be gentle...)  :)

-----
Bryce Fields
www.royalrodent.com

"Do or do not. There is no try." -- Yoda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100805/2413ca38/attachment.htm>

From kevinar18 at hotmail.com  Thu Aug  5 12:14:26 2010
From: kevinar18 at hotmail.com (Kevin Ar18)
Date: Thu, 5 Aug 2010 15:14:26 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
Message-ID: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>



First off, let me start with a question to see if maybe I missed something somewhere:
 
Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath?
 
 
 
As far as I know, there is no way to do this using the HTML5 spec.  However, if I am wrong, then there is no need for the rest of this discussion.
 
 
 
 
Rationale:
One of the greatest benefits I see in SVG is the way it can potentially be used to integrate with HTML pages and affect the visual layout in new ways.  Unfortunately, the current SVG-HTML integration keeps the two quite separated.
 
>From my perspective, there are two features that would make SVG drastically more useful to websites:
1) The ability for SVG shapes to affect the flow and positioning of HTML elements (not just a square inserted into the the page, but the actual odd shape of SVG objects changing text borders, relative positioning of inline elements, etc... -- html currently has no such box/layout model like this).
2) The ability to overlay svg objects over certain parts of the page, but the transparent areas act like they don't exist.
 
The first point is too complex to deal with now.  However, the second point might be possible with minimal changes to the spec -- and, hopefully, minor changes to browsers.
 
 
Proposal:
1. Add a new property to the <svg> tag, such as: blockingcanvas="true|false" (just an example)
2. When set to non-blocking mode... any transparent areas act like they do not exist.  This particularly makes sense, when you overlay an SVG shape on top of other content on your website (usually HTML), then content in the transparent areas can be interacted with just like normal.
 
 
Problem:
1. Needed to make SVG-HTML interaction more useful
2. This might need clarification in the specs because already different browsers treat the transparent part of the svg canvas differently.  Opera has the ability to allow interaction with content beneath the transparent area (although it might be buggy).  Firefox blocks the entire transparent svg canvas even if it contains no SVG objects.
 
Example and further clarification:
At the end of this message is a sample page.
 
Anyways, in this example, the <svg> canvas hovers over the content of the page.
* In my proposal, you should be able to click on all the google links that you can see (many are underneath the svg canvas).
* As always, actual SVG objects (like the red line) would block interaction with (and visibility of) the material underneeth.
 
 
* In terms of events, "click", "mouseout", "mouseover", etc... on the red line (SVG path) would trigger an event on the SVG path only).
* In terms of events on the transparent area inside and outside the red line would trigger an event on the content underneath -- which in this case may be the document body or one of the links.
 
* Standard browser interaction like text selection, context menus, etc... would also be affected.
 
* Essentially, it would be treated like the transparent areas of the <svg> canvas do not exist and the content underneath is what is being interacted with.
 
* Other issues:
  How "border" style affects the svg canvas blocking/non-blocking would need clarification.
 
 
 
------------------------------
<?xml version="1.0"?>
<!--Credits/Copyright/Reference (Entire Document):
 http://www.whatwg.org/specs/web-apps/current-work/
 http://www.w3.org/TR/SVG11/
  http://www.w3.org/TR/SVG11/struct.html#NewDocumentOverview (copied some of the working layout from here)
 http://www.w3.org/TR/xml-names11/
-->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>
<body>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>
<a href="http://www.google.com/">google.com</a><br/>

<svg style="position:absolute; top:0px; left:0px; border:1px solid black;" x="0" y="0" xmlns="http://www.w3.org/2000/svg" width="500" height="500">
 <path d="M 0,0 l 5,5 100,0 0,100 -100,0 z" stroke="red" stroke-width="5" fill="none"/>
</svg>
</body>
</html> 		 	   		  

From bzbarsky at MIT.EDU  Thu Aug  5 12:17:47 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 05 Aug 2010 15:17:47 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>
Message-ID: <4C5B0E5B.2050401@mit.edu>

On 8/5/10 3:14 PM, Kevin Ar18 wrote:
> Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath?

Yes.  See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty

-Boris

From kevinar18 at hotmail.com  Thu Aug  5 12:36:59 2010
From: kevinar18 at hotmail.com (Kevin Ar18)
Date: Thu, 5 Aug 2010 15:36:59 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <4C5B0E5B.2050401@mit.edu>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>,
	<4C5B0E5B.2050401@mit.edu>
Message-ID: <SNT110-W34A4AB36D359D0C6666892AA900@phx.gbl>


> On 8/5/10 3:14 PM, Kevin Ar18 wrote:
> > Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath?
>
> Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty

Quick question, if you are familiar with it.
 
This seems to only affect SVG objects interacting with other SVG objects (inside an SVG canvas).
 
Does it also apply to the SVG canvas inside an HTML page? 		 	   		  

From bzbarsky at MIT.EDU  Thu Aug  5 13:07:08 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 05 Aug 2010 16:07:08 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <SNT110-W34A4AB36D359D0C6666892AA900@phx.gbl>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>,
	<4C5B0E5B.2050401@mit.edu>
	<SNT110-W34A4AB36D359D0C6666892AA900@phx.gbl>
Message-ID: <4C5B19EC.5060600@mit.edu>

On 8/5/10 3:36 PM, Kevin Ar18 wrote:
>
>> On 8/5/10 3:14 PM, Kevin Ar18 wrote:
>>> Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath?
>>
>> Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty
>
> Quick question, if you are familiar with it.
>
> This seems to only affect SVG objects interacting with other SVG objects (inside an SVG canvas).
>
> Does it also apply to the SVG canvas inside an HTML page? 		 	   		

This might depend on the browser, since nothing actually defines the 
interaction of SVG and HTML in this area very well.  Per SVG spec, 
pointer-events is not supposed to apply to <svg>, for example.

However in the case of Gecko specifically, the "none" value is supported 
for all elements, not just SVG elements.  So if you set 
pointer-events:none on the <svg> and then whatever values of 
pointer-events you want on its descendants, things should work.

In Opera and Webkit it looks like <svg> doesn't get events by default at 
all.  So there's no issue.  So this testcase does what you want, I 
think, in all of Opera, Webkit, Gecko.

<html xmlns="http://www.w3.org/1999/xhtml">
   <div style="position: absolute; top: 0; left: 0;
               width: 100px; height: 100px; background: green;"
        onclick="alert('s')"></div>
   <svg style="position: absolute; top: 0; left: 0;
               pointer-events: none"
        onclick="alert('t')" width="100" height="100"
        xmlns="http://www.w3.org/2000/svg">
     <circle cx="50" cy="50" r="20" fill="red"
             pointer-events="visible"></circle>
   </svg>
</html>

-Boris

From kevinar18 at hotmail.com  Thu Aug  5 13:13:34 2010
From: kevinar18 at hotmail.com (Kevin Ar18)
Date: Thu, 5 Aug 2010 16:13:34 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <4C5B0E5B.2050401@mit.edu>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>,
	<4C5B0E5B.2050401@mit.edu>
Message-ID: <SNT110-W3769C198068079D61542ABAA900@phx.gbl>


> > Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath?
>
> Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty
>
> -Boris
 
Another followup.  First, I should thank you for that piece of info.  I was indeed not aware of that particular property.
 
I tried: pointer-events:painted
... and at the suggestion of a friend, I tried: pointer-events:none
 
 
Results:
 
 
Opera -- works
 
Opera (no pointer-event style):
 * click through works fine (canvas non-blocking) -- links, and various mouse events work on the document HTML body
Opera (pointer-events:painted):
 * same as above
 
 
Firefox Gecko/20100804 Minefield/4.0b3pre -- very buggy
 
(no pointer-event):
* blocks everything underneath the invisible canvas
(pointer-events:painted):
* blocks everything underneath
(poiner-events:none):
* this seems to work
 
 
 
uzbl git.20100403-2
* click through works (canvas non-blocking)
 
 
 
----------------
So, would the conclusing (based on the specs and the results) be that Firefox is the problem here and I need to file some bug report(s)?  ... or is there any vagueness in the spec that might be the cause? 		 	   		  

From kevinar18 at hotmail.com  Thu Aug  5 13:16:31 2010
From: kevinar18 at hotmail.com (Kevin Ar18)
Date: Thu, 5 Aug 2010 16:16:31 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <4C5B19EC.5060600@mit.edu>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>, ,
	<4C5B0E5B.2050401@mit.edu>,
	<SNT110-W34A4AB36D359D0C6666892AA900@phx.gbl>,
	<4C5B19EC.5060600@mit.edu>
Message-ID: <SNT110-W33ABDA2ED2E6E6F0F7B480AA900@phx.gbl>


> This might depend on the browser, since nothing actually defines the
> interaction of SVG and HTML in this area very well. Per SVG spec,
> pointer-events is not supposed to apply to , for example.
>
> However in the case of Gecko specifically, the "none" value is supported
> for all elements, not just SVG elements. So if you set
> pointer-events:none on the and then whatever values of
> pointer-events you want on its descendants, things should work.
>
> In Opera and Webkit it looks like doesn't get events by default at
> all. So there's no issue. So this testcase does what you want, I
> think, in all of Opera, Webkit, Gecko.

Seems we came to a similar conclusion (and similar test cases). :)
 
Do you think there is a need for some clarification on this issue in the HTML5 specs? 		 	   		  

From bzbarsky at MIT.EDU  Thu Aug  5 13:20:35 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 05 Aug 2010 16:20:35 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <SNT110-W33ABDA2ED2E6E6F0F7B480AA900@phx.gbl>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>, ,
	<4C5B0E5B.2050401@mit.edu>,
	<SNT110-W34A4AB36D359D0C6666892AA900@phx.gbl>,
	<4C5B19EC.5060600@mit.edu>
	<SNT110-W33ABDA2ED2E6E6F0F7B480AA900@phx.gbl>
Message-ID: <4C5B1D13.7020102@mit.edu>

On 8/5/10 4:16 PM, Kevin Ar18 wrote:
> Do you think there is a need for some clarification on this issue in the HTML5 specs? 		 	   		

I think there's work on a clarification going on already in the CSS 
working group.  See the thread starting with 
http://lists.w3.org/Archives/Public/www-style/2008Jul/0428.html

-Boris

From kevinar18 at hotmail.com  Thu Aug  5 13:40:10 2010
From: kevinar18 at hotmail.com (Kevin Ar18)
Date: Thu, 5 Aug 2010 16:40:10 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <4C5B1D13.7020102@mit.edu>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>,
	, , <4C5B0E5B.2050401@mit.edu>, ,
	<SNT110-W34A4AB36D359D0C6666892AA900@phx.gbl>, ,
	<4C5B19EC.5060600@mit.edu>,
	<SNT110-W33ABDA2ED2E6E6F0F7B480AA900@phx.gbl>,
	<4C5B1D13.7020102@mit.edu>
Message-ID: <SNT110-W18F1076DE914490A4B8031AA900@phx.gbl>


> > Do you think there is a need for some clarification on this issue in the HTML5 specs?
>
> I think there's work on a clarification going on already in the CSS
> working group. See the thread starting with
> http://lists.w3.org/Archives/Public/www-style/2008Jul/0428.html

 
 
I guess that would solve future issues... but it involves a new spec right?
 
My concern is that we get this specific HTML5-SVG interaction right now, so that SVG can be much more useful on regular websites in the very near future.  Since the problem area is Firefox, I thought maybe I could file a bug report and take care of this issue that way.  However, I am not clear on the specs and whether I should file a report.
 
According to here (http://www.w3.org/TR/SVG11/struct.html#SVGElement) pointer-events is a property of the svg tag.
According to here (http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty) pointer-events is not a property of the svg tag since svg is not part of the graphical elements group.  In fact, this is what you said in another email.
 
So, does this actually mean a browser should not support pointer-events for the svg tag within a html document?  I was considering filing a report for Firefox about not supporting pointer-events:painted for the svg tag inside an html document.
 
P.S.  I know, I should probably switch to the implementations mailing list soon, but I just want to confirm a few things about the spec before I start doing testcases and bugreports. :) 		 	   		  

From herenvardo at gmail.com  Thu Aug  5 13:50:27 2010
From: herenvardo at gmail.com (Eduard Pascual)
Date: Thu, 5 Aug 2010 22:50:27 +0200
Subject: [whatwg] "Content-Disposition" property for <a> tags
In-Reply-To: <4C57026B.2020806@mit.edu>
References: <op.vgnjqqx448yz2f@dennis>
	<60A2EADF-E42B-4154-B3E2-E9BC8D60684E@adactio.com> 
	<op.vgtiz3g048yz2f@dennis> <0097F4E418EA47BBAF9C9433340158C6@NETBOOK> 
	<AANLkTin_QoGZyhGTHhs2onpVzf7yXq4Bi4akZXBQpndG@mail.gmail.com> 
	<4C57026B.2020806@mit.edu>
Message-ID: <AANLkTik3zXZWYKKL-CiE6dYiXZn3ORya4PGjECBLoeU-@mail.gmail.com>

On Mon, Aug 2, 2010 at 7:37 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 8/2/10 1:15 PM, Aryeh Gregor wrote:
>>
>> If you don't agree that this use-case is worth adding the feature for,
>> do you think that:
>> 3) Something else?
>
> For the use case your describe, it might just make more sense for browsers
> to support Content-Disposition on data: URIs directly somehow... ?Maybe.

I'd definitelly love that! :P
It would solve my use-case [1], and similar other cases.

Trying to sum up things:
Some applications use "save" buttons. While it may seem redundant with
the browser's ability to save the target of a link when the user
explicitly tells so; an in-page save button is still a clear
call-to-action.
Furthermore, some web-apps attempt to mimic the look-and-feel of
comparable desktop apps. There is a vast ammount of software that
performs some kind of saving; and to implement it on the web we
authors need some way to, at least, hint the browser that a resource
is being "navigated" as part of some in-page "save" UI element. The
way this is normally achieved is by round-tripping the server,
uploading (normally POSTing) the data for the server to send it back
with the "Content-Disposition" header. This is a workaround that
presents many issues:
- Prevents the application from working offline; even if everything
else on the app is purely HTML+CSS+JS-based.
- May cause significant delays when the volume of the data is large.
- It forces the data to take a trip around the world, creating a
security/privacy vulnerability that could be easily avoided with
client-based downloads (unless the server uses encryption, of course,
but encryption is expensive both CPU- and money- wise).
- It attaches network connection's unreliability to a feature that
would otherwise "just work".
- It may cause the bill to go to the clouds when using the app from a
pay-per-volume connection (such as those provided by many mobile phone
operators).

Of course, some people are worried about this being abused. And it's a
legitimate worry. Despite it may seem so, there is no need to _force_
a download. All we (authors) need is a way to _hint_ the browser that
a download is assumed/expected from the app's side. It's entirely up
to the browser (probably taking in account user preferences) how to
deal with such a hint.
Furthermore, I'm strongly convinced that in-page save buttons should
behave as closely as possible as Content-Disposition: attachment:
anything else would go against user's expectations (example: if a user
normally gets a Save/Open/Cancel dialog when accessing a zip file,
then any in-page feature to "save" a zip file should present the same
dialog).


Just my thoughts.

Regards,
Eduard Pascual

From dhtmlkitchen at gmail.com  Thu Aug  5 14:41:16 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 5 Aug 2010 14:41:16 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <56C08488-5AD7-49D0-8EB9-4C4BB7D37744@apple.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com>
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr>
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
	<AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>
	<AANLkTimrrvhHj0dy8wZhO761BpXuh5831wTVX2fN6m-+@mail.gmail.com>
	<D7F43572-46DE-4374-B100-6C6976012416@apple.com>
	<AANLkTi=GrTYVeu2L0NMzKSypWGyLw8LV-zjHNp=KvhgM@mail.gmail.com>
	<56C08488-5AD7-49D0-8EB9-4C4BB7D37744@apple.com>
Message-ID: <AANLkTin0Hf9LGdtJKh2sZwx_viy=8iwT5MH9tvUW38_k@mail.gmail.com>

On 8/5/10, Oliver Hunt <oliver at apple.com> wrote:
>
> On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote:
>
>> On 8/4/10, Oliver Hunt <oliver at apple.com> wrote:
>>>
>>> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:
>>>
>>>> On 8/4/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>>>
>>>> [...]
>>>>> "submitButton" in form.elements
>>>>>
>>>>> Existing implementations vary on when they use catchalls. I'd like to
>>>>> see standardization for this behavior and codification so that
>>>>> implementations behave similarly -- either use a catchall for a
>>>>> particular type of collection or use a native object. If a catchall is
>>>>
>>>> Native object either way, but either with a new ES catchall behavior
>>>> or with a native ES object, as specified today.
>>>>
>>>> Garrett
>>> As a question, if the node lists were implemented as catchalls, how would
>>> the behaviour differ from current NodeLists?
>>


I'll tell you, I took another peek at WebIDL and see now "getter".

The DOM, web IDL, etc should not be specifying how catchalls work;
that's an ECMAScript language feature and so it is the job for the ES
committee.

In particular, WebIDL should not use terminology "getter" because that
may be confused with the ECMAScript language construct of the same
name.

>
> So your only desire is to have NodeLists lose the host object issues?
>

That isn't very precise; I can't acknowledge that as being correct.

In this thread, I want:
 * NodeList spec'd as native ES object (DOM)
 * Static Array generics (ES)
 * Consolidate collections (DOM) to:
  -  allow [[Get]] to return undefined (not require null)
  -  use more specific terminology than "integer index" (unsigned long)
  - resolve "has" checks for collections (DOM and ES)

* Array from a NodeList can be guaranteed with [].prototype.slice.call
if NodeList is specified as a native ES object in a DOM specification
(perhaps WebIDL, as that effort seems to be continuing).

* Array Generics, as JavaScriptTM has, for a while, had Array.slice,
et al to simplify from Array.prototype.slice.call. This is something
that should be done by ES committee.

Regarding indexed collections in general, the behavior of an indexed
collection should be consolidated where possible.

"has" checks should work as expected and should not fall apart as
shown in the article.

  var form = document.forms[0];
  "0" in form; // false in Gecko
  Array.prototype.indexOf.call(form, form[0]);

Firefox: -1
Safari: 0

[...]

I have many other desires, none of them having anything to do with
this thread or programming at all.

>>  [].slice.call( ho )
>
> It sounds like all you want is for the array (and other similar) methods to
> work on NodeLists, etc but currently some implementations make use of the
> ES5 text saying the they don't need to support host objects, correct?
>
> An ES definition for the type would merely be for the purpose of removing
> the ability for an implementation to make use of the "we don't need to
> support operation X on host objects"?
>

Sorry, but I didn't understand what you meant by "the type".

I'm not proposing ES remove the text "whether or not the xxx
method..." if that's what you meant. Rather, I'm proposing that
NodeList be specified by the DOM ECMAScript bindings to be a native
ECMAScript object. That way, it will not be possible for any ES method
to discriminate against a host object.

Does that answer your question? Are there any criticism or concerns
with that proposal?

Garrett

From bzbarsky at MIT.EDU  Thu Aug  5 14:49:54 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 05 Aug 2010 17:49:54 -0400
Subject: [whatwg] Non-blocking SVG Canvas?
In-Reply-To: <SNT110-W18F1076DE914490A4B8031AA900@phx.gbl>
References: <SNT110-W61D1B415C8215EDBBF49AEAA900@phx.gbl>, , ,
	<4C5B0E5B.2050401@mit.edu>, ,
	<SNT110-W34A4AB36D359D0C6666892AA900@phx.gbl>, ,
	<4C5B19EC.5060600@mit.edu>,
	<SNT110-W33ABDA2ED2E6E6F0F7B480AA900@phx.gbl>,
	<4C5B1D13.7020102@mit.edu>
	<SNT110-W18F1076DE914490A4B8031AA900@phx.gbl>
Message-ID: <4C5B3202.5000605@mit.edu>

On 8/5/10 4:40 PM, Kevin Ar18 wrote:
> I guess that would solve future issues... but it involves a new spec right?

Well, any sort of clarification here does, yes.

> My concern is that we get this specific HTML5-SVG interaction right now

It needs a new spec no matter what, no matter where it lives...

>  Since the problem area is Firefox

In the sense that in Gecko <svg> is not transparent to events by default?

Note that transparency to events is not even interoperable inside HTML; 
e.g. an empty div will block events in some browsers but not others.

That said, support for pointer-events:none on arbitrary elements makes 
this point moot; you just assume the worst and add styles that describe 
the exact behavior you want.

> However, I am not clear on the specs

The specs do not define event targeting behavior at all.

> According to here (http://www.w3.org/TR/SVG11/struct.html#SVGElement) pointer-events is a property of the svg tag.

Correct.

> According to here (http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty) pointer-events is not a property of the svg tag since svg is not part of the graphical elements group.

Not quite.  It doesn't _apply_ to the <svg> tag.  But it's a property of 
all elements.  And since it inherits by default, this distinction is a 
meaningful one (e.g. you can set pointer-events to some value on an 
<svg> to set it to that value on all graphical elements contained in the 
<svg>).

> So, does this actually mean a browser should not support pointer-events for the svg tag within a html document?

Technically, per SVG spec, yes.  I believe there is common agreement 
(well, at least in Webkit and Gecko) that this needs a spec change to 
give better behavior.

>  I was considering filing a report for Firefox about not supporting pointer-events:painted for the svg tag inside an html document.

The thing is... as "painted" is defined in the SVG spec, it doesn't make 
sense for <svg> (which never has any fill or stroke that actually do 
anything).  This is why a separate spec is needed to define the behavior 
here.

That said, you may be interested in 
https://bugzilla.mozilla.org/show_bug.cgi?id=380573

-Boris

From smfr at me.com  Thu Aug  5 15:17:54 2010
From: smfr at me.com (Simon Fraser)
Date: Thu, 05 Aug 2010 15:17:54 -0700
Subject: [whatwg] Feedback on the Mozilla FullScreen API proposal
Message-ID: <87A60BB0-49A6-4450-A62A-3861EB2F22F8@me.com>

This is feedback on the Mozilla FullScreen API proposal here:
<https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI>

> The user agent may transition a Document into or out of the
> fullscreen state at any time, whether or not script has requested
> it. User agents are encouraged to provide standard UI to exit the
> fullscreen state, for example if the user presses the Escape key.

Does this imply that the UA has a "fullscreen" button, when
the user uses this to make the window fullscreen, then the
CSS pseudoclasses described in this document are applied?
I'm not sure that's always desirable; I think it might result
in unexpected behavior for users who use the fullscreen button
as an equivalent to maximizing the window.

I'd suggest that the CSS pseudoclasses are only applied when the
fullscreen JS API has been called by the web content.

>  * void cancelFullScreen()

I think "exit" would be better than "cancel".

> New methods of Document:
>  * void requestFullScreen()
>  * void requestFullScreenWithKeys()

> New methods of Element:
>  * void requestFullScreen()
>  * void requestFullScreenWithKeys()

Do we really need to add these to both Document and Element?
It seems like the Document ones could be removed; if an
author wants to take the Documemnt fullscreen, they simply
call the methods on document.documentElement.

I'm not fan of "WithKeys" in the method names. Out of
context, it's not clear what "keys" means. I think
"keyboardInput" or "keyInput" would be more understandable.
Also, why not just use a parameter:

    void requestFullScreen(bool allowKeyboardInput)
    
or have some constants for behavior:

    const unsigned short ALLOW_KEYBOARD_INPUT = 1;
    void requestFullScreen(unsigned short behavior)
    
This would be extensible, and would allow us to permit other
behaviors later.

Why don't requestFullScreen()/requestFullScreenWithKeys() return
a boolean value indicating whether the UA will allow the request
to proceed? The author has no information about whether fullscreen
is going to happen after making this call, and UAs will certainly
want to deny fullscreen in various situations.

> New content attribute of the <iframe> element:
>  * allowfullscreen
> This is a boolean attribute. When this attribute is not set, UAs
> should ignore fullscreen requests in the iframe or its descendants.

Descendant nodes, or descendant iframes?

> * :full-screen-doc

I don't like the abbreviation of "document" here. Would "page"
be a better term to use than "document" for these?

>  * :full-screen-doc
> While a Document is in the fullscreen state, the 'full-screen-doc'
> pseudoclass applies to the root element of that Document.
> 
>  * :full-screen-doc-with-target
> While a Document is in the fullscreen state and the document's
> current fullscreen element is an element in the document, the
> 'full-screen-doc-with-target' pseudoclass applies to the root
> element of that Document.

Just to be clear, if a document is fullscreen, and the fullscreen
element is not the document element, then the document element
will get both these pseudoclasses? What happens when the
fullscreen element is the the document element?

I'd like to see the proposal fleshed out to address the following
scenarios:

* the document is fullscreen, and navigation happens
* the document is fullscreen, and the content calls requestFullScreen()
  again (possibly with a different element, possibly inside an iframe).
* the document is fullscreen, and the fullscreen element is removed
  from the DOM
* the document is fullscreen, and the fullscreen element has 
  display:none set on it.
* consideration of whether the fullscreen API can be called at
  any time (risk of "drive-by-fullscreening").
* affect, if any, on calls to focus() on elements which are not children
  of the fullscreen element.
  
Thanks
Simon


From dhtmlkitchen at gmail.com  Thu Aug  5 16:48:31 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 5 Aug 2010 16:48:31 -0700
Subject: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
In-Reply-To: <AANLkTin0Hf9LGdtJKh2sZwx_viy=8iwT5MH9tvUW38_k@mail.gmail.com>
References: <4BD257B1.6040500@enseirb-matmeca.fr>
	<s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
	<u2tc9e12661004242335j1480e6f6t8abff26ee1e11be9@mail.gmail.com>
	<r2z34df39071004260943ydc4e521fu1ae31de63aa8ecc7@mail.gmail.com>
	<4BD5C792.7050106@davidflanagan.com> <4BD5D280.30706@doxdesk.com>
	<4BD6C264.7070805@opera.com> <4BD72BBE.80106@enseirb-matmeca.fr>
	<4BD7F437.4030602@opera.com>
	<Pine.LNX.4.64.1007300030090.7470@ps20323.dreamhostps.com>
	<AANLkTikWBuOHz6GzfGjPBvF87jciaCCmoHqrSkRxP3we@mail.gmail.com>
	<AANLkTimm7V_-YvZ1h1GZvN4Pc1Bm458HOa0-TSe4T3Y2@mail.gmail.com>
	<2F852F6C-7354-4D42-882C-20EE195BFF0F@apple.com>
	<AANLkTi=QrvRR3np5B6Th7Jqgjqps78rGq_BOLW5EkJn=@mail.gmail.com>
	<AANLkTingaH7=DgRE+FbAehYU7jsY=wio1SFLJebFOzu1@mail.gmail.com>
	<AANLkTi=UESzYr93yEi2U79SxroZWNesw2ug-19FdUcn-@mail.gmail.com>
	<AANLkTimrrvhHj0dy8wZhO761BpXuh5831wTVX2fN6m-+@mail.gmail.com>
	<D7F43572-46DE-4374-B100-6C6976012416@apple.com>
	<AANLkTi=GrTYVeu2L0NMzKSypWGyLw8LV-zjHNp=KvhgM@mail.gmail.com>
	<56C08488-5AD7-49D0-8EB9-4C4BB7D37744@apple.com>
	<AANLkTin0Hf9LGdtJKh2sZwx_viy=8iwT5MH9tvUW38_k@mail.gmail.com>
Message-ID: <AANLkTik5pouu0Nb63VMF3sXVt_bb9=ktVV-23mrs94SV@mail.gmail.com>

On 8/5/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On 8/5/10, Oliver Hunt <oliver at apple.com> wrote:
>>
>> On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote:
>>
>>> On 8/4/10, Oliver Hunt <oliver at apple.com> wrote:
>>>>
>>>> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:
>>>>
>>>>> On 8/4/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>>>>
>>>>> [...]

[...]

>
> I'm not proposing ES remove the text "whether or not the xxx
> method..." if that's what you meant. Rather, I'm proposing that
> NodeList be specified by the DOM ECMAScript bindings to be a native
> ECMAScript object. That way, it will not be possible for any ES method
> to discriminate against a host object.
>
Correction:
 "...to discriminate against those objects."

(ES methods ([].concat, et al) would still be able to discriminate
against any other host object that is not implemented as a native
object).

[...]

Garrett

From robert at ocallahan.org  Thu Aug  5 17:56:19 2010
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 6 Aug 2010 12:56:19 +1200
Subject: [whatwg] Feedback on the Mozilla FullScreen API proposal
In-Reply-To: <87A60BB0-49A6-4450-A62A-3861EB2F22F8@me.com>
References: <87A60BB0-49A6-4450-A62A-3861EB2F22F8@me.com>
Message-ID: <AANLkTim8ActDmav7QGwGrdROVmwqzSTMg6JqkwzHvP7K@mail.gmail.com>

On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser <smfr at me.com> wrote:

> This is feedback on the Mozilla FullScreen API proposal here:
> <https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI>
>
> > The user agent may transition a Document into or out of the
> > fullscreen state at any time, whether or not script has requested
> > it. User agents are encouraged to provide standard UI to exit the
> > fullscreen state, for example if the user presses the Escape key.
>
> Does this imply that the UA has a "fullscreen" button, when
> the user uses this to make the window fullscreen, then the
> CSS pseudoclasses described in this document are applied?
>

Yes, that's the idea. We want to be able to integrate fullscreen UI with
scripted fullscreen.


> I'm not sure that's always desirable; I think it might result
> in unexpected behavior for users who use the fullscreen button
> as an equivalent to maximizing the window.

I'd suggest that the CSS pseudoclasses are only applied when the
> fullscreen JS API has been called by the web content.
>

Well, that's up to the UA; you can have a fullscreen mode that doesn't put
the document into the fullscreen state, if you want.

Note that the API lets authors distinguish "fullscreen with a specific
targeted element" vs "fullscreen with no targeted element", and a basic
fullscreen UI would only enter the latter mode. So I don't think you'll get
unexpected behavior in practice if they're integrated.

Personally I think they should be integrated. For example, if you have a
canvas game that occupies most of the window except for some instruction
text, and the game has a fullscreen command that makes the canvas fill the
window and resizes the canvas buffer to the window size, I think it would be
nice for the UA's fullscreen UI to trigger the same behavior. Or maybe you
have a slide viewer and you want the UA's fullscreen UI to trigger
fullscreen presentation mode. This API makes that possible.

>  * void cancelFullScreen()
>
> I think "exit" would be better than "cancel".
>

The only problem with "exit" is that you might call it when you're not
actually in fullscreen state, since requests are asynchronous. I think of it
more as cancelling the request than actually forcing a change.

> New methods of Document:
> >  * void requestFullScreen()
> >  * void requestFullScreenWithKeys()
>
> > New methods of Element:
> >  * void requestFullScreen()
> >  * void requestFullScreenWithKeys()
>
> Do we really need to add these to both Document and Element?
> It seems like the Document ones could be removed; if an
> author wants to take the Documemnt fullscreen, they simply
> call the methods on document.documentElement.
>

Yes, we can do that. This means getting rid of the concept of not having a
fullscreen element, and instead special-casing the case where the fullscreen
element is the root element in a few places. But I think that's probably a
win. Thanks.

I'm not fan of "WithKeys" in the method names. Out of
> context, it's not clear what "keys" means. I think
> "keyboardInput" or "keyInput" would be more understandable.
>

OK.


> Also, why not just use a parameter:
>
>    void requestFullScreen(bool allowKeyboardInput)
>

boolean parameters are bad style IMHO. It's hard to tell at the call site
what they mean.

or have some constants for behavior:
>
>    const unsigned short ALLOW_KEYBOARD_INPUT = 1;
>    void requestFullScreen(unsigned short behavior)
>
> This would be extensible, and would allow us to permit other
> behaviors later.
>

Sure.

Why don't requestFullScreen()/requestFullScreenWithKeys() return
> a boolean value indicating whether the UA will allow the request
> to proceed? The author has no information about whether fullscreen
> is going to happen after making this call, and UAs will certainly
> want to deny fullscreen in various situations.
>

The UA may not be able to make a decision synchronously. Permitting
asynchronous decisions about whether to permit fullscreen was a key goal
here. For example that gives UAs the option of presenting passive
confirmation UI.

> New content attribute of the <iframe> element:
> >  * allowfullscreen
> > This is a boolean attribute. When this attribute is not set, UAs
> > should ignore fullscreen requests in the iframe or its descendants.
>
> Descendant nodes, or descendant iframes?
>

Descendant frames. I'll clarify that.

> * :full-screen-doc
>
> I don't like the abbreviation of "document" here. Would "page"
> be a better term to use than "document" for these?
>

We can just make it ':full-screen-document'.

>  * :full-screen-doc
> > While a Document is in the fullscreen state, the 'full-screen-doc'
> > pseudoclass applies to the root element of that Document.
> >
> >  * :full-screen-doc-with-target
> > While a Document is in the fullscreen state and the document's
> > current fullscreen element is an element in the document, the
> > 'full-screen-doc-with-target' pseudoclass applies to the root
> > element of that Document.
>
> Just to be clear, if a document is fullscreen, and the fullscreen
> element is not the document element, then the document element
> will get both these pseudoclasses?


Correct.

What happens when the
> fullscreen element is the the document element?
>

As written, it would get all three pseudoclasses. But I think we can get rid
of full-screen-doc-with-target completely.

I'd like to see the proposal fleshed out to address the following
> scenarios:
>
> * the document is fullscreen, and navigation happens
>
* the document is fullscreen, and the content calls requestFullScreen()

>  again (possibly with a different element, possibly inside an iframe).
> * the document is fullscreen, and the fullscreen element is removed
>  from the DOM
> * the document is fullscreen, and the fullscreen element has
>  display:none set on it.
> * consideration of whether the fullscreen API can be called at
>  any time (risk of "drive-by-fullscreening").
> * affect, if any, on calls to focus() on elements which are not children
>  of the fullscreen element.
>

Done. In most of those cases, nothing special happens. That is intentional;
for example, I think trying to special-case handling of display:none or
focus would quickly add a lot of complexity.

Thanks for the feedback!

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100806/8b6d3c0f/attachment-0001.htm>

From ian at hixie.ch  Thu Aug  5 18:01:47 2010
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 6 Aug 2010 01:01:47 +0000 (UTC)
Subject: [whatwg] WebSockets: why boolean return value for send()?
In-Reply-To: <op.va60luzzidj3kv@simon-pieterss-macbook.local>
References: <op.va60luzzidj3kv@simon-pieterss-macbook.local>
Message-ID: <Pine.LNX.4.64.1008060100090.7470@ps20323.dreamhostps.com>

On Thu, 15 Apr 2010, Simon Pieters wrote:
>
> WebSocket send():
> 
> [[
> The send(data) method t