From russell.leggett at gmail.com  Fri Aug  1 05:28:43 2008
From: russell.leggett at gmail.com (Russell Leggett)
Date: Fri, 1 Aug 2008 08:28:43 -0400
Subject: [whatwg] Joined blocks
In-Reply-To: <4892A08F.1050707@arc.net.au>
References: <489297CA.9050902@arc.net.au>
	<Pine.LNX.4.62.0808010522070.3295@hixie.dreamhostps.com>
	<4892A08F.1050707@arc.net.au>
Message-ID: <680cacd10808010528y3d9e10e9pcee2c7b4848b736f@mail.gmail.com>

For what it's worth, Shannon, I totally agree with you. Not only is this
something I have been wanted for a long time, but I think it belongs in the
html. It's one thing if you just want columns, which is being covered here:
http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but there
are times when the joined blocks are more remote and distinctly not columns,
requiring the extra markup to control where it must join to. However, while
useful for complex layouts, this is definitely the much smaller use case. I
think it would make a great addition, but I suppose people have to have
priorities! ;)
-Russ

On Fri, Aug 1, 2008 at 1:35 AM, Shannon <shannon at arc.net.au> wrote:

>  I agree this is _mostly_ a CSS issue except that there is semantic meaning
> to the join attribute beyond layout. The attribute could serve as a guide to
> search engines, web-scrapers or WYSIWYG applications that two areas of the
> page should be considered a single piece of content. I am also unsure as to
> how this might affect other aspects of browser, javascript or DOM behaviour.
> There may be other uses or side-effects I can't imagine. At any rate CSS
> cannot associate elements so the join attribute should be considered
> independent of the style considerations as a means of saying "this block
> follows that one". Nonetheless I will do as you suggest.
>
> Shannon
>
>
> Ian Hickson wrote:
>
> On Fri, 1 Aug 2008, Shannon wrote:
>
>
>  Something I think is really missing from HTML is "linked text" (in the
> traditional desktop publishing sense), where two or more text boxes are
> joined so that content overflows the first into the second and
> subsequent boxes. This is a standard process for practically all
> multi-column magazines, books and news layouts. It is especially
> valuable for column layouts where the information is dynamic and
> variable in length and therefore cannot be manually balanced. This is
> not something that can be solved server-side since the actual flow is
> dependent on user style-sheets, viewport and font-size.
>
>
>  I agree that this would be a useful feature for the Web platform. However,
> I believe the CSS working group is a better venue for exploring such
> options. I recommend forwarding your proposal to www-style at w3.org.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080801/bc0b01e5/attachment.htm>

From jackalmage at gmail.com  Fri Aug  1 08:00:13 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 1 Aug 2008 10:00:13 -0500
Subject: [whatwg] Joined blocks
In-Reply-To: <680cacd10808010528y3d9e10e9pcee2c7b4848b736f@mail.gmail.com>
References: <489297CA.9050902@arc.net.au>
	<Pine.LNX.4.62.0808010522070.3295@hixie.dreamhostps.com>
	<4892A08F.1050707@arc.net.au>
	<680cacd10808010528y3d9e10e9pcee2c7b4848b736f@mail.gmail.com>
Message-ID: <dd0fbad0808010800u2ba93f76g2f6ef5d9def7d085@mail.gmail.com>

On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett
<russell.leggett at gmail.com>wrote:

> For what it's worth, Shannon, I totally agree with you. Not only is this
> something I have been wanted for a long time, but I think it belongs in the
> html. It's one thing if you just want columns, which is being covered here:
> http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but there
> are times when the joined blocks are more remote and distinctly not columns,
> requiring the extra markup to control where it must join to. However, while
> useful for complex layouts, this is definitely the much smaller use case. I
> think it would make a great addition, but I suppose people have to have
> priorities! ;)
> -Russ
>

This is definitely and distinctly a CSS issue, not a HTML one.  The fact
that the contents of an element flow into another box elsewhere in the page
has nothing to do with the underlying structure of the data - it's still a
single cohesive element, and thus in html it would be marked up exactly as
normal.  You just happen to be displaying it differently.

As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of
dynamic columns, which will be the most common need for this sort of thing.
However, it's certainly reasonable that one would want more than that, to
allow the contents of an element to flow to an arbitrary location elsewhere
on the page.  I could have sworn there was a flow-to property proposed in
one of the working drafts, but I couldn't find it, so it's possible it only
existed in my fevered imagination (it's also possible I was misremembering
the "named flows" feature in Generated Content for Paged Media [1]).  A
limited form of this property exists in the Paged Media section of the
Template Layout module [2], where you can specify a template that spans
across several pages.  If the contents of a slot would overflow, it instead
forces a page-break within the slot and flows onto the next page, filling
the slot of the same name.

I've got some ideas in this regard, but we should move it to the CSS list,
www-style at w3.org.

~TJ

[1] http://www.w3.org/TR/css3-gcpm/#named1
[2] http://www.w3.org/TR/css3-layout/#templates
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080801/b4515ad7/attachment.htm>

From h.iverson at gmail.com  Fri Aug  1 13:39:45 2008
From: h.iverson at gmail.com (Harlan Iverson)
Date: Fri, 1 Aug 2008 15:39:45 -0500
Subject: [whatwg] maintaining WebSocket connections between page loads
Message-ID: <25097ca30808011339u7fa2c658ta9ade0abd16b05c0@mail.gmail.com>

Hello,

I am an implementor of BOSH and interested in WebSockets as future option
for browser based XMPP connections. I think a useful feature of BOSH is the
ability to send a pause request to the server, which effectively increases
the amount of time that can elapse before it considers a client timed out; a
client then resumes by making a normal request with the same session ID and
the request ID incremented as usual. This is useful/needed because BOSH is a
sequenced protocol. Importantly, it enables a use case of maintaining a
'persistent' connection between page loads.

Is there any equivalent mechanism in WebSockets to produce a 'persistent'
connection between page loads? Combined with sessionStorage this would be
very useful for an application such as Facebook Chat.

My thought is something like this:

window.addEventListener( "load", function() {
  if( sessionStorage.resumeToken != undefined ) {
    // this part is sketchy...
    try {
      con = new WebSocket( sessionStorage.resumeToken );
    } catch(e) {
      // too much time elapsed, invalid token
      con = new WebSocket( "ws://..." );
    }
  } else {
    con = new WebSocket( "ws://..." );
  }
}, false );


window.addEventListener( "unload", function() {
  // timeout could be defined by UA, and connection closes after that time
  sessionStorage.resumeToken = con.pause();
}, false );

Personally I'm not a fan of the WebSocket constructor initiating the
connection immediately, but I'm sure there are reasons for it being like
that. My preference would be to have connect and resume methods to
complement disconnect and pause, respectively.

I haven't thought through security implications of this sort of mechanism,
but at the very least it seems safe if tokens can only be used within the
same origin.

Best,

Harlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080801/2539a46a/attachment.htm>

From shannon at arc.net.au  Fri Aug  1 23:39:40 2008
From: shannon at arc.net.au (Shannon)
Date: Sat, 02 Aug 2008 16:39:40 +1000
Subject: [whatwg] Joined blocks
In-Reply-To: <dd0fbad0808010800u2ba93f76g2f6ef5d9def7d085@mail.gmail.com>
References: <489297CA.9050902@arc.net.au>	<Pine.LNX.4.62.0808010522070.3295@hixie.dreamhostps.com>	<4892A08F.1050707@arc.net.au>	<680cacd10808010528y3d9e10e9pcee2c7b4848b736f@mail.gmail.com>
	<dd0fbad0808010800u2ba93f76g2f6ef5d9def7d085@mail.gmail.com>
Message-ID: <4894012C.6030009@arc.net.au>

Tab Atkins Jr. wrote:
>
> This is definitely and distinctly a CSS issue, not a HTML one.  The 
> fact that the contents of an element flow into another box elsewhere 
> in the page has nothing to do with the underlying structure of the 
> data - it's still a single cohesive element, and thus in html it would 
> be marked up exactly as normal.  You just happen to be displaying it 
> differently.

The accuracy of your statement depends largely on whether the 
specification allows the content source to be defined across all joined 
blocks or only in the first. For example:

<div id="col1"><p>first para</p><p>second para</p></div>
... other unrelated markup ...
<div join="col1"><p>third para</p></div>

This markup would be common when the author is trying to support legacy 
or non-CSS browsers. The join attribute allows supporting agents to know 
that conceptually the third para follows on from the second. This might 
be useful for text or audio browsers to correctly concatenate related 
sections of text and for search engines trying to demarcate meaningful 
areas of the page. I strongly recommend that HTML5 define the join 
attribute and then allow the CSS group to define its behaviour in 
relation to visual styles. The 'class' attribute sets a precedent for 
this as it is defined in HTML despite generally having no implications 
beyond being a style hook. CSS cannot currently target elements except 
by their structural alignment to others and in many cases the blocks to 
be joined won't have a simple relationship. Targetting the id of joined 
elements with the 'join' attribute is still required regardless of how 
the CSS rules are implemented and this is the correct forum for new HTML 
attributes.

>
> I've got some ideas in this regard, but we should move it to the CSS 
> list, www-style at w3.org <mailto:www-style at w3.org>.

Already done. The topic is currently waiting on moderation.


Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080802/0c77a83d/attachment.htm>

From ian at hixie.ch  Sat Aug  2 00:01:23 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 2 Aug 2008 07:01:23 +0000 (UTC)
Subject: [whatwg] Joined blocks
In-Reply-To: <4894012C.6030009@arc.net.au>
References: <489297CA.9050902@arc.net.au>
	<Pine.LNX.4.62.0808010522070.3295@hixie.dreamhostps.com>
	<4892A08F.1050707@arc.net.au>
	<680cacd10808010528y3d9e10e9pcee2c7b4848b736f@mail.gmail.com>
	<dd0fbad0808010800u2ba93f76g2f6ef5d9def7d085@mail.gmail.com>
	<4894012C.6030009@arc.net.au>
Message-ID: <Pine.LNX.4.62.0808020657350.13029@hixie.dreamhostps.com>

On Sat, 2 Aug 2008, Shannon wrote:
> 
> The accuracy of your statement depends largely on whether the 
> specification allows the content source to be defined across all joined 
> blocks or only in the first. For example:
> 
> <div id="col1"><p>first para</p><p>second para</p></div>
> ... other unrelated markup ...
> <div join="col1"><p>third para</p></div>
> 
> This markup would be common when the author is trying to support legacy 
> or non-CSS browsers.

I agree that such markup would be common today, but I think that we should 
design the language with the intent to move past this style.

I would much, much rather see documents that <section> elements for each 
section, and then have the CSS split the section block into multiple 
boxes, than have the markup itself have each final resulting box split 
into different <div>s.

In the meantime, having blocks split into separate <div>s is the only way 
forward, but I think we can work around the accessibility problems of this 
by including links to the next part at the end of each block. I don't 
think we should add new features to handle this in HTML, I'd rather add 
them to CSS.

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


From gregory.houston at gmail.com  Sat Aug  2 01:23:45 2008
From: gregory.houston at gmail.com (Greg Houston)
Date: Sat, 2 Aug 2008 03:23:45 -0500
Subject: [whatwg] Separating Interface and Content
Message-ID: <29ae901a0808020123j55bdfaa9m9916e9c6946f3a8@mail.gmail.com>

Ten years ago we separated style from content. Pretty soon I think we
may need to start thinking more about separating the interface from
the content as well. We are still treating the web as a web of
documents when it is gradually becoming something more akin to a web
of applications. As an application developer the ratio of user
interface markup (divs within divs within divs) to content markup
(text and images and such) in each of my pages is gradually increasing
on the side of the interface. Just as removing style from HTML vastly
cleaned it up and gave an incredible boost to what we could do with
style, I imagine the same thing would be true if we separated the
interface from the content. The HTML would be cleaner and web
interface technology might be able to fully develop like CSS is doing.

Right now we tend to think of having a plain document that we then
warp into the shape of a user interface with CSS and a little
Javascript magic. But on the backend, for web applications at least,
that is not really what we are doing. We are making an interface and
then injecting content into its various parts and with AJAX updating
that content in those various parts individually. Seeing such a web
"page" as a single document rather than as an application with many
documents open within it is starting to make less and less sense.

I am aware of XUL, but am not very familiar with it, and I imagine not
a lot of developers are yet. My open question is, given the direction
the web seems to be going in, in developing HTML5 are we giving much
thought to eventually separating the interface from the content? Like
right now we are adding such elements as meter, progress, menu,
context menu and so forth to the specification when it seems they
might be better suited to a separate file. Five years from now are we
going to be giving people a hard time for sticking context menus right
into their HTML file the same way we now hassle people for using
tables to structure their document? "That guy is still putting
progress bars in his HTML markup." The progress element hasn't been
implemented yet, but I can already foresee it's demise.

Right now we load a document and then apply CSS to it. It might make
more sense to load the UI file first, then the UI's CSS, then the
document(s) and their CSS. Again, I am not familiar with how XUL
works. It may do something similar or do something a lot smarter.

Another way to think about this is the differences between your screen
CSS and print CSS. What do you hide in your print CSS? With each new
project it seems like I am setting increasingly longer lists of
elements to display: none in the print.css. It is all interface stuff
that does not specifically relate to what the viewer wants to print.
Generally almost all of my menus are hidden from print. Once context
menus are implemented they will certainly go on that list. So if I
feel that I need to hide something from being printed, should that
something be in the content file in the first place or would it be
better suited in an interface file? Should there be a way to print
only specific sections of an HTML file rather than the whole thing? If
so, how would you go about defining the different sections in the
markup? Maybe someone wants to print the help text in this div
container but is not interested in printing all the other widgets on
the page.

The CSS for my content (paragraphs, blockquotes, ...) is generally
rather small and has not really increased much in size over the years,
but the CSS for all the interface divs and unordered lists twisted
into crazy menuing systems grows month by month, from project to
project. I think this is a good indicator of the direction things are
going in.

- Greg Houston


From russell.leggett at gmail.com  Sat Aug  2 17:06:51 2008
From: russell.leggett at gmail.com (Russell Leggett)
Date: Sat, 2 Aug 2008 20:06:51 -0400
Subject: [whatwg] Joined blocks
In-Reply-To: <dd0fbad0808010800u2ba93f76g2f6ef5d9def7d085@mail.gmail.com>
References: <489297CA.9050902@arc.net.au>
	<Pine.LNX.4.62.0808010522070.3295@hixie.dreamhostps.com>
	<4892A08F.1050707@arc.net.au>
	<680cacd10808010528y3d9e10e9pcee2c7b4848b736f@mail.gmail.com>
	<dd0fbad0808010800u2ba93f76g2f6ef5d9def7d085@mail.gmail.com>
Message-ID: <680cacd10808021706r28879d0dk506a73c026c32448@mail.gmail.com>

I would be happy to have this as a purely css solution, but if multiple
container elements are required for the content to flow to, would you not
want that relationship in the html? We specify anchors, links, and
relationships in html, why not this? How the flow between blocks should
certainly be controlled by css - when to break between blocks etc., but
there a semantic and structural aspect as well.
-Russ

On Fri, Aug 1, 2008 at 11:00 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett <russell.leggett at gmail.com
> > wrote:
>
>> For what it's worth, Shannon, I totally agree with you. Not only is this
>> something I have been wanted for a long time, but I think it belongs in the
>> html. It's one thing if you just want columns, which is being covered here:
>> http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but
>> there are times when the joined blocks are more remote and distinctly not
>> columns, requiring the extra markup to control where it must join to.
>> However, while useful for complex layouts, this is definitely the much
>> smaller use case. I think it would make a great addition, but I suppose
>> people have to have priorities! ;)
>> -Russ
>>
>
> This is definitely and distinctly a CSS issue, not a HTML one.  The fact
> that the contents of an element flow into another box elsewhere in the page
> has nothing to do with the underlying structure of the data - it's still a
> single cohesive element, and thus in html it would be marked up exactly as
> normal.  You just happen to be displaying it differently.
>
> As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of
> dynamic columns, which will be the most common need for this sort of thing.
> However, it's certainly reasonable that one would want more than that, to
> allow the contents of an element to flow to an arbitrary location elsewhere
> on the page.  I could have sworn there was a flow-to property proposed in
> one of the working drafts, but I couldn't find it, so it's possible it only
> existed in my fevered imagination (it's also possible I was misremembering
> the "named flows" feature in Generated Content for Paged Media [1]).  A
> limited form of this property exists in the Paged Media section of the
> Template Layout module [2], where you can specify a template that spans
> across several pages.  If the contents of a slot would overflow, it instead
> forces a page-break within the slot and flows onto the next page, filling
> the slot of the same name.
>
> I've got some ideas in this regard, but we should move it to the CSS list,
> www-style at w3.org.
>
> ~TJ
>
> [1] http://www.w3.org/TR/css3-gcpm/#named1
> [2] http://www.w3.org/TR/css3-layout/#templates
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080802/4d5a5511/attachment.htm>

From russell.leggett at gmail.com  Sat Aug  2 17:10:44 2008
From: russell.leggett at gmail.com (Russell Leggett)
Date: Sat, 2 Aug 2008 20:10:44 -0400
Subject: [whatwg] Joined blocks
In-Reply-To: <680cacd10808021706r28879d0dk506a73c026c32448@mail.gmail.com>
References: <489297CA.9050902@arc.net.au>
	<Pine.LNX.4.62.0808010522070.3295@hixie.dreamhostps.com>
	<4892A08F.1050707@arc.net.au>
	<680cacd10808010528y3d9e10e9pcee2c7b4848b736f@mail.gmail.com>
	<dd0fbad0808010800u2ba93f76g2f6ef5d9def7d085@mail.gmail.com>
	<680cacd10808021706r28879d0dk506a73c026c32448@mail.gmail.com>
Message-ID: <680cacd10808021710s1a6c2c06he1e66b00cf1c8b98@mail.gmail.com>

Ignore my last statement. It was a draft I wrote before reading Ian's
response. If he has something in mind to get the same thing accomplished
without adding extra tags, all the better.

On Sat, Aug 2, 2008 at 8:06 PM, Russell Leggett
<russell.leggett at gmail.com>wrote:

> I would be happy to have this as a purely css solution, but if multiple
> container elements are required for the content to flow to, would you not
> want that relationship in the html? We specify anchors, links, and
> relationships in html, why not this? How the flow between blocks should
> certainly be controlled by css - when to break between blocks etc., but
> there a semantic and structural aspect as well.
> -Russ
>
>
> On Fri, Aug 1, 2008 at 11:00 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
>
>> On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett <
>> russell.leggett at gmail.com> wrote:
>>
>>> For what it's worth, Shannon, I totally agree with you. Not only is this
>>> something I have been wanted for a long time, but I think it belongs in the
>>> html. It's one thing if you just want columns, which is being covered here:
>>> http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but
>>> there are times when the joined blocks are more remote and distinctly not
>>> columns, requiring the extra markup to control where it must join to.
>>> However, while useful for complex layouts, this is definitely the much
>>> smaller use case. I think it would make a great addition, but I suppose
>>> people have to have priorities! ;)
>>> -Russ
>>>
>>
>> This is definitely and distinctly a CSS issue, not a HTML one.  The fact
>> that the contents of an element flow into another box elsewhere in the page
>> has nothing to do with the underlying structure of the data - it's still a
>> single cohesive element, and thus in html it would be marked up exactly as
>> normal.  You just happen to be displaying it differently.
>>
>> As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of
>> dynamic columns, which will be the most common need for this sort of thing.
>> However, it's certainly reasonable that one would want more than that, to
>> allow the contents of an element to flow to an arbitrary location elsewhere
>> on the page.  I could have sworn there was a flow-to property proposed in
>> one of the working drafts, but I couldn't find it, so it's possible it only
>> existed in my fevered imagination (it's also possible I was misremembering
>> the "named flows" feature in Generated Content for Paged Media [1]).  A
>> limited form of this property exists in the Paged Media section of the
>> Template Layout module [2], where you can specify a template that spans
>> across several pages.  If the contents of a slot would overflow, it instead
>> forces a page-break within the slot and flows onto the next page, filling
>> the slot of the same name.
>>
>> I've got some ideas in this regard, but we should move it to the CSS list,
>> www-style at w3.org.
>>
>> ~TJ
>>
>> [1] http://www.w3.org/TR/css3-gcpm/#named1
>> [2] http://www.w3.org/TR/css3-layout/#templates
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080802/4cf0f4b5/attachment.htm>

From timeless at gmail.com  Sun Aug  3 03:35:32 2008
From: timeless at gmail.com (timeless)
Date: Sun, 3 Aug 2008 03:35:32 -0700
Subject: [whatwg] Signatures
In-Reply-To: <3586624e0807310433ydb1f689g6648bb362ef96757@mail.gmail.com>
References: <01cd01c6cf2d$28710010$82c5a8c0@arport2v>
	<3586624e0611010022kcac5aa1ld5921705d2d31067@mail.gmail.com>
	<op.tibwjcwb1h6og4@feldgendler.plesk.ru>
	<005e01c6fe58$c1e64a70$82c5a8c0@arport2v>
	<op.tidtpgxi1h6og4@feldgendler.plesk.ru>
	<20061102095551.GA4979@malware>
	<op.tifdqcl91h6og4@feldgendler.plesk.ru>
	<Pine.LNX.4.62.0807310116560.3299@hixie.dreamhostps.com>
	<3586624e0807310319k35241ffdr8c8c09dfc6ab9b35@mail.gmail.com>
	<3586624e0807310433ydb1f689g6648bb362ef96757@mail.gmail.com>
Message-ID: <26b395e60808030335o5ef68b9bg6dd1e64bd2696263@mail.gmail.com>

On Thu, Jul 31, 2008 at 4:33 AM, Channy Yun <channy at creation.net> wrote:
> The national PKI system has own certificate issuing process to citizen with
> face-to-face meeting. And it requires to "submit ones client certificate"
> for e-government and financial transaction with "digital signature" per each
> signature.

could you please provide example urls for this?

I'm not quite sure I understand why standard certificate challenges
are insufficient for this.

oddly, my own bank does something like this w/ a java applet, except
if i pretend to be a mobile client, it waves this stupid requirement.

> "submit ones client certificate" is traditional SSL authentication and
> "digital signature" is new requirement.

> In fact, ActiveX and Java plugin are needed for digital signature.

> If we can submit returned encrypted message in form via SSL, the technical
> requirement is sufficient for all national PKI system. Especially, Camellia
> (Japanese and European official cryptographic algorithm) already implemented
> in Open SSL for web browsers. Most of them is ready.

http://boblord.livejournal.com/16968.html

It seems NSS supports it too.

> server via SSL, web server can decrypt form data signed by client
> certificate and check validation and insured transaction by each country's
> law.

urls for these "laws" would be appreciated.


From christoph.paeper at crissov.de  Sun Aug  3 05:35:03 2008
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Sun, 3 Aug 2008 14:35:03 +0200
Subject: [whatwg] Application deployment
In-Reply-To: <11e306600807280903r529a4b3el9f6bd235eac5208f@mail.gmail.com>
References: <9A4E588F5D734EC7A0BB719BCD4C9C71@POCZTOWIEC>
	<C4B3483D.67E8%adrian.sutton@ephox.com>
	<11e306600807280903r529a4b3el9f6bd235eac5208f@mail.gmail.com>
Message-ID: <B3123FEE-FEFC-4078-8DF9-3C4E6C93D65C@crissov.de>

Robert O'Callahan:
>> http://www.example.com/site.jar#/path/inside/foo.html#heading1
>
> URL parsing doesn't support multiple fragment identifiers

I'm surprised that RFC 3986 (like 2396) makes '#' reserved in  
fragment identifiers (only '[]', too). The fragment ID is terminated  
only by the end of the URI after all. The one reason for disallowing  
'#' I can think of is tokenization starting from the end of the  
string, but as far as I know that may fail for other parts.

   fragment    = *( pchar / "/" / "?" )
   pchar       = unreserved / pct-encoded / sub-delims / ":" / "@"
   unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
   pct-encoded = "%" HEXDIG HEXDIG
   sub-delims  = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" /  
"," / ";" / "="

<http://www.example.com/site.jar#/path/inside/foo.html%23heading1>  
should work fine, though.

-----8<--------8<--------8<--------8<--------8<--------8<--------8<-----

I'm also surprised that RFC 3986 (unlike 2396) misses a section on US- 
ASCII characters deliberately excluded, i.e. <C0> and '"<>{}|\`^ ',  
previously also '[]'. I think

   reserved    = gen-delims / sub-delims
   gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
   ...

should be something like

   reserved    = delims / enclosing / unwise / controls
   delims      = gen-delims / sub-delims
   enclosing   = DQUOTE / "<" / ">" / SP
   unwise      = "{" / "}" / "|" / "\" / "`" / "^"
   controls    = %x00-1F / %x7F
   ...


From christoph.paeper at crissov.de  Sun Aug  3 05:49:25 2008
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Sun, 3 Aug 2008 14:49:25 +0200
Subject: [whatwg] Joined blocks
In-Reply-To: <489297CA.9050902@arc.net.au>
References: <489297CA.9050902@arc.net.au>
Message-ID: <3C9AB595-957C-4066-9B6F-A7694A75964E@crissov.de>

Shannon:

> Something I think is really missing from HTML is "linked text"

Linked or continued (numbered, ordered) lists have been dicussed here  
a while ago, and were rejected if I remember correctly. They made a  
stronger use case than generic continued texts in my opinion,  
although both could be done the same way, i.e. with IDs and some sort  
of |continue| attribute.


From jonas at sicking.cc  Sun Aug  3 13:47:24 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Sun, 03 Aug 2008 13:47:24 -0700
Subject: [whatwg] pushState
In-Reply-To: <Pine.LNX.4.62.0807292009520.30692@hixie.dreamhostps.com>
References: <4889BFDF.7010003@sicking.cc>
	<Pine.LNX.4.62.0807251847070.10848@hixie.dreamhostps.com>
	<488A496E.70604@sicking.cc>
	<Pine.LNX.4.62.0807252154320.10848@hixie.dreamhostps.com>
	<488A6154.9080701@sicking.cc>
	<Pine.LNX.4.62.0807252334590.10848@hixie.dreamhostps.com>
	<488ABBDC.5030308@sicking.cc> <488C7C25.7070003@sicking.cc>
	<Pine.LNX.4.62.0807282229580.10848@hixie.dreamhostps.com>
	<488F57E4.9070508@sicking.cc>
	<Pine.LNX.4.62.0807292009520.30692@hixie.dreamhostps.com>
Message-ID: <4896195C.2040101@sicking.cc>

Ian Hickson wrote:
> On Tue, 29 Jul 2008, Jonas Sicking wrote:
>> I'll check with the ECMA Script folks, but this one might be an 
>> alternative to link to:
>>
>> http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
>>
>> State that the object passed as 'data' is passed to JSON.parse with the 
>> second argument not specified. Any exception thrown is forwarded out to 
>> the caller of pushState as usual.
> 
> Interesting, thanks. Doesn't really define it clearly though. :-(
> 
> 
>>>> When entering a SH state for which a Document has been destroyed, we 
>>>> load the URL associated with that SH entry. After the 'load' event 
>>>> for the Document has fired, and if a data object was provided in the 
>>>> pushState call for the SH entry, we fire a PopStateEvent event 
>>>> containing the data stored for the object.
>>> How would this work with bookmarking?
>> Just as specified (or at least intended) in the spec right now.
>>
>> Say that the user starts on page1.html
>>
>> <bookmark>   (bookmarks page1.html)
>> pushState("title", "data")
>> <bookmark>   (bookmarks page1.html)
>> pushState("title", "data", "page2.html")
>> <bookmark>   (bookmarks page2.html)
>>
>> Additionally, a UA is free to add the ability to store the data 
>> parameter in its bookmark storage. For example firefox under some 
>> circumstances flags URIs in the bookmark store as POST URIs, i.e. they 
>> should be fetched with POST rather than GET (this is specifically for 
>> search engine bookmarks). Similarly the data can be stored alongside the 
>> URI for the bookmark, however this is optional, just like the fastback 
>> cache.
> 
> The problem I have with this is that it increases the number of possible 
> user-visible behaviours and failure scenarios:
> 
>  - same Document, script knows how to handle data.
>  - different Document, script knows how to handle data.
>  - same URL, different Document, data ignored.
>  - different URL, different Document, script knows how to handle data,
>    but copying URL fails to work as expected.
>  - different URL, different Document, data ignored.

I'm actually more worried about the URL thing causing bugs than the data 
thing.

* To avoid bad user experience behavior the site has to send almost
   exactly the same markup for both URLs, i.e. both for the page that
   called pushState, and for the page served for the URL in the URL
   argument in the pushState call.
* Entering a URL that is results in a 404 (or any other non-succcess
   value). This works fine when pushState is called, but fails on reload.

This applies no matter which solution we choose for the data parameter.

Additionally, if we allow the data parameter to be preserved across 
Document recreations there is also:
* Both URLs have to react the same way when a popstate event is fired.

However all these can be seen as variants of the first bullet. If the 
page serves the same markup it wouldn't be a 404, and it should deal 
fine with the popstate event.

In other words. If a page uses pushState to transition from
https://bugzilla.mozilla.org/show_bug.cgi?id=123456
to
https://bugzilla.mozilla.org/show_bug.cgi?id=321321
then things are likely to work fine. However if a page tries to use 
pushState to transition between
https://bugzilla.mozilla.org/show_bug.cgi?id=123456
and
https://bugzilla.mozilla.org/query.cgi
then the risk of something going wrong is quite big. I think this will 
be true no matter if the data parameter is supported or not.

So I think we should either drop the URL argument entirely and say that 
URL transitions are too risky. Or we should leave the spec as is (but 
require that data is serializeable) and just encourage people not to 
transition between wildly different pages.

Personally I think keeping the URL is fine. We can never entirely 
prevent pages from having bugs. But instead encourage the safe 
transitions, and always use safe-looking transitions in examples in the 
spec.

/ Jonas


From bijumaillist at gmail.com  Sun Aug  3 21:19:48 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Mon, 4 Aug 2008 00:19:48 -0400
Subject: [whatwg] VIDEO tag height/width best fit
Message-ID: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>

I apologize if I did not understood
http://www.whatwg.org/specs/web-apps/current-work/#video

I see a situation where we want to specify the height and width of the
BOX in which a video need to be displayed. And while writing HTML code
we dont know the height/width of the video. But when playing we want
the video to be displayed with maximum size which can fit in the BOX
without loosing the aspect ratio.

After reading the <video> tag specification I dont see a way to
achieve this with out javascript code.

We should have one more attribute to tell how to "fit" the image/video

== "fit" attribute values ===
* center          - if it is small keep at center
* stretch         - stretch/skew height and width to fit
* stretch-height  - stretch/skew height only to fit,
                    adjust width to maintain aspect ratio.
* stretch-width   - stretch/skew width only to fit,
                    adjust height to maintain aspect ratio.
* stretch-best    - stretch/skew height or width to maximum
                    so that other will fit in
                    and maintain aspect ratio.

May be we can also have a "tile" option

This problem also exist for <img> tag.


From philipj at opera.com  Sun Aug  3 22:35:52 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 04 Aug 2008 12:35:52 +0700
Subject: [whatwg] VIDEO tag height/width best fit
In-Reply-To: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
References: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
Message-ID: <1217828152.23606.4.camel@localhost>

Video is automatically scaled to fit inside its "box" while maintaining
the correct aspect ratio.

Philip

On Mon, 2008-08-04 at 00:19 -0400, Biju Gm at il wrote:
> I apologize if I did not understood
> http://www.whatwg.org/specs/web-apps/current-work/#video
> 
> I see a situation where we want to specify the height and width of the
> BOX in which a video need to be displayed. And while writing HTML code
> we dont know the height/width of the video. But when playing we want
> the video to be displayed with maximum size which can fit in the BOX
> without loosing the aspect ratio.
> 
> After reading the <video> tag specification I dont see a way to
> achieve this with out javascript code.
> 
> We should have one more attribute to tell how to "fit" the image/video
> 
> == "fit" attribute values ===
> * center          - if it is small keep at center
> * stretch         - stretch/skew height and width to fit
> * stretch-height  - stretch/skew height only to fit,
>                     adjust width to maintain aspect ratio.
> * stretch-width   - stretch/skew width only to fit,
>                     adjust height to maintain aspect ratio.
> * stretch-best    - stretch/skew height or width to maximum
>                     so that other will fit in
>                     and maintain aspect ratio.
> 
> May be we can also have a "tile" option
> 
> This problem also exist for <img> tag.
-- 
Philip J?genstedt
Opera Software



From ian at hixie.ch  Mon Aug  4 03:17:43 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 4 Aug 2008 10:17:43 +0000 (UTC)
Subject: [whatwg] Images and alternative text
In-Reply-To: <20080421093043.GA20100@stripey.com>
References: <480BEB65.9000207@arc.net.au> <480C3126.9020905@googlemail.com>
	<480C38A6.6060700@arc.net.au> <480C4947.1070408@googlemail.com>
	<480C51EC.1030503@arc.net.au> <480BEB65.9000207@arc.net.au>
	<480C3126.9020905@googlemail.com> <480C38A6.6060700@arc.net.au>
	<480BEB65.9000207@arc.net.au> <20080421093043.GA20100@stripey.com>
Message-ID: <Pine.LNX.4.62.0808040817210.13400@hixie.dreamhostps.com>

On Fri, 18 Apr 2008, Bill Mason wrote:
>
> The example was a case of a hacker who replaces the Google logo on 
> google.com with an image only containing the text "WE HACKED YOUR 
> SERVERS".  We assume the hacker cares enough about accessibility to set 
> the alt attribute to the same text.
> 
> The new image would appear to fall into the "phrase or paragraph with an 
> alternative graphical representation" requirement. The spec's current 
> language that the image is "something [that] can be more clearly stated 
> in graphical form" something doesn't fit well because this hypothetical 
> image is not 'more clear' -- it's equivalent.

Added a section for this case.


On Fri, 18 Apr 2008, Philip Taylor wrote:
>
> I believe the company logo case is also unclear in the spec. See e.g. 
> http://www.google.com/ (when it's not a special day) - the image is 
> simply the word "Google" (as a page heading, so it should probably be in 
> <h1>), so common sense says it should have alt="Google". The spec phrase 
> "Icons: a short phrase or label with an alternative graphical 
> representation" sounds like it might apply here, but none of the cases 
> in that section seems to work: in particular, I don't think "the logo is 
> being used to represent the entity" would apply, because the purpose of 
> the image is not to represent the entity (as it would be in e.g. a list 
> of search engines that shows small images of all their logos so you can 
> choose your favourite), and instead its purpose is to tell users what 
> site they are on (and to make it look prettier). It should be made 
> clearer whether the existing case does or does not apply. If it does not 
> apply, it should be made clear what alt text to use instead.

I've added text to clarify this case.


> What should happen for 'tracker' images? (i.e. <img
> src="http://evil.google.com/user-track.php?site=97519340" width="1"
> height="1" alt="???">)

Added a section.


> [...] some versions of Google (depending on cookies, IP address,
> etc) implement the "Google" logo as four separate images [...]

Added a section.


> And as a more general point, the spec provides a list of cases for using 
> img (and how to use alt for those cases), but this list will never be 
> complete (especially since the case matches are all subjective and open 
> to interpretation in multiple ways), so there needs to be a default case 
> statement for images where the author doesn't think any of the specific 
> requirements applies.

I'd like to try making it comprehensive first. Am I missing any other 
cases?


On Sat, 19 Apr 2008, Simon Pieters wrote:
> [counter images]
>
> Moreover, such images often use width=0 height=0, but that's invalid per
> HTML5, which seems a bit unhelpful.

Those images aren't representing images, so they seem invalid to me. If we 
want to support this case it seems like there have got to be better ways 
to do it.


> [slicing]
>
> For instance it would be reasonable to use two images -- a filled star and an
> unfilled star -- to represent a rating of something:
> 
>    <p>Rating: <img src=1><img src=1><img src=1><img src=0><img src=0></p>
> 
> You'd want the text version to be:
> 
>    Rating: 3/5
> 
> Hence:
> 
>    <p>Rating: <img src=1 alt=3/5><img src=1 alt><img src=1 alt><img
>    src=0 alt><img src=0 alt></p>

Added an example like this to the spec.


On Sat, 19 Apr 2008, Edward O'Connor wrote:
> 
> HTML5 provides the <meter> element for this use case.
> 
>     <p>Rating: <meter>3/5</meter></p>

I've used <meter> in the example, to hint at this.


On Sun, 20 Apr 2008, Shannon wrote:
>
> What about this as a possible solution?
> 
> <img src="part1.png" altgroup="rating">
> <img src="part2.png" altgroup="rating">
> <img src="part3.png" altgroup="rating">
> <altgroup id="rating" value="3/5">
> 
> I don't think this would raise any serious implementation issues as the 
> logic is quite simple; If all elements in an altgroup are unavailable 
> then display the value of the altgroup tag. The alt attribute would then 
> be optional where altgroup is defined but required in all other cases.

This seems over-engineered for such a simple problem.


On Mon, 21 Apr 2008, Shannon wrote:
> 
> Yes this proposal requires a new tag and attribute but that is a lot 
> less disruptive than giving designers an easy way to opt out of 
> accessibility (while still claiming compliance). I'd like to believe 
> that designers would do the right thing without being told but I know 
> for a fact most of them don't. The alt requirement for w3c validation is 
> what got me using them in the first place so I know it's having some 
> effect.

The spec doesn't allow them to claim compliance without being accessible 
here.


On Mon, 21 Apr 2008, Shannon wrote:
>
> Not the same thing at all. There is no direct association between the 
> elements so there is no way a validator or browser would know the 
> difference between a missing/empty alt and an optional one - thus making 
> ALL use of alt optional as far as formal validation is concerned.

Well, similarly there's no way for the validator to know if the alt="" 
attribute is allowed to be empty, or is allowed to say "Goat", or 
whatever. There's a limit to what validators can do.


On Mon, 21 Apr 2008, Shannon wrote:
>
> How can <img alt> or <img alt=""> not be related to making alt optional?
>
> Both represent a total lack of information with no explicit relationship 
> to any other element. There is no way a parser can resolve whether this 
> information is supplied previously or not. If the parser can't tell then 
> it can't validate the alt requirement - thereby mandating that alt (that 
> is the text, not the empty attribute) be optional for a conforming 
> document (as far as a validator knows anyway). Once alt text becomes 
> optional then it is likely that many designers/templates/wysiwyg 
> applications will simply insert alt="" into every image to pass 
> validation without consideration for blind users. It is this situation I 
> am trying to avoid. A valid document should provide valid alt 
> information, not empty ones. An altgroup supports this - empty alt tags 
> do not.

There are a lot of images that need to say alt="" (with the empty value) 
to get optimal accessibility, e.g. decorative images, images redundant 
with surrounding text, etc. Even in HTML4, alt="" with the empty value is 
allowed in certain cases.


On Mon, 21 Apr 2008, Smylers wrote:
> 
> But it's _also_ what HTML 5 is trying to lessen.  One way to improve the 
> situation is for people (and tools) _not_ to unthinkingly insert alt="" 
> in situations where that _isn't_ appropriate; where it's impossible to 
> know what appropriate alt text is then it's better to leave it out 
> entirely, so as to distinguish these cases.

Right now, in cases where it's impossible to know what appropriate alt 
text is, the author (or editor) should use alt="{image}" or some such.

-- 
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  4 03:58:45 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 4 Aug 2008 10:58:45 +0000 (UTC)
Subject: [whatwg] VIDEO tag height/width best fit
In-Reply-To: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
References: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808041056360.13029@hixie.dreamhostps.com>

On Mon, 4 Aug 2008, Biju Gm at il wrote:
>
> I apologize if I did not understood
> http://www.whatwg.org/specs/web-apps/current-work/#video
> 
> I see a situation where we want to specify the height and width of the 
> BOX in which a video need to be displayed. And while writing HTML code 
> we dont know the height/width of the video. But when playing we want the 
> video to be displayed with maximum size which can fit in the BOX without 
> loosing the aspect ratio.

It's automatically like this.

# Video content should be rendered inside the element's playback area such 
# that the video content is shown centered in the playback area at the 
# largest possible size that fits completely within it, with the video 
# content's adjusted aspect ratio being preserved.
 -- http://www.whatwg.org/specs/web-apps/current-work/#video

Cheers,
-- 
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  4 02:08:59 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 04 Aug 2008 02:08:59 -0700
Subject: [whatwg] Proposal for a link attribute to replace <a href>
In-Reply-To: <Pine.LNX.4.62.0807301128510.29977@hixie.dreamhostps.com>
References: <9900645.1212458671611.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
	<Pine.LNX.4.62.0807301128510.29977@hixie.dreamhostps.com>
Message-ID: <4896C72B.3050909@sicking.cc>

Ian Hickson wrote:
> Every now and then, the issue of a global href="" attribute for all 
> elements comes up. There are many valid use cases for this, like being 
> able to make all cells in a table row act like a link, or making a banner 
> ad act like a single block of a link.
> 
> Unfortunately, I've been told over and over by implementers that a global 
> href="" is a bad idea, and at the end of the day, the implementors are the 
> ones who have the final say, so that's just a non-starter.

Which implementations have you heard this from? As far as mozilla goes 
we would have no technical problems implementing this.

The problems that I can see are of a more 'social' type. I.e. how to 
behave when two links are nested, or when a button is nested inside a 
link. Or how the event model interacts with the navigation action.

All these problems exist already, but might become more common if it was 
easier to sprinkle 'href' attributes throughout the DOM.

/ Jonas


From dhtmlkitchen at gmail.com  Mon Aug  4 10:46:43 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 4 Aug 2008 10:46:43 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
Message-ID: <c9e12660808041046m5f96b6f2qd929935714263b2b@mail.gmail.com>

I'm a little surprised at the lack of response here, so I'm replying
to myself here, just to keep this issue active.

I did a little more research and found that the misconception is more
common that I thought: DOM objects that have indexed properties are
often mistaken for arrays. This is the "misconception" that I found
documented in HTML5.

The following documents discuss DOM Collections using the term "Array":
 http://www.quirksmode.org/dom/w3c_core.html#t60
 http://www.quirksmode.org/dom/tests/attributesArray.html
 http://www.quirksmode.org/dom/tests/stylesheets.html
 http://ajaxian.com/archives/preloading-images-with-jquery#javascript-1
 http://jennifermadden.com/javascript/arraySimple.html
 http://httpunit.sourceforge.net/doc/javascript-support.html

Ian had politely asked me to post this information to the list.

Calling an HTMLCollection an array will mislead developers who don't
know the difference. It might also lead a reader to believe that the
author of the HTML specification deliberately used the word 'array'
and that "elements" is an array (not an HTMLCollection).

It seems that the only benefit in calling an HTMLCollection an array
is that 'array' is shorter to type.

Typing "HTMLCollection" is longer than typing "array" but it is misleading.

But that still leaves the other two issues. The first is the worst, I
think, because it relies on deprecated behavior and isn't very good
practice.

Garrett

On Tue, Jul 29, 2008 at 11:33 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> I took a brief look at the WF 2.0 document yesterday and found some
> serious misconceptions and examples of "programming by coincidence."
> These reflect very poorly on html5.
>
> The errors can be found on the link:
> http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
>
> Doc Bugs:
> 1) Treating a a form element as an HTMLCollection.
> 2) The use of - with - to augment the scope chain is not necessary.
> 3) Calling the "elements" HTMLCollection an "array"
>
> (1) The definition of HTMLFormElement does not have a specialized [[Get]]
> for element names (nor should there be, as this is known to be
> problematic). The example in the documetation depends on such behavior.
>
> (2) - with - augments the scope chain with the object. This is completely
> unnecessary here and will create problems if, for example, there is an
> element named "watch". It is a bad practice and I see this influence in the
> popular libraries.
>
> (3) There is no specification for a special [[Get]] for the "elements"
> HTMLCollection as a shortcut to "namedItem", either (though this would not
> seem to be a problem, and all implementations have supported this behavior
> for quite a long time). I did notice that the elements collection is
> mistakenly called an 'array'. This is a serious documentation mistake of
> the worst kind: The spreading of misinformation. It will continue influence
> the muddy knowledge that is so common among most developers who tend want
> to call "push" et c directly on that NodeList object (see the
> "dojo.NodeList" for details). The elements Collection should be called an
> HTMLCollection and this should be changed immediately.
>
> // WRONG
> document.forms[0].qty,
>
> The "elements" property is what the example should use:-
>
> // RIGHT.
> document.forms[0].elements.namedItem('qty');
> document.forms[0].elements.qty; // Access via custom get
>
> This avoids ambiguity when having a form that has an element named "name",
> for example. It becomes ambiguous as to whether the "form.name" refers to
> the element or the form's "name" attribute. Problems could also arise with
> "action", "length", "toString", "elements".
>
> -------------------------------------------------
> // (GS) Don't augment scope chain here.
> with (document.forms[0]) {
>
> // (GS) Don't treat a form as a collection.
> // Use the 'elements' colletion.
>  if (qty.validity.valueMissing) {
>    // the quantity control is required but not filled in
>  } else if (qty.validity.typeMismatch) {
>    // the quantity control is filled in, but it is not a number
>  }
> }
>
> And further down:-
>
> // (GS) Don't treat a form as a collection.
> // Use the 'elements' colletion.
> var myControl = document.forms[0].addr;
>
> if (myControl.value == 'a at b.c') {
>  myControl.setCustomValidity('You must enter your real address.');
> }
> -------------------------------------------------
> Fixed:
>
> var f = document.forms[0],
>    qv = f.elements.namedItem('qty').validity;
>
>  if (qv.valueMissing) {
>    // Value required but not filled in.
>  } else if (qv.typeMismatch) {
>    // Value filled in, but it is not a number.
>  }
> }
>
> var addErrInvalidMsg = 'You must enter your real address.';
> var addr = document.forms[0].elements.namedItem('addr');
> if (addr.value === 'a at b.c') {
>  addr.setCustomValidity(addErrInvalidMsg);
> }
>


From jonas at sicking.cc  Mon Aug  4 11:21:01 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 04 Aug 2008 11:21:01 -0700
Subject: [whatwg] Proposal for a link attribute to replace <a href>
In-Reply-To: <4896C72B.3050909@sicking.cc>
References: <9900645.1212458671611.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>	<Pine.LNX.4.62.0807301128510.29977@hixie.dreamhostps.com>
	<4896C72B.3050909@sicking.cc>
Message-ID: <4897488D.4010109@sicking.cc>

Jonas Sicking wrote:
> Ian Hickson wrote:
>> Every now and then, the issue of a global href="" attribute for all 
>> elements comes up. There are many valid use cases for this, like being 
>> able to make all cells in a table row act like a link, or making a 
>> banner ad act like a single block of a link.
>>
>> Unfortunately, I've been told over and over by implementers that a 
>> global href="" is a bad idea, and at the end of the day, the 
>> implementors are the ones who have the final say, so that's just a 
>> non-starter.
> 
> Which implementations have you heard this from? As far as mozilla goes 
> we would have no technical problems implementing this.
> 
> The problems that I can see are of a more 'social' type. I.e. how to 
> behave when two links are nested, or when a button is nested inside a 
> link. Or how the event model interacts with the navigation action.
> 
> All these problems exist already, but might become more common if it was 
> easier to sprinkle 'href' attributes throughout the DOM.

Actually, I think I spoke a bit too broadly.

Just adding support for the 'href' content attribute, and the ability to 
click and style those elements just like you can an <a> today should be 
easy, at least in gecko.

This is modulo the issue of what happens with the elements that already 
have a 'href' attribute with a different meaning (i.e. other than making 
the element into a clickable link), such as <base> and <link>

However if we want to add support for the long list of JS attributes 
that exist on <a> elements today on each and every HTML element I 
suspect that is going to get messier. Especially considering the 
collisions for <base> and <link>. What would myBaseElement.accessKey do? 
And is myDivElement.protocol really intuitive what it does?

However these are problems that can be solved on a spec level IMHO.

/ Jonas


From simonp at opera.com  Mon Aug  4 13:09:43 2008
From: simonp at opera.com (Simon Pieters)
Date: Mon, 04 Aug 2008 22:09:43 +0200
Subject: [whatwg] Proposal for a link attribute to replace <a href>
In-Reply-To: <4897488D.4010109@sicking.cc>
References: <9900645.1212458671611.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
	<Pine.LNX.4.62.0807301128510.29977@hixie.dreamhostps.com>
	<4896C72B.3050909@sicking.cc> <4897488D.4010109@sicking.cc>
Message-ID: <op.ufdoyhkdidj3kv@hp-a0a83fcd39d2.belkin>

On Mon, 04 Aug 2008 20:21:01 +0200, Jonas Sicking <jonas at sicking.cc> wrote:

> However if we want to add support for the long list of JS attributes  
> that exist on <a> elements today on each and every HTML element I  
> suspect that is going to get messier. Especially considering the  
> collisions for <base> and <link>. What would myBaseElement.accessKey do?  
> And is myDivElement.protocol really intuitive what it does?

Also it would quite likely clash with existing content that expects that  
those attributes don't exist on e.g. divs. (Opera has had problems with  
some new DOM attributes in WF2 due to legacy.)

-- 
Simon Pieters
Opera Software


From aa at google.com  Mon Aug  4 13:13:24 2008
From: aa at google.com (Aaron Boodman)
Date: Mon, 4 Aug 2008 13:13:24 -0700
Subject: [whatwg] Aborting an in-progress database transaction
Message-ID: <278fd46c0808041313g26f2e174v28ce4a26451866ee@mail.gmail.com>

It seems like you need a way to abort an in-progress transaction. An
easy way to do this would be to add an abort() method to
SQLTransaction.

Thoughts?

- a


From aa at google.com  Mon Aug  4 13:24:08 2008
From: aa at google.com (Aaron Boodman)
Date: Mon, 4 Aug 2008 13:24:08 -0700
Subject: [whatwg] database transactions should be serialized
Message-ID: <278fd46c0808041324i63b2c93eofc32f8b5a58bdefc@mail.gmail.com>

I think this has been covered in passing before, but I wanted to bring
it up explicitly.

Currently, the database API has an error code for the situation where
you open a transaction for read, then try to write but the database is
locked.

I think that the spec should at least suggest, but perhaps require,
implementors to serialize access to a single database to prevent this
from happening. Without this, developers must wrap every single write
attempt in error handling and retry if a lock error occurs.

It seems likely that developers will forget to do this and it will be
a significant pain point with the API. Applications will seem to work,
but then mysteriously fail in production when users have multiple
copies of the application open.

Even if the developer adds retry logic, it is easy for a page to get
starved by another page.

Serializing access would prevent all these problems at the cost of
read concurrency, which I think is OK for the first version of this
API. A future version of the API could add the concept of "read
transactions" which would allow concurrency, but would fail
immediately when you try to write with them.

- a


From ebutler at mozilla.com  Mon Aug  4 14:29:12 2008
From: ebutler at mozilla.com (Eric Butler)
Date: Mon, 04 Aug 2008 14:29:12 -0700
Subject: [whatwg] <canvas> shadow compositing oddities
In-Reply-To: <ea09c0d10807290629i72261665n6c6b8efc47d25277@mail.gmail.com>
References: <488CC721.5020903@mozilla.com>
	<ea09c0d10807290629i72261665n6c6b8efc47d25277@mail.gmail.com>
Message-ID: <489774A8.3050205@mozilla.com>

Philip Taylor wrote:
> On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler <ebutler at mozilla.com> wrote:
>   
>> [...]
>> However, following the spec's drawing model, there are a few operators that
>> behave rather unexpectedly if the shadow color is left at its default value.
>> For instance, since A in B always results in transparency if either A or B
>> is fully transparent, source-in will always simply clear the clipping region
>> to fully transparent no matter what the source and destination are.
>>     
>
> Oops - that does seem quite broken. (It's probably my fault - I didn't
> notice that problem when I was looking at how shadows should work...

The need to be able to disable shadows explicitly seems clear. But I 
also believe that the spec should provide
for a means to disable normal drawing and only draw shadows to increase 
the usefulness of shadows.

As it stands, if you draw with shadows, you'll end up getting some of 
the shadows drawn on top of some of
the actual shapes. But perhaps the developer wants to have all shadows 
behind all shapes for a particular set
of shapes. The only way to accomplish that would be to create a second 
canvas, do all the drawing without
shadows on that, then draw the canvas with its shadow back to the 
original, which seems cumbersome
to use and is terribly inefficient.

It would be simpler if the user could simply turn on only shadows, do 
the drawing once, then turn on only
normal rendering and do the drawing again. You cannot simply set the 
fill/stroke style to transparent for
the same reason that it doesn't quite work for shadows. So I believe 
that the spec should provide for the
means to explicitly disable both shadows and normal drawing separately.

To that end, perhaps there could be an attribute which indicated what 
the current state of the drawing model
was: object only, shadow only, or objects and shadows, defaulting to 
drawing only objects. This would create
more expected output for all composite operators, and would allow 
developers to do some more complex
tricks with shadows.

Oliver Hunt wrote:
>
> We could special case opacity 0, with 0,0 offset, and 0 blur radius as 
> being a "do not draw shadow" flag perhaps?
>
This wouldn't solve the problem of disabling normal drawing and doesn't 
seem like a very clean API to me.
A more explicit attribute seems better in my opinion.

While it is true that having shadows and objects always in the drawing 
model can be hacked around when all but
certain uncommon composite operators are being used, it seems unclean to 
have to keep flipping the style back
and forth to hack around things. Furthermore, it is extremely difficult 
if not impossible to achieve certain effects
without the ability to modify the drawing model. So I believe such a 
means should be provided.

-Eric Butler


From t.broyer at gmail.com  Mon Aug  4 15:17:39 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Tue, 5 Aug 2008 00:17:39 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
Message-ID: <a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>

On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
>
> (3) There is no specification for a special [[Get]] for the "elements"
> HTMLCollection as a shortcut to "namedItem", either (though this would not
> seem to be a problem,

Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and I believe the "elements" property of HTMLFormElement is actually
an HTMLFormControlsCollection:
http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection

> and all implementations have supported this behavior for quite a long time).

Note that all implementations also supports the same behavior on
HTMLFormElement and HTMLDocument.

Otherwise, FWIW, I'm OK with what you're saying about the use of
with(...){...} (useless and generally considered bad practice) and
calling a collection "array".

-- 
Thomas Broyer


From vladimir at pobox.com  Mon Aug  4 16:27:33 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 4 Aug 2008 16:27:33 -0700
Subject: [whatwg] <canvas> shadow compositing oddities
In-Reply-To: <489774A8.3050205@mozilla.com>
References: <488CC721.5020903@mozilla.com>
	<ea09c0d10807290629i72261665n6c6b8efc47d25277@mail.gmail.com>
	<489774A8.3050205@mozilla.com>
Message-ID: <5ED9B825-635E-47AA-B2A8-E95DE9F5ECE1@pobox.com>


On Aug 4, 2008, at 2:29 PM, Eric Butler wrote:

> Philip Taylor wrote:
>> On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler <ebutler at mozilla.com>  
>> wrote:
>>
>>> [...]
>>> However, following the spec's drawing model, there are a few  
>>> operators that
>>> behave rather unexpectedly if the shadow color is left at its  
>>> default value.
>>> For instance, since A in B always results in transparency if  
>>> either A or B
>>> is fully transparent, source-in will always simply clear the  
>>> clipping region
>>> to fully transparent no matter what the source and destination are.
>>>
>>
>> Oops - that does seem quite broken. (It's probably my fault - I  
>> didn't
>> notice that problem when I was looking at how shadows should work...
>
> The need to be able to disable shadows explicitly seems clear. But I  
> also believe that the spec should provide
> for a means to disable normal drawing and only draw shadows to  
> increase the usefulness of shadows.
>
> As it stands, if you draw with shadows, you'll end up getting some  
> of the shadows drawn on top of some of
> the actual shapes. But perhaps the developer wants to have all  
> shadows behind all shapes for a particular set
> of shapes. The only way to accomplish that would be to create a  
> second canvas, do all the drawing without
> shadows on that, then draw the canvas with its shadow back to the  
> original, which seems cumbersome
> to use and is terribly inefficient.

I think that'll cause problems as well -- for example, let's say you  
had two overlapping paths that you wanted to draw a shadow behind.   
The two paths are both solid and are supposed to be rendered as a  
single shape to the user.  If you drew them separately with shadows,  
as it stands now, the shadows would end up adding and would be denser  
in the overlap areas which isn't what the author would intend.  I  
would suggest:

- special case opacity 0, 0,0 offset, 0 blur radius as 'shadows off',  
as Oliver suggested to preserve current usage

- if shadows aren't off, draw them normally -- one shadow per drawing  
operation

- go the whole way and add beginLayer/endLayer, akin to  
CGContextBeginTransparencyLayer[WithRect]/EndTransparencyLayer.  Could  
also call it pushGroup/popGroup.  As a side benefit, this would  
provide a simple way to implement double-buffered rendering without  
needing to use two canvases.  (http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#/ 
/apple_ref/c/func/CGContextBeginTransparencyLayer)

    - Vlad



From noclip at gmail.com  Mon Aug  4 18:12:49 2008
From: noclip at gmail.com (noclip)
Date: Mon, 04 Aug 2008 21:12:49 -0400
Subject: [whatwg] Nested lists?
Message-ID: <4897A911.4050604@gmail.com>

Are there plans to natively support nested unordered lists in HTML 5? 
I'm referring here to something like this:

Top level list item
 |-- Childless second level list item
 |-- Another childless second level list
[+]- Collapsed second level list item with children
[-]- Expanded second level list item with children
 |    |-- Third level list item
 |    |-- Another third level list item
 |   [+]- Collapsed third level list item with children
 |   [-]- Expanded third level list item with children
 |    |    |-- Fourth level list item
 |    |    |__ Another fourth level list item
 |    |__ A final third level list item
[+]- Another collapsed second level list item
 |__ A final second level list item

This is already possible through CSS, but these kinds of nested lists 
are more organizational than presentational and could benefit from 
native support with their own kind of unordered list element. The markup 
for the above list could be something like this:

<nl>
   <li id="foo">Top level list item</li>
   <lg parent="foo">
      <li>Childless second level list item</li>
      <li>Another childless second level list item</li>
      <li id="bar">Collapsed second level list item with children</li>
      <lg parent="bar">
         <!-- Child list items here -->
      </lg>
      <li id="three">Expanded second level list item with children</li>
      <lg parent="three">
         <li>Third level list item</li>
         <li>Another third level list item</li>
         <li id="four">Collapsed third level list item</li>
         <lg parent="bar">
            <!-- Child list items here -->
         </lg>
         <li id="five">Expanded third level list item with children</li>
         <lg parent="bar">
            <li>Fourth level list item</li>
            <li>Another fourth level list item</li>
         </lg>
         <li>A final third level list item</li>
      </lg>
      <li id="boo">Another collapsed second level list item</li>
      <lg parent="boo">
         <!-- Child list items here -->
      </lg>
      <li>A final second level list item</li>
   </lg>
</nl>

Or you could define the list groups separately, at the beginning or end 
of the <nl>.


From noclip at gmail.com  Mon Aug  4 18:15:01 2008
From: noclip at gmail.com (noclip)
Date: Mon, 04 Aug 2008 21:15:01 -0400
Subject: [whatwg] Nested lists
Message-ID: <4897A995.8080906@gmail.com>

Are there plans to natively support nested unordered lists in HTML 5? 
I'm referring here to something like this:

Top level list item
|-- Childless second level list item
|-- Another childless second level list
[+]- Collapsed second level list item with children
[-]- Expanded second level list item with children
|    |-- Third level list item
|    |-- Another third level list item
|   [+]- Collapsed third level list item with children
|   [-]- Expanded third level list item with children
|    |    |-- Fourth level list item
|    |    |__ Another fourth level list item
|    |__ A final third level list item
[+]- Another collapsed second level list item
|__ A final second level list item

This is already possible through CSS, but these kinds of nested lists 
are more organizational than presentational and could benefit from 
native support with their own kind of unordered list element. The markup 
for the above list could be something like this:

<nl>
  <li id="foo">Top level list item</li>
  <lg parent="foo">
     <li>Childless second level list item</li>
     <li>Another childless second level list item</li>
     <li id="bar">Collapsed second level list item with children</li>
     <lg parent="bar">
        <!-- Child list items here -->
     </lg>
     <li id="three">Expanded second level list item with children</li>
     <lg parent="three">
        <li>Third level list item</li>
        <li>Another third level list item</li>
        <li id="four">Collapsed third level list item</li>
        <lg parent="bar">
           <!-- Child list items here -->
        </lg>
        <li id="five">Expanded third level list item with children</li>
        <lg parent="bar">
           <li>Fourth level list item</li>
           <li>Another fourth level list item</li>
        </lg>
        <li>A final third level list item</li>
     </lg>
     <li id="boo">Another collapsed second level list item</li>
     <lg parent="boo">
        <!-- Child list items here -->
     </lg>
     <li>A final second level list item</li>
  </lg>
</nl>

Or you could define the list groups separately, at the beginning or end 
of the <nl>.N



From robert at ocallahan.org  Mon Aug  4 18:25:56 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 5 Aug 2008 13:25:56 +1200
Subject: [whatwg] <audio controls>
Message-ID: <11e306600808041825s21668475g4c75c3a357f3aba@mail.gmail.com>

Currently the spec doesn't say anything about the rendering of the <audio>
element. Webkit makes <audio> without "controls" display:none by default,
which seems reasonable, but it would be nice if spec recommended this
behaviour. When "controls" is added, the element needs to be visible, so it
will need an intrinsic size. Since the spec specifies the intrinsic size for
<video>, shouldn't it do so for <audio> as well?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080805/71deb6ad/attachment.htm>

From bijumaillist at gmail.com  Mon Aug  4 18:26:48 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Mon, 4 Aug 2008 21:26:48 -0400
Subject: [whatwg] VIDEO tag height/width best fit
In-Reply-To: <Pine.LNX.4.62.0808041056360.13029@hixie.dreamhostps.com>
References: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
	<Pine.LNX.4.62.0808041056360.13029@hixie.dreamhostps.com>
Message-ID: <4a27dd80808041826u759dab7fm5c607975d4fb7131@mail.gmail.com>

I dont get this effect in new firefox see
https://bugzilla.mozilla.org/attachment.cgi?id=332287

So can I am assuming it is a firefox bug
https://bugzilla.mozilla.org/show_bug.cgi?id=449142

On Mon, Aug 4, 2008 at 6:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 4 Aug 2008, Biju Gm at il wrote:
> It's automatically like this.
>
> # Video content should be rendered inside the element's playback area such
> # that the video content is shown centered in the playback area at the
> # largest possible size that fits completely within it, with the video
> # content's adjusted aspect ratio being preserved.
>  -- http://www.whatwg.org/specs/web-apps/current-work/#video


From ian at hixie.ch  Mon Aug  4 19:48:35 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 02:48:35 +0000 (UTC)
Subject: [whatwg] VIDEO tag height/width best fit
In-Reply-To: <4a27dd80808041826u759dab7fm5c607975d4fb7131@mail.gmail.com>
References: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
	<Pine.LNX.4.62.0808041056360.13029@hixie.dreamhostps.com>
	<4a27dd80808041826u759dab7fm5c607975d4fb7131@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808050248280.13029@hixie.dreamhostps.com>

On Mon, 4 Aug 2008, Biju Gm at il wrote:
>
> I dont get this effect in new firefox see 
> https://bugzilla.mozilla.org/attachment.cgi?id=332287
> 
> So can I am assuming it is a firefox bug 
> https://bugzilla.mozilla.org/show_bug.cgi?id=449142

Yup.

-- 
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  4 19:52:36 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 02:52:36 +0000 (UTC)
Subject: [whatwg] <audio controls>
In-Reply-To: <11e306600808041825s21668475g4c75c3a357f3aba@mail.gmail.com>
References: <11e306600808041825s21668475g4c75c3a357f3aba@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808050250420.13029@hixie.dreamhostps.com>

On Tue, 5 Aug 2008, Robert O'Callahan wrote:
>
> Currently the spec doesn't say anything about the rendering of the 
> <audio> element. Webkit makes <audio> without "controls" display:none by 
> default, which seems reasonable, but it would be nice if spec 
> recommended this behaviour. When "controls" is added, the element needs 
> to be visible, so it will need an intrinsic size. Since the spec 
> specifies the intrinsic size for <video>, shouldn't it do so for <audio> 
> as well?

Agreed with all the above. I was hoping to put details about the intrinsic 
size of the controls of audio and video elements into the rendering 
section, based on what browsers implemented. :-) I don't have any opinion 
either way about what it should be. Looks like for video, the trend is to 
use overlaying controls (obviously that won't work for audio).

-- 
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  4 20:01:56 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 03:01:56 +0000 (UTC)
Subject: [whatwg] Nested lists?
In-Reply-To: <4897A911.4050604@gmail.com>
References: <4897A911.4050604@gmail.com>
Message-ID: <Pine.LNX.4.62.0808050253010.13029@hixie.dreamhostps.com>

On Mon, 4 Aug 2008, noclip wrote:
>
> Are there plans to natively support nested unordered lists in HTML 5? 
> I'm referring here to something like this:
> 
> Top level list item
> |-- Childless second level list item
> |-- Another childless second level list
> [+]- Collapsed second level list item with children
> [-]- Expanded second level list item with children
> |    |-- Third level list item
> |    |-- Another third level list item
> |   [+]- Collapsed third level list item with children
> |   [-]- Expanded third level list item with children
> |    |    |-- Fourth level list item
> |    |    |__ Another fourth level list item
> |    |__ A final third level list item
> [+]- Another collapsed second level list item
> |__ A final second level list item

You can do the above today using the <datagrid> element and the <ul> 
element, as follows (I've put "..." where I couldn't see the elements in 
the view given above):

<datagrid>
 <ul>
  <li class="open"> Top level list item
   <ul>
    <li> Childless second level list item
    <li> Another childless second level list
    <li class="closed"> Collapsed second level list item with children
     <ul>
      ...
     </ul>
    <li class="open"> Expanded second level list item with children
     <ul>
      <li> Third level list item
      <li> Another thid level list item
      <li class="closed"> Collapsed third level list item with children
       <ul>
        ...
       </ul>
      <li class="open"> Expanded third level list item with children
       <ul>
        <li> Fourth level list item
        <li> Another fourth level list item
       </ul>
      <li> A final third level list item
     </ul>
    <li class="closed"> Another collapsed second level list item
     <ul>
      ...
     </ul>
    <li> A final second level list item
   </ul>
 </ul>
</datagrid>

(Note that the </li> end tags are implied.)

Today this works except you can't open and close the items:
   http://junkyard.damowmow.com/333

In future browsers that support <datagrid>, you should see a tree view on 
that page.

HTH,
-- 
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  4 20:24:57 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 04 Aug 2008 20:24:57 -0700
Subject: [whatwg] Workers comments
Message-ID: <4897C809.8010807@sicking.cc>

So having read through the workers spec I have a number of fairly large 
concerns.

The overall concern is that I think the spec is unnecessarily
complicated. I'll comment in detail below on specific features. An
overall requirement for mozilla is that we are very selective about
which features are exposed on the thread. For example exposing a full
navigator or window object is a huge amount of work. This doesn't mean
that it shouldn't be done, but there needs to be very good reasons when
exposing things.

So the first comment is the 'window' and 'self' properties. I don't see
a reason for these. I got a comment that they were there for easier
porting of code from the main window to a worker context. However just
having access to the window object is unlikely to help much. People
don't use the window object, they use properties and functions off of
it, such as window.location, window.name, window.document etc. So
without also adding these properties too I think it's unlikely that many
more scripts will run. Further I think having a property called 'window'
that doesn't return a true window object, with everything that goes with
it, is going to be a big source of confusion for developers.

On the subject of window. I think the fact that the global scope
interface is named something with 'Window' is very confusing for anyone
reading the spec. While I agree that there is some amount of association
between the global scope and the window, I think there is a much
stronger association between window and the properties that live on it,
such as window.location, window.document, window.frames, window.scrollX, 
etc.

Additionally I am worried that sharing interfaces between the global 
scope object for browser contexts, and the global scope object for 
workers is going to lead to unnecessary feature creep with argument such 
as "the object is available in the browsing context, so why not make it 
available in the worker context". I much rather want arguments like 
"this feature is needed in thread contexts because of reason X and use 
case Y". This is due to the fact that making threadsafe


What is the use cases for the onconnect and onunload properties?
'onconnect' doesn't seem to add anything beyond simply leaving the code
outside any function. I.e. doing

function foo() { ... }
function bar() { ... }
function onconnect() { <code here> }

seems the same as

function foo() { ... }
function bar() { ... }
<code here>


The fact that the only way to communicate between workers and the main 
browser context is through MessagePorts seems unnecessarily complex as 
well as differing from how windows communicates using postMessage. I 
think MessagePorts are a fine concept, but I don't think they should be 
mandatory as I think in many cases they are more complicated than 
needed. The whole concept of entangled message ports that clone and die 
when you pass them around is something that I don't think we should 
force upon developers unless absolutely needed. In the current draft I 
can't even see how to reach the message port object inside the worker, 
though that might be a temporary oversight. But it does indicate that 
the level of complexity for communication is non-trivial.

A better model seems to be reusing what we do for window objects. Simply 
make createWorker return a Worker object that has a sole .postMessage 
property, and make it possible to pass a Worker object through 
postMessage. We would also have to expose some way to send messages to 
the main browsing context, either through a separate postMessageToWindow 
function inside the worker context, or through a Worker object 
representing the main browser context. This doesn't stop us from adding 
support for MessagePorts as well, but it allows sites not to mess with 
them unless needed.


In general I feel like the current draft is very far from the three 
existing drafted APIs; the old google gears API, the new google gears 
API and the API from mozilla. I would much rather start from any one of 
those and make changes as needed based on use cases and experience from 
those implementations. This should help both with ease of 
implementation, as well as ease of porting code written for the existing 
gears API.

/ Jonas


From ian at hixie.ch  Mon Aug  4 22:11:56 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 05:11:56 +0000 (UTC)
Subject: [whatwg] pushState
In-Reply-To: <4896195C.2040101@sicking.cc>
References: <4889BFDF.7010003@sicking.cc>
	<Pine.LNX.4.62.0807251847070.10848@hixie.dreamhostps.com>
	<488A496E.70604@sicking.cc>
	<Pine.LNX.4.62.0807252154320.10848@hixie.dreamhostps.com>
	<488A6154.9080701@sicking.cc>
	<Pine.LNX.4.62.0807252334590.10848@hixie.dreamhostps.com>
	<488ABBDC.5030308@sicking.cc> <488C7C25.7070003@sicking.cc>
	<Pine.LNX.4.62.0807282229580.10848@hixie.dreamhostps.com>
	<488F57E4.9070508@sicking.cc>
	<Pine.LNX.4.62.0807292009520.30692@hixie.dreamhostps.com>
	<4896195C.2040101@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808050500190.13029@hixie.dreamhostps.com>

On Sun, 3 Aug 2008, Jonas Sicking wrote:
> >
> > The problem I have with this is that it increases the number of 
> > possible user-visible behaviours and failure scenarios:
> > 
> >  - same Document, script knows how to handle data.
> >  - different Document, script knows how to handle data.
> >  - same URL, different Document, data ignored.
> >  - different URL, different Document, script knows how to handle data,
> >    but copying URL fails to work as expected.
> >  - different URL, different Document, data ignored.
> 
> I'm actually more worried about the URL thing causing bugs than the data
> thing.
> 
> * To avoid bad user experience behavior the site has to send almost
>   exactly the same markup for both URLs, i.e. both for the page that
>   called pushState, and for the page served for the URL in the URL
>   argument in the pushState call.

Equivalently though, to avoid a bad experience, a site will have to 
provide a statically generated URL version anyway, even if data is 
provided, to handle the bookmark case.


> * Entering a URL that is results in a 404 (or any other non-succcess
>   value). This works fine when pushState is called, but fails on reload.

Equivalently, if the author screws up the data handling but gets the right 
URL, then things will work fine in static browsing (with no JS) but as 
soon as you enable JS in a browser that does pushState(), things will 
break if you go back.


> Additionally, if we allow the data parameter to be preserved across Document
> recreations there is also:
> * Both URLs have to react the same way when a popstate event is fired.

I am proposing getting rid of popstate and the data altogether.


> So I think we should either drop the URL argument entirely and say that 
> URL transitions are too risky.

This would fail to address one of the core use cases, namely 
bookmarkability, so this isn't really an option.


> Or we should leave the spec as is (but require that data is 
> serializeable) and just encourage people not to transition between 
> wildly different pages.

Well I'm fine with leaving the spec as is, obviously, but if we have the 
data object, especially if it can only be used with one Document as in the 
current spec, I think it would be very confusing if exceptions were raised 
when things like elements were put into the data. It also seems like it 
wouldn't really gain us anything -- in the cross-session case (restarting 
the browser, etc) these data objects, according to the spec today, would 
be thrown out anyway.

If we want to handle the cross-Document case (i.e. if we want to never 
have entries disappear from the session history) then I think we are 
better off just getting rid of the data argument altogether and always 
using the URL field.

-- 
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  4 23:02:25 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 06:02:25 +0000 (UTC)
Subject: [whatwg] handler URI escaping in 4.5.1 appears to be different
 from	encodeURIComponent
In-Reply-To: <46FAF61E.9050706@mozilla.org>
References: <46FAF61E.9050706@mozilla.org>
Message-ID: <Pine.LNX.4.62.0808050601500.5140@hixie.dreamhostps.com>

On Wed, 26 Sep 2007, Dan Mosedale wrote:
>
> The escaping specified in 
> <http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers> is 
> slightly different than the escaping done by encodeURIComponent (as 
> described at 
> <http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Functions:encodeURIComponent>). 
> Specifically, encodeURIComponent is documented as not escaping:
> 
>    ! * ' ( )
> 
> characters, whereas the spec seems to want these characters to be 
> escaped.  Is this intentional?  If so, what's the motivation?

The spec was changed recently to just require that things that can't be in 
the <query> component of a URI be escaped, instead of saying everything 
must be escaped. Is that ok?

-- 
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  4 23:03:08 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 4 Aug 2008 23:03:08 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
Message-ID: <c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>

On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer <t.broyer at gmail.com> wrote:
> On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
>>
>> (3) There is no specification for a special [[Get]] for the "elements"
>> HTMLCollection as a shortcut to "namedItem", either (though this would not
>> seem to be a problem,
>
> Actually, there is:
> http://www.w3.org/TR/html5/dom.html#htmlcollection
> and I believe the "elements" property of HTMLFormElement is actually
> an HTMLFormControlsCollection:
> http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
>

First off, the IndexGetter behavior on the HTMLCollection[1] is the
authors imagination. It is a shame to see such misinformation has made
it so far.

The following example shows that indexed Properties exist on
NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
There is no [[ IndexGetter ]] as Cameron likes to make pretend.

======================================================
<!DOCTYPE HTML>
<html>
<head>
<title>Additional Properties on NamedNodeMap, HTMLCollection, NodeList</title>
<link rel="author" title="Garrett Smith" href="mailto:dhtmlkitchen at gmail.com"/>
</head>

<body id="body">
<select id='s'>
<option></option>
</select>
<pre>
<script type="text/javascript">
var s = document.getElementById('s');
document.write([
  "NamedNodeMap: '0'in document.body.attributes : "
  + ('0'in document.body.attributes),
  "HTMLCollection '0'in document.body.childNodes : "
  + ('0'in document.body.childNodes),
  "HTMLOptionsCollection '0'in s.options : "
  + ('0'in s.options),
  "NodeList: '0'in document.getElementsByTagName('*') : "
  + ('0'in document.getElementsByTagName('*')),
  "'id'in document.body.attributes : "
  + ('id'in document.body.attributes)
].join('\n'));
</script>
</pre>

<p>
    This test is informative. It is not pass/fail. There is no public standard.
</p>
</body>
</html>
======================================================

Even if the author wrote 0 tests, simple observations should show him
just how wrong he is. I wrote about this twice on public-webapi list,
addressing Cameron McCormick with direct questions. Both messages died
with 0 replies. The second one I wrote to the public-webapi list:-

| It can be demonstrated that all of: NamedNodeMap, NodeList, and
| HTMLCollection are implemented in the top 4 browsers with extra
| numeric properties being added.

| http://html5.googlecode.com/svn/trunk/incoming/garrett-smith/noIndexGetter.html

| StyleSheetList, and CSSRuleList also have this behavior. I can't
| find an object that implements indexed properties the way you
| have documented them.

| Although the HTML DOM spec defines a 'length' property for
| NamedNodeMap, yet provides no way to access items by index. This
| seems to be a strange design decision, though not the most harmful.
| Ideally, such decisions would be tested out before writing a lengthy
| document. Firefox, Opera, Safari, and IE all allow access by ordinal
| index, via property access, but not by the way you have described in
| your document.

My example demonstrates that there is no [[ IndexGetter ]] on
NamedNodeMap, et c. Ignoring valid criticism serves no useful purpose.
This was documented in IDL, of all the places.

>> and all implementations have supported this behavior for quite a long time).
>
> Note that all implementations also supports the same behavior on
> HTMLFormElement and HTMLDocument.
>

That is not true about document. There no indexed properties, no [[
IndexGetter ]], and no [[ NameGetter ]] and no named property. There
may be either a specialized [[ IndexGetter ]] or an indexed property
on a Form Element, and the [[ IndexedGetter ]] exists only in Firefox,
on the HTMLFormElement. I cannot understand decision to specify [[
IndexGetter ]] as "standard" for all objects with indexed properties
when it has been demonstrated to exist only on HTMLFormElement and
only in one browser:

Firefox.

==========================
<!DOCTYPE HTML>
<html>
<head>
      <title>Document</title>
      <style type='text/css'>
li {
      display: none;
}
      </style>
</head>
<body id="test">

<h1>Document Has</h1>
<ul>
      <li id='nameProperty'>Named Property</li>
      <li id='noNameProperty'>No Named Property</li>
      <li id='nameGetter'> [[ NameGetter ]]</li>
      <li id='indexProperty'>Indexed Property</li>
      <li id='indexGetter'>[[IndexGetter]]</li>
      <li id='noIndexProperty'>No Indexed Property</li>
</ul>

<h1>Form Has</h1>
<ul>
      <li id='fnameProperty'>Named Property</li>
      <li id='fnoNameProperty'>No Named Property</li>
      <li id='fnameGetter'>[[ NameGetter ]]</li>
      <li id='findexProperty'>Indexed Property</li>
      <li id='findexGetter'>[[IndexGetter]]</li>
      <li id='fnoIndexProperty'>No Indexed Property</li>
</ul>

<form action="" name="f">
 <input type="text" name="t" id="t">
</form>

<script type="text/javascript">
var ids = [];
if('test' in document) ids.push('nameProperty');
else {
 ids.push('noNameProperty');
 if(document.test) ids.push("nameGetter");
}
if('0'in document) ids.push('indexProperty');
else {
      ids.push('noIndexProperty');
      if(document[0]) ids.push('indexGetter');
}

var f = document.forms[0];
if('t'in f) ids.push('fnameProperty');
else {
 ids.push('fnoNameProperty');
 if(f.t) ids.push("fnameGetter");
}if('0'in f) ids.push('findexProperty');
else {
 ids.push('fnoIndexProperty');
 if(f[0]) ids.push('findexGetter');
}

try{
for(var i = 0; i < ids.length; i++)
 document.getElementById(ids[i]).style.display = "block";
 } catch(x) { alert(ids[i]); }
</script>
</body>
</html>
==========================
Safari3, Opera9, IE8

Document Has
  No Named Property
  No Indexed Property
Form Has
  Named Property
  Indexed Property

Firefox3:
Document Has
    * No Named Property
    * No Indexed Property
Form Has
    * Named Property
    * [[IndexGetter]]
    * No Indexed Property

The results show that document has no [[ NameGetter ]] or [[
IndexGetter]], and a Form has no [[ NameGetter ]] or [[IndexGetter]],
except in Firefox, which implements some sort of specialized [[Get]]
(Cameron would call this the "[[IndexGetter]]") on the Form, and my
example uses that term.

Historically, Netscape's document object had FORM and Image named
elements' names as properties. It is unnecessary to have these
lookups, as we can easily use the DOM document.forms collection.
Creating a specification for new functionality based on a the
deprecated Netscape API is pointless because we have the "elements"
collection, and it is bad because it may introduce problems (it is in
fact specified incorrectly).

There is no point of using Netscape 4 DOM document property lookups in
HTML 5 for examples, and certainly not for a specification. This is
intellectual idiocy.

[1] HTML DOM
http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/ecma-script-binding.html

Garrett

>
> --
> Thomas Broyer
>


From aa at google.com  Mon Aug  4 23:05:47 2008
From: aa at google.com (Aaron Boodman)
Date: Mon, 4 Aug 2008 23:05:47 -0700
Subject: [whatwg] Workers comments
In-Reply-To: <4897C809.8010807@sicking.cc>
References: <4897C809.8010807@sicking.cc>
Message-ID: <278fd46c0808042305t5c5f9665p4527cd760ae905e2@mail.gmail.com>

On Mon, Aug 4, 2008 at 8:24 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> The overall concern is that I think the spec is unnecessarily
> complicated. I'll comment in detail below on specific features. An
> overall requirement for mozilla is that we are very selective about
> which features are exposed on the thread. For example exposing a full
> navigator or window object is a huge amount of work. This doesn't mean
> that it shouldn't be done, but there needs to be very good reasons when
> exposing things.

I don't see anything about a 'navigator' object except this comment:

May need to define a browser sniffing API (like window.navigator).

That doesn't imply to me that it will be the entire navigator object,
just something having similar capabilities wrt browser sniffing.

Similarly, the only thing that the spec says should be available from
Window are the things listed in these two interfaces:

http://www.whatwg.org/specs/web-workers/current-work/#the-windowworker
http://www.whatwg.org/specs/web-apps/current-work/#window

This is a very small subset of Window.

> So the first comment is the 'window' and 'self' properties.

I agree, these seem unnecessary.

> On the subject of window. I think the fact that the global scope
> interface is named something with 'Window' is very confusing for anyone
> reading the spec. While I agree that there is some amount of association
> between the global scope and the window, I think there is a much
> stronger association between window and the properties that live on it,
> such as window.location, window.document, window.frames, window.scrollX,
> etc.

I agree with this. I think the global object in a worker should be
called something different, such as WorkerGlobal or WorkerContext.

I don't think we should pay too much attention to trying to make
existing code compatible with this environment, as that seems
hopeless.

However, I do feel that in the cases where an existing interface works
nicely for its intended purpose, there's no point reinventing it. Less
"brain print", as a coworker likes to say.

So for example, I would be for moving over a subset of the navigator
and location objects as-is (these seem to work well), but against
moving over the document.cookie "interface" (it works poorly).

> Additionally I am worried that sharing interfaces between the global scope
> object for browser contexts, and the global scope object for workers is
> going to lead to unnecessary feature creep with argument such as "the object
> is available in the browsing context, so why not make it available in the
> worker context". I much rather want arguments like "this feature is needed
> in thread contexts because of reason X and use case Y".

I don't think having a common base interface in the spec is going to
make this kind of feature creep any more or less likely. It just seems
natural that if functionality is available in both workers and the
main browsing context, it should work the same way.

> What is the use cases for the onconnect and onunload properties?
> 'onconnect' doesn't seem to add anything beyond simply leaving the code
> outside any function. I.e. doing

I believe that onconnect is meant to be how a worker gets the
MessagePort object from people who are trying to talk to it.

Hixie, it occurs to me that it might be helpful for everyone if you
could add some code samples for how applications would use this API to
the top. It's easier to grok what the point is at a glance, and allows
people to think about the API proposal holistically instead of trying
to piece it together from the algorithms.

> The fact that the only way to communicate between workers and the main
> browser context is through MessagePorts seems unnecessarily complex as well
> as differing from how windows communicates using postMessage. I think
> MessagePorts are a fine concept, but I don't think they should be mandatory
> as I think in many cases they are more complicated than needed. The whole
> concept of entangled message ports that clone and die when you pass them
> around is something that I don't think we should force upon developers
> unless absolutely needed. In the current draft I can't even see how to reach
> the message port object inside the worker, though that might be a temporary
> oversight. But it does indicate that the level of complexity for
> communication is non-trivial.
>
> A better model seems to be reusing what we do for window objects. Simply
> make createWorker return a Worker object that has a sole .postMessage
> property, and make it possible to pass a Worker object through postMessage.
> We would also have to expose some way to send messages to the main browsing
> context, either through a separate postMessageToWindow function inside the
> worker context, or through a Worker object representing the main browser
> context. This doesn't stop us from adding support for MessagePorts as well,
> but it allows sites not to mess with them unless needed.

I can get behind simplifying the API. However, the "simple" I would go
for would be to just allow workers to talk to their creator. No
passing workers (or ports) around at all.

If we decide to allow workers to talk directly to other people than
their creator, then I think something like MessagePorts is a better
approach than passing workers around. The advantage of MessagePorts is
that it works with iframes too.


- a


From ian at hixie.ch  Mon Aug  4 23:29:06 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 06:29:06 +0000 (UTC)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <31fb000f0806230027y42ee32dqd2c55a948d65a4c1@mail.gmail.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan> 
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com> 
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan> 
	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
	<31fb000f0806230027y42ee32dqd2c55a948d65a4c1@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808050607350.5140@hixie.dreamhostps.com>

On Mon, 23 Jun 2008, Frode B?rli wrote:
> 
> 1. Which readystate does an img object have, before it is added to the 
> DOM? Example:
> 
> var i = document.createElement("IMG");
> alert(i.readystate); // afaict the state SHOULD be uninitialized here...
> i.onreadystatechange(function(){alert(this.readystate);}
> i.src = "some_url.jpg";
> alert(i.readystate);

It seems only IE supports this property, so hopefully we don't need to 
spec it (or support it in other UAs).


> The example applies to iframes as well, i believe.

I couldn't reproduce this.


> 2. How can we listen to the onreadystatechange, if we want to trigger an 
> event when the object starts loading? It will not change readystate 
> since it was already in the state loading.

In HTML5 there's no way to get an event when an <img> begins loading. It 
begins loading when the src="" is set.

-- 
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  5 01:12:57 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 08:12:57 +0000 (UTC)
Subject: [whatwg] Methods defined for one document called after that
 document is no longer the one being displayed
Message-ID: <Pine.LNX.4.62.0808050759070.5140@hixie.dreamhostps.com>


I would like some input from browser vendors.

Right now, if you navigate an iframe to a document, and take a 
reference to a method defined in that document, and then navigate that 
iframe to another document, and then call the method, browsers differ in 
what they do.

There are several behaviours:

 - In one browser, the Window object changes with each navigation,
   and the global object is that object, and the method runs fine.

 - In one browser, the method call fails, saying that methods can't be 
   called while the document that defined them isn't the active document 
   of the browsing context whose global object is the method's.

 - In one browser, the Window object acts as a kind of view on the global 
   object, which changes with each navigation, leading the method to see 
   the original global object in its scope chain, but the new one if it
   uses the 'window' object. (In this environment, 'this' at the top scope 
   returns the 'window' object, not the global object.)

 - In one browser, the global object and the Window are the same, but the 
   global object is totally wiped out with each navigation, preventing the
   method from accessing its global object's data. (In this browser, the 
   results are slightly different when navigating top-level windows 
   instead of frames.)

These results were derived from:
   http://damowmow.com/playground/demos/global-object/004.html

I propose to adopt the second behaviour above. It seems by far the 
simplest behaviour to define and implement. Are there any objections to 
this? Given the lack of interoperability here, it seems like we aren't 
really constrained to pick something due to compatibility.

The change would be that if a method is invoked when the script execution 
context that the method was running in has a Document object that is not 
the active Document object of its browsing context, then that method 
immediately throws an exception. Access to variables obtained from such 
script execution contexts would be unaffected.

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


From aa at google.com  Tue Aug  5 01:33:51 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 5 Aug 2008 01:33:51 -0700
Subject: [whatwg] Methods defined for one document called after that
	document is no longer the one being displayed
In-Reply-To: <Pine.LNX.4.62.0808050759070.5140@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0808050759070.5140@hixie.dreamhostps.com>
Message-ID: <278fd46c0808050133t40c3f562u25d0586fe30067f3@mail.gmail.com>

On Tue, Aug 5, 2008 at 1:12 AM, Ian Hickson <ian at hixie.ch> wrote:
> Right now, if you navigate an iframe to a document, and take a
> reference to a method defined in that document, and then navigate that
> iframe to another document, and then call the method, browsers differ in
> what they do.

By 'method' do you mean any function object, defined anywhere in that
window? For example, does document.getElementById count? Does the foo
in var myglobal = {foo:function(){...}}; ? What about getters?

>  - In one browser, the method call fails, saying that methods can't be
>   called while the document that defined them isn't the active document
>   of the browsing context whose global object is the method's.

Off the cuff, this behavior seems good to me. I think it would be good
if this applied to any function or getter.

- a


From ian at hixie.ch  Tue Aug  5 01:43:05 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 08:43:05 +0000 (UTC)
Subject: [whatwg] Methods defined for one document called after that
 document is no longer the one being displayed
In-Reply-To: <278fd46c0808050133t40c3f562u25d0586fe30067f3@mail.gmail.com>
References: <Pine.LNX.4.62.0808050759070.5140@hixie.dreamhostps.com>
	<278fd46c0808050133t40c3f562u25d0586fe30067f3@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808050835100.5136@hixie.dreamhostps.com>

On Tue, 5 Aug 2008, Aaron Boodman wrote:
> On Tue, Aug 5, 2008 at 1:12 AM, Ian Hickson <ian at hixie.ch> wrote:
> > Right now, if you navigate an iframe to a document, and take a
> > reference to a method defined in that document, and then navigate that
> > iframe to another document, and then call the method, browsers differ in
> > what they do.
> 
> By 'method' do you mean any function object, defined anywhere in that 
> window? For example, does document.getElementById count? Does the foo in 
> var myglobal = {foo:function(){...}}; ? What about getters?

I think I mean any function object, including getters and setters defined 
by the script (i.e. not host objects). But I haven't checked. Possibly any 
code whose global object is that global object.


> >  - In one browser, the method call fails, saying that methods can't be
> >   called while the document that defined them isn't the active document
> >   of the browsing context whose global object is the method's.
> 
> Off the cuff, this behavior seems good to me. I think it would be good
> if this applied to any function or getter.

Agreed.

-- 
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  5 02:17:01 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 09:17:01 +0000 (UTC)
Subject: [whatwg] Use of 'direction' of canvas element
In-Reply-To: <20080613223041.GA24221@pickering.dbaron.org>
References: <20080613223041.GA24221@pickering.dbaron.org>
Message-ID: <Pine.LNX.4.62.0808050916190.5140@hixie.dreamhostps.com>

On Fri, 13 Jun 2008, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text
> has the following bullet point:
>   # Form a hypothetical infinitely wide CSS line box containing a
>   # single inline box containing the text text, with all the
>   # properties at their initial values except the 'font' property of
>   # the inline element set to font and the 'direction' property of
>   # the inline element set to the 'direction' property of the canvas
>   # element. [CSS]
> 
> This should describe what to do if the canvas element is not in a
> document (and therefore has no 'direction').
> 
> It should probably fall back to 'ltr' as a last resort.
> 
> However, as an intermediate step, it might be worth falling back to
> the direction property of the root element (if present) of the
> canvas element's ownerDocument.

I've made it depend on the 'dir' attribute of the <cavnas> element if the 
CSS property doesn't have a defined computed value.

Thanks,
-- 
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  5 07:16:26 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 5 Aug 2008 09:16:26 -0500
Subject: [whatwg] Fwd:  Nested lists
In-Reply-To: <dd0fbad0808050715t1d55d257h3fa0a708c760120c@mail.gmail.com>
References: <4897A995.8080906@gmail.com>
	<dd0fbad0808050715t1d55d257h3fa0a708c760120c@mail.gmail.com>
Message-ID: <dd0fbad0808050716h143ef949gaab472af28a331b7@mail.gmail.com>

Blarg forward to list.

---------- Forwarded message ----------
From: Tab Atkins Jr. <jackalmage at gmail.com>
Date: Tue, Aug 5, 2008 at 9:15 AM
Subject: Re: [whatwg] Nested lists
To: noclip <noclip at gmail.com>




On Mon, Aug 4, 2008 at 8:15 PM, noclip <noclip at gmail.com> wrote:

> Are there plans to natively support nested unordered lists in HTML 5? I'm
> referring here to something like this:
>
> Top level list item
> |-- Childless second level list item
> |-- Another childless second level list
> [+]- Collapsed second level list item with children
> [-]- Expanded second level list item with children
> |    |-- Third level list item
> |    |-- Another third level list item
> |   [+]- Collapsed third level list item with children
> |   [-]- Expanded third level list item with children
> |    |    |-- Fourth level list item
> |    |    |__ Another fourth level list item
> |    |__ A final third level list item
> [+]- Another collapsed second level list item
> |__ A final second level list item
>
> This is already possible through CSS, but these kinds of nested lists are
> more organizational than presentational and could benefit from native
> support with their own kind of unordered list element. The markup for the
> above list could be something like this:
>
> <nl>
>  <li id="foo">Top level list item</li>
>  <lg parent="foo">
>    <li>Childless second level list item</li>
>    <li>Another childless second level list item</li>
>    <li id="bar">Collapsed second level list item with children</li>
>    <lg parent="bar">
>       <!-- Child list items here -->
>    </lg>
>    <li id="three">Expanded second level list item with children</li>
>    <lg parent="three">
>       <li>Third level list item</li>
>       <li>Another third level list item</li>
>       <li id="four">Collapsed third level list item</li>
>       <lg parent="bar">
>          <!-- Child list items here -->
>       </lg>
>       <li id="five">Expanded third level list item with children</li>
>       <lg parent="bar">
>          <li>Fourth level list item</li>
>          <li>Another fourth level list item</li>
>       </lg>
>       <li>A final third level list item</li>
>    </lg>
>    <li id="boo">Another collapsed second level list item</li>
>    <lg parent="boo">
>       <!-- Child list items here -->
>    </lg>
>    <li>A final second level list item</li>
>  </lg>
> </nl>
>
> Or you could define the list groups separately, at the beginning or end of
> the <nl>.


Could you be more specific about how this is better than just nesting
<ul>s?  Your example can be organized just as well with:
 <ul>
    <li>Foo</li>
    <li>
        <ul>
            <li>Bar</li>
            <li>Baz</li>
...

This markup has the added advantage that it'll display a nested list no
matter what - it is it's own fallback content if the UA doesn't have
appropriate CSS support.  Plus it automatically nests appropriately, without
the need to specify parents explicitly.  As shown in your example, that's
somewhat error-prone ( below <li id="five"> you have <lg parent="bar">,
which should obviously be <lg parent="five">).  ^_^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080805/6a2ce1b7/attachment.htm>

From jonas at sicking.cc  Tue Aug  5 08:25:30 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 05 Aug 2008 08:25:30 -0700
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
Message-ID: <489870EA.9050101@sicking.cc>

Ian Hickson wrote:
>> But, oddity is par for the course in DOM, so I guess we'll just follow 
>> the HTML 5 spec as-is, initialize readyState to "loading" in the object 
>> constructor, and keep our fingers crossed.
> 
> If you find any problems with doing this, please let me know, so we can 
> update the spec!

The concern I have with doing that is that document created through 
other means, such as .implementation.createDocument, 
XSLTProccessor.transformToDocument, DOMParser.parse, etc, probably 
should not be in the 'uninitialized' state. Especially the last two 
should return documents that is in the 'complete' state I would think.

/ Jonas



From jonas at sicking.cc  Tue Aug  5 08:26:38 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 05 Aug 2008 08:26:38 -0700
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <Pine.LNX.4.62.0808050607350.5140@hixie.dreamhostps.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>	<31fb000f0806230027y42ee32dqd2c55a948d65a4c1@mail.gmail.com>
	<Pine.LNX.4.62.0808050607350.5140@hixie.dreamhostps.com>
Message-ID: <4898712E.1030602@sicking.cc>

>> 2. How can we listen to the onreadystatechange, if we want to trigger an 
>> event when the object starts loading? It will not change readystate 
>> since it was already in the state loading.
> 
> In HTML5 there's no way to get an event when an <img> begins loading. It 
> begins loading when the src="" is set.

Nothing prevents an implementation from firing ProgressEvents while 
loading images though, that would give you an event when an image starts 
loading.

I don't think any browser does that as of yet though.

/ Jonas



From aa at google.com  Tue Aug  5 13:29:52 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 5 Aug 2008 13:29:52 -0700
Subject: [whatwg] Web Workers and MessagePort feedback
Message-ID: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>

I'm still digesting the Web Worker proposal, but here is some
feedback. Sorry it is a bit long.


Structural API stuff:

- I still haven't really internalized the need to either have workers
speak directly to anyone other than the person who created them, or
the other use cases that MessageChannels are intended for. There is a
lot of complexity here. I think we need to add some requirements and
motivations to the top of the doc, and some code samples showing the
intended usage before implementors can really decide whether it's
worth taking on.

- It seems like we might want an object that represents workers. This
would allow us put the 'onload' and 'onerror' events from MessagePort
there, instead of on MessagePort, which makes more sense to me (I
don't know what it means for a MessagePort to 'load' or 'error'
outside of the context of a worker). MessagePort.onunload could then
change to 'onclose' to go with the close() method.

It seems like over time, we might want to be able to perform other
operations on a worker and having the worker object might be handy.

I know this is weird wrt GC when combined with MessagePorts, and I
don't have a proposed solution.


- It's odd to me that the way to establish a channel to a worker
depends on whether you are the creator of the worker or not. The
creator gets a MessagePort to a new channel back from createWorker(),
but any other function must pass a new MessagePort over the original
one, and the worker must know to use that secondary port to talk back.

I would prefer to see something like:

void Worker.postMessage(DOMString message)
void Worker.postMessage(DOMString message, MessagePort port)

That way the way to establish a new channel is the same for all
callers. It also has the advantage of looking similar to a window's
postMessage API.


Here is how the previous two suggestions would look together:

var worker = new Worker("foo.js");
worker.onload = function() { ... }
worker.onerror = function() { ... }
worker.onunload = function() { ... }  // called when the worker shuts down
worker.sendMessage("hello!");

var channel = new MessageChannel();
channel.port1.onmessage = function(e) { ... }
worker.sendMessage("please return my call", channel.port2);

// called when the channel is closed, either because the worker shut down taking
// the other end of the port with it, or because the other end of the
port was GC'd,
// or because the other port was explicitly closed.
channel.port1.onclose = function() { ... }


semantics questions

- The spec doesn't seem to say what happens if you send a worker a
message before it has finished loading. I think that the message
should be queued and delivered when the worker load is complete. This
makes waiting for onload unnecessary, unless preparing the message you
want to send is somehow expensive.


- The spec says that as soon as a worker is not reachable (determined
via GC) from any MessagePort, it is eligible for shutdown. Shutdown
would attempt to finish all queued messages, but not allow any new
ones.

This concerns me because it means that workers will have different
behavior depending on GC timing. If a worker is not referenced from
any port, and it sends an XHR, that XHR may or may not be sent
depending on when GC runs. This is different than how XHR behaves
normally. Typically, XHR objects that have outstanding IO but no
referers will not be GC'd until they complete or fail.

Finally this does not allow use cases such as creating a worker to
synchronize a local database with the network without ever sending
notifications back to the parent.

Maybe workers should stay alive as long as any of the following are true:

- There is script running in them
- There are messages to them queued
- There is a messageport alive anywhere that could send messages to them
- There are "asynchronous operations" (xhr, timers, database
operations) inside them outstanding


API nitpickery

- Why is there an ownerWindow property on MessagePort? If I understand
correctly, this is just a synonym for the 'window' object of the
currently executing script context.  I think it should go away.


- I'm curious as to why MessagePort and WindowWorker do not implement
EventTarget. It seems like we may as well reuse it. And at least for
WindowWorker, it seems like the same problems of having multiple
functions clobber each other that motivated EventTarget would apply.


- The purpose of 'import()' on WindowWorker was not immediately
obvious to me from its name. Should it be 'importScript()'? or
'includeScript()' maybe?


- Should import() accept an array of URLs, so that the UA can fetch
them in parallel if it has the ability to do that?


- The string URL property on the WindowWorker interface is less useful
than the parsed structure that window.location has. Can we use
something like this instead, except making it read-only?


- The "front-line" nomenclature was a bit weird to me. How about "top-level"?


- Would it be too weird to have createWorker overloaded to take an
optional name parameter? This would make the behavior similar to
window.open(), which either opens a new window or reuses an existing
window with the same name.


- a


From ian at hixie.ch  Tue Aug  5 13:44:13 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 20:44:13 +0000 (UTC)
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <op.ub60rs1y64w2qv@annevk-t60.oslo.opera.com>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
	<4843EA57.3070900@myrealbox.com>
	<87609C1C-5D3F-4EF6-A888-DF110740D645@iki.fi>
	<op.ub60rs1y64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0808052041580.5140@hixie.dreamhostps.com>

On Mon, 2 Jun 2008, Matthew Paul Thomas wrote:
> 
> The disadvantage of using a data-* attribute is that more kinds of 
> mistakes would be undetectable by a validator. It would have no idea 
> that (a) the value of the attribute must be the ID of an element 
> elsewhere in the document, and (b) each value must be unique within the 
> document.
> 
> I wonder if the data-* attribute naming scheme could be classified 
> somehow to allow basic type checking like this. I expect there will be 
> other cases where authors want an attribute value to match the ID of an 
> element in the page.

On Tue, 3 Jun 2008, Henri Sivonen wrote:
> 
> I don't like the idea of trying to encode the datatypes of data-* 
> attributes in a validator-sensitive way. What datatypes would a 
> validator support for data-* attributes? The HTML5 datatype library used 
> by Validator.nu already contains 41 datatypes, but people will likely 
> want to have others. The whole point of data-* is to provide a place 
> where a validator doesn't go without authors having to abuse e.g. title 
> which is a freeform but exposed to humans.
> 
> The foreseeable problem with data-* is, of course, that microformat-like 
> activity will happen there instead of going through the trouble of 
> getting unprefixed validator-sensitive attributes minted with community 
> review in the WHATWG and the HTML WG.

On Wed, 4 Jun 2008, Anne van Kesteren wrote:
> 
> That'd be wrong as data-* does not allow implementation by UAs... Having 
> said that, if we don't make it clear what the idea is that might end up 
> happening in practice here and there.

I agree that not constraining data-* will lead to a validation "hole" 
where people can't check that their data is matching their presumed 
schema, but I think the right solution to this is for validators to offer 
out-of-band ways to specify schemas for data-* attributes, not for the 
spec to constrain the values, IMHO.

-- 
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  5 13:45:34 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 20:45:34 +0000 (UTC)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <4898712E.1030602@sicking.cc>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan> 
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com> 
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan> 
	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
	<31fb000f0806230027y42ee32dqd2c55a948d65a4c1@mail.gmail.com>
	<Pine.LNX.4.62.0808050607350.5140@hixie.dreamhostps.com>
	<4898712E.1030602@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808052045030.5136@hixie.dreamhostps.com>

On Tue, 5 Aug 2008, Jonas Sicking wrote:
> > >
> > > 2. How can we listen to the onreadystatechange, if we want to 
> > > trigger an event when the object starts loading? It will not change 
> > > readystate since it was already in the state loading.
> > 
> > In HTML5 there's no way to get an event when an <img> begins loading. 
> > It begins loading when the src="" is set.
> 
> Nothing prevents an implementation from firing ProgressEvents while 
> loading images though, that would give you an event when an image starts 
> loading.

Well, nothing allows it either, at the moment. Would this be useful? I 
mean, I can add it if there is a desire for browsers to do this. It 
doesn't seem that useful though.

-- 
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  5 14:02:47 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 21:02:47 +0000 (UTC)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <489870EA.9050101@sicking.cc>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
	<489870EA.9050101@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808052100520.5140@hixie.dreamhostps.com>

On Tue, 5 Aug 2008, Jonas Sicking wrote:
> Ian Hickson wrote:
> > > But, oddity is par for the course in DOM, so I guess we'll just follow the
> > > HTML 5 spec as-is, initialize readyState to "loading" in the object
> > > constructor, and keep our fingers crossed.
> > 
> > If you find any problems with doing this, please let me know, so we can
> > update the spec!
> 
> The concern I have with doing that is that document created through 
> other means, such as .implementation.createDocument, 
> XSLTProccessor.transformToDocument, DOMParser.parse, etc, probably 
> should not be in the 'uninitialized' state. Especially the last two 
> should return documents that is in the 'complete' state I would think.

IE doesn't have any of those mechanisms. In IE,

   w(new ActiveXObject("Msxml.DOMDocument").readyState);

...returns "4", which isn't any of the values I expected.

Right now the spec says that anything that doesn't go through a parser 
will remain in the readyState == "loading" state forever. Is that a 
problem? We could define that mechanisms that create a Document object 
without an associated parser set it to "complete" if you want. I'm not 
sure that that would be especially useful, although it would, I guess, be 
somewhat more self-consistent.

Does anyone have an opinion on this?

-- 
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  5 14:06:50 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 5 Aug 2008 21:06:50 +0000 (UTC)
Subject: [whatwg] Psuedo classes based on DOM Events
In-Reply-To: <ea56cd6c0612042318m7474dfe2i96bed2431c365f00@mail.gmail.com>
References: <ea56cd6c0612042318m7474dfe2i96bed2431c365f00@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808052105130.5140@hixie.dreamhostps.com>

On Tue, 5 Dec 2006, Rohan Prabhu wrote:
>
> Dear all,
> i was just wondering, that in the Web Controls 1.0 specifications, in
> the psuedo classes specifications, could it be that the psuedo classes
> could also be the DOM Events which would modify the style information
> attached to it. Like for ex:
> 
> #objectid:onmouseup
> #objectid:onmousedown
> #objectid:onmouseover
> #objectid:onmouseout
> #objectid:onkeypress
> 
> etc...
> 
> just a idea from the silly mind of mine :D .. but do give ur comments on 
> that..

Sorry for the delay in responding. It looks like the Web Controls spec 
might never actually see the light of day; features like ARIA have been 
developed in the meantime to address much of the same use cases.

I recommend contacting the CSS working group with the idea described 
above, as they might be in a better position to follow up on this.

Thanks for the feedback though; I will keep track of it in case we ever 
do work on the Web Controls spec after all.

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


From jonas at sicking.cc  Tue Aug  5 14:52:39 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 05 Aug 2008 14:52:39 -0700
Subject: [whatwg] Web Workers and MessagePort feedback
In-Reply-To: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
Message-ID: <4898CBA7.2080801@sicking.cc>

Aaron Boodman wrote:
> I'm still digesting the Web Worker proposal, but here is some
> feedback. Sorry it is a bit long.
> 
> 
> Structural API stuff:
> 
> - I still haven't really internalized the need to either have workers
> speak directly to anyone other than the person who created them, or
> the other use cases that MessageChannels are intended for. There is a
> lot of complexity here. I think we need to add some requirements and
> motivations to the top of the doc, and some code samples showing the
> intended usage before implementors can really decide whether it's
> worth taking on.
> 
> - It seems like we might want an object that represents workers. This
> would allow us put the 'onload' and 'onerror' events from MessagePort
> there, instead of on MessagePort, which makes more sense to me (I
> don't know what it means for a MessagePort to 'load' or 'error'
> outside of the context of a worker). MessagePort.onunload could then
> change to 'onclose' to go with the close() method.
> 
> It seems like over time, we might want to be able to perform other
> operations on a worker and having the worker object might be handy.

Agreed.

> I know this is weird wrt GC when combined with MessagePorts, and I
> don't have a proposed solution.

I don't think we should say much regarding GC at all. All we should say 
is that GC should not affect the operation of the page. I.e. it is not 
allowed to GC an Worker that someone still has references to, or a 
Worker that has XHR loads in progress or timers pending.

Very few other specs mention GC and I haven't noticed that ever being a 
problem. For example everyone agrees that it's a bug that gecko 
sometimes GCs the parent of a node, if you're not actively holding any 
references to anything in the parent chain.

> - It's odd to me that the way to establish a channel to a worker
> depends on whether you are the creator of the worker or not. The
> creator gets a MessagePort to a new channel back from createWorker(),
> but any other function must pass a new MessagePort over the original
> one, and the worker must know to use that secondary port to talk back.
> 
> I would prefer to see something like:
> 
> void Worker.postMessage(DOMString message)
> void Worker.postMessage(DOMString message, MessagePort port)
> 
> That way the way to establish a new channel is the same for all
> callers. It also has the advantage of looking similar to a window's
> postMessage API.

Agreed.

> Here is how the previous two suggestions would look together:
> 
> var worker = new Worker("foo.js");
> worker.onload = function() { ... }
> worker.onerror = function() { ... }
> worker.onunload = function() { ... }  // called when the worker shuts down
> worker.sendMessage("hello!");

So I really like this API. However it makes it completely impossible to 
ever pass worker objects across threads. I.e. we could never allow:

worker1.postMessage("...", worker2);

This would be very strange if we had .onload, .onerror etc on the worker 
object itself since those properties wouldn't make much sense living in 
multiple "threads" at once.

While I agree direct communication between sibling workers is an 
edgecase, it's something I would prefer to not make impossible for 
future versions of the spec.

Though I just realized that we could cover that case using only 
MessagePorts. So we say that you can only communicate with your creator, 
and any children using direct .postMessage. If you want to more complex 
communication patterns then set up MessagePorts.

> - The spec says that as soon as a worker is not reachable (determined
> via GC) from any MessagePort, it is eligible for shutdown. Shutdown
> would attempt to finish all queued messages, but not allow any new
> ones.
> 
> This concerns me because it means that workers will have different
> behavior depending on GC timing. If a worker is not referenced from
> any port, and it sends an XHR, that XHR may or may not be sent
> depending on when GC runs. This is different than how XHR behaves
> normally. Typically, XHR objects that have outstanding IO but no
> referers will not be GC'd until they complete or fail.
> 
> Finally this does not allow use cases such as creating a worker to
> synchronize a local database with the network without ever sending
> notifications back to the parent.
> 
> Maybe workers should stay alive as long as any of the following are true:
> 
> - There is script running in them
> - There are messages to them queued
> - There is a messageport alive anywhere that could send messages to them
> - There are "asynchronous operations" (xhr, timers, database
> operations) inside them outstanding

Agreed. Like I said above, I think the less we say about GC the better. 
GC effects should not be noticeable to the page.

> - Why is there an ownerWindow property on MessagePort? If I understand
> correctly, this is just a synonym for the 'window' object of the
> currently executing script context.  I think it should go away.

If we put postMessage directly on the Worker object we don't need to 
mention MessagePorts in the Web workers spec at all. They can just be an 
orthogonal specs.

> - The purpose of 'import()' on WindowWorker was not immediately
> obvious to me from its name. Should it be 'importScript()'? or
> 'includeScript()' maybe?
> 
> - Should import() accept an array of URLs, so that the UA can fetch
> them in parallel if it has the ability to do that?

Agreed on both.

> - The string URL property on the WindowWorker interface is less useful
> than the parsed structure that window.location has. Can we use
> something like this instead, except making it read-only?

Why do we need it at all?

If we do think it's useful, most of the uses that I've seen for the 
parsed URL structure has been to set the .hash in order to scroll around 
on a page or communicate between iframes of different origins (ugh!!). 
Neither of these applies here I'd say.

> - The "front-line" nomenclature was a bit weird to me. How about "top-level"?

I didn't try to grokk this part yet. Is it just about estabilishing 
lifetime of the worker objects? If so, see my previous comments about GC.

> - Would it be too weird to have createWorker overloaded to take an
> optional name parameter? This would make the behavior similar to
> window.open(), which either opens a new window or reuses an existing
> window with the same name.

What would it be used for? window.open uses the name so you can target 
links at it which doesn't seem like it applies here either.

/ Jonas


From aa at google.com  Tue Aug  5 15:33:05 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 5 Aug 2008 15:33:05 -0700
Subject: [whatwg] Web Workers and MessagePort feedback
In-Reply-To: <4898CBA7.2080801@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
Message-ID: <278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>

Thanks for the quick reply...

On Tue, Aug 5, 2008 at 2:52 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> I know this is weird wrt GC when combined with MessagePorts, and I
>> don't have a proposed solution.
>
> I don't think we should say much regarding GC at all. All we should say is
> that GC should not affect the operation of the page. I.e. it is not allowed
> to GC an Worker that someone still has references to, or a Worker that has
> XHR loads in progress or timers pending.
>
> Very few other specs mention GC and I haven't noticed that ever being a
> problem. For example everyone agrees that it's a bug that gecko sometimes
> GCs the parent of a node, if you're not actively holding any references to
> anything in the parent chain.

The spec doesn't have to mention GC, but it does mention
'reachability' right now and what happens when an object is no longer
reachable. This has an impact on interop, so I think it should be
well-defined.

>> Here is how the previous two suggestions would look together:
>>
>> var worker = new Worker("foo.js");
>> worker.onload = function() { ... }
>> worker.onerror = function() { ... }
>> worker.onunload = function() { ... }  // called when the worker shuts down
>> worker.sendMessage("hello!");
>
> So I really like this API. However it makes it completely impossible to ever
> pass worker objects across threads. I.e. we could never allow:
>
> worker1.postMessage("...", worker2);
>
> This would be very strange if we had .onload, .onerror etc on the worker
> object itself since those properties wouldn't make much sense living in
> multiple "threads" at once.
>
> While I agree direct communication between sibling workers is an edgecase,
> it's something I would prefer to not make impossible for future versions of
> the spec.
>
> Though I just realized that we could cover that case using only
> MessagePorts. So we say that you can only communicate with your creator, and
> any children using direct .postMessage. If you want to more complex
> communication patterns then set up MessagePorts.

Makes sense, and I like how this is something that could be layered in
a later version.

>> - The spec says that as soon as a worker is not reachable (determined
>> via GC) from any MessagePort, it is eligible for shutdown. Shutdown
>> would attempt to finish all queued messages, but not allow any new
>> ones.
>>
>> This concerns me because it means that workers will have different
>> behavior depending on GC timing. If a worker is not referenced from
>> any port, and it sends an XHR, that XHR may or may not be sent
>> depending on when GC runs. This is different than how XHR behaves
>> normally. Typically, XHR objects that have outstanding IO but no
>> referers will not be GC'd until they complete or fail.
>>
>> Finally this does not allow use cases such as creating a worker to
>> synchronize a local database with the network without ever sending
>> notifications back to the parent.
>>
>> Maybe workers should stay alive as long as any of the following are true:
>>
>> - There is script running in them
>> - There are messages to them queued
>> - There is a messageport alive anywhere that could send messages to them
>> - There are "asynchronous operations" (xhr, timers, database
>> operations) inside them outstanding
>
> Agreed. Like I said above, I think the less we say about GC the better. GC
> effects should not be noticeable to the page.

Ok, but right now, the spec says something that contradicts this. It
should either be changed, or removed, if people think the right
behavior goes without saying.

>> - Why is there an ownerWindow property on MessagePort? If I understand
>> correctly, this is just a synonym for the 'window' object of the
>> currently executing script context.  I think it should go away.
>
> If we put postMessage directly on the Worker object we don't need to mention
> MessagePorts in the Web workers spec at all. They can just be an orthogonal
> specs.

This feedback was referencing the separate MessageChannel section of
the web-apps spec. I glommed my feedback together because it was the
first time I'd looked at MessageChannels closely and they go together
for my purposes.

>> - The string URL property on the WindowWorker interface is less useful
>> than the parsed structure that window.location has. Can we use
>> something like this instead, except making it read-only?
>
> Why do we need it at all?
>
> If we do think it's useful, most of the uses that I've seen for the parsed
> URL structure has been to set the .hash in order to scroll around on a page
> or communicate between iframes of different origins (ugh!!). Neither of
> these applies here I'd say.

The protocol, host, hostname, port, pathname, and search properties
are all very useful. An application might want to compare the origin
of a message it receives with it's own host and port, for example.

Providing these split out avoids common parsing mistakes.

>> - The "front-line" nomenclature was a bit weird to me. How about
>> "top-level"?
>
> I didn't try to grokk this part yet. Is it just about estabilishing lifetime
> of the worker objects? If so, see my previous comments about GC.

Yes, that's mostly what it's about.

>> - Would it be too weird to have createWorker overloaded to take an
>> optional name parameter? This would make the behavior similar to
>> window.open(), which either opens a new window or reuses an existing
>> window with the same name.
>
> What would it be used for? window.open uses the name so you can target links
> at it which doesn't seem like it applies here either.

It's intended to be used by shared workers. Multiple pages are
intended to be able to open workers with the same name and URL, and
they get the same worker instance. This allows an application to
coordinate activities across multiple instances of itself.

This may go to my point about having motivations and sample code high
up in the document to establish the goals.

- a


From jonas at sicking.cc  Tue Aug  5 15:49:59 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 05 Aug 2008 15:49:59 -0700
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <Pine.LNX.4.62.0808052100520.5140@hixie.dreamhostps.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>	<489870EA.9050101@sicking.cc>
	<Pine.LNX.4.62.0808052100520.5140@hixie.dreamhostps.com>
Message-ID: <4898D917.2020208@sicking.cc>

Ian Hickson wrote:
> On Tue, 5 Aug 2008, Jonas Sicking wrote:
>> Ian Hickson wrote:
>>>> But, oddity is par for the course in DOM, so I guess we'll just follow the
>>>> HTML 5 spec as-is, initialize readyState to "loading" in the object
>>>> constructor, and keep our fingers crossed.
>>> If you find any problems with doing this, please let me know, so we can
>>> update the spec!
>> The concern I have with doing that is that document created through 
>> other means, such as .implementation.createDocument, 
>> XSLTProccessor.transformToDocument, DOMParser.parse, etc, probably 
>> should not be in the 'uninitialized' state. Especially the last two 
>> should return documents that is in the 'complete' state I would think.
> 
> IE doesn't have any of those mechanisms. In IE,
> 
>    w(new ActiveXObject("Msxml.DOMDocument").readyState);
> 
> ...returns "4", which isn't any of the values I expected.
> 
> Right now the spec says that anything that doesn't go through a parser 
> will remain in the readyState == "loading" state forever. Is that a 
> problem?

The one usecase I have heard for .readystate is to figure out if the 
document has had its onload event fired yet, or if one is coming later. 
In that scenario it would seem unexpected to return "loading" as no 
onload event is about to fire.

> We could define that mechanisms that create a Document object 
> without an associated parser set it to "complete" if you want. I'm not 
> sure that that would be especially useful, although it would, I guess, be 
> somewhat more self-consistent.

Yeah, i think so.

/ Jonas


From t.broyer at gmail.com  Tue Aug  5 16:02:18 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Wed, 6 Aug 2008 01:02:18 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
Message-ID: <a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>

On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
> On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
>>
>> Actually, there is:
>> http://www.w3.org/TR/html5/dom.html#htmlcollection
>> and I believe the "elements" property of HTMLFormElement is actually
>> an HTMLFormControlsCollection:
>> http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
>>
>
> First off, the IndexGetter behavior on the HTMLCollection[1] is the
> authors imagination.

Aren't "document.forms[0]" and "document.forms.myform" working?

> The following example shows that indexed Properties exist on
> NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
> There is no [[ IndexGetter ]] as Cameron likes to make pretend.

This is an "implementation detail" of the ECMAScript binding.

In C#, these would obviously be mapped to indexers ("public
HTMLElement this[int index] { get { ... } }" and "public object
this[String name] { get { ... } }"), and there is no equivalent in
Java.
I guess that in Python and Ruby, which share their "dynamic" nature
with ECMAScript, these wouldn't be true properties as well (i.e. '0'
in document.forms would be False, and document.forms["0"] wouldn't be
equivalent to document.forms[0])


-- 
Thomas Broyer


From shogun70 at westnet.com.au  Tue Aug  5 18:27:08 2008
From: shogun70 at westnet.com.au (Sean Hogan)
Date: Wed, 06 Aug 2008 11:27:08 +1000
Subject: [whatwg] Proposal for a link attribute to replace <a href>
In-Reply-To: <op.ufdoyhkdidj3kv@hp-a0a83fcd39d2.belkin>
References: <9900645.1212458671611.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>	<Pine.LNX.4.62.0807301128510.29977@hixie.dreamhostps.com>	<4896C72B.3050909@sicking.cc>
	<4897488D.4010109@sicking.cc>
	<op.ufdoyhkdidj3kv@hp-a0a83fcd39d2.belkin>
Message-ID: <4898FDEC.4060400@westnet.com.au>

Simon Pieters wrote:
> On Mon, 04 Aug 2008 20:21:01 +0200, Jonas Sicking <jonas at sicking.cc> 
> wrote:
>
>> However if we want to add support for the long list of JS attributes 
>> that exist on <a> elements today on each and every HTML element I 
>> suspect that is going to get messier. Especially considering the 
>> collisions for <base> and <link>. What would myBaseElement.accessKey 
>> do? And is myDivElement.protocol really intuitive what it does?
>
> Also it would quite likely clash with existing content that expects 
> that those attributes don't exist on e.g. divs. (Opera has had 
> problems with some new DOM attributes in WF2 due to legacy.)
>
One idea is to enable all elements to cross-reference to hyperlink ("a" 
or "link") elements.
This could be achieved with a "link" attribute that contains the ID of 
the hyperlink element.
The behavior of elements with @link would be UA defined, but could be:
  onclick: follow the hyperlink on the referenced "a" or "link" elemenr
  oncontextmenu: offer menu options to a) scrollTo the hyperlink element 
or b) follow the hyperlink.

If the link attribute is present but empty then it could be assumed to 
reference getElementsByTagName("a")[0].

Pros:
- don't need to add properties of hyperlink elements to other elements
- Javascript implementations for older browsers would be trivial
- the link attribute can be used as a styling hook
- multiple elements can use the one hyperlink


Cons:
- won't inherit :visited styles



From aa at google.com  Tue Aug  5 23:30:23 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 5 Aug 2008 23:30:23 -0700
Subject: [whatwg] Offline Web Applications feedback
Message-ID: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>

Some quick notes/questions...

- I think the manifest should be some structured, extensible format
such as XML or JSON. The current text-based format is going to quickly
turn into a mess as we add additional fields and rows.

- I like the fallback entry feature, but I don't understand why it is
coupled to opportunistic caching. On the Gears team, we frequently get
requests to add a feature where a certain pattern of URLs will try to
go the network first, and if that fails, will fall through to a
certain cached fallback URL. But nobody has asked for a way to lazily
cache URLs matching a certain pattern. Even if they had, I don't
understand what that has to do with the fallback behavior. Can we
split these apart, and maybe just remove the opportunistic caching
thing entirely?

- It seems odd that you request a resource and the server returns 400
(bad request) we fallback. Maybe it should just be up to the server to
return an error message that directs the user to the fallback URL? I'm
not sure about this one, looking for feedback.

- Maybe this is obvious, but it's not specified what happens when the
server returns a redirect for a resource that is being cached. Do we
cache the redirect chain and replay it?

- In practice, I expect the number of URLs in the online whitelist is
going to be unbounded because of querystrings. I think if this is
going to exist, it has to be a pattern.

- I know you added the behavior of failing loads when a URL is not in
the manifest based on something I said, but now that I read it, it
feels a bit draconian. I wish that developers could somehow easily
control the space of URLs they expect to be online as well as the ones
they expect to be offline. But maybe we should just remove the whole
thing about failing loads of resources not in the manifest and online
whitelist for v1.


- a


From dhtmlkitchen at gmail.com  Tue Aug  5 23:48:52 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 5 Aug 2008 23:48:52 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
Message-ID: <c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>

On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer <t.broyer at gmail.com> wrote:
> On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
>> On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
>>>
>>> Actually, there is:
>>> http://www.w3.org/TR/html5/dom.html#htmlcollection
>>> and I believe the "elements" property of HTMLFormElement is actually
>>> an HTMLFormControlsCollection:
>>> http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
>>>
>>
>> First off, the IndexGetter behavior on the HTMLCollection[1] is the
>> authors imagination.
>
> Aren't "document.forms[0]" and "document.forms.myform" working?
>

Can you be more specific and direct in your reply? It isn't clear what
your point is.

>> The following example shows that indexed Properties exist on
>> NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
>> There is no [[ IndexGetter ]] as Cameron likes to make pretend.
>
> This is an "implementation detail" of the ECMAScript binding.
>

In EcmaScript, the property access operators seem to look like a
"getter" to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this seems implemented as a "getter". A "getter" is a
method that gets the value of a property of that name.

Cameron McCormick is learning JavaScript and in the process, trying to
write a specification. That is dangerous. What is worse is that he is
displaying complete arrogance by refusing to discuss his obvious
mistakes based on what he and Simon imagine browsers are doing and
what they want browsers to do. That, I pointed out, and in a fairly
cordial manner here:
http://lists.w3.org/Archives/Public/public-html/2008Jul/0169.html

But unfortunately Cameron decided to make neither change nor
acknowledgment of this mistake of his (I will probably not have time
or energy to get around to discussing his other mistakes, which are
probably more serious and potentially harmful).

> In C#, these would obviously be mapped to indexers ("public
> HTMLElement this[int index] { get { ... } }" and "public object
> this[String name] { get { ... } }"), and there is no equivalent in
> Java.

What you are calling obvious is not clear to me.

What is clear is that there is a new specification that includes
something about indexed properties on collection objects. My example
made clear that that there is no "getter" for properties, except for
Form in Mozilla, and that is deprecated behavior from Netscape. A much
better alternative exists in browsers today. That behavior is the
properties added to a collection (ES bindings in browsers).

That part of the specification was based on either misunderstanding,
poor observation, or imagination. It has been documented vaguely,
making references to EcmaScript [[Get]], but is apparently supposed to
be used in other languages. Since the item() method is always
available, it is really unnecessary and can only serve to create real
problems by requiring the changing of Stable code.

Here is Cameron demonstrates his failed attempt to understand what the
browser is doing:

http://www.w3.org/TR/DOM-Bindings/#IndexGetter
| If the [IndexGetter]  extended attribute appears on an
| operation with a single unsigned long argument, it indicates
| that an object that implements the interface  can be indexed
| with an unsigned long,

Apparently it would mean something like:

// "operation"
childNodes[ 0 ];

I clearly nicely pointed out Cameron's misunderstanding to him, on this list;

With the methods item() and namedItem() and getNamedItem(), the
bindings in EcmaScript can provide property access to the property.
There is no [[IndexGetter]].

> I guess that in Python and Ruby, which share their "dynamic" nature
> with ECMAScript, these wouldn't be true properties as well

As well? As well as what? And what sort of 'guess'? This sounds like
the type of vague guessing that went into Cameron's wrote up.

>  (i.e. '0'
> in document.forms would be False, and document.forms["0"] wouldn't be
> equivalent to document.forms[0])
>

Why do you say this?

In EcmaScript, document.forms[0] is equivalent to document.forms['0'].
I'm not sure what you're thinking.

Property access calls ToString on the property name. What would be
"shared" with Python and Ruby?

This thread took a turn from the problems in WF 2.0, and the official
documentation of the misconceptions that are so common in a good
number of web devs. I'd like to get back to that next.


>
> --
> Thomas Broyer
>


From cam at mcc.id.au  Wed Aug  6 00:27:13 2008
From: cam at mcc.id.au (Cameron McCormack)
Date: Wed, 6 Aug 2008 17:27:13 +1000
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
Message-ID: <20080806072713.GA26711@arc.mcc.id.au>

Hi Garrett.

Garrett Smith:
> In EcmaScript, the property access operators seem to look like a
> "getter" to Cameron. What they really do is provide access to
> properties added to the collection, or, in one case (on one
> implementation), this seems implemented as a "getter". A "getter" is a
> method that gets the value of a property of that name.

I?m sorry I haven?t had a chance to reply yet, I?ve been quite busy with
other things and haven?t had a chance to work on Web IDL for the last
few weeks.  (Actually I had a half written reply to your earlier mail
drafted, but I hadn?t got to finishing it yet.)

Your tests do show that the HTML collections expose items through real
properties rather than ?fake? ones returned through a custom [[Get]].
So yes that means that HTML 5 won?t be able to use [IndexGetter] etc. to
accurately describe current browser behaviour.  That doesn?t necessarily
mean that [IndexGetter] etc. will have to be changed, just that for the
purpose of documenting HTML collections they?re insufficient.

I think that Web IDL can?t provide as much syntactic help for HTML
collections where the properties are real.  So HTML will probably have
to include a sentence such as:

  In the ECMAScript language binding, for every node in the collection
  there must exist a property on the collection object whose name is
  the index of the node in the collection, and whose value is the node.

With some wording about whether these extra properties take precedence
over other properties on the object due to the interface, etc.  Ian?

> Cameron McCormick is learning JavaScript and in the process, trying to
> write a specification. That is dangerous. What is worse is that he is
> displaying complete arrogance by refusing to discuss his obvious
> mistakes based on what he and Simon imagine browsers are doing and
> what they want browsers to do. That, I pointed out, and in a fairly
> cordial manner here:
> http://lists.w3.org/Archives/Public/public-html/2008Jul/0169.html

I wouldn?t say that I know every detail of ECMA-262 off by heart, so in
that regard I?d agree that I?m learning.

And please don?t take my non-reply as arrogance.  Other things in my
life have just taken precedence the last few weeks. :-)

> But unfortunately Cameron decided to make neither change nor
> acknowledgment of this mistake of his (I will probably not have time
> or energy to get around to discussing his other mistakes, which are
> probably more serious and potentially harmful).

I have certainly tried to write Web IDL with the aim of it being useful
for other specs (like HTML 5) to document actual behaviour, where that?s
interoperable, and to that end I do test implementations.  Now in this
particular instance, I didn?t test whether the properties were real ones
or not, so thanks for that test that shows they are.

> That part of the specification was based on either misunderstanding,
> poor observation, or imagination. It has been documented vaguely,
> making references to EcmaScript [[Get]], but is apparently supposed to
> be used in other languages. Since the item() method is always
> available, it is really unnecessary and can only serve to create real
> problems by requiring the changing of Stable code.

ECMAScript 3rd ed and Java are the only language bindings included in
Web IDL, but I try to make the extended attributes generic enough to be
useful for other languages.

> Here is Cameron demonstrates his failed attempt to understand what the
> browser is doing:
> 
> http://www.w3.org/TR/DOM-Bindings/#IndexGetter
> | If the [IndexGetter]  extended attribute appears on an
> | operation with a single unsigned long argument, it indicates
> | that an object that implements the interface  can be indexed
> | with an unsigned long,
> 
> Apparently it would mean something like:
> 
> // "operation"
> childNodes[ 0 ];
> 
> I clearly nicely pointed out Cameron's misunderstanding to him, on
> this list;
>
> With the methods item() and namedItem() and getNamedItem(), the
> bindings in EcmaScript can provide property access to the property.
> There is no [[IndexGetter]].

As [IndexGetter] is written at the moment, no, but as you?ve shown,
the numeric properties do exist.  And, assuming the wording is fixed up
to say that those real properties do exist on the object, is there still
a problem with using that in an example?

> >  (i.e. '0'
> > in document.forms would be False, and document.forms["0"] wouldn't be
> > equivalent to document.forms[0])
> >
> 
> Why do you say this?
> 
> In EcmaScript, document.forms[0] is equivalent to document.forms['0'].
> I'm not sure what you're thinking.
> 
> Property access calls ToString on the property name. What would be
> "shared" with Python and Ruby?

I think Simon?s saying that something similar, i.e. indexing an object,
could be implemented in Python and Ruby.  I?m not really a Python or
Ruby programmer, but I have seen some documentation on how Python can do
that sort of thing:

  http://docs.python.org/ref/specialnames.html

So if someone were writing Python bindings for some interface written in
Web IDL, then you could consider the [IndexGetter] to be a good guide to
do that sort of thing.

Thanks,

Cameron

-- 
Cameron McCormack ? http://mcc.id.au/


From mjs at apple.com  Wed Aug  6 02:20:32 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 6 Aug 2008 02:20:32 -0700
Subject: [whatwg] Offline Web Applications feedback
In-Reply-To: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
References: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
Message-ID: <017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>


On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:

> Some quick notes/questions...
>
> - I think the manifest should be some structured, extensible format
> such as XML or JSON. The current text-based format is going to quickly
> turn into a mess as we add additional fields and rows.

We've implemented the current format already in WebKit (available in  
nightlies and the Safari 4 Developer Preview).

The format does not seem to have much call for extension and seems  
easy to understand and use as-is.

> - I like the fallback entry feature, but I don't understand why it is
> coupled to opportunistic caching. On the Gears team, we frequently get
> requests to add a feature where a certain pattern of URLs will try to
> go the network first, and if that fails, will fall through to a
> certain cached fallback URL. But nobody has asked for a way to lazily
> cache URLs matching a certain pattern. Even if they had, I don't
> understand what that has to do with the fallback behavior. Can we
> split these apart, and maybe just remove the opportunistic caching
> thing entirely?

I think the idea of opportunistic caching (as I understand it) is that  
the author can be lazy, and not write a manifest at all.

>
>
> - It seems odd that you request a resource and the server returns 400
> (bad request) we fallback. Maybe it should just be up to the server to
> return an error message that directs the user to the fallback URL? I'm
> not sure about this one, looking for feedback.
>
> - Maybe this is obvious, but it's not specified what happens when the
> server returns a redirect for a resource that is being cached. Do we
> cache the redirect chain and replay it?
>
> - In practice, I expect the number of URLs in the online whitelist is
> going to be unbounded because of querystrings. I think if this is
> going to exist, it has to be a pattern.

I agree the online whitelist should allow patterns of some form.

> - I know you added the behavior of failing loads when a URL is not in
> the manifest based on something I said, but now that I read it, it
> feels a bit draconian. I wish that developers could somehow easily
> control the space of URLs they expect to be online as well as the ones
> they expect to be offline. But maybe we should just remove the whole
> thing about failing loads of resources not in the manifest and online
> whitelist for v1.

I think it would be hard to add later after the fact.

Regards,
Maciej



From mjs at apple.com  Wed Aug  6 02:29:14 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 6 Aug 2008 02:29:14 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <20080806072713.GA26711@arc.mcc.id.au>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
Message-ID: <F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>


On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:

> Hi Garrett.
>
> Garrett Smith:
>> In EcmaScript, the property access operators seem to look like a
>> "getter" to Cameron. What they really do is provide access to
>> properties added to the collection, or, in one case (on one
>> implementation), this seems implemented as a "getter". A "getter"  
>> is a
>> method that gets the value of a property of that name.
>
> I?m sorry I haven?t had a chance to reply yet, I?ve been quite busy  
> with
> other things and haven?t had a chance to work on Web IDL for the last
> few weeks.  (Actually I had a half written reply to your earlier mail
> drafted, but I hadn?t got to finishing it yet.)
>
> Your tests do show that the HTML collections expose items through real
> properties rather than ?fake? ones returned through a custom [[Get]].
> So yes that means that HTML 5 won?t be able to use [IndexGetter]  
> etc. to
> accurately describe current browser behaviour.  That doesn?t  
> necessarily
> mean that [IndexGetter] etc. will have to be changed, just that for  
> the
> purpose of documenting HTML collections they?re insufficient.

I think Garret has a valid point (despite his needlessly rude tone)  
that the way we describe magical dynamic properties in a way that  
makes clear they are also visible to the "in" operator and to  
Object.prototype.hasOwnProperty. Are there any DOM bindings that have  
index (or named) properties which are *not* visible in such a way? If  
not, then the current [IndexGetter] definition is useless and we need  
a better formalism.

> I think that Web IDL can?t provide as much syntactic help for HTML
> collections where the properties are real.  So HTML will probably have
> to include a sentence such as:

I also don't understand what is meant to by calling some properties  
"real". I don't think this is a meaningful distinction. The core of  
the point that Garret raised (as far as I can tell) is that the  
properties are visible to has/in checks as well as gettable, and I  
think this is true in all cases of DOM objects with dynamic index/ 
named properties.

>  In the ECMAScript language binding, for every node in the collection
>  there must exist a property on the collection object whose name is
>  the index of the node in the collection, and whose value is the node.
>
> With some wording about whether these extra properties take precedence
> over other properties on the object due to the interface, etc.  Ian?

I think Web IDL should provide a formalism to cater to this, because  
nearly all bindings with special dynamic properties work like this  
afaik. But I think it would have to involve a pseudo-method for the  
"hasOwnProperty" check (which "in" is based on).


Regards,
Maciej



From ian at hixie.ch  Wed Aug  6 04:24:53 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 Aug 2008 11:24:53 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>


Summary:

 * I've written an intro section which shows how the API is expected to be 
   used. I've tried to illustrate each use case that people raised. I will 
   add more tomorrow.

 * I've completely decoupled workers and Window objects.

 * I've moved APIs to a "utils" object, so that we rarely, if ever, have 
   to add members to the global scope (reduces chances of future 
   collisions).

 * I've simplified the way message channels and ports work.

 * I've replaced the URL string with a Location object.


On Mon, 4 Aug 2008, Jonas Sicking wrote:
> 
> So the first comment is the 'window' and 'self' properties. I don't see 
> a reason for these.

We need some self-reference so that people can check for the presence of 
members on the global scope.

'window' was there to allow library re-use. I've now removed it, leaving 
only 'self'.

I have also simplified the spec to remove the Window concepts from the 
workers.

I also removed all the APIs to a "utils" object, leaving the global scope 
with only:

  self - self reference for checking presence of APIs
  location - the address of the script
  name - the name of the worker, if it is shared
  closing - whether the worker is shutting down
  close() - to shut the worker down
  utils - all the APIs
  onconnect - to receive new connections
  onunload - to run any shut down code
  port - the first connection

I can move more of this to 'utils' if people want. Opinions?


> The fact that the only way to communicate between workers and the main 
> browser context is through MessagePorts seems unnecessarily complex as 
> well as differing from how windows communicates using postMessage.

We can't use the Window object postMessage() communication method, because 
it relies on the objects being able to have references to each other. 

I've tried to simplify the MessagePort interface as follows:

 * messages are now queued, and won't be delivered until either the 
   'start()' method on the port is called, or the 'onmessage' attribute is 
   set to some value.

 * messages are now queued, instead of a port becoming inactive when its 
   other side is suspended.

 * I've made the worker receive its first port as a property of the global 
   object (port) instead of having to listen to the 'connect' event 
   (though the connect event still fires, so you can do shared workers).


On Mon, 4 Aug 2008, Aaron Boodman wrote:
> 
> So for example, I would be for moving over a subset of the navigator and 
> location objects as-is (these seem to work well), but against moving 
> over the document.cookie "interface" (it works poorly).

I agree with porting some subset of 'navigator' over, though since the 
relevant parts of 'navigator' aren't defined even for HTML5 yet, I haven't 
yet done this. There's an issue marker in the spec about this. What bits 
would you like defined?


On Tue, 5 Aug 2008, Aaron Boodman wrote:
> 
> The protocol, host, hostname, port, pathname, and search properties are 
> all very useful. An application might want to compare the origin of a 
> message it receives with it's own host and port, for example.

Ok, I've provided a castrated Location interface.


On Tue, 5 Aug 2008, Aaron Boodman wrote:
> 
> - It seems like we might want an object that represents workers. This 
> would allow us put the 'onload' and 'onerror' events from MessagePort 
> there, instead of on MessagePort, which makes more sense to me (I don't 
> know what it means for a MessagePort to 'load' or 'error' outside of the 
> context of a worker).

The main reason for not having a separate Worker object is that I couldn't 
find anything that would go on it other than the port. You'd still want 
the unload messages going to whoever "owns" the port, not whoever created 
the worker, if you passed the port around. Basically, adding a Worker 
object just seemed like it would double the number of objects, and 
potentially the complexity if we also allow Worker objects to be sent 
along channels, without really providing any new features.


> MessagePort.onunload could then change to 'onclose' to go with the 
> close() method.

The main reason I used 'unload' and 'close' is consistency with how the 
rest of the platform works. (With a Window, you call window.close() to 
invoke window.onunload.) I can change that if people want, though I do 
think consistency is worth keeping here.


> - It's odd to me that the way to establish a channel to a worker depends 
> on whether you are the creator of the worker or not. The creator gets a 
> MessagePort to a new channel back from createWorker(), but any other 
> function must pass a new MessagePort over the original one, and the 
> worker must know to use that secondary port to talk back.

In the old mechanism, from the worker's point of view there was only one 
way to get a new connection, onconnect. The changes to simplify the 
mechanism actually introduced a new mechanism, so it is true that we now 
have two mechanisms, one for the initial creation and one for others. Is 
that a problem?

(I don't think it is, you can use either mechanism, as I will show 
tomorrow in the shared worker examples.)


> I would prefer to see something like:
> 
> void Worker.postMessage(DOMString message)
> void Worker.postMessage(DOMString message, MessagePort port)
> 
> That way the way to establish a new channel is the same for all callers. 
> It also has the advantage of looking similar to a window's postMessage 
> API.

With the exception of Worker being called MessagePort, that's exactly the 
API we have now.


> Here is how the previous two suggestions would look together:
> 
> var worker = new Worker("foo.js");
> worker.onload = function() { ... }
> worker.onerror = function() { ... }
> worker.onunload = function() { ... }  // called when the worker shuts down
> worker.sendMessage("hello!");
> 
> var channel = new MessageChannel();
> channel.port1.onmessage = function(e) { ... }
> worker.sendMessage("please return my call", channel.port2);
>
> // called when the channel is closed, either because the worker shut down taking
> // the other end of the port with it, or because the other end of the
> // port was GC'd, or because the other port was explicitly closed.
> channel.port1.onclose = function() { ... }

The above would in fact work right now, unchanged.


> - The spec says that as soon as a worker is not reachable (determined 
> via GC) from any MessagePort, it is eligible for shutdown. Shutdown 
> would attempt to finish all queued messages, but not allow any new ones.
> 
> This concerns me because it means that workers will have different 
> behavior depending on GC timing. If a worker is not referenced from any 
> port, and it sends an XHR, that XHR may or may not be sent depending on 
> when GC runs. This is different than how XHR behaves normally. 
> Typically, XHR objects that have outstanding IO but no referers will not 
> be GC'd until they complete or fail.

We could say that XHR network I/O must complete, but are you saying you 
want the callbacks to fire as well? If so, what prevents an evil site from 
just setting up an infinite sequence of callbacks and having this 
invisible worker do work forever on the user's machine without the user's 
knowledge?

Note that I've simplified a lot of the GC-related stuff. I couldn't remove 
it all, as this does interact with GC to some extent.


> Finally this does not allow use cases such as creating a worker to 
> synchronize a local database with the network without ever sending 
> notifications back to the parent.

This is addressed now, in that a worker automatically keeps a reference to 
its original creator (in the 'port' property of the global object), so 
these won't get GC'ed even if they never communicate, until the creator 
dies.


> Maybe workers should stay alive as long as any of the following are true:
> 
> - There is script running in them
> - There are messages to them queued
> - There is a messageport alive anywhere that could send messages to them
> - There are "asynchronous operations" (xhr, timers, database
> operations) inside them outstanding

The latter is easy to abuse to keep the workers alive hours beyond the 
point at which the user things they are dead. I think this is a serious 
problem.


> API nitpickery
> 
> - Why is there an ownerWindow property on MessagePort? If I understand 
> correctly, this is just a synonym for the 'window' object of the 
> currently executing script context.  I think it should go away.

It's gone.


> - I'm curious as to why MessagePort and WindowWorker do not implement 
> EventTarget. It seems like we may as well reuse it. And at least for 
> WindowWorker, it seems like the same problems of having multiple 
> functions clobber each other that motivated EventTarget would apply.

They do.


> - The purpose of 'import()' on WindowWorker was not immediately obvious 
> to me from its name. Should it be 'importScript()'? or 'includeScript()' 
> maybe?

Changed to importScript().


> - Should import() accept an array of URLs, so that the UA can fetch them 
> in parallel if it has the ability to do that?

We could do that if you like. Is it needed?


> - The "front-line" nomenclature was a bit weird to me. How about 
> "top-level"?

I wanted to avoid "top-level" because I used that with browsing contexts. 
I agree that "front-line" isn't a good term.


> - Would it be too weird to have createWorker overloaded to take an 
> optional name parameter? This would make the behavior similar to 
> window.open(), which either opens a new window or reuses an existing 
> window with the same name.

People seem to dislike overloading in general, but I don't mind. Anyone 
against this?

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


From t.broyer at gmail.com  Wed Aug  6 07:17:33 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Wed, 6 Aug 2008 16:17:33 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
Message-ID: <a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>

On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>
> I think Garret has a valid point (despite his needlessly rude tone) that the
> way we describe magical dynamic properties in a way that makes clear they
> are also visible to the "in" operator and to
> Object.prototype.hasOwnProperty. Are there any DOM bindings that have index
> (or named) properties which are *not* visible in such a way?

You mean "ECMAScript binding implementation", right?

Using reflection on a C# class won't give you a property named "0" or
"myform", even though you can get them using myvariable[0] and
myvariable["myform"].
If I were to implement a binding in Python, I would do the same
(though ? 0 in myvariable ? and ? "myform" in myvariable ? would work
the same as in ECMAScript today; but dir(myvariable) wouldn't show "0"
or "myform")

> If not, then the current [IndexGetter] definition is useless and we need
> a better formalism.

...or rather the ECMAScript binding should define this particularity.

> I think Web IDL should provide a formalism to cater to this, because nearly
> all bindings with special dynamic properties work like this afaik. But I
> think it would have to involve a pseudo-method for the "hasOwnProperty"
> check (which "in" is based on).

hasOwnProperty is ECMAScript-specific.

-- 
Thomas Broyer

From dhtmlkitchen at gmail.com  Wed Aug  6 11:23:33 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 6 Aug 2008 11:23:33 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
Message-ID: <c9e12660808061123j78593fe7va0087c45cb6525ad@mail.gmail.com>

On Wed, Aug 6, 2008 at 2:29 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:
>
>> Hi Garrett.
>>
>> Garrett Smith:
>>>

[snip]

>> Your tests do show that the HTML collections expose items through real
>> properties rather than "fake" ones returned through a custom [[Get]].
>> So yes that means that HTML 5 won't be able to use [IndexGetter] etc. to
>> accurately describe current browser behaviour.  That doesn't necessarily
>> mean that [IndexGetter] etc. will have to be changed, just that for the
>> purpose of documenting HTML collections they're insufficient.
>
> I think Garret has a valid point (despite his needlessly rude tone)

My apologies for being rude.

What would you suggest, Maciej?

If Cameron McCormick ignores constructive criticism for three weeks,
what's to say he'll won't ignore it another three weeks and then
forget about it altogether?

I tried to elicit a response by providing test cases and through
constructive criticism.

The longer that document stays up there in its current form, the
greater the chance that someone will come along and write a book or
blog about this and teach those who are less knowledgeable, and pretty
soon, it starts appearing as a 'bug' on webbugtrack and filed as a bug
against IE. It has happened before. I can see on the JScript blog
right now, a bug that is not a bug, filed against IE, and comments
from the JScript team about how they will "fix" it.

(my name is Garrett BTW)

> that the
> way we describe magical dynamic properties in a way that makes clear they
> are also visible to the "in" operator and to
> Object.prototype.hasOwnProperty. Are there any DOM bindings that have index
> (or named) properties which are *not* visible in such a way? If not, then
> the current [IndexGetter] definition is useless and we need a better
> formalism.

Did you miss the demo that I posted yesterday? The one Cameron
mentioned in his comment, (that you're replying to)? It shows that
implementations will provide access to items/elements that are not
properties on Form.

Also, for NamedNodeMap, it seems that IE and Opera add attributes as
properties to the object,

>
>> I think that Web IDL can't provide as much syntactic help for HTML
>> collections where the properties are real.  So HTML will probably have
>> to include a sentence such as:
>
> I also don't understand what is meant to by calling some properties "real".
> I don't think this is a meaningful distinction. The core of the point that
> Garret raised (as far as I can tell) is that the properties are visible to
> has/in checks as well as gettable, and I think this is true in all cases of
> DOM objects with dynamic index/named properties.
>

That is not true. I posted results and explained in discussion of my
last example that in Firefox3, FORM has:

# [[IndexGetter]]
# No Indexed Property

Additionally, the NamedNodeMap in FF3 and Safari3 will provide access
to properties that would have otherwise have to be got via
'getNamedItem()'

For example:

<body id='test'>
<script>
alert('id' in document.body.attributes)
</script>
</body>

alerts "false" in FF3 and Saf2 (but 'true' in Saf3).

>>  In the ECMAScript language binding, for every node in the collection
>>  there must exist a property on the collection object whose name is
>>  the index of the node in the collection, and whose value is the node.
>>

Sounds fine to me, but I would probably have chosen SHOULD over MUST.

>> With some wording about whether these extra properties take precedence
>> over other properties on the object due to the interface, etc.  Ian?
>

I disagree with that.

Testcases to determine what implementations do and what are the worst
problems to avoid would be the most useful at this point. For example,
a HTMLFORMElement with the name "length", and attribute "length" on
the form.

<form length="10">
  <input name="length">
</form>

Please do make up some test cases. You can post these to the list.
Talk to Ian about where to upload them for reference.

There is a testcase on connect.microsoft.com. I don't have time to
look it up now, (site is kind of hard to use and slow) but was filed
by "PPKPPK" about the "attributes array" (deja vu).

> I think Web IDL should provide a formalism to cater to this, because nearly
> all bindings with special dynamic properties work like this afaik. But I
> think it would have to involve a pseudo-method for the "hasOwnProperty"
> check (which "in" is based on).
>

WRONG.

The 'in' operator is based on the [[HasProperty]], not "hasOwnProperty"


Garrett

>
> Regards,
> Maciej
>
>


From cprince at google.com  Wed Aug  6 11:53:05 2008
From: cprince at google.com (Chris Prince)
Date: Wed, 6 Aug 2008 11:53:05 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
Message-ID: <cd580da00808061153q77b8f79bx41a6d23dd88689b6@mail.gmail.com>

>> - Would it be too weird to have createWorker overloaded to take an
>> optional name parameter? This would make the behavior similar to
>> window.open(), which either opens a new window or reuses an existing
>> window with the same name.
>
> People seem to dislike overloading in general, but I don't mind. Anyone
> against this?

First, let me apologize for not jumping into this thread earlier.  As
I was the one who designed workers, and have been iterating on the
design for nearly two years now (!), I really need to start sharing my
thoughts on this list, instead of just the Gears lists.

I'll try to write up some more detailed comments later, but for the
question above about a 'name' parameter and overoading:

My current thinking is that the best API design for createWorker() is:
   MessagePort createWorker(worker_body, [WorkerOptions])

The reason: workers are a powerful concept, and it's very likely we'll
want to extend them over time.

The 'name' option is just one such case.  Here are a few others:

  - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm')
  - 'isContent' to pass a string or Blob instead of a url
  - 'lifetime' for running beyond the lifetime of a page
  - etc.

I'd say other options are likely to be just as 'important' as name, so
I wouldn't special-case that parameter.  A 'WorkerOptions' parameter
supports naming, but future expansion as well.


From ian at hixie.ch  Wed Aug  6 13:06:33 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 Aug 2008 20:06:33 +0000 (UTC)
Subject: [whatwg] <img> element comments
In-Reply-To: <4890E401.9030407@myrealbox.com>
References: <op.tifz6nv2aw9dld@id-c0020>
	<Pine.LNX.4.62.0611040626450.289@dhalsim.dreamhost.com>
	<454C5294.2040702@lachy.id.au> <454D05B6.2020405@earthlink.net>
	<op.tiigxkr5aw9dld@id-c0020>
	<Pine.LNX.4.64.0708151015040.16834@dhalsim.dreamhost.com>
	<46C3CD0D.5090608@lachy.id.au> <001301c7dffb$44c8e3b0$640a0a0a@pirate>
	<Pine.LNX.4.64.0708170008330.16834@dhalsim.dreamhost.com>
	<596E9E65-0E57-4160-89B4-151F427A71C6@iki.fi>
	<cf95ea12e3c62baaac30e5fadff58cb9@myrealbox.com>
	<Pine.LNX.4.62.0807300307390.29977@hixie.dreamhostps.com>
	<4890E401.9030407@myrealbox.com>
Message-ID: <Pine.LNX.4.62.0808062002580.5136@hixie.dreamhostps.com>

On Wed, 30 Jul 2008, Matthew Paul Thomas wrote:
> >
> > I'm not sure that this usage of <img> is one that the spec today 
> > considers valid. Wouldn't <canvas> be the better way to do this?
>
> Indeed it wouldn't, because <canvas> wouldn't work in w3m at all!

Yeah, you're right, <canvas> wouldn't work particularly well for this.

<meter> is probably the right element for this. You can use fallback 
content in the <meter> element to show text in legacy browsers that don't 
support HTML5.


> And it seems a little excessive to need to construct a <canvas> when all 
> we want to do is stretch an image horizontally.

What you want to do is show a graph, not stretch an image. The image is 
just the way you've found to do it. However, I don't think it's a valid 
solution. You're saying that the meaning of the image is affected by the 
dimensions at which it is drawn, which seems very dubious since it means 
you would lose the meaning if you just copied the image, or if you lost 
the context (the width only means something relative to other widths), 
etc.


> So to reiterate Henri's point, given that browsers (I assume) have to 
> obey disproportionate width= and height= attributes for compatibility 
> with the Web anyway, I don't see the point of requiring authors to make 
> them match the image's proportions.

The point is to catch errors (aspect ratio mistakes) when authors are 
using HTML in a more appropriate manner.

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


From simonp at opera.com  Wed Aug  6 13:42:09 2008
From: simonp at opera.com (Simon Pieters)
Date: Wed, 06 Aug 2008 22:42:09 +0200
Subject: [whatwg] <img> element comments
In-Reply-To: <Pine.LNX.4.62.0808062002580.5136@hixie.dreamhostps.com>
References: <op.tifz6nv2aw9dld@id-c0020>
	<Pine.LNX.4.62.0611040626450.289@dhalsim.dreamhost.com>
	<454C5294.2040702@lachy.id.au> <454D05B6.2020405@earthlink.net>
	<op.tiigxkr5aw9dld@id-c0020>
	<Pine.LNX.4.64.0708151015040.16834@dhalsim.dreamhost.com>
	<46C3CD0D.5090608@lachy.id.au> <001301c7dffb$44c8e3b0$640a0a0a@pirate>
	<Pine.LNX.4.64.0708170008330.16834@dhalsim.dreamhost.com>
	<596E9E65-0E57-4160-89B4-151F427A71C6@iki.fi>
	<cf95ea12e3c62baaac30e5fadff58cb9@myrealbox.com>
	<Pine.LNX.4.62.0807300307390.29977@hixie.dreamhostps.com>
	<4890E401.9030407@myrealbox.com>
	<Pine.LNX.4.62.0808062002580.5136@hixie.dreamhostps.com>
Message-ID: <op.ufhfsjtqidj3kv@hp-a0a83fcd39d2.belkin>

On Wed, 06 Aug 2008 22:06:33 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 30 Jul 2008, Matthew Paul Thomas wrote:
>> >
>> > I'm not sure that this usage of <img> is one that the spec today
>> > considers valid. Wouldn't <canvas> be the better way to do this?
>>
>> Indeed it wouldn't, because <canvas> wouldn't work in w3m at all!
>
> Yeah, you're right, <canvas> wouldn't work particularly well for this.
>
> <meter> is probably the right element for this. You can use fallback
> content in the <meter> element to show text in legacy browsers that don't
> support HTML5.
>
>
>> And it seems a little excessive to need to construct a <canvas> when all
>> we want to do is stretch an image horizontally.
>
> What you want to do is show a graph, not stretch an image. The image is
> just the way you've found to do it. However, I don't think it's a valid
> solution.

I don't think this is any more abuse of <img> than e.g. "A group of images  
that form a single larger picture" or "An image not intended for the user".


> You're saying that the meaning of the image is affected by the
> dimensions at which it is drawn, which seems very dubious since it means
> you would lose the meaning if you just copied the image, or if you lost
> the context (the width only means something relative to other widths),
> etc.

"A group of images that form a single larger picture" would also lose the  
meaning if you just copied the image, or if you lost the context.


>> So to reiterate Henri's point, given that browsers (I assume) have to
>> obey disproportionate width= and height= attributes for compatibility
>> with the Web anyway, I don't see the point of requiring authors to make
>> them match the image's proportions.
>
> The point is to catch errors (aspect ratio mistakes) when authors are
> using HTML in a more appropriate manner.

Validators can still issue warnings to help with aspect ratio mistakes  
without putting up a road block for authors trying to migrate to HTML5.

-- 
Simon Pieters
Opera Software


From simonp at opera.com  Wed Aug  6 13:51:44 2008
From: simonp at opera.com (Simon Pieters)
Date: Wed, 06 Aug 2008 22:51:44 +0200
Subject: [whatwg] <img> element comments
In-Reply-To: <op.ufhfsjtqidj3kv@hp-a0a83fcd39d2.belkin>
References: <op.tifz6nv2aw9dld@id-c0020>
	<Pine.LNX.4.62.0611040626450.289@dhalsim.dreamhost.com>
	<454C5294.2040702@lachy.id.au> <454D05B6.2020405@earthlink.net>
	<op.tiigxkr5aw9dld@id-c0020>
	<Pine.LNX.4.64.0708151015040.16834@dhalsim.dreamhost.com>
	<46C3CD0D.5090608@lachy.id.au> <001301c7dffb$44c8e3b0$640a0a0a@pirate>
	<Pine.LNX.4.64.0708170008330.16834@dhalsim.dreamhost.com>
	<596E9E65-0E57-4160-89B4-151F427A71C6@iki.fi>
	<cf95ea12e3c62baaac30e5fadff58cb9@myrealbox.com>
	<Pine.LNX.4.62.0807300307390.29977@hixie.dreamhostps.com>
	<4890E401.9030407@myrealbox.com>
	<Pine.LNX.4.62.0808062002580.5136@hixie.dreamhostps.com>
	<op.ufhfsjtqidj3kv@hp-a0a83fcd39d2.belkin>
Message-ID: <op.ufhf8itnidj3kv@hp-a0a83fcd39d2.belkin>

On Wed, 06 Aug 2008 22:42:09 +0200, Simon Pieters <simonp at opera.com> wrote:

> Validators can still issue warnings to help with aspect ratio mistakes  
> without putting up a road block for authors trying to migrate to HTML5.

Moreover, currently the spec bans this, which seems legitimate enough:

    <img src=800x600.jpg width=333 height=250>


-- 
Simon Pieters
Opera Software


From michaeln at google.com  Wed Aug  6 17:39:00 2008
From: michaeln at google.com (Michael Nordman)
Date: Wed, 6 Aug 2008 17:39:00 -0700
Subject: [whatwg] Offline Web Applications feedback
In-Reply-To: <017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
References: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
	<017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
Message-ID: <fa2eab050808061739w54e95718ic782e55a7f1ff465@mail.gmail.com>

On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:
>
>  Some quick notes/questions...
>>
>> - I think the manifest should be some structured, extensible format
>> such as XML or JSON. The current text-based format is going to quickly
>> turn into a mess as we add additional fields and rows.
>>
>
> We've implemented the current format already in WebKit (available in
> nightlies and the Safari 4 Developer Preview).
>
> The format does not seem to have much call for extension and seems easy to
> understand and use as-is.


I would prefer to see something more extensible, XML comes to mind.
Extensibility would accommodate the addition of experimental sections and
entry attributes while retaining compatibility with what has been formally
adopted into the spec.


>
>  - I like the fallback entry feature, but I don't understand why it is
>> coupled to opportunistic caching. On the Gears team, we frequently get
>> requests to add a feature where a certain pattern of URLs will try to
>> go the network first, and if that fails, will fall through to a
>> certain cached fallback URL. But nobody has asked for a way to lazily
>> cache URLs matching a certain pattern. Even if they had, I don't
>> understand what that has to do with the fallback behavior. Can we
>> split these apart, and maybe just remove the opportunistic caching
>> thing entirely?
>>
>
> I think the idea of opportunistic caching (as I understand it) is that the
> author can be lazy, and not write a manifest at all.
>

Seems like there are a few different use cases to accommodate. Spitting this
up would add clarity and allow us to make indpendent decisions about  which
should be in or out of the spec.

1) Being lazy about listing images and css located in well known
directories, automatically caching as the app runs.

2) Hijacking parameterized requests and returning a local resource without
incurring any network traffic.

3) Falling back on a local resource iff server/network error.

The first item is really a convenience, the latter two are more significant
features. Gears does the second one. The third item has been requested of
the Gears team, but that one does present interesting versioning issues /
sharp edges (not to mention implementation nightmares for extension
developers).

What if... the server is running a newer version of the app than is
currently in use... depending on type of resource it is, i think there could
be some unexpected consequences, especially when you consider local SQL data
with an expected schema.


>
>>
>> - It seems odd that you request a resource and the server returns 400
>> (bad request) we fallback. Maybe it should just be up to the server to
>> return an error message that directs the user to the fallback URL? I'm
>> not sure about this one, looking for feedback.
>>
>> - Maybe this is obvious, but it's not specified what happens when the
>> server returns a redirect for a resource that is being cached. Do we
>> cache the redirect chain and replay it?
>>
>> - In practice, I expect the number of URLs in the online whitelist is
>> going to be unbounded because of querystrings. I think if this is
>> going to exist, it has to be a pattern.
>>
>
> I agree the online whitelist should allow patterns of some form.
>
>

Without the "fail if not represented in the manifest" behavior, the online
whitelist may not be critical, although this idea has come up with Gears
too, configuration such that...
    <prefix>...&bypassAppCache=1
... any url of that form goes thru to the default resource loading.



>
>  - I know you added the behavior of failing loads when a URL is not in
>> the manifest based on something I said, but now that I read it, it
>> feels a bit draconian. I wish that developers could somehow easily
>> control the space of URLs they expect to be online as well as the ones
>> they expect to be offline. But maybe we should just remove the whole
>> thing about failing loads of resources not in the manifest and online
>> whitelist for v1.
>>
>
> I think it would be hard to add later after the fact.


Not sure the "fail if not represented in manifest" is a good idea either...
are there unintended consequences lurking here... what does this do in the
face of mashups?


>
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080806/f9366e50/attachment.htm>

From aa at google.com  Wed Aug  6 17:48:49 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 6 Aug 2008 17:48:49 -0700
Subject: [whatwg] Offline Web Applications feedback
In-Reply-To: <017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
References: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
	<017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
Message-ID: <278fd46c0808061748u318b4d7aj8f2e89b5c32d2742@mail.gmail.com>

On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:
>
>> Some quick notes/questions...
>>
>> - I think the manifest should be some structured, extensible format
>> such as XML or JSON. The current text-based format is going to quickly
>> turn into a mess as we add additional fields and rows.
>
> We've implemented the current format already in WebKit (available in
> nightlies and the Safari 4 Developer Preview).
>
> The format does not seem to have much call for extension and seems easy to
> understand and use as-is.

I think that the unnamed columns make it difficult to use, because you
have to remember which column does what. I've used a similar
text-based format, the Firefox chrome.manifest format, and I found it
difficult for the same reason.

If we ever needed to have columns that were optional for a given
section, it would become difficult to see if they were specified
because of the lack of names.

If rows ever get long with more than a few columns, there is no
ability to wrap them with the given format. This would come for free
with many other formats.

If we ever needed to add any kind of hierarchy, we would have to
reinvent something like XML, JSON, or YAML.

To me, the idea of inventing a custom one-off format for this is ugly.
I realize this is somewhat a matter of taste (unix uses lots of
line-based format and hey, it works fine for them), so I will drop
this and just leave it as a vote for XML.

>> - I like the fallback entry feature, but I don't understand why it is
>> coupled to opportunistic caching. On the Gears team, we frequently get
>> requests to add a feature where a certain pattern of URLs will try to
>> go the network first, and if that fails, will fall through to a
>> certain cached fallback URL. But nobody has asked for a way to lazily
>> cache URLs matching a certain pattern. Even if they had, I don't
>> understand what that has to do with the fallback behavior. Can we
>> split these apart, and maybe just remove the opportunistic caching
>> thing entirely?
>
> I think the idea of opportunistic caching (as I understand it) is that the
> author can be lazy, and not write a manifest at all.

Ok, I don't think this feature needs to be in this spec then, IMO.
HTTP caching essentially does the same thing, anyway. If it is in the
spec, I think it should be separated from the fallback feature.

- a


From mjs at apple.com  Wed Aug  6 19:03:49 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 6 Aug 2008 19:03:49 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808061123j78593fe7va0087c45cb6525ad@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<c9e12660808061123j78593fe7va0087c45cb6525ad@mail.gmail.com>
Message-ID: <697C0EA4-FF2C-4AEA-A1F7-CDF724773F33@apple.com>


On Aug 6, 2008, at 11:23 AM, Garrett Smith wrote:

>
> My apologies for being rude.
>
> What would you suggest, Maciej?

I would suggest:

a) Point out mistakes courteously.
b) Preferably do so in the appropriate public forum where others can  
see them (I don't see any mail from you on this topic in public- 
webapps).
c) Assume good faith on the part of the editor, even if you do not  
receive an immediate reply.

> If Cameron McCormick ignores constructive criticism for three weeks,
> what's to say he'll won't ignore it another three weeks and then
> forget about it altogether?

Because he has a track record of responding to feedback

> I tried to elicit a response by providing test cases and through
> constructive criticism.
>
> The longer that document stays up there in its current form, the
> greater the chance that someone will come along and write a book or
> blog about this and teach those who are less knowledgeable, and pretty
> soon, it starts appearing as a 'bug' on webbugtrack and filed as a bug
> against IE. It has happened before. I can see on the JScript blog
> right now, a bug that is not a bug, filed against IE, and comments
> from the JScript team about how they will "fix" it.

This lacks all sense of proportion. No one expects a W3C Working Draft  
to be technically correct in all details, and browser vendors and  
authors of books in particular know to test things and not rely on  
specs, and to look at the maturity level of documents. I would hasten  
to add that the mistake they'd make based on this (that '0' in  
HTMLCollection might be false when it is in fact true) is an error  
that would have almost no effect on anyone in practice.

While pointing out technical errors in specifications is extremely  
valuable, please do not assume that just because you found it, it must  
become the most important thing in the world for the editor.

> (my name is Garrett BTW)

My apologies for the typo.

>
>
>> that the
>> way we describe magical dynamic properties in a way that makes  
>> clear they
>> are also visible to the "in" operator and to
>> Object.prototype.hasOwnProperty. Are there any DOM bindings that  
>> have index
>> (or named) properties which are *not* visible in such a way? If  
>> not, then
>> the current [IndexGetter] definition is useless and we need a better
>> formalism.
>
> Did you miss the demo that I posted yesterday? The one Cameron
> mentioned in his comment, (that you're replying to)? It shows that
> implementations will provide access to items/elements that are not
> properties on Form.



>
>
> Also, for NamedNodeMap, it seems that IE and Opera add attributes as
> properties to the object,
>
>>
>>> I think that Web IDL can't provide as much syntactic help for HTML
>>> collections where the properties are real.  So HTML will probably  
>>> have
>>> to include a sentence such as:
>>
>> I also don't understand what is meant to by calling some properties  
>> "real".
>> I don't think this is a meaningful distinction. The core of the  
>> point that
>> Garret raised (as far as I can tell) is that the properties are  
>> visible to
>> has/in checks as well as gettable, and I think this is true in all  
>> cases of
>> DOM objects with dynamic index/named properties.
>>
>
> That is not true. I posted results and explained in discussion of my
> last example that in Firefox3, FORM has:
>
> # [[IndexGetter]]
> # No Indexed Property

[[IndexGetter]] is a spec fiction, as is the notion of whether  
something "has" a property. What is observable is the effects of  
getting the property, hasOwnProperty, in, and attempts to delete or  
put the property. If you describe things in those terms it will be  
easier to know what you mean.

It may be that we need two different ways to spec dynamically  
available properties if the difference matters for compatibility.

> Additionally, the NamedNodeMap in FF3 and Safari3 will provide access
> to properties that would have otherwise have to be got via
> 'getNamedItem()'
>
> For example:
>
> <body id='test'>
> <script>
> alert('id' in document.body.attributes)
> </script>
> </body>
>
> alerts "false" in FF3 and Saf2 (but 'true' in Saf3).

It probably doesn't matter which behavior is chosen on this, since it  
is such an unlikey thing to do, but better to choose one. And better  
for such things to be consistent if possible.


>>> In the ECMAScript language binding, for every node in the collection
>>> there must exist a property on the collection object whose name is
>>> the index of the node in the collection, and whose value is the  
>>> node.
>>>
>
> Sounds fine to me, but I would probably have chosen SHOULD over MUST.
>
>>> With some wording about whether these extra properties take  
>>> precedence
>>> over other properties on the object due to the interface, etc.  Ian?
>>
>
> I disagree with that.
>
> Testcases to determine what implementations do and what are the worst
> problems to avoid would be the most useful at this point. For example,
> a HTMLFORMElement with the name "length", and attribute "length" on
> the form.
>
> <form length="10">
>  <input name="length">
> </form>
>
> Please do make up some test cases. You can post these to the list.
> Talk to Ian about where to upload them for reference.
>
> There is a testcase on connect.microsoft.com. I don't have time to
> look it up now, (site is kind of hard to use and slow) but was filed
> by "PPKPPK" about the "attributes array" (deja vu).
>
>> I think Web IDL should provide a formalism to cater to this,  
>> because nearly
>> all bindings with special dynamic properties work like this afaik.  
>> But I
>> think it would have to involve a pseudo-method for the  
>> "hasOwnProperty"
>> check (which "in" is based on).
>>
>
> WRONG.
>
> The 'in' operator is based on the [[HasProperty]], not  
> "hasOwnProperty"

First of all, [[HasProperty]] is often implemented in terms of  
hasOwnProperty, since it cannot return true unless hasOwnProperty does  
for some element of the prototype chain. Second, how could this  
distinction possibly make a difference in this case? If the property  
is an own property, then there is no operational difference between  
[[HasProperty]] and hasOwnProperty. Thus, your all-caps "WRONG" seems  
a little over the top.

Regards,
Maciej





From mjs at apple.com  Wed Aug  6 19:06:59 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 6 Aug 2008 19:06:59 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
Message-ID: <D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>


On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:

> On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>>
>> I think Garret has a valid point (despite his needlessly rude tone)  
>> that the
>> way we describe magical dynamic properties in a way that makes  
>> clear they
>> are also visible to the "in" operator and to
>> Object.prototype.hasOwnProperty. Are there any DOM bindings that  
>> have index
>> (or named) properties which are *not* visible in such a way?
>
> You mean "ECMAScript binding implementation", right?
>
> Using reflection on a C# class won't give you a property named "0" or
> "myform", even though you can get them using myvariable[0] and
> myvariable["myform"].
> If I were to implement a binding in Python, I would do the same
> (though ? 0 in myvariable ? and ? "myform" in myvariable ? would work
> the same as in ECMAScript today; but dir(myvariable) wouldn't show "0"
> or "myform")
>
>> If not, then the current [IndexGetter] definition is useless and we  
>> need
>> a better formalism.
>
> ...or rather the ECMAScript binding should define this particularity.
>
>> I think Web IDL should provide a formalism to cater to this,  
>> because nearly
>> all bindings with special dynamic properties work like this afaik.  
>> But I
>> think it would have to involve a pseudo-method for the  
>> "hasOwnProperty"
>> check (which "in" is based on).
>
> hasOwnProperty is ECMAScript-specific.

The Web IDL includes specific requirements for how to map an interface  
specified in Web IDL to ECMAScript. So, indeed, that would be the part  
of the Web IDL spec that would be the best place to define this.

Regards,
Maciej



From mjs at apple.com  Wed Aug  6 19:08:20 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 6 Aug 2008 19:08:20 -0700
Subject: [whatwg] Offline Web Applications feedback
In-Reply-To: <278fd46c0808061748u318b4d7aj8f2e89b5c32d2742@mail.gmail.com>
References: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
	<017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
	<278fd46c0808061748u318b4d7aj8f2e89b5c32d2742@mail.gmail.com>
Message-ID: <CB33CA4C-EDF2-4F8B-ADF8-0A44CEF659B6@apple.com>


On Aug 6, 2008, at 5:48 PM, Aaron Boodman wrote:

> On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>>
>> On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:
>>
>>> Some quick notes/questions...
>>>
>>> - I think the manifest should be some structured, extensible format
>>> such as XML or JSON. The current text-based format is going to  
>>> quickly
>>> turn into a mess as we add additional fields and rows.
>>
>> We've implemented the current format already in WebKit (available in
>> nightlies and the Safari 4 Developer Preview).
>>
>> The format does not seem to have much call for extension and seems  
>> easy to
>> understand and use as-is.
>
> I think that the unnamed columns make it difficult to use, because you
> have to remember which column does what. I've used a similar
> text-based format, the Firefox chrome.manifest format, and I found it
> difficult for the same reason.
>
> If we ever needed to have columns that were optional for a given
> section, it would become difficult to see if they were specified
> because of the lack of names.
>
> If rows ever get long with more than a few columns, there is no
> ability to wrap them with the given format. This would come for free
> with many other formats.
>
> If we ever needed to add any kind of hierarchy, we would have to
> reinvent something like XML, JSON, or YAML.
>
> To me, the idea of inventing a custom one-off format for this is ugly.
> I realize this is somewhat a matter of taste (unix uses lots of
> line-based format and hey, it works fine for them), so I will drop
> this and just leave it as a vote for XML.

XML will be ugly even before we extend it.

>>> - I like the fallback entry feature, but I don't understand why it  
>>> is
>>> coupled to opportunistic caching. On the Gears team, we frequently  
>>> get
>>> requests to add a feature where a certain pattern of URLs will try  
>>> to
>>> go the network first, and if that fails, will fall through to a
>>> certain cached fallback URL. But nobody has asked for a way to  
>>> lazily
>>> cache URLs matching a certain pattern. Even if they had, I don't
>>> understand what that has to do with the fallback behavior. Can we
>>> split these apart, and maybe just remove the opportunistic caching
>>> thing entirely?
>>
>> I think the idea of opportunistic caching (as I understand it) is  
>> that the
>> author can be lazy, and not write a manifest at all.
>
> Ok, I don't think this feature needs to be in this spec then, IMO.
> HTTP caching essentially does the same thing, anyway. If it is in the
> spec, I think it should be separated from the fallback feature.

HTTP caching can't promise that all the resources you load when your  
Web App loads will be available offline. I will agree the feature does  
not seem essential.

Regards,
Maciej



From aa at google.com  Wed Aug  6 19:12:57 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 6 Aug 2008 19:12:57 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
Message-ID: <278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>

On Wed, Aug 6, 2008 at 4:24 AM, Ian Hickson <ian at hixie.ch> wrote:
>  * I've written an intro section which shows how the API is expected to be
>   used. I've tried to illustrate each use case that people raised. I will
>   add more tomorrow.

Thanks, that helps a lot.

>  * I've moved APIs to a "utils" object, so that we rarely, if ever, have
>   to add members to the global scope (reduces chances of future
>   collisions).

I am opposed to the utils object. I don't see any precedent for this
anywhere, and it just feels ugly to me. I liked it the way you had it
before, with these APIs in a shared base interface.

>  * I've replaced the URL string with a Location object.

Thanks :).

> I've tried to simplify the MessagePort interface as follows:
>
>  * messages are now queued, and won't be delivered until either the
>   'start()' method on the port is called, or the 'onmessage' attribute is
>   set to some value.
>
>  * messages are now queued, instead of a port becoming inactive when its
>   other side is suspended.

Can you explain the rationale for these two changes?

>  * I've made the worker receive its first port as a property of the global
>   object (port) instead of having to listen to the 'connect' event
>   (though the connect event still fires, so you can do shared workers).

I liked it the way you had it, before. I'd rather the first connection
to a worker wasn't a special case, either for the worker or for the
worker's creator.

That's also one reason why I like having a separate Worker object and
having the two-step process of creating the worker, then sending it a
message. It means that creating a new channel to a worker is always
the same.

> On Mon, 4 Aug 2008, Aaron Boodman wrote:
>>
>> So for example, I would be for moving over a subset of the navigator and
>> location objects as-is (these seem to work well), but against moving
>> over the document.cookie "interface" (it works poorly).
>
> I agree with porting some subset of 'navigator' over, though since the
> relevant parts of 'navigator' aren't defined even for HTML5 yet, I haven't
> yet done this. There's an issue marker in the spec about this. What bits
> would you like defined?

The ones that are most often used for browser detection are most important, so:

- appName
- appCodeName
- appVersion
- platform
- userAgent

I know the whole business of browser detection is a big mess right
now, so if you're working on defining something better, I'd be open to
having some combination of the old navigator object and that new thing
in workers. But there is a lot of code that is very carefully crafted
to analyze the navigator object, so maybe it's best not to mess with
that too much.

> On Tue, 5 Aug 2008, Aaron Boodman wrote:
>>
>> - It seems like we might want an object that represents workers. This
>> would allow us put the 'onload' and 'onerror' events from MessagePort
>> there, instead of on MessagePort, which makes more sense to me (I don't
>> know what it means for a MessagePort to 'load' or 'error' outside of the
>> context of a worker).
>
> The main reason for not having a separate Worker object is that I couldn't
> find anything that would go on it other than the port. You'd still want
> the unload messages going to whoever "owns" the port, not whoever created
> the worker, if you passed the port around. Basically, adding a Worker
> object just seemed like it would double the number of objects, and
> potentially the complexity if we also allow Worker objects to be sent
> along channels, without really providing any new features.

I think that 'load', 'error', and 'unload' could go on the worker. As
far as I can tell, the only thing 'load' and 'error' are used for is
telling the creator of a worker that the worker loaded or failed to
load. In that case, it seems wrong to throw them on MessagePort, since
MessagePorts are also used for many other things.

I also still think that Workers could have their own sendMessage. The
messages sent to this would be delivered to the worker as 'message'
events targeted at WorkerGlobalObject (eliminating the need for
onconnect?). This would make Workers and postMessage very similar to
Window and postMessage, which seems nice to me.

>> MessagePort.onunload could then change to 'onclose' to go with the
>> close() method.
>
> The main reason I used 'unload' and 'close' is consistency with how the
> rest of the platform works. (With a Window, you call window.close() to
> invoke window.onunload.) I can change that if people want, though I do
> think consistency is worth keeping here.

I think the concept of a port becoming inactive is interesting in all
the cases MessagePorts are used, so this should stay. In fact, should
it be called 'oninactive'?

>> I would prefer to see something like:
>>
>> void Worker.postMessage(DOMString message)
>> void Worker.postMessage(DOMString message, MessagePort port)
>>
>> That way the way to establish a new channel is the same for all callers.
>> It also has the advantage of looking similar to a window's postMessage
>> API.
>
> With the exception of Worker being called MessagePort, that's exactly the
> API we have now.
>
>> Here is how the previous two suggestions would look together:
>>
>> var worker = new Worker("foo.js");
>> worker.onload = function() { ... }
>> worker.onerror = function() { ... }
>> worker.onunload = function() { ... }  // called when the worker shuts down
>> worker.sendMessage("hello!");
>>
>> var channel = new MessageChannel();
>> channel.port1.onmessage = function(e) { ... }
>> worker.sendMessage("please return my call", channel.port2);
>>
>> // called when the channel is closed, either because the worker shut down taking
>> // the other end of the port with it, or because the other end of the
>> // port was GC'd, or because the other port was explicitly closed.
>> channel.port1.onclose = function() { ... }
>
> The above would in fact work right now, unchanged.

Fair enough. I still think the distinction between Workers and
MessagePorts may be important.

>> - The spec says that as soon as a worker is not reachable (determined
>> via GC) from any MessagePort, it is eligible for shutdown. Shutdown
>> would attempt to finish all queued messages, but not allow any new ones.
>>
>> This concerns me because it means that workers will have different
>> behavior depending on GC timing. If a worker is not referenced from any
>> port, and it sends an XHR, that XHR may or may not be sent depending on
>> when GC runs. This is different than how XHR behaves normally.
>> Typically, XHR objects that have outstanding IO but no referers will not
>> be GC'd until they complete or fail.
>
> We could say that XHR network I/O must complete, but are you saying you
> want the callbacks to fire as well? If so, what prevents an evil site from
> just setting up an infinite sequence of callbacks and having this
> invisible worker do work forever on the user's machine without the user's
> knowledge?
>
> Note that I've simplified a lot of the GC-related stuff. I couldn't remove
> it all, as this does interact with GC to some extent.
>
>> Finally this does not allow use cases such as creating a worker to
>> synchronize a local database with the network without ever sending
>> notifications back to the parent.
>
> This is addressed now, in that a worker automatically keeps a reference to
> its original creator (in the 'port' property of the global object), so
> these won't get GC'ed even if they never communicate, until the creator
> dies.
>
>> Maybe workers should stay alive as long as any of the following are true:
>>
>> - There is script running in them
>> - There are messages to them queued
>> - There is a messageport alive anywhere that could send messages to them
>> - There are "asynchronous operations" (xhr, timers, database
>> operations) inside them outstanding
>
> The latter is easy to abuse to keep the workers alive hours beyond the
> point at which the user things they are dead. I think this is a serious
> problem.

We talked about this out on IRC, but for those playing along at home:

The idea of having a special relationship between a worker and the
page that created it bothers me. Especially since otherwise, your
proposal elegantly makes all workers independent of particular pages.
One example of how this stinks is that page A could create a worker
and then share it with page B. If the worker creates an XHR, and then
page A shuts down before page B, the behavior is different than if the
pages shut down in the reverse order.

So, I propose the following:

Workers should stay alive as long as:
- They are running script
- They have messages queued for them
- They have a MessagePort alive somewhere that could potentially send
them a message
- They have 'asynchronous tasks' pending inside them (timers, xhr,
database transactions, etc)

The last point could allow workers to stay alive forever, past the
point when any page using the worker has been closed, which would be
bad. So, the browser should forcibly shoot any worker that is, for any
reason, still running once every page or worker that has ever used it
unloads.

The tricky bit is that for this model to be completely consistent, I
think that workers themselves have to also be considered 'asynchronous
tasks'. This is OK I think, since at the end of the day, pages will be
unloaded and everything will get taken down. But I haven't thought it
through all the way, and I admit it does feel really complex. Better
ideas welcome.

>> - I'm curious as to why MessagePort and WindowWorker do not implement
>> EventTarget. It seems like we may as well reuse it. And at least for
>> WindowWorker, it seems like the same problems of having multiple
>> functions clobber each other that motivated EventTarget would apply.
>
> They do.

They didn't, but you've fixed it now :)

>> - Should import() accept an array of URLs, so that the UA can fetch them
>> in parallel if it has the ability to do that?
>
> We could do that if you like. Is it needed?

With the connection limits being upped in all the browsers, I think
this would be a good thing to have from the beginning.

>> - Would it be too weird to have createWorker overloaded to take an
>> optional name parameter? This would make the behavior similar to
>> window.open(), which either opens a new window or reuses an existing
>> window with the same name.
>
> People seem to dislike overloading in general, but I don't mind. Anyone
> against this?

On Wed, Aug 6, 2008 at 11:53 AM, Chris Prince <cprince at google.com> wrote:
> My current thinking is that the best API design for createWorker() is:
>   MessagePort createWorker(worker_body, [WorkerOptions])
>
> The reason: workers are a powerful concept, and it's very likely we'll
> want to extend them over time.
>
> The 'name' option is just one such case.  Here are a few others:
>
>  - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm')
>  - 'isContent' to pass a string or Blob instead of a url
>  - 'lifetime' for running beyond the lifetime of a page
>  - etc.
>
> I'd say other options are likely to be just as 'important' as name, so
> I wouldn't special-case that parameter.  A 'WorkerOptions' parameter
> supports naming, but future expansion as well.

FWIW, Chris's suggestion is also fine with me. In general, I like
these options objects since they are easily extensible.

- a


From aa at google.com  Wed Aug  6 19:28:02 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 6 Aug 2008 19:28:02 -0700
Subject: [whatwg] Offline Web Applications feedback
In-Reply-To: <CB33CA4C-EDF2-4F8B-ADF8-0A44CEF659B6@apple.com>
References: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
	<017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
	<278fd46c0808061748u318b4d7aj8f2e89b5c32d2742@mail.gmail.com>
	<CB33CA4C-EDF2-4F8B-ADF8-0A44CEF659B6@apple.com>
Message-ID: <278fd46c0808061928w6829600ft69c10eeaa9a77475@mail.gmail.com>

On Wed, Aug 6, 2008 at 7:08 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> HTTP caching can't promise that all the resources you load when your Web App
> loads will be available offline.

But neither can this feature, since a resource is only there if the
application previously loaded it for some reason.

- a


From mjs at apple.com  Wed Aug  6 19:49:09 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 6 Aug 2008 19:49:09 -0700
Subject: [whatwg] Offline Web Applications feedback
In-Reply-To: <278fd46c0808061928w6829600ft69c10eeaa9a77475@mail.gmail.com>
References: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
	<017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
	<278fd46c0808061748u318b4d7aj8f2e89b5c32d2742@mail.gmail.com>
	<CB33CA4C-EDF2-4F8B-ADF8-0A44CEF659B6@apple.com>
	<278fd46c0808061928w6829600ft69c10eeaa9a77475@mail.gmail.com>
Message-ID: <D5870E0C-34D4-4B0C-8C3F-E046C275B96A@apple.com>


On Aug 6, 2008, at 7:28 PM, Aaron Boodman wrote:

> On Wed, Aug 6, 2008 at 7:08 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>> HTTP caching can't promise that all the resources you load when  
>> your Web App
>> loads will be available offline.
>
> But neither can this feature, since a resource is only there if the
> application previously loaded it for some reason.

Right, the idea is that you just have your whole web app as an  
opportunistic caching namespace and make sure it loads everything it  
ever needs offline the first time it loads. I don't think this is a  
great feature but I believe this was the design intent/

  - Maciej



From tstarling at wikimedia.org  Wed Aug  6 19:53:25 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Thu, 07 Aug 2008 12:53:25 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
Message-ID: <489A63A5.3060603@wikimedia.org>

Would it be possible to add methods or properties to HTMLMediaElement to
support scripted determination of client codec capabilities?

The supported codecs will no doubt change through the years, as the
technology and the legal situation changes. I'd like to see
determination of codec support (Vorbis, FLAC, Dirac, etc.) as well as
container support (AVI, Ogg, etc.), and I think both can be done fairly
simply by making available an array of supported MIME types.
Implementors could be encouraged, via the standard, to expose both
codecs and containers.

-- Tim Starling
Wikimedia Foundation


From robert at ocallahan.org  Wed Aug  6 19:59:06 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 7 Aug 2008 14:59:06 +1200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489A63A5.3060603@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>
Message-ID: <11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>

That would be nice to have. Unfortunately DirectShow and Quicktime do not
seem to expose the ability to enumerate supported codecs, so it might be
hard to implement for some browsers.

As things stand, you can use <source> elements to offer different formats,
and you can try to play a stream and use script to detect if it fails to
play.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080807/459d633d/attachment.htm>

From aa at google.com  Wed Aug  6 20:02:24 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 6 Aug 2008 20:02:24 -0700
Subject: [whatwg] Offline Web Applications feedback
In-Reply-To: <D5870E0C-34D4-4B0C-8C3F-E046C275B96A@apple.com>
References: <278fd46c0808052330n7087f2b9g97665ea9371b2955@mail.gmail.com>
	<017DDDC8-A42D-4731-97CD-89EB999C65CC@apple.com>
	<278fd46c0808061748u318b4d7aj8f2e89b5c32d2742@mail.gmail.com>
	<CB33CA4C-EDF2-4F8B-ADF8-0A44CEF659B6@apple.com>
	<278fd46c0808061928w6829600ft69c10eeaa9a77475@mail.gmail.com>
	<D5870E0C-34D4-4B0C-8C3F-E046C275B96A@apple.com>
Message-ID: <278fd46c0808062002o3d052bcesaa6c696b74834b91@mail.gmail.com>

On Wed, Aug 6, 2008 at 7:49 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> Right, the idea is that you just have your whole web app as an opportunistic
> caching namespace and make sure it loads everything it ever needs offline
> the first time it loads. I don't think this is a great feature but I believe
> this was the design intent/

I see, thanks.

- a


From dhtmlkitchen at gmail.com  Wed Aug  6 20:20:10 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 6 Aug 2008 20:20:10 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <697C0EA4-FF2C-4AEA-A1F7-CDF724773F33@apple.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<c9e12660808061123j78593fe7va0087c45cb6525ad@mail.gmail.com>
	<697C0EA4-FF2C-4AEA-A1F7-CDF724773F33@apple.com>
Message-ID: <c9e12660808062020x387a29a3l4e0006df2403ad91@mail.gmail.com>

On Wed, Aug 6, 2008 at 7:03 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 6, 2008, at 11:23 AM, Garrett Smith wrote:
>
>>
>> My apologies for being rude.
>>
>> What would you suggest, Maciej?
>
> I would suggest:
>
> a) Point out mistakes courteously.

Done.

> b) Preferably do so in the appropriate public forum where others can see
> them (I don't see any mail from you on this topic in public-webapps).

Sorry, it was public-html, not webapi.

> c) Assume good faith on the part of the editor, even if you do not receive
> an immediate reply.
>

I'll do my best.

>> If Cameron McCormick ignores constructive criticism for three weeks,
>> what's to say he'll won't ignore it another three weeks and then
>> forget about it altogether?
>
> Because he has a track record of responding to feedback
>

These things often change and develop very quickly. Two weeks seems
like long enough. Should it be four?


>> I tried to elicit a response by providing test cases and through
>> constructive criticism.
>>
>> The longer that document stays up there in its current form, the
>> greater the chance that someone will come along and write a book or
>> blog about this and teach those who are less knowledgeable, and pretty
>> soon, it starts appearing as a 'bug' on webbugtrack and filed as a bug
>> against IE. It has happened before. I can see on the JScript blog
>> right now, a bug that is not a bug, filed against IE, and comments
>> from the JScript team about how they will "fix" it.
>
> This lacks all sense of proportion. No one expects a W3C Working Draft to be
> technically correct in all details,

I ask that the standards docs are based on tests and facts; examples
at the very least. I don't think its too much to ask. I don't agree
with the mentality you ascribe to: just add [x] to the document. It is
careless. It is harmful. And, I think it is arrogant.

In fact, browser vendors do implement stuff in working Drafts. For
example, look at the CSSOM disaster that Anne cooked up. I can find
bugs right now on connect.microsoft.com, regarding that spec and I can
observe changed behavior in IE8b1 that closely matches that spec,
deviating from MSIE 7. We have a Working Draft that got adopted
without ever becoming a Technical Recommendation.

> and browser vendors and authors of books
> in particular know to test things

LOL.

What book authors are you talking about?

> and not rely on specs, and to look at the
> maturity level of documents. I would hasten to add that the mistake they'd
> make based on this (that '0' in HTMLCollection might be false when it is in
> fact true) is an error that would have almost no effect on anyone in
> practice.
>
> While pointing out technical errors in specifications is extremely valuable,
> please do not assume that just because you found it, it must become the most
> important thing in the world for the editor.
>

The inference here is that I found something, then, I decided that it
would become the most important thing in the world of the editor.

The only way you could make such inferences is if you read my mind,
right? So, let's have an example of that. Why don't you tell me what
I'm thinking right now, Maciej?


>> # No Indexed Property
>
> [[IndexGetter]] is a spec fiction,

I think I agree with that, it exists in the spec; it is fiction.

> as is the notion of whether something
> "has" a property. What is observable is the effects of getting the property,
> hasOwnProperty, in, and attempts to delete or put the property. If you
> describe things in those terms it will be easier to know what you mean.
>

If you ask a specific question using that terminology, I'll try and
answer it. If I don't have an answer, I'll say "I don't know".

Or post up some examples. That would be great.

>>
>> For example:
>>
>> <body id='test'>
>> <script>
>> alert('id' in document.body.attributes)
>> </script>
>> </body>
>>
>> alerts "false" in FF3 and Saf2 (but 'true' in Saf3).
>
> It probably doesn't matter which behavior is chosen on this, since it is
> such an unlikey thing to do, but better to choose one. And better for such
> things to be consistent if possible.
>

An example would show that IE doesn't support getters.

Creating a bug for IE where a good cross-browser solution exists would
seem unethical.

The indexed items could be specified to be a property, which is more
consistent in implementations.

It could be left to an implementation detail.


>>
>>> I think Web IDL should provide a formalism to cater to this, because
>>> nearly
>>> all bindings with special dynamic properties work like this afaik. But I
>>> think it would have to involve a pseudo-method for the "hasOwnProperty"
>>> check (which "in" is based on).
>>>
>>
>> WRONG.
>>
>> The 'in' operator is based on the [[HasProperty]], not "hasOwnProperty"
>
> First of all, [[HasProperty]] is often implemented in terms of
> hasOwnProperty, since it cannot return true unless hasOwnProperty does for
> some element of the prototype chain. Second, how could this distinction
> possibly make a difference in this case?

You're discussing an implementation detail. Saying that the 'in'
operator uses hasOwnProperty is dead wrong. Rather than apologize, you
decided to try and defend your position. You, of all people on this
list, should be very careful not to mislead others about this topic.
You're probably one who could considered an expert on this topic.

> If the property is an own property,
> then there is no operational difference between [[HasProperty]] and
> hasOwnProperty. Thus, your all-caps "WRONG" seems a little over the top.
>

There would be a difference. The difference would be that
hasOwnProperty is a method in EcmaScript, 'in' is an operator. Just
launch Opera and try this:

<body id='x'>
<script>
alert(({}).hasOwnProperty.call(document.body, 'id'));
alert(({}).hasOwnProperty.call(document.body.attributes, 'id'));
</script>
</body>


and we can see 'false' twice.

That is a bug in Opera.

Opera has a different implementation than Webkit.

But the point is not to confuse others by saying that the in operator
calls 'hasOwnProperty' whatever implementation details exists in your
implementation don't necessarily exist in another.

As far as IDL goes, it seems like a bad idea to specify a property
being added to that object.

In Java, - 0 - would be an illegal identifier. It would be possible to
use Array access in Java, but HTMLCollection, NamedNodeMap, et c
aren't Arrays. There already exists the item() method. The need for
specifying an EcmaScript binding shortcut in ID hasn't been
demonstrated.

The phenomenon we're talking about is non-standardized property-access
that returns a property on an object.

Could this be a note in the EcmaScript Bindings?


Garrett

> Regards,
> Maciej


From bijumaillist at gmail.com  Wed Aug  6 20:26:06 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Wed, 6 Aug 2008 23:26:06 -0400
Subject: [whatwg] VIDEO tag height/width best fit
In-Reply-To: <Pine.LNX.4.62.0808041056360.13029@hixie.dreamhostps.com>
References: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
	<Pine.LNX.4.62.0808041056360.13029@hixie.dreamhostps.com>
Message-ID: <4a27dd80808062026n399a6ce7gf1c64969216a5762@mail.gmail.com>

We found Firefox implementation is wrong for aspect ratio adjustment.
So if it is fixed and the developer really to change aspect ratio how
will he able to it.

Use case are
1) developer wants to give special effect.
2) to fix aspect ratio problem in the existing media.
    like http://simon.html5.org/test/html/semantics/video/002.htm
   (on my PC the girl in the video looks taller)

On Mon, Aug 4, 2008 at 6:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 4 Aug 2008, Biju Gm at il wrote:

> It's automatically like this.
>
> # Video content should be rendered inside the element's playback area such
> # that the video content is shown centered in the playback area at the
> # largest possible size that fits completely within it, with the video
> # content's adjusted aspect ratio being preserved.
>  -- http://www.whatwg.org/specs/web-apps/current-work/#video


From robert at ocallahan.org  Wed Aug  6 20:54:04 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 7 Aug 2008 15:54:04 +1200
Subject: [whatwg] Setting the "title" attribute
Message-ID: <11e306600808062054n959f4e9gd41a5da88a80d665@mail.gmail.com>

http://www.w3.org/html/wg/html5/#dom-tree

>
>    1. If the title element <http://www.w3.org/html/wg/html5/#the-title1>is null, then a new
>    title <http://www.w3.org/html/wg/html5/#title1> element must be created
>    and appended to the head element<http://www.w3.org/html/wg/html5/#the-head0>.
>
>    2. The children of the title element<http://www.w3.org/html/wg/html5/#the-title1>(if any) must all be removed.
>    3. A single Text node whose data is the new value being assigned must
>    be appended to the title element<http://www.w3.org/html/wg/html5/#the-title1>.
>
>
>
Steps 1 and 2 can fire mutation events and cause "the title element" to
become null again. I suppose if that happens, the algorithm should stop, but
the spec should say so.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080807/b023a081/attachment.htm>

From ian at hixie.ch  Wed Aug  6 21:15:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Aug 2008 04:15:19 +0000 (UTC)
Subject: [whatwg] VIDEO tag height/width best fit
In-Reply-To: <4a27dd80808062026n399a6ce7gf1c64969216a5762@mail.gmail.com>
References: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
	<Pine.LNX.4.62.0808041056360.13029@hixie.dreamhostps.com>
	<4a27dd80808062026n399a6ce7gf1c64969216a5762@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808070412040.5136@hixie.dreamhostps.com>

On Wed, 6 Aug 2008, Biju Gm at il wrote:
>
> We found Firefox implementation is wrong for aspect ratio adjustment. So 
> if it is fixed and the developer really to change aspect ratio how will 
> he able to it.
> 
> Use case are
> 1) developer wants to give special effect.
> 2) to fix aspect ratio problem in the existing media.
>     like http://simon.html5.org/test/html/semantics/video/002.htm
>    (on my PC the girl in the video looks taller)

The pixelratio="" attribute allows you to manually correct the ratio if 
the video metadata is incorrectly encoded.

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


From bijumaillist at gmail.com  Wed Aug  6 21:58:07 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Thu, 7 Aug 2008 00:58:07 -0400
Subject: [whatwg] Video : Slow motion, fast forward effects
Message-ID: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>

How can I get Slow motion, fast forward effect on <VIDEO>.?

Is it possible to go backward at various speed also?

TIA
Biju

PS: On Firefox I tried changing "playbackRate" attribute by
        Markup as well as script, but did not see any effect.


From ian at hixie.ch  Wed Aug  6 22:49:31 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Aug 2008 05:49:31 +0000 (UTC)
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>

On Thu, 7 Aug 2008, Biju Gm at il wrote:
>
> How can I get Slow motion, fast forward effect on <VIDEO>.?
> 
> Is it possible to go backward at various speed also?
> 
> PS: On Firefox I tried changing "playbackRate" attribute by
>         Markup as well as script, but did not see any effect.

playbackRate is the right way to do it, but maybe Firefox doesn't yet 
support it.

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


From bijumaillist at gmail.com  Wed Aug  6 23:11:30 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Thu, 7 Aug 2008 02:11:30 -0400
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
Message-ID: <4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>

On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
> playbackRate is the right way to do it, but maybe Firefox doesn't yet
> support it.

So can I assume HTML5 spec also allow playbackRate  to be negative value.
ie to support go backward at various speed....

Thanks
~Biju


From ian at hixie.ch  Wed Aug  6 23:20:29 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Aug 2008 06:20:29 +0000 (UTC)
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>

On Thu, 7 Aug 2008, Biju Gm at il wrote:
>
> On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
> > playbackRate is the right way to do it, but maybe Firefox doesn't yet
> > support it.
> 
> So can I assume HTML5 spec also allow playbackRate  to be negative value.
> ie to support go backward at various speed....

Yes.

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


From tstarling at wikimedia.org  Wed Aug  6 23:53:56 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Thu, 07 Aug 2008 16:53:56 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
Message-ID: <489A9C04.9040006@wikimedia.org>

Robert O'Callahan wrote:
> That would be nice to have. Unfortunately DirectShow and Quicktime do
> not seem to expose the ability to enumerate supported codecs, so it
> might be hard to implement for some browsers.
>
> As things stand, you can use <source> elements to offer different
> formats, and you can try to play a stream and use script to detect if
> it fails to play.

DirectShow and QuickTime can add those interfaces at a later date. When
the backends develop this capability, there should be a standard way to
go the next step and expose it to JavaScript. Otherwise every
implementor will develop their own interface.

In fact, QuickTime already has enough query capabilities for Wikimedia's
purposes. Here is part of the JavaScript code I wrote to embed QuickTime:

    // Detect XiphQT (may throw)
    var xiphQtVersion = false, done = false;
    try {
        xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh', 'Xiph');
        done = true;
    } catch ( e ) {}
    if ( done ) {
        window.clearInterval( this_.qtTimers[params.id] );
        if ( !xiphQtVersion || xiphQtVersion == '0.0' ) {
            // ... show error message "no XiphQt" ...
        }
        // Disable autoplay on back button
        this_.setParam( videoElt, 'AUTOPLAY', 'False' );
    }

It works very well, but it's the sort of thing that I'd rather not have
to implement a dozen times for a dozen incompatible scriptable interfaces.

--
Tim Starling
Wikimedia Foundation


From hsivonen at iki.fi  Thu Aug  7 00:58:07 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Thu, 7 Aug 2008 10:58:07 +0300
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489A9C04.9040006@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
	<489A9C04.9040006@wikimedia.org>
Message-ID: <BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>

On Aug 7, 2008, at 09:53, Tim Starling wrote:

>        xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',  
> 'Xiph');


This kind of FourCC use is exactly the kind of thing I meant earlier  
when I asked if the MIME stuff is really the best match for frameworks.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From ian at hixie.ch  Thu Aug  7 01:01:23 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Aug 2008 08:01:23 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com> 
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>

On Wed, 6 Aug 2008, Aaron Boodman wrote:
> 
> I am opposed to the utils object. I don't see any precedent for this 
> anywhere, and it just feels ugly to me. I liked it the way you had it 
> before, with these APIs in a shared base interface.

Ok. I don't have an opinion on this. Jonas?

In the absence of any arguments either way, my default would be put it all 
on the global object; clashes are manageable, the Window object does it 
that way, and there are enough things that we kinda want to put on the 
global scope anyway (the core worker stuff) that it's not a clear that the 
gain is huge.


> > I've tried to simplify the MessagePort interface as follows:
> >
> >  * messages are now queued, and won't be delivered until either the
> >    'start()' method on the port is called, or the 'onmessage' 
> >    attribute is set to some value.
> >
> >  * messages are now queued, instead of a port becoming inactive when its
> >    other side is suspended.
> 
> Can you explain the rationale for these two changes?

It makes it a lot simpler to use. Before, you ran the risk of the port 
becoming unavailable as you posted to it, now it'll just get sent later. 
Before, you had to wait for hte onload on the port before sending 
messages, now it'll just work.


> >  * I've made the worker receive its first port as a property of the global
> >    object (port) instead of having to listen to the 'connect' event
> >    (though the connect event still fires, so you can do shared 
> >    workers).
> 
> I liked it the way you had it, before. I'd rather the first connection 
> to a worker wasn't a special case, either for the worker or for the 
> worker's creator.

If it's not a special case, in the simple case you have to listen to an 
event just to get the port, which seems excessive. For example this in 
the old model:

   var port;
   onconnect = function (event) {
     port = event.port;
   }

...becomes this in the current model:

   // don't have to do anything!

(It also means that workers by default have a lifetime of the creator even 
if they don't do anything. I guess we don't need this anymore given the 
new lifetime stuff, though.)


> That's also one reason why I like having a separate Worker object and 
> having the two-step process of creating the worker, then sending it a 
> message. It means that creating a new channel to a worker is always the 
> same.

It seems that designing the API to add extra steps is a bad thing 
generally speaking. :-)


> I think that 'load', 'error', and 'unload' could go on the worker. As 
> far as I can tell, the only thing 'load' and 'error' are used for is 
> telling the creator of a worker that the worker loaded or failed to 
> load. In that case, it seems wrong to throw them on MessagePort, since 
> MessagePorts are also used for many other things.
> 
> I also still think that Workers could have their own sendMessage. The 
> messages sent to this would be delivered to the worker as 'message' 
> events targeted at WorkerGlobalObject (eliminating the need for 
> onconnect?). This would make Workers and postMessage very similar to 
> Window and postMessage, which seems nice to me.

How's this for a compromise:

We make the createWorker() methods return a Worker object, but the Worker 
object _inherits_ from MessagePort. So effectively it is a port, but we 
can move the onload and onerror stuff to the Worker object instead of 
having them on all MessagePorts.

Would that work for you?


> > The main reason I used 'unload' and 'close' is consistency with how 
> > the rest of the platform works. (With a Window, you call 
> > window.close() to invoke window.onunload.) I can change that if people 
> > want, though I do think consistency is worth keeping here.
> 
> I think the concept of a port becoming inactive is interesting in all 
> the cases MessagePorts are used, so this should stay. In fact, should it 
> be called 'oninactive'?

Well at this point a port only becomes inactive (and fires unload) when 
the close() method is called or when the other side is owned by a document 
that gets discarded.

Incidentally, I noticed that unload isn't called when it stops being an 
active needed worker (i.e. when its users are all discarded). Should we 
fire unload in that case too? I'm thinking the "Closing orphan workers" 
step should fire unload at the worker.


> > On Mon, 4 Aug 2008, Aaron Boodman wrote:
> >>
> >> So for example, I would be for moving over a subset of the navigator and
> >> location objects as-is (these seem to work well), but against moving
> >> over the document.cookie "interface" (it works poorly).
> >
> > I agree with porting some subset of 'navigator' over, though since the
> > relevant parts of 'navigator' aren't defined even for HTML5 yet, I haven't
> > yet done this. There's an issue marker in the spec about this. What bits
> > would you like defined?
> 
> The ones that are most often used for browser detection are most important, so:
> 
> - appName
> - appCodeName
> - appVersion
> - platform
> - userAgent
> 
> I know the whole business of browser detection is a big mess right now, 
> so if you're working on defining something better, I'd be open to having 
> some combination of the old navigator object and that new thing in 
> workers. But there is a lot of code that is very carefully crafted to 
> analyze the navigator object, so maybe it's best not to mess with that 
> too much.

I'll deal with this separately.


> >> - Should import() accept an array of URLs, so that the UA can fetch 
> >> them in parallel if it has the ability to do that?
> >
> > We could do that if you like. Is it needed?
> 
> With the connection limits being upped in all the browsers, I think this 
> would be a good thing to have from the beginning.

Fair enough. Should they be run in whatever order they load in or should 
they be run in the order given on the aguments?


> On Wed, Aug 6, 2008 at 11:53 AM, Chris Prince <cprince at google.com> wrote:
> > My current thinking is that the best API design for createWorker() is:
> >   MessagePort createWorker(worker_body, [WorkerOptions])
> >
> > The reason: workers are a powerful concept, and it's very likely we'll
> > want to extend them over time.
> >
> > The 'name' option is just one such case.  Here are a few others:
> >
> >  - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm')
> >  - 'isContent' to pass a string or Blob instead of a url
> >  - 'lifetime' for running beyond the lifetime of a page
> >  - etc.
> >
> > I'd say other options are likely to be just as 'important' as name, so
> > I wouldn't special-case that parameter.  A 'WorkerOptions' parameter
> > supports naming, but future expansion as well.
> 
> FWIW, Chris's suggestion is also fine with me. In general, I like
> these options objects since they are easily extensible.

The language should be done via an HTTP Content-Type. isContent can be 
done using data: URLs instead, if this is really needed. If we want to do 
something with a different lifetime I think we want to do it with a much 
clearer API entry point than an option burried in an argument.

So I'm not really convinced about this. I would be interested in other 
viewpoints, though.

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


From chris.double at double.co.nz  Thu Aug  7 01:10:33 2008
From: chris.double at double.co.nz (Chris Double)
Date: Thu, 7 Aug 2008 20:10:33 +1200
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
Message-ID: <c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>

On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 7 Aug 2008, Biju Gm at il wrote:
>>
>> On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
>> > playbackRate is the right way to do it, but maybe Firefox doesn't yet
>> > support it.
>>
>> So can I assume HTML5 spec also allow playbackRate  to be negative value.
>> ie to support go backward at various speed....
>
> Yes.

Would you expect the audio to be played backwards too?

Given that codecs are often highly optimized for forward playback the
cost in memory can be excessive to go the other way. Could there be a
possibility to say 'reverse playback not supported'?

Chris.
-- 
http://www.bluishcoder.co.nz


From maikmerten at googlemail.com  Thu Aug  7 01:28:02 2008
From: maikmerten at googlemail.com (Maik Merten)
Date: Thu, 07 Aug 2008 10:28:02 +0200
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
Message-ID: <489AB212.2020701@googlemail.com>

Chris Double schrieb:
> Given that codecs are often highly optimized for forward playback the
> cost in memory can be excessive to go the other way. Could there be a
> possibility to say 'reverse playback not supported'?

This may be needed anyway, given that with streaming media you can't 
reverse playback, even if the codec would allow it easily (which is not 
the case for MPEG, VC-1, Theora, Dirac, <your favorite codec here>).

An interesting case would also be how to handle playback speeds smaller 
than "1x" in the streaming case, given that you cannot possibly have an 
infinite buffer of input data. Streaming mostly forces a playback speed 
of "+1x" in all cases.

Maik


From tstarling at wikimedia.org  Thu Aug  7 01:33:36 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Thu, 07 Aug 2008 18:33:36 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
References: <489A63A5.3060603@wikimedia.org>	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	<489A9C04.9040006@wikimedia.org>
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
Message-ID: <489AB360.6010408@wikimedia.org>

Henri Sivonen wrote:
> On Aug 7, 2008, at 09:53, Tim Starling wrote:
>
>>        xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
>> 'Xiph');
>
>
> This kind of FourCC use is exactly the kind of thing I meant earlier
> when I asked if the MIME stuff is really the best match for frameworks.
>

FourCC and MIME are not mutually exclusive, see RFC 2361.

-- Tim Starling


From philipj at opera.com  Thu Aug  7 01:57:29 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 07 Aug 2008 15:57:29 +0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <489AB212.2020701@googlemail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<489AB212.2020701@googlemail.com>
Message-ID: <1218099449.6392.8.camel@localhost>

I suggest that the spec allows raising the NOT_SUPPORTED_ERR exception
in response to any playback rate which it cannot provide for the current
configuration. With a netcast you couldn't support any playback rate
except 1.0 without first buffering all the data you want to play at a
faster rate, so changing the playback rate doesn't make sense. Throwing
NOT_SUPPORTED_ERR must be better than just ignoring it, but the question
is if script authors will remember to check for exceptions when setting
the attribute...

Philip

On Thu, 2008-08-07 at 10:28 +0200, Maik Merten wrote:
> Chris Double schrieb:
> > Given that codecs are often highly optimized for forward playback the
> > cost in memory can be excessive to go the other way. Could there be a
> > possibility to say 'reverse playback not supported'?
> 
> This may be needed anyway, given that with streaming media you can't 
> reverse playback, even if the codec would allow it easily (which is not 
> the case for MPEG, VC-1, Theora, Dirac, <your favorite codec here>).
> 
> An interesting case would also be how to handle playback speeds smaller 
> than "1x" in the streaming case, given that you cannot possibly have an 
> infinite buffer of input data. Streaming mostly forces a playback speed 
> of "+1x" in all cases.
> 
> Maik
-- 
Philip J?genstedt
Opera Software



From mikko.rantalainen at peda.net  Thu Aug  7 02:22:51 2008
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Thu, 07 Aug 2008 12:22:51 +0300
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489AB360.6010408@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	<489A9C04.9040006@wikimedia.org>	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
	<489AB360.6010408@wikimedia.org>
Message-ID: <489ABEEB.7080603@peda.net>

Tim Starling wrote:
> Henri Sivonen wrote:
>> On Aug 7, 2008, at 09:53, Tim Starling wrote:
>>
>>>        xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
>>> 'Xiph');
>>
>> This kind of FourCC use is exactly the kind of thing I meant earlier
>> when I asked if the MIME stuff is really the best match for frameworks.
> 
> FourCC and MIME are not mutually exclusive, see RFC 2361.

RFC 2361 doesn't seem to provide a method for describing both video
codec and audio codec for a resource. The same parameter ("codec") is
used for both audio and video codec information but I cannot understand
how a resource that contains both video and audio should be labeled.

RFC 4281 seems to provide a parameter "codecs" that is a comma separated
list of used codecs. The detail required ("MUST") for the "codecs"
parameter seems quite high and I'm afraid that this parameter will not
be correctly used in real world, unfortunately. In theory, this would
seem a good way to provide the information needed for a resource.

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080807/10130933/attachment.pgp>

From jonas at sicking.cc  Thu Aug  7 03:43:18 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 07 Aug 2008 03:43:18 -0700
Subject: [whatwg] Setting the "title" attribute
In-Reply-To: <11e306600808062054n959f4e9gd41a5da88a80d665@mail.gmail.com>
References: <11e306600808062054n959f4e9gd41a5da88a80d665@mail.gmail.com>
Message-ID: <489AD1C6.6000304@sicking.cc>

Robert O'Callahan wrote:
> http://www.w3.org/html/wg/html5/#dom-tree
> 
>        1. If the |title| element
>           <http://www.w3.org/html/wg/html5/#the-title1> is null, then a
>           new |title <http://www.w3.org/html/wg/html5/#title1>| element
>           must be created and appended to the |head| element
>           <http://www.w3.org/html/wg/html5/#the-head0>.
>        2. The children of the |title| element
>           <http://www.w3.org/html/wg/html5/#the-title1> (if any) must
>           all be removed.
>        3. A single |Text| node whose data is the new value being
>           assigned must be appended to the |title| element
>           <http://www.w3.org/html/wg/html5/#the-title1>. 
> 
> 
> Steps 1 and 2 can fire mutation events and cause "the title element" to 
> become null again. I suppose if that happens, the algorithm should stop, 
> but the spec should say so.

Actually, if we make the changes discussed to the mutation events spec, 
we can consider setting the title a compound operation. This means that 
mutation events won't fire until the above algorithm is fully done, so 
any changes to the title element or attribute can simply be considered a 
separate operation.

/ Jonas


From chris.double at double.co.nz  Thu Aug  7 03:57:10 2008
From: chris.double at double.co.nz (Chris Double)
Date: Thu, 7 Aug 2008 22:57:10 +1200
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
Message-ID: <c2e346f90808070357r2d806c3m5aa3d14533d65656@mail.gmail.com>

On Thu, Aug 7, 2008 at 4:58 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
>
> PS: On Firefox I tried changing "playbackRate" attribute by
>        Markup as well as script, but did not see any effect.

playbackRate is not yet supported by the Ogg backend. The build I have
on my site with the gstreamer backend does have it however.

Chris.
-- 
http://www.bluishcoder.co.nz


From tstarling at wikimedia.org  Thu Aug  7 04:23:26 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Thu, 07 Aug 2008 21:23:26 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489ABEEB.7080603@peda.net>
References: <489A63A5.3060603@wikimedia.org>	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	<489A9C04.9040006@wikimedia.org>	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	<489AB360.6010408@wikimedia.org>
	<489ABEEB.7080603@peda.net>
Message-ID: <489ADB2E.50405@wikimedia.org>

Mikko Rantalainen wrote:
> Tim Starling wrote:
>   
>> Henri Sivonen wrote:
>>     
>>> On Aug 7, 2008, at 09:53, Tim Starling wrote:
>>>
>>>       
>>>>        xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
>>>> 'Xiph');
>>>>         
>>> This kind of FourCC use is exactly the kind of thing I meant earlier
>>> when I asked if the MIME stuff is really the best match for frameworks.
>>>       
>> FourCC and MIME are not mutually exclusive, see RFC 2361.
>>     
>
> RFC 2361 doesn't seem to provide a method for describing both video
> codec and audio codec for a resource. The same parameter ("codec") is
> used for both audio and video codec information but I cannot understand
> how a resource that contains both video and audio should be labeled.
>
> RFC 4281 seems to provide a parameter "codecs" that is a comma separated
> list of used codecs. The detail required ("MUST") for the "codecs"
> parameter seems quite high and I'm afraid that this parameter will not
> be correctly used in real world, unfortunately. In theory, this would
> seem a good way to provide the information needed for a resource.
>
>   

Well, I was thinking of an interface which would list the codecs, rather
than the overall file types. But it could be done either way. By file type:

if ( video.supportsType( 'application/ogg;codecs="vorbis,theora"' ) ) {
 ...
}

By codec/container:

if ( 'application/ogg' in video.supportedTypes
  && 'video/theora' in video.supportedTypes
  && 'audio/vorbis' in video.supportedTypes )
{
  ...
}

The first one looks easier in this application, and allows for multiple
backends with different allowed combinations of container and codec. The
second one allows for complete enumeration of client capabilities.

Obviously you couldn't provide an interface to enumerate every possible
combination of container, audio codec and video codec.

The reason this is needed, as opposed to using multiple <source> tags,
is because inevitably, some clients will support certain formats via
<object> (or in our special case, <applet>) and not via <video>.
Querying the browser's <video> capabilities allows JS to decide what
sort of embedding method to use. It's an essential migration feature.

-- Tim Starling


From jeremydo at google.com  Thu Aug  7 10:59:18 2008
From: jeremydo at google.com (Jeremy Doig)
Date: Thu, 7 Aug 2008 10:59:18 -0700
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489ADB2E.50405@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
	<489A9C04.9040006@wikimedia.org>
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>
	<489ADB2E.50405@wikimedia.org>
Message-ID: <35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>

how would this work (say) for different avc profile levels and features (eg:
PAFF support) ?would we require video creators to know the specific
capabilities of every fourCC target ?

On Thu, Aug 7, 2008 at 4:23 AM, Tim Starling <tstarling at wikimedia.org>wrote:

> Mikko Rantalainen wrote:
> > Tim Starling wrote:
> >
> >> Henri Sivonen wrote:
> >>
> >>> On Aug 7, 2008, at 09:53, Tim Starling wrote:
> >>>
> >>>
> >>>>        xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
> >>>> 'Xiph');
> >>>>
> >>> This kind of FourCC use is exactly the kind of thing I meant earlier
> >>> when I asked if the MIME stuff is really the best match for frameworks.
> >>>
> >> FourCC and MIME are not mutually exclusive, see RFC 2361.
> >>
> >
> > RFC 2361 doesn't seem to provide a method for describing both video
> > codec and audio codec for a resource. The same parameter ("codec") is
> > used for both audio and video codec information but I cannot understand
> > how a resource that contains both video and audio should be labeled.
> >
> > RFC 4281 seems to provide a parameter "codecs" that is a comma separated
> > list of used codecs. The detail required ("MUST") for the "codecs"
> > parameter seems quite high and I'm afraid that this parameter will not
> > be correctly used in real world, unfortunately. In theory, this would
> > seem a good way to provide the information needed for a resource.
> >
> >
>
> Well, I was thinking of an interface which would list the codecs, rather
> than the overall file types. But it could be done either way. By file type:
>
> if ( video.supportsType( 'application/ogg;codecs="vorbis,theora"' ) ) {
>  ...
> }
>
> By codec/container:
>
> if ( 'application/ogg' in video.supportedTypes
>  && 'video/theora' in video.supportedTypes
>  && 'audio/vorbis' in video.supportedTypes )
> {
>  ...
> }
>
> The first one looks easier in this application, and allows for multiple
> backends with different allowed combinations of container and codec. The
> second one allows for complete enumeration of client capabilities.
>
> Obviously you couldn't provide an interface to enumerate every possible
> combination of container, audio codec and video codec.
>
> The reason this is needed, as opposed to using multiple <source> tags,
> is because inevitably, some clients will support certain formats via
> <object> (or in our special case, <applet>) and not via <video>.
> Querying the browser's <video> capabilities allows JS to decide what
> sort of embedding method to use. It's an essential migration feature.
>
> -- Tim Starling
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080807/2e29d11e/attachment.htm>

From cprince at google.com  Thu Aug  7 11:16:50 2008
From: cprince at google.com (Chris Prince)
Date: Thu, 7 Aug 2008 11:16:50 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>
Message-ID: <cd580da00808071116w4549d5d5mdecb7710dbf8ebd4@mail.gmail.com>

>> On Wed, Aug 6, 2008 at 11:53 AM, Chris Prince <cprince at google.com> wrote:
>> > My current thinking is that the best API design for createWorker() is:
>> >   MessagePort createWorker(worker_body, [WorkerOptions])
>> >
>> > The reason: workers are a powerful concept, and it's very likely we'll
>> > want to extend them over time.
>> >
>> > The 'name' option is just one such case.  Here are a few others:
>> >
>> >  - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm')
>> >  - 'isContent' to pass a string or Blob instead of a url
>> >  - 'lifetime' for running beyond the lifetime of a page
>> >  - etc.
>> >
>> > I'd say other options are likely to be just as 'important' as name, so
>> > I wouldn't special-case that parameter.  A 'WorkerOptions' parameter
>> > supports naming, but future expansion as well.
>>
>> FWIW, Chris's suggestion is also fine with me. In general, I like
>> these options objects since they are easily extensible.
>
> The language should be done via an HTTP Content-Type. isContent can be
> done using data: URLs instead, if this is really needed. If we want to do
> something with a different lifetime I think we want to do it with a much
> clearer API entry point than an option burried in an argument.
>
> So I'm not really convinced about this. I would be interested in other
> viewpoints, though.

I think you are missing the point.  I'll try to rephrase it:

It is short-sighted to expect you can fully spec something as large as
workers.  This is a significant new concept, and we are only
scratching the surface.

So why back ourselves into a corner?  Let's be smart about the API
design, and allow for future flexibility.

I don't see any downsides to the approach outlined above.  If you have
something specific in mind, please let us know.


From giles at xiph.org  Thu Aug  7 11:53:56 2008
From: giles at xiph.org (Ralph Giles)
Date: Thu, 7 Aug 2008 11:53:56 -0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <1218099449.6392.8.camel@localhost>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<489AB212.2020701@googlemail.com> <1218099449.6392.8.camel@localhost>
Message-ID: <5d88ef650808071153s4fa9339fq7c18dda0ed794495@mail.gmail.com>

On Thu, Aug 7, 2008 at 1:57 AM, Philip J?genstedt <philipj at opera.com> wrote:

> I suggest that the spec allows raising the NOT_SUPPORTED_ERR exception
> in response to any playback rate which it cannot provide for the current
> configuration.

That sounds reasonable. It is a special effect.

> With a netcast you couldn't support any playback rate
> except 1.0 without first buffering all the data you want to play at a
> faster rate, so changing the playback rate doesn't make sense.

Well, it would be better to implement the requested playback rate (and
direction) as long as you can and then rebuffer when necessary. Doing
that well requires extra sophistication in the buffering code, but the
client might just be trying to scrub a bit, which would fit within a
normal seek buffer. Even with live streams, if you try to pull faster
than realtime you'll just buffer-wait, and if you're going slower
you'll fill whatever space you have, then have to drop and restart.

If all you have is a jitter buffer, then sure.

 -r


From jonas at sicking.cc  Thu Aug  7 11:53:15 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 07 Aug 2008 11:53:15 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>	<4898CBA7.2080801@sicking.cc>	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
Message-ID: <489B449B.4020603@sicking.cc>

Aaron Boodman wrote:
> That's also one reason why I like having a separate Worker object and
> having the two-step process of creating the worker, then sending it a
> message. It means that creating a new channel to a worker is always
> the same.

Hixie asked me on IRC why I didn't like the MessagePort solution. So 
here is a list of a few reasons:

I prefer that the createWorker function returns an actual Worker object. 
I think that is what you would expect from an API with such a name. 
Otherwise we should call it something like 
createAWorkerAndReturnAMessagePort. We shouldn't trick people into 
thinking that they have a worker when they really have a MessagePort, 
even if the two APIs happen to mostly align. One way to fix this and 
still keep MessagePorts would be to return a Worker object that has a 
.port property, but that has other problems, see below.

To add to the above point, while the MessagePort API currently aligns 
with the proposed Worker API, this seems likely to change in the future, 
for example to test if a worker is shared between multiple frames.

I in general am not a big fan of the MessagePort API, the whole cloning 
and dying thing is really ugly. I don't think there is much we can do 
about that, but because of it I think we should only use the API when 
it's strictly needed, which seems to be only in fairly complex usecases. 
I am aware that returning a MessagePort basically means that you write 
your code the same way in the trivial cases, but I dislike designing a 
complex API and telling the users "don't pay attention to the full API 
of the object you are using, just think of it as something else and 
it'll work fine".

Exposing a MessagePort as a permanent property, like the global 'port' 
property, has the downside that that object can potentially die if the 
MessagePort is ever passed through postMessage somewhere. This leaves 
the user with a permanent property containing a dead useless object. Not 
exposing it as a permanent property forces things like the onconnect 
event and returning a MessagePort from createWorker.

> On Wed, Aug 6, 2008 at 11:53 AM, Chris Prince <cprince at google.com> wrote:
>> My current thinking is that the best API design for createWorker() is:
>>   MessagePort createWorker(worker_body, [WorkerOptions])
>>
>> The reason: workers are a powerful concept, and it's very likely we'll
>> want to extend them over time.
>>
>> The 'name' option is just one such case.  Here are a few others:
>>
>>  - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm')
>>  - 'isContent' to pass a string or Blob instead of a url
>>  - 'lifetime' for running beyond the lifetime of a page
>>  - etc.
>>
>> I'd say other options are likely to be just as 'important' as name, so
>> I wouldn't special-case that parameter.  A 'WorkerOptions' parameter
>> supports naming, but future expansion as well.
> 
> FWIW, Chris's suggestion is also fine with me. In general, I like
> these options objects since they are easily extensible.

I do sort of prefer the idea of keeping the "give me a worker that is 
potentially shared with other windows" API separate. In fact I think we 
should call it createSharedWorker or some such. But allowing optional 
arguments at the end seems like a good idea. Not sure if that requires 
specific action right now or not though.

/ Jonas


From singer at apple.com  Thu Aug  7 12:08:38 2008
From: singer at apple.com (Dave Singer)
Date: Thu, 7 Aug 2008 12:08:38 -0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
Message-ID: <p06240815c4c0f833337f@[10.0.1.8]>

At 20:10  +1200 7/08/08, Chris Double wrote:
>On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>>  On Thu, 7 Aug 2008, Biju Gm at il wrote:
>>>
>>>  On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>  > playbackRate is the right way to do it, but maybe Firefox doesn't yet
>>>  > support it.
>>>
>>>  So can I assume HTML5 spec also allow playbackRate  to be negative value.
>>>  ie to support go backward at various speed....
>>
>>  Yes.
>
>Would you expect the audio to be played backwards too?

I think that's extra credit and optional.  As you say, even with 
audio coded in independent frames you have to flip the samples, which 
is a pain.  For audio with forward dependencies, correct decoding 
means decoding forwards and then flipping whole chunks of timeline 
(though AAC doesn't suffer too badly if you don't do this, by the 
way).

>
>Given that codecs are often highly optimized for forward playback the
>cost in memory can be excessive to go the other way. Could there be a
>possibility to say 'reverse playback not supported'?

Indeed, on I/P/B video, showing all the frames is also painful.

I think that the spec. should say that degraded playback (e.g. I 
frames only) or no playback (non-reversed audio) may occur...
-- 
David Singer
Apple/QuickTime


From jonas at sicking.cc  Thu Aug  7 12:08:14 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 07 Aug 2008 12:08:14 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>
Message-ID: <489B481E.4060203@sicking.cc>

Ian Hickson wrote:
> On Wed, 6 Aug 2008, Aaron Boodman wrote:
>> I am opposed to the utils object. I don't see any precedent for this 
>> anywhere, and it just feels ugly to me. I liked it the way you had it 
>> before, with these APIs in a shared base interface.
> 
> Ok. I don't have an opinion on this. Jonas?
> 
> In the absence of any arguments either way, my default would be put it all 
> on the global object; clashes are manageable, the Window object does it 
> that way, and there are enough things that we kinda want to put on the 
> global scope anyway (the core worker stuff) that it's not a clear that the 
> gain is huge.

I don't feel very strongly about this right now. It's something we 
started debating at mozilla and I think we'll debate it a bit more 
before coming to a conclusion. I'm fine with putting it in the global 
scope for now. Sorry, i didn't mean to ask for an immediate action on 
this yet.

>> That's also one reason why I like having a separate Worker object and 
>> having the two-step process of creating the worker, then sending it a 
>> message. It means that creating a new channel to a worker is always the 
>> same.
> 
> It seems that designing the API to add extra steps is a bad thing 
> generally speaking. :-)

Though in the vast majority of cases only the first step is needed. A 
second step is only needed in the very complex use cases of:

* Having sibling workers talk directly to each other.
* Having a worker talk directly to a frame from a different origin.
* Having a worker shared across different instances of the app.

>> I think that 'load', 'error', and 'unload' could go on the worker. As 
>> far as I can tell, the only thing 'load' and 'error' are used for is 
>> telling the creator of a worker that the worker loaded or failed to 
>> load. In that case, it seems wrong to throw them on MessagePort, since 
>> MessagePorts are also used for many other things.
>>
>> I also still think that Workers could have their own sendMessage. The 
>> messages sent to this would be delivered to the worker as 'message' 
>> events targeted at WorkerGlobalObject (eliminating the need for 
>> onconnect?). This would make Workers and postMessage very similar to 
>> Window and postMessage, which seems nice to me.
> 
> How's this for a compromise:
> 
> We make the createWorker() methods return a Worker object, but the Worker 
> object _inherits_ from MessagePort. So effectively it is a port, but we 
> can move the onload and onerror stuff to the Worker object instead of 
> having them on all MessagePorts.
> 
> Would that work for you?

I thought about that, but what happens if you pass such an object to 
postMessage? Throws an exception? Only the parts of the API that is a 
MessagePort dies?

One solution I thought about is to have a base interface such as:

interface MessagePort {
   void postMessage(...);
   attribute EventListener onmessage;
   ...
}

Then have

interface Worker : MessagePort {
    bool isShared();
    <worker specific stuff>
}

interface PipePort : MessagePort {
    attribute Window ownerWindow;
    <Pipe specific stuff>
}


And then make the APIs that we want to allow passing around pipe-ends 
take a PipePort object.

The result is basically that workers are separate objects from what's 
returned for (new MessagePipe()).port1, but they share some API.

>>>> - Should import() accept an array of URLs, so that the UA can fetch 
>>>> them in parallel if it has the ability to do that?
>>> We could do that if you like. Is it needed?
>> With the connection limits being upped in all the browsers, I think this 
>> would be a good thing to have from the beginning.
> 
> Fair enough. Should they be run in whatever order they load in or should 
> they be run in the order given on the aguments?

Yes. Another thing is that this function should probably return void and 
always throw if something goes wrong. I doubt that having the server 
return a 404 is expected enough that just returning 'false' will keep 
the program executing fine.

/ Jonas


From jonas at sicking.cc  Thu Aug  7 12:11:11 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 07 Aug 2008 12:11:11 -0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <p06240815c4c0f833337f@[10.0.1.8]>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<p06240815c4c0f833337f@[10.0.1.8]>
Message-ID: <489B48CF.8080309@sicking.cc>

Dave Singer wrote:
> At 20:10  +1200 7/08/08, Chris Double wrote:
>> On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>  On Thu, 7 Aug 2008, Biju Gm at il wrote:
>>>>
>>>>  On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>>  > playbackRate is the right way to do it, but maybe Firefox doesn't 
>>>> yet
>>>>  > support it.
>>>>
>>>>  So can I assume HTML5 spec also allow playbackRate  to be negative 
>>>> value.
>>>>  ie to support go backward at various speed....
>>>
>>>  Yes.
>>
>> Would you expect the audio to be played backwards too?
> 
> I think that's extra credit and optional.  As you say, even with audio 
> coded in independent frames you have to flip the samples, which is a 
> pain.  For audio with forward dependencies, correct decoding means 
> decoding forwards and then flipping whole chunks of timeline (though AAC 
> doesn't suffer too badly if you don't do this, by the way).

Honestly, this seems useless enough that the spec should just say that 
when playback is less than 0 sound should be turned off. I'd hate to see 
engineers working on this just because "the spec says it should work 
that way".

/ Jonas


From singer at apple.com  Thu Aug  7 12:14:26 2008
From: singer at apple.com (Dave Singer)
Date: Thu, 7 Aug 2008 12:14:26 -0700
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
	<489A9C04.9040006@wikimedia.org>
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>
	<489ADB2E.50405@wikimedia.org>
	<35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
Message-ID: <p06240816c4c0f91a6995@[10.0.1.8]>

I think this is a good idea, but one rapidly runs into the problems 
talked about in the 'bucket' RFC, notably that there is not a 
universal language for naming codecs (4ccs etc).  But it's proved 
useful in the past.

In general, the source fallbacks are also a way to 'probe' this, 
albeit in a very different way.

I'm not sure you can always get a definitive answer to the question 
"if I gave you a file with this (extended) MIME type, could you play 
it?" and I am fairly sure that asking the implementation to enumerate 
all the types it could support would be hard.

But this kind of query is really useful on a 'portal' page -- entry 
points to sites.  A script can detect that you need to download oh, 
say, Theora, in order to see the videos in the rest of the site, and 
shows a frame or page that would help you load it. :-)
-- 
David Singer
Apple/QuickTime


From singer at apple.com  Thu Aug  7 12:16:21 2008
From: singer at apple.com (Dave Singer)
Date: Thu, 7 Aug 2008 12:16:21 -0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <489B48CF.8080309@sicking.cc>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<p06240815c4c0f833337f@[10.0.1.8]> <489B48CF.8080309@sicking.cc>
Message-ID: <p06240817c4c0fa4ab102@[10.0.1.8]>

At 12:11  -0700 7/08/08, Jonas Sicking wrote:
>Dave Singer wrote:
>>At 20:10  +1200 7/08/08, Chris Double wrote:
>>>On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>>  On Thu, 7 Aug 2008, Biju Gm at il wrote:
>>>>>
>>>>>  On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>>>  > playbackRate is the right way to do it, but maybe Firefox doesn't yet
>>>>>  > support it.
>>>>>
>>>>>  So can I assume HTML5 spec also allow playbackRate  to be negative value.
>>>>>  ie to support go backward at various speed....
>>>>
>>>>  Yes.
>>>
>>>Would you expect the audio to be played backwards too?
>>
>>I think that's extra credit and optional.  As you say, even with 
>>audio coded in independent frames you have to flip the samples, 
>>which is a pain.  For audio with forward dependencies, correct 
>>decoding means decoding forwards and then flipping whole chunks of 
>>timeline (though AAC doesn't suffer too badly if you don't do this, 
>>by the way).
>
>Honestly, this seems useless enough that the spec should just say 
>that when playback is less than 0 sound should be turned off. I'd 
>hate to see engineers working on this just because "the spec says it 
>should work that way".

I'm sorry if I wasn't clear:  I agree.  If you want your 
implementation to shine, or be used heavily for audio scrubbing, or 
something, go ahead and implement.  But it should not be required. 
("For extra credit")
-- 
David Singer
Apple/QuickTime


From supercanadian at gmail.com  Thu Aug  7 12:23:00 2008
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu, 7 Aug 2008 12:23:00 -0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <489B48CF.8080309@sicking.cc>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<p06240815c4c0f833337f@10.0.1.8> <489B48CF.8080309@sicking.cc>
Message-ID: <84ce626f0808071223m63984236v33050e3106c011f8@mail.gmail.com>

Hello,

On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Dave Singer wrote:
>
>> At 20:10  +1200 7/08/08, Chris Double wrote:
>>
>>> On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>>>  On Thu, 7 Aug 2008, Biju Gm at il wrote:
>>>>
>>>>>
>>>>>  On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>>>  > playbackRate is the right way to do it, but maybe Firefox doesn't
>>>>> yet
>>>>>  > support it.
>>>>>
>>>>>  So can I assume HTML5 spec also allow playbackRate  to be negative
>>>>> value.
>>>>>  ie to support go backward at various speed....
>>>>>
>>>>
>>>>  Yes.
>>>>
>>>
>>> Would you expect the audio to be played backwards too?
>>>
>>
>> I think that's extra credit and optional.  As you say, even with audio
>> coded in independent frames you have to flip the samples, which is a pain.
>>  For audio with forward dependencies, correct decoding means decoding
>> forwards and then flipping whole chunks of timeline (though AAC doesn't
>> suffer too badly if you don't do this, by the way).
>>
>
> Honestly, this seems useless enough that the spec should just say that when
> playback is less than 0 sound should be turned off. I'd hate to see
> engineers working on this just because "the spec says it should work that
> way".
>

I don't think turning sound off is a good idea.

This feature would be used to implement "scrubing".  Like what you see in
Non-Linear Editors... for making movies, etc.  (I.e., grabbing the "position
handle" of the player, and moving it forwards and backwards through the
video, and varying speeds, to find what you are looking for.)

In those types of applications, the audio is on.  And it is important for
usability, for the video editor to hear the sound.

-- 
Charles Iliya Krempeaux, B.Sc.
http://ChangeLog.ca/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080807/803b7c00/attachment.htm>

From singer at apple.com  Thu Aug  7 13:21:59 2008
From: singer at apple.com (Dave Singer)
Date: Thu, 7 Aug 2008 13:21:59 -0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <84ce626f0808071223m63984236v33050e3106c011f8@mail.gmail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<p06240815c4c0f833337f@10.0.1.8> <489B48CF.8080309@sicking.cc>
	<84ce626f0808071223m63984236v33050e3106c011f8@mail.gmail.com>
Message-ID: <p0624081bc4c1099245c9@[10.0.1.8]>

At 12:23  -0700 7/08/08, Charles Iliya Krempeaux wrote:
>I don't think turning sound off is a good idea.

well, the alternative is throwing a Not_supported error and not even 
showing the video.  So, I still feel that for a/v movies, reversing 
the sound should be permitted but not required.

>This feature would be used to implement "scrubing".  Like what you 
>see in Non-Linear Editors... for making movies, etc.  (I.e., 
>grabbing the "position handle" of the player, and moving it forwards 
>and backwards through the video, and varying speeds, to find what 
>you are looking for.)
>
>In those types of applications, the audio is on.  And it is 
>important for usability, for the video editor to hear the sound.

If it's important to the user, they should use a browser which implements it.
-- 
David Singer
Apple/QuickTime


From ian at hixie.ch  Thu Aug  7 13:37:20 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Aug 2008 20:37:20 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <489B481E.4060203@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com> 
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>
	<489B481E.4060203@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808072028300.5140@hixie.dreamhostps.com>

On Thu, 7 Aug 2008, Jonas Sicking wrote:
> > 
> > We make the createWorker() methods return a Worker object, but the 
> > Worker object _inherits_ from MessagePort. So effectively it is a 
> > port, but we can move the onload and onerror stuff to the Worker 
> > object instead of having them on all MessagePorts.
> 
> I thought about that, but what happens if you pass such an object to
> postMessage?

It would just get cloned as usual.

The only things that a Worker object would have that a regular MessagePort 
wouldn't is the onload and onerror things, and they're only relevant until 
the point where you have a connection, so losing them when you clone the 
port is fine.


> One solution I thought about is to have a base interface such as:
> 
> interface MessagePort { ... }
> 
> Then have
> 
> interface Worker : MessagePort {
>    bool isShared();
>    <worker specific stuff>
> }
> 
> interface PipePort : MessagePort {
>    attribute Window ownerWindow;
>    <Pipe specific stuff>
> }

ownerWindow is gone. There's no pipe-specific stuff that wouldn't also 
apply to a worker. There's no worker-specific stuff once the channel has 
been established.

What's the use case for isShared()? What does it do?


I really don't like this idea of making Workers less generic. There's no 
need for it as far as I can tell, and all it does is make things less 
powerful while actually increasing implementation complexity.

Would it be better if instead of createWorker() we called the method 
connectToWorker(), and it creates it as well if the worker is unnamed or 
doesn't yet exist? That would resolve the issue of what looks like a 
constructor not returning an object representing what it constructs?

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


From dhtmlkitchen at gmail.com  Thu Aug  7 13:51:58 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 7 Aug 2008 13:51:58 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
	<D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
Message-ID: <c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>

On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
>
>> On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>>>


>>> I think Web IDL should provide a formalism to cater to this, because
>>> nearly
>>> all bindings with special dynamic properties work like this afaik. But I
>>> think it would have to involve a pseudo-method for the "hasOwnProperty"
>>> check (which "in" is based on).
>>
>> hasOwnProperty is ECMAScript-specific.
>

Yes it is.

> The Web IDL includes specific requirements for how to map an interface
> specified in Web IDL to ECMAScript. So, indeed, that would be the part of
> the Web IDL spec that would be the best place to define this.
>

Since Maciej is probably considered to be an EcmaScript expert and I
am not, and since he had stated that 'in' calls 'hasOwnProperty', and
even continued to argue the claim, it is necessary and appropriate to
demonstrate proof that the 'in' does not call 'hasOwnProperty'.

The following example shows that no implementation calls
hasOwnProperty with use of 'in' operator.

If an implementation were to do that, that would be a bug.

There should be an alert on the second button and no alert on the
first. After both buttons have been clicked once, there should be a
green PASS.

<!DOCTYPE HTML>
<html lang="en">
<head>
      <title>hasOwnProperty</title>
      <style type="text/css">
#fail { background: red; }
#pass { background: #0f0; }
.res { display: none; font-weight: 700; }
      </style>

</head>
<body>
<script type="text/javascript">
      var rec = {}, failed;
      var mo = {
        name : "Maciej",
        title : "unknown"
      };

      Object.prototype.hasOwnProperty = function(p) {
        if(p == "unknown") {
           document.getElementById('fail').style.display='inline-block';
           failed = true;
       }
        alert('calling hasOwnProperty: '+ p);
      };

   function testIn(){
       rec['name'] = true;
       checkPass();
       'name'in mo;
   }

   function testHasOwnProperty(p){
       rec['title'] = true;
       checkPass();
       mo.hasOwnProperty('name');
   }

   function checkPass(){
       if(rec['name'] && rec['title'] && !failed)
       document.getElementById('pass').style.display='inline-block';
   }
</script>
<button onclick="testIn()">testIn()</button>
<button onclick="testHasOwnProperty();"
>testHasOwnProperty;</button>

<div id="fail" class="res">FAIL</div>
<div id="pass" class="res">PASS</div>
</body>
</html>

=============================================

Result in IE8b1, FF3, Webkit, Op9, Saf2.04
* alert on second button,
* PASS

the 'in' operator does not call 'hasOwnProperty'.

'hasOwnProperty' is EcmaScript specific. Whether or not ordinally
indexed properties should be 'own' properties is not a place for IDL
to decide.

Garrett

> Regards,
> Maciej
>
>


From mjs at apple.com  Thu Aug  7 14:16:56 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 7 Aug 2008 14:16:56 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
	<D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
	<c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>
Message-ID: <BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com>


On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:

> On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>>
>> On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
>>
>>> On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>>>>
>
>
>>>> I think Web IDL should provide a formalism to cater to this,  
>>>> because
>>>> nearly
>>>> all bindings with special dynamic properties work like this  
>>>> afaik. But I
>>>> think it would have to involve a pseudo-method for the  
>>>> "hasOwnProperty"
>>>> check (which "in" is based on).
>>>
>>> hasOwnProperty is ECMAScript-specific.
>>
>
> Yes it is.
>
>> The Web IDL includes specific requirements for how to map an  
>> interface
>> specified in Web IDL to ECMAScript. So, indeed, that would be the  
>> part of
>> the Web IDL spec that would be the best place to define this.
>>
>
> Since Maciej is probably considered to be an EcmaScript expert and I
> am not, and since he had stated that 'in' calls 'hasOwnProperty', and
> even continued to argue the claim, it is necessary and appropriate to
> demonstrate proof that the 'in' does not call 'hasOwnProperty'.
>
> The following example shows that no implementation calls
> hasOwnProperty with use of 'in' operator.

The more accurate way to put it would be that the 'in' operator  
performs the same check at ever item in the prototype chain (including  
the original object) that the original value of hasOwnProperty  
performs on only the object itself. You are correct that replacing  
hasOwnProperty either on an object or in its prototype chain will have  
no effect on operation of the 'in' operator.

> 'hasOwnProperty' is EcmaScript specific. Whether or not ordinally
> indexed properties should be 'own' properties is not a place for IDL
> to decide.

It is just as relevant to specify whether a property is an own  
property as it is to specify whether it is visible to the 'in'  
operator. Both are edge cases that may affect interoperability but  
likely won't (since most authors will just get the property, and not  
check for presence). Visibility to the 'in' operator seems to  
observable difference on which you base your distinction between  
'having a getter' and 'having a real property'.

Regards,
Maciej



From cprince at google.com  Thu Aug  7 14:47:02 2008
From: cprince at google.com (Chris Prince)
Date: Thu, 7 Aug 2008 14:47:02 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808072028300.5140@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>
	<489B481E.4060203@sicking.cc>
	<Pine.LNX.4.62.0808072028300.5140@hixie.dreamhostps.com>
Message-ID: <cd580da00808071447y18759e2btac7ee3d20c1fd693@mail.gmail.com>

> Would it be better if instead of createWorker() we called the method
> connectToWorker(), and it creates it as well if the worker is unnamed or
> doesn't yet exist?

That sounds pretty good to me.


From annevk at opera.com  Thu Aug  7 15:22:17 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 08 Aug 2008 00:22:17 +0200
Subject: [whatwg] pushState
In-Reply-To: <4896195C.2040101@sicking.cc>
References: <4889BFDF.7010003@sicking.cc>
	<Pine.LNX.4.62.0807251847070.10848@hixie.dreamhostps.com>
	<488A496E.70604@sicking.cc>
	<Pine.LNX.4.62.0807252154320.10848@hixie.dreamhostps.com>
	<488A6154.9080701@sicking.cc>
	<Pine.LNX.4.62.0807252334590.10848@hixie.dreamhostps.com>
	<488ABBDC.5030308@sicking.cc> <488C7C25.7070003@sicking.cc>
	<Pine.LNX.4.62.0807282229580.10848@hixie.dreamhostps.com>
	<488F57E4.9070508@sicking.cc>
	<Pine.LNX.4.62.0807292009520.30692@hixie.dreamhostps.com>
	<4896195C.2040101@sicking.cc>
Message-ID: <op.ufje3f2c64w2qv@annevk-t60.oslo.opera.com>

On Sun, 03 Aug 2008 22:47:24 +0200, Jonas Sicking <jonas at sicking.cc> wrote:
> Personally I think keeping the URL is fine. We can never entirely  
> prevent pages from having bugs. But instead encourage the safe  
> transitions, and always use safe-looking transitions in examples in the  
> spec.

FWIW, I think the URL argument is the best part of this feature. I don't  
want to lose it!


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From dhtmlkitchen at gmail.com  Thu Aug  7 15:46:04 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 7 Aug 2008 15:46:04 -0700
Subject: [whatwg]  HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
	<D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
	<c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>
	<BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com>
	<c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com>
Message-ID: <c9e12660808071546j6ba762acl8ebc55b73586edb5@mail.gmail.com>

(put back on list, forgot to reply-all)


On Thu, Aug 7, 2008 at 2:16 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:
>
>> On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
>>>
>>>> On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>>>>>
>>
>>
>>>>> I think Web IDL should provide a formalism to cater to this, because
>>>>> nearly
>>>>> all bindings with special dynamic properties work like this afaik. But
>>>>> I
>>>>> think it would have to involve a pseudo-method for the "hasOwnProperty"
>>>>> check (which "in" is based on).
>>>>
>>>> hasOwnProperty is ECMAScript-specific.
>>>
>>
>> Yes it is.
>>
>>> The Web IDL includes specific requirements for how to map an interface
>>> specified in Web IDL to ECMAScript. So, indeed, that would be the part of
>>> the Web IDL spec that would be the best place to define this.
>>>
>>
>> Since Maciej is probably considered to be an EcmaScript expert and I
>> am not, and since he had stated that 'in' calls 'hasOwnProperty', and
>> even continued to argue the claim, it is necessary and appropriate to
>> demonstrate proof that the 'in' does not call 'hasOwnProperty'.
>>
>> The following example shows that no implementation calls
>> hasOwnProperty with use of 'in' operator.
>
> The more accurate way to put it would be that the 'in' operator performs the
> same check at ever item in the prototype chain (including the original
> object) that the original value of hasOwnProperty performs on only the
> object itself. You are correct that replacing hasOwnProperty either on an
> object or in its prototype chain will have no effect on operation of the
> 'in' operator.
>

What you're sort of describing is called [[HasProperty]] in the
specification. In terms of the specification, it is not related to
hasOwnProperty.

[[HasProperty]] is internal and works differently.

| 8.6.2.4 [[HasProperty]](P)
|
| When the [[HasProperty]] method of O is called with property name P,
| the following steps are taken:
| 1. If O has a property with name P, return true.
| 2. If the [[Prototype]] of O is null, return false.
| 3. Call the [[HasProperty]] method of [[Prototype]] with property
| name P.
| 4. Return Result(3).

 [[HasProperty]](P) doesn't call ToString(P). [[HasFeature]] an
internal mechanism.

hasOwnProperty is not internal; it's part of Object.prototype:

| 15.2.4.5  Object.prototype.hasOwnProperty(V)\
|
| When the hasOwnProperty method is called with argument V, the
| following steps are taken:
|
| 1. Let O be this object.
| 2. Call ToString(V)
| 3. If O doesn't have a property with the name given by Result(2),
| return false.
| 4. Return true.
|
| NOTE Unlike [[HasProperty]] (8.6.2.4), this method does not consider
| objects in the prototype chain.


>> 'hasOwnProperty' is EcmaScript specific. Whether or not ordinally
>> indexed properties should be 'own' properties is not a place for IDL
>> to decide.
>
> It is just as relevant to specify whether a property is an own property as
> it is to specify whether it is visible to the 'in' operator. Both are edge
> cases that may affect interoperability but likely won't (since most authors
> will just get the property, and not check for presence). Visibility to the
> 'in' operator seems to observable difference on which you base your
> distinction between 'having a getter' and 'having a real property'.
>

Why should IDL include discussion of the prototype chain?
How can you define the prototype chain for other languages?
How can you declare properties on an object where the property name is
not a valid identifier?

There is no prototype chain in Java. The closest thing would be static
class variables. That still doesn't get around the problem of having
properties with the name '0', '1', et c. Those are not valid
identifiers in Java

namedNodeMap.0

Would not compile.

You can't have invalid identifiers in Java.

The alternative would be to not pretend or try to force other
languages to behave like EcmaScript, but to recognize EcmaScript for
what it is and allow that behavior in that binding; allow property
access using [], as it is implemented in browsers. This would require
nothing more than a simple explanation in the binding.

Garrett

> Regards,
> Maciej
>
>


From smfr at mac.com  Thu Aug  7 15:52:17 2008
From: smfr at mac.com (Simon Fraser)
Date: Thu, 07 Aug 2008 15:52:17 -0700
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <84ce626f0808071223m63984236v33050e3106c011f8@mail.gmail.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<p06240815c4c0f833337f@10.0.1.8> <489B48CF.8080309@sicking.cc>
	<84ce626f0808071223m63984236v33050e3106c011f8@mail.gmail.com>
Message-ID: <7C5020DF-2417-4CF7-BBC1-84D104E76269@mac.com>

On Aug 7, 2008, at 12:23 PM, Charles Iliya Krempeaux wrote:

> Hello,
>
> On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking <jonas at sicking.cc>  
> wrote:
> Dave Singer wrote:
> At 20:10  +1200 7/08/08, Chris Double wrote:
> On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>  On Thu, 7 Aug 2008, Biju Gm at il wrote:
>
>  On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
>  > playbackRate is the right way to do it, but maybe Firefox doesn't  
> yet
>  > support it.
>
>  So can I assume HTML5 spec also allow playbackRate  to be negative  
> value.
>  ie to support go backward at various speed....
>
>  Yes.
>
> Would you expect the audio to be played backwards too?
>
> I think that's extra credit and optional.  As you say, even with  
> audio coded in independent frames you have to flip the samples,  
> which is a pain.  For audio with forward dependencies, correct  
> decoding means decoding forwards and then flipping whole chunks of  
> timeline (though AAC doesn't suffer too badly if you don't do this,  
> by the way).
>
> Honestly, this seems useless enough that the spec should just say  
> that when playback is less than 0 sound should be turned off. I'd  
> hate to see engineers working on this just because "the spec says it  
> should work that way".
>
> I don't think turning sound off is a good idea.
>
> This feature would be used to implement "scrubing".  Like what you  
> see in Non-Linear Editors... for making movies, etc.  (I.e.,  
> grabbing the "position handle" of the player, and moving it forwards  
> and backwards through the video, and varying speeds, to find what  
> you are looking for.)
>
> In those types of applications, the audio is on.  And it is  
> important for usability, for the video editor to hear the sound.

But those applications are not na?vely playing the sound at the  
current playback rate; they are grabbing little snippets of audio  
samples from the current playhead position, and playing them at normal  
rate. I don't think the spec should go into this much detail about  
what happens to audio when rate != 1.

Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080807/017aa1a2/attachment.htm>

From robert at ocallahan.org  Thu Aug  7 15:58:17 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 8 Aug 2008 10:58:17 +1200
Subject: [whatwg] Setting the "title" attribute
In-Reply-To: <489AD1C6.6000304@sicking.cc>
References: <11e306600808062054n959f4e9gd41a5da88a80d665@mail.gmail.com>
	<489AD1C6.6000304@sicking.cc>
Message-ID: <11e306600808071558od21f72ap9bc35bd7aa95acfb@mail.gmail.com>

On Thu, Aug 7, 2008 at 10:43 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Actually, if we make the changes discussed to the mutation events spec, we
> can consider setting the title a compound operation. This means that
> mutation events won't fire until the above algorithm is fully done, so any
> changes to the title element or attribute can simply be considered a
> separate operation.
>

Yeah, this pretty much what Hixie said on IRC. Suits me.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080808/65808d0d/attachment.htm>

From webmartians at verizon.net  Thu Aug  7 16:06:29 2008
From: webmartians at verizon.net (WeBMartians)
Date: Thu, 07 Aug 2008 19:06:29 -0400
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <7C5020DF-2417-4CF7-BBC1-84D104E76269@mac.com>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<Pine.LNX.4.62.0808070535010.5136@hixie.dreamhostps.com>
	<4a27dd80808062311r61e67b4bi6580749b22767ec6@mail.gmail.com>
	<Pine.LNX.4.62.0808070620160.5136@hixie.dreamhostps.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<p06240815c4c0f833337f@10.0.1.8> <489B48CF.8080309@sicking.cc>
	<84ce626f0808071223m63984236v33050e3106c011f8@mail.gmail.com>
	<7C5020DF-2417-4CF7-BBC1-84D104E76269@mac.com>
Message-ID: <6F28EE0F3FE648EAB4498288F2ED1128@pirate>

The big VoDS (Broadbus/Motorola, SeaChange, Arroyo...) do not offer audio when the play rate is anything other than +1.0.
________________________________
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Simon Fraser
Sent: Thursday, 2008 August 07 18:52
To: Charles Iliya Krempeaux
Cc: Biju Gm at il; Dave Singer; whatwg at lists.whatwg.org; Chris Double; Ian Hickson; Jonas Sicking
Subject: Re: [whatwg] Video : Slow motion, fast forward effects

On Aug 7, 2008, at 12:23 PM, Charles Iliya Krempeaux wrote:
	Hello,
	On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking <jonas at sicking.cc> wrote:
		Dave Singer wrote:
			At 20:10  +1200 7/08/08, Chris Double wrote:
				On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
					 On Thu, 7 Aug 2008, Biju Gm at il wrote:
					 On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> wrote:
					 > playbackRate is the right way to do it, but maybe Firefox doesn't yet
					 > support it.
					
					 So can I assume HTML5 spec also allow playbackRate  to be negative value.
					 ie to support go backward at various speed....

					 Yes.

				Would you expect the audio to be played backwards too?

			I think that's extra credit and optional.  As you say, even with audio coded in independent frames you have
to flip the samples, which is a pain.  For audio with forward dependencies, correct decoding means decoding forwards and then
flipping whole chunks of timeline (though AAC doesn't suffer too badly if you don't do this, by the way).

		Honestly, this seems useless enough that the spec should just say that when playback is less than 0 sound should be
turned off. I'd hate to see engineers working on this just because "the spec says it should work that way".

	I don't think turning sound off is a good idea.

	This feature would be used to implement "scrubing".  Like what you see in Non-Linear Editors... for making movies, etc.
(I.e., grabbing the "position handle" of the player, and moving it forwards and backwards through the video, and varying speeds, to
find what you are looking for.)

	In those types of applications, the audio is on.  And it is important for usability, for the video editor to hear the sound.

But those applications are not na?vely playing the sound at the current playback rate; they are grabbing little snippets of audio
samples from the current playhead position, and playing them at normal rate. I don't think the spec should go into this much detail
about what happens to audio when rate != 1.

Simon



From robert at ocallahan.org  Thu Aug  7 16:12:12 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 8 Aug 2008 11:12:12 +1200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489A9C04.9040006@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
	<489A9C04.9040006@wikimedia.org>
Message-ID: <11e306600808071612q470e7256k2072337f4da8a32f@mail.gmail.com>

On Thu, Aug 7, 2008 at 6:53 PM, Tim Starling <tstarling at wikimedia.org>wrote:

> DirectShow and QuickTime can add those interfaces at a later date. When
> the backends develop this capability, there should be a standard way to
> go the next step and expose it to JavaScript. Otherwise every
> implementor will develop their own interface.


Sure. But the interface has to be able to say "I don't know". And then we're
relying on authors to do the right thing if they get that answer ... which
is always a worry.

In fact, QuickTime already has enough query capabilities for Wikimedia's
> purposes.


Probing for a particular component is a different problem from listing all
supported codecs, which is what I thought you were asking for. I suppose we
could hardcode a list of well-known components along with the codecs they
support and then probe for them to estimate what codecs are supported. But,
yuck.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080808/0ab3d390/attachment.htm>

From jonas at sicking.cc  Thu Aug  7 18:38:33 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 07 Aug 2008 18:38:33 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808072028300.5140@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>	<Pine.LNX.4.62.0808070714540.5140@hixie.dreamhostps.com>	<489B481E.4060203@sicking.cc>
	<Pine.LNX.4.62.0808072028300.5140@hixie.dreamhostps.com>
Message-ID: <489BA399.6060901@sicking.cc>

Ian Hickson wrote:
> On Thu, 7 Aug 2008, Jonas Sicking wrote:
>>> We make the createWorker() methods return a Worker object, but the 
>>> Worker object _inherits_ from MessagePort. So effectively it is a 
>>> port, but we can move the onload and onerror stuff to the Worker 
>>> object instead of having them on all MessagePorts.
>> I thought about that, but what happens if you pass such an object to
>> postMessage?
> 
> It would just get cloned as usual.

This seems to be exactly the same thing as what the spec says now, just 
with a different name.

> The only things that a Worker object would have that a regular MessagePort 
> wouldn't is the onload and onerror things, and they're only relevant until 
> the point where you have a connection, so losing them when you clone the 
> port is fine.
> 
> 
>> One solution I thought about is to have a base interface such as:
>>
>> interface MessagePort { ... }
>>
>> Then have
>>
>> interface Worker : MessagePort {
>>    bool isShared();
>>    <worker specific stuff>
>> }
>>
>> interface PipePort : MessagePort {
>>    attribute Window ownerWindow;
>>    <Pipe specific stuff>
>> }
> 
> ownerWindow is gone. There's no pipe-specific stuff that wouldn't also 
> apply to a worker. There's no worker-specific stuff once the channel has 
> been established.

I think it's much overly optimistic to think that we will never want to 
add port specific stuff to the port object, or worker specific stuff to 
the worker object. I just don't have that high confidence in that we can 
design these interfaces perfectly in the first version, nor phantom the 
features that people will want in future versions.

> I really don't like this idea of making Workers less generic. There's no 
> need for it as far as I can tell, and all it does is make things less 
> powerful while actually increasing implementation complexity.

Why is it making them less generic?

One need listed is the ability to in the future add properties that make 
sense on one interface but not the other. You are already listing 
onerror and onload as not really making sense on a generic MessagePort.

Why does it make things less powerful?

So far it seems like implementors are commenting on wanting this change, 
so implementation complexity doesn't seem like a real concern.

> Would it be better if instead of createWorker() we called the method 
> connectToWorker(), and it creates it as well if the worker is unnamed or 
> doesn't yet exist? That would resolve the issue of what looks like a 
> constructor not returning an object representing what it constructs?

That only addresses one of the comments listed in my last mail.

/ Jonas



From ian at hixie.ch  Thu Aug  7 23:10:25 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Aug 2008 06:10:25 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <489B449B.4020603@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<489B449B.4020603@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>


I've made createWorker() and createNamedWorker() return Worker objects 
with a 'port' attribute that represents the original message port.

I've removed the 'utils' object and put all the APIs back onto the global 
scope.

I've changed importScript() to importScripts() and made it take any number 
of URLs.

I've made unload be fired in a worker when the worker's lifetime expires.


On Wed, 6 Aug 2008, Chris Prince wrote:
>
> I'll try to write up some more detailed comments later, but for the 
> question above about a 'name' parameter and overoading:
> 
> My current thinking is that the best API design for createWorker() is:
>    MessagePort createWorker(worker_body, [WorkerOptions])
> 
> The reason: workers are a powerful concept, and it's very likely we'll 
> want to extend them over time.

I agree in general, but I think named workers are an important enough 
distinction that it's worth a second constructor.


> I'd say other options are likely to be just as 'important' as name, so I 
> wouldn't special-case that parameter.  A 'WorkerOptions' parameter 
> supports naming, but future expansion as well.

"name" is pretty important, I don't know of anything other than the URL of 
the script that I would say is more important.



On Thu, 7 Aug 2008, Chris Prince wrote:
> 
> It is short-sighted to expect you can fully spec something as large as 
> workers.  This is a significant new concept, and we are only scratching 
> the surface.
> 
> So why back ourselves into a corner?  Let's be smart about the API 
> design, and allow for future flexibility.
> 
> I don't see any downsides to the approach outlined above.  If you have 
> something specific in mind, please let us know.

There's no downside per se, it's just not neccessary at this point. We can 
always add more arguments later, including one for a lot of optional 
parameters should we decide we need an object to do that.


On Thu, 7 Aug 2008, Jonas Sicking wrote:
>>
>> [utils]
> 
> I don't feel very strongly about this right now. It's something we 
> started debating at mozilla and I think we'll debate it a bit more 
> before coming to a conclusion. I'm fine with putting it in the global 
> scope for now. Sorry, i didn't mean to ask for an immediate action on 
> this yet.

You said things were urgent, I assumed I should act on all your requests. :-)


> One solution I thought about is to have a base interface such as:
> 
> interface MessagePort {
>   void postMessage(...);
>   attribute EventListener onmessage;
>   ...
> }
> 
> Then have
> 
> interface Worker : MessagePort {
>    bool isShared();
>    <worker specific stuff>
> }
> 
> interface PipePort : MessagePort {
>    attribute Window ownerWindow;
>    <Pipe specific stuff>
> }
> 
> 
> And then make the APIs that we want to allow passing around pipe-ends take a
> PipePort object.
> 
> The result is basically that workers are separate objects from what's 
> returned for (new MessagePipe()).port1, but they share some API.

The problem there though is that when you receive a port, you have no idea 
if it's a port into another frame, or a port into a worker that happened 
to be created as a pipe, or a port into a worker that happened to be 
created when the worker was created. I don't see why you would ever need 
to have that distinction, either. The whole point of ports as an 
architectural concept is that they provide an opaque interface, and who 
exactly is on the other side is not something that you should need to have 
any information about.

In the design in the spec now, there's a Worker object that has 'load', 
'error', and 'unload' events on, which fire at the appropriate times in 
the lifetime of the worker, and there's a .pipe attribute that provides a 
pipe into the worker.


> [importScripts()]
>
> Yes. Another thing is that this function should probably return void and 
> always throw if something goes wrong. I doubt that having the server 
> return a 404 is expected enough that just returning 'false' will keep 
> the program executing fine.

Ok.


On Thu, 7 Aug 2008, Jonas Sicking wrote:
> 
> To add to the above point, while the MessagePort API currently aligns 
> with the proposed Worker API, this seems likely to change in the future, 
> for example to test if a worker is shared between multiple frames.

I don't see why we'd ever do this, but I do see other things we might want 
to do to control a worker, e.g. close it or throttle it.


> I in general am not a big fan of the MessagePort API, the whole cloning 
> and dying thing is really ugly. I don't think there is much we can do 
> about that, but because of it I think we should only use the API when 
> it's strictly needed, which seems to be only in fairly complex usecases. 

I don't really understand this concern. Why is it complex? Then again, I 
have the same reaction to your proposal for a Worker object. :-)


> Exposing a MessagePort as a permanent property, like the global 'port' 
> property, has the downside that that object can potentially die if the 
> MessagePort is ever passed through postMessage somewhere.

Do you mean that:

   var w = createWorker('worker.js');
   otherWindow.postMessage('here is the worker you asked for', w.port);
   w.port.postMessage('oh i wanted to talk to you after all');

...would fail? (It would return false from the last call.)

I don't think this is a big problem. I mean, it's like being worried that 
references into a window fail to have the right effect after the window is 
closed or navigated.


> This leaves the user with a permanent property containing a dead useless 
> object. Not exposing it as a permanent property forces things like the 
> onconnect event and returning a MessagePort from createWorker.

Do you mean on the Worker (outside) or the WorkerGlobalScope (inside)?

The current spec doesn't expose 'port' as a permanent attribute on the 
WorkerGlobalScope (inside), it's just a property added to the global 
object, it's not NoDelete or anything.


> I do sort of prefer the idea of keeping the "give me a worker that is 
> potentially shared with other windows" API separate. In fact I think we 
> should call it createSharedWorker or some such. But allowing optional 
> arguments at the end seems like a good idea. Not sure if that requires 
> specific action right now or not though.

I've renamed createNamedWorker() to createSharedWorker().

Any other objections?

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


From jonas at sicking.cc  Fri Aug  8 00:15:33 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 08 Aug 2008 00:15:33 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<489B449B.4020603@sicking.cc>
	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>
Message-ID: <489BF295.2000206@sicking.cc>

>> One solution I thought about is to have a base interface such as:
>>
>> interface MessagePort {
>>   void postMessage(...);
>>   attribute EventListener onmessage;
>>   ...
>> }
>>
>> Then have
>>
>> interface Worker : MessagePort {
>>    bool isShared();
>>    <worker specific stuff>
>> }
>>
>> interface PipePort : MessagePort {
>>    attribute Window ownerWindow;
>>    <Pipe specific stuff>
>> }
>>
>>
>> And then make the APIs that we want to allow passing around pipe-ends take a
>> PipePort object.
>>
>> The result is basically that workers are separate objects from what's 
>> returned for (new MessagePipe()).port1, but they share some API.
> 
> The problem there though is that when you receive a port, you have no idea 
> if it's a port into another frame, or a port into a worker that happened 
> to be created as a pipe, or a port into a worker that happened to be 
> created when the worker was created. I don't see why you would ever need 
> to have that distinction, either.

Sorry, I might have been unclear. My suggested inheritance might be 
better explained as

interface CommunicationPort {
   void postMessage(...)
   attribute EventListener onmessage;
   ...
}

interface Worker : CommuncationPort {
   attribute EventListener onload;
   attribute EventListener onerror;
}

interface MessagePort : CommunicationPort {
}

I.e. we wouldn't allow a Worker to be passed to postMessage, but the 
object returned from myPipe.port1 would be allowed.

> The whole point of ports as an 
> architectural concept is that they provide an opaque interface, and who 
> exactly is on the other side is not something that you should need to have 
> any information about.

Why do we need this feature? I.e. why is it useful to have an abstracted 
MessagePort where you don't know who you are communicating with?

The one useful thing that I see that MessagePorts do is that they allow 
objects that usually can't directly reach each other send messages to 
each other. I.e. two iframes that live next to each other can't usually 
get a reference to each other, but using MessagePorts a communcation 
channel can be negotiated between them.

Similarly, two sibling workers can't in the current proposal reach each 
other, but using MessagePorts they can communicate with each other anyway.

>> I in general am not a big fan of the MessagePort API, the whole cloning 
>> and dying thing is really ugly. I don't think there is much we can do 
>> about that, but because of it I think we should only use the API when 
>> it's strictly needed, which seems to be only in fairly complex usecases. 
> 
> I don't really understand this concern. Why is it complex? Then again, I 
> have the same reaction to your proposal for a Worker object. :-)

My proposal makes Workers behave the same way as Windows when it comes 
to sending messages. I think postMessage on Windows can generally be 
considered a success, I haven't heard a lot of people complaining about 
it being complex.

>> Exposing a MessagePort as a permanent property, like the global 'port' 
>> property, has the downside that that object can potentially die if the 
>> MessagePort is ever passed through postMessage somewhere.
> 
> Do you mean that:
> 
>    var w = createWorker('worker.js');
>    otherWindow.postMessage('here is the worker you asked for', w.port);
>    w.port.postMessage('oh i wanted to talk to you after all');
> 
> ...would fail? (It would return false from the last call.)

Yes.

Further, the fact that a clone is created on the other end rather than 
the same object I think can be confusing. I.e. if I set an expando on a 
port the receiver of the port won't see the expando. This is required 
since otherwise we'd have synchronous communication between threads, but 
I think it's confusing to authors. This is why I generally don't like 
MessagePorts and think that they should be used as little as possible.

Also, I would have expected the above to throw an exception. Having it 
silently fail (which is what'll happen if you don't check the return 
value) seems likely to cause hidden bugs.

> I don't think this is a big problem. I mean, it's like being worried that 
> references into a window fail to have the right effect after the window is 
> closed or navigated.

I think for windows we are usually saved by the fact that generally when 
a window is navigated, all the code that uses that window is killed.

>> This leaves the user with a permanent property containing a dead useless 
>> object. Not exposing it as a permanent property forces things like the 
>> onconnect event and returning a MessagePort from createWorker.
> 
> Do you mean on the Worker (outside) or the WorkerGlobalScope (inside)?

Yes

> The current spec doesn't expose 'port' as a permanent attribute on the 
> WorkerGlobalScope (inside), it's just a property added to the global 
> object, it's not NoDelete or anything.

Hmm.. pretty much all other properties that are created by a browser is 
permanent. So I don't expect that this will change as far as user 
expected behavior goes.

I have yet to actually see any advantages to demanding the use of 
MessagePorts. Other than potentially somewhat nicer interface for shared 
workers, but I don't think that's common enough to optimize for, nor do 
I think the win there is particularly big.

/ Jonas


From ian at hixie.ch  Fri Aug  8 00:48:32 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Aug 2008 07:48:32 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <489BF295.2000206@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<489B449B.4020603@sicking.cc>
	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>
	<489BF295.2000206@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>

On Fri, 8 Aug 2008, Jonas Sicking wrote:
> 
> I.e. we wouldn't allow a Worker to be passed to postMessage, but the 
> object returned from myPipe.port1 would be allowed.

I strongly disagree with the idea of making communication channels with 
workers be a "second class citizen" in terms of being able to send 
communication channels about.


> > The whole point of ports as an architectural concept is that they 
> > provide an opaque interface, and who exactly is on the other side is 
> > not something that you should need to have any information about.
> 
> Why do we need this feature? I.e. why is it useful to have an abstracted 
> MessagePort where you don't know who you are communicating with?

It is a critical component of any capabilities granting mechanism.


> My proposal makes Workers behave the same way as Windows when it comes 
> to sending messages.

That's the problem. The Window communication mechanism is a pretty crappy 
one -- it's a single channel, there's no delegation, if you want to 
connect two windows who don't know about each other you have to proxy, 
etc. If it wasn't for the fact that everyone is implementing it, I'd 
really be pushing for changing to a more capable (and more secure) system, 
something much more akin to message channels.

(I originally came up with postMessage() years ago, I have learnt much in 
that time about how message passing mechanisms should work.)


> > > Exposing a MessagePort as a permanent property, like the global 
> > > 'port' property, has the downside that that object can potentially 
> > > die if the MessagePort is ever passed through postMessage somewhere.
> > 
> > Do you mean that:
> > 
> >    var w = createWorker('worker.js');
> >    otherWindow.postMessage('here is the worker you asked for', w.port);
> >    w.port.postMessage('oh i wanted to talk to you after all');
> > 
> > ...would fail? (It would return false from the last call.)
> 
> Yes.
> 
> Further, the fact that a clone is created on the other end rather than 
> the same object I think can be confusing. I.e. if I set an expando on a 
> port the receiver of the port won't see the expando. This is required 
> since otherwise we'd have synchronous communication between threads, but 
> I think it's confusing to authors. This is why I generally don't like 
> MessagePorts and think that they should be used as little as possible.

I disagree, but I don't know what I can say to convince you. All I can say 
is that the original impetus for the message channel mechanism came from 
authors who wanted a more capable messaging mechanism.


> Also, I would have expected the above to throw an exception. Having it 
> silently fail (which is what'll happen if you don't check the return 
> value) seems likely to cause hidden bugs.

Throwing an exception seems a little drastic, but I could be convinced to 
change that -- the problem is that there's no way to know if it's going to 
throw (or return false) before the call. Which is better?:

   if (!p.postMessage(msg)) {
     // it went away
   }

...or:

   try {
      p.postMessage(msg);
   } catch (e) {
      if (e.code == 20) {
        // it went away
      }
   }

...?

Consider also that the postMessage() might not be critical, e.g.:

   // this code runs when the user asks to save his work
   for each (var p in registeredNotifiers) {
     // registeredNotifiers is a list of ports to parts of
     // the codebase that want to be notified just before
     // something is saved
     p.postMessage(msg);
   }
   doSave();

If the author doesn't check for the potential exceptions (which at the 
time of writing he might not be expecting, since he doesn't know if anyone 
is ever going to be doing something with the ports that would cause an 
exception to be possible here), then the saving doesn't work. If we just 
return false, then the error is ignored, which is likely fine here.


> > I don't think this is a big problem. I mean, it's like being worried 
> > that references into a window fail to have the right effect after the 
> > window is closed or navigated.
> 
> I think for windows we are usually saved by the fact that generally when 
> a window is navigated, all the code that uses that window is killed.

Not if it's in another window. I think it's very much the same problem.

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


From tstarling at wikimedia.org  Fri Aug  8 03:42:54 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Fri, 08 Aug 2008 20:42:54 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
References: <489A63A5.3060603@wikimedia.org>	
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	
	<489A9C04.9040006@wikimedia.org>	
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>	
	<489ADB2E.50405@wikimedia.org>
	<35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
Message-ID: <489C232E.9030505@wikimedia.org>

Jeremy Doig wrote:
> how would this work (say) for different avc profile levels and
> features (eg: PAFF support) ?

I don't think that's our problem. The details of determining a type name
for a given file should be in another standard, it should not be in HTML
5. All HTML 5 has to do is delegate responsibility for type assignment.

> would we require video creators to know the specific capabilities of
> every fourCC target ?

Video creators aren't *required* to do anything. They can just embed
their videos in HTML with no specified type and test it on a few
platforms to see if it works.

The point of the interface (from my point of view) is to assist website
designers when they wish to promulgate a new or unpopular video format.
Presumably, the website designer will know the new video format very
well, otherwise they wouldn't bother.

-- Tim Starling


From tstarling at wikimedia.org  Fri Aug  8 03:46:15 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Fri, 08 Aug 2008 20:46:15 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <p06240816c4c0f91a6995@[10.0.1.8]>
References: <489A63A5.3060603@wikimedia.org>	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	<489A9C04.9040006@wikimedia.org>	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	<489AB360.6010408@wikimedia.org>
	<489ABEEB.7080603@peda.net>	<489ADB2E.50405@wikimedia.org>	<35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
	<p06240816c4c0f91a6995@[10.0.1.8]>
Message-ID: <489C23F7.3050602@wikimedia.org>

Dave Singer wrote:
> I think this is a good idea, but one rapidly runs into the problems
> talked about in the 'bucket' RFC, notably that there is not a
> universal language for naming codecs (4ccs etc).  But it's proved
> useful in the past.
>
> In general, the source fallbacks are also a way to 'probe' this,
> albeit in a very different way.
>
> I'm not sure you can always get a definitive answer to the question
> "if I gave you a file with this (extended) MIME type, could you play
> it?" and I am fairly sure that asking the implementation to enumerate
> all the types it could support would be hard.

If you can't get an answer to that question, then how will the browsers
implement <source> fallbacks? What I'm suggesting is basically the same,
except without the requirement to download a video file.

All the issues with type names are also present with <source>.

-- Tim Starling


From hsivonen at iki.fi  Fri Aug  8 06:49:17 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 8 Aug 2008 16:49:17 +0300
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489C232E.9030505@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>	
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	
	<489A9C04.9040006@wikimedia.org>	
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>	
	<489ADB2E.50405@wikimedia.org>
	<35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
	<489C232E.9030505@wikimedia.org>
Message-ID: <67DCC040-C6AB-4D9A-B7A5-CA750E916282@iki.fi>

On Aug 8, 2008, at 13:42, Tim Starling wrote:

> Jeremy Doig wrote:
>> how would this work (say) for different avc profile levels and
>> features (eg: PAFF support) ?

The main problem with AVC levels is that J. Random Author has no idea  
what AVC level his/her tool emitted.

> I don't think that's our problem. The details of determining a type  
> name
> for a given file should be in another standard, it should not be in  
> HTML
> 5. All HTML 5 has to do is delegate responsibility for type  
> assignment.


HTML5 needs to delegate it to something that is implementable given  
the APIs QuickTime, GStreamer, DirectShow and Phonon provide. A  
standard doesn't help if it doesn't match the APIs.

Does what HTML5 says now match the framework APIs?

The MIME codecs parameter seems to confuse both WebKit and Minefield,  
for instance:
http://hsivonen.iki.fi/test/moz/video-selection/source-mp4-ogg.html
vs.
http://hsivonen.iki.fi/test/moz/video-selection/source-mp4-ogg-params.html

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From jonas at sicking.cc  Fri Aug  8 10:10:52 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 08 Aug 2008 10:10:52 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>	<4898CBA7.2080801@sicking.cc>	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>	<489B449B.4020603@sicking.cc>	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>	<489BF295.2000206@sicking.cc>
	<Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>
Message-ID: <489C7E1C.5060006@sicking.cc>

So the API I'm proposing is the following:

[NoInterfaceObject] interface WorkerFactory {
    Worker createWorker(in DOMString scriptURL);
    Worker createSharedWorker(in DOMString name, in DOMString scriptURL);
};


interface Worker {
    boolean postMessage(in DOMString message);
    boolean postMessage(in DOMString message,
                        in MessagePort messagePort);

    // event handler attributes
             attribute EventListener onmessage;
             attribute EventListener onload;
             attribute EventListener onerror;
             attribute EventListener onunload;
};

interface WorkerParent {
    boolean postMessage(in DOMString message);
    boolean postMessage(in DOMString message,
                        in MessagePort messagePort);
};

[NoInterfaceObject] interface WorkerGlobalScope {
    // core worker features
    readonly attribute WorkerGlobalScope self;
    readonly attribute WorkerLocation location;
    readonly attribute DOMString name;
    readonly attribute boolean closing;
    readonly attribute WorkerParent parent;
    void close();

    // event handler attributes
             attribute EventListener onunload;
};

(We might want to add an onconnect property to WorkerGlobalScope, but it
doesn't seem strictly needed)

I think that it has the following advantages over the current draft spec:

* We don't expose users to MessagePort objects in the majority of
   scenarios.
* There is no permanent .port properties anywhere that would go dead if
   the port is passed somewhere.
* There is no need for pseudo properties anywhere (the port variable
   inside the WorkerGlobalScript)
* The current draft duplicates the onunload property on both the
   worker and its port. Not sure if this is needed or just a bug.
* All onX objects live on the same object rather than some living
   on the worker, some living on worker.port.

I'd be interested to hear what others think of this proposal.

/ Jonas


From ian at hixie.ch  Fri Aug  8 10:36:55 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Aug 2008 17:36:55 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <489C7E1C.5060006@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<489B449B.4020603@sicking.cc>
	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>
	<489BF295.2000206@sicking.cc>
	<Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>
	<489C7E1C.5060006@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808081730050.5136@hixie.dreamhostps.com>

On Fri, 8 Aug 2008, Jonas Sicking wrote:
>
> So the API I'm proposing is the following:

This seems to be a strict subset of what the spec has now; the only 
difference being that there's no easy way to create a worker and then pass 
it to someone else to take care of, and there seems to be no easy way for 
a worker to hear about a new "parent".

> (We might want to add an onconnect property to WorkerGlobalScope, but it 
> doesn't seem strictly needed)

How else would you connect to a shared worker?


> I think that it has the following advantages over the current draft spec:
> 
> * We don't expose users to MessagePort objects in the majority of
>   scenarios.

I do not consider this an advantage. All we're doing is moving the 
complexity to a later point -- instead of learning part of the API and 
then more of the API if they want to, authors have to learn two APIs, one 
of which is just as complicated as today's, and another that is not quite 
the same as either Window.postMessage() or port.postMessage() but is 
similar enough to get them confused.


> * There is no permanent .port properties anywhere that would go dead if
>   the port is passed somewhere.

The .parent property is as likely to go dead, e.g. if the parent goes away 
after the worker has been provided a port to another window.


> * There is no need for pseudo properties anywhere (the port variable
>   inside the WorkerGlobalScript)

Replacing 'port' with 'parent' doesn't really change much. :-)


> * The current draft duplicates the onunload property on both the
>   worker and its port. Not sure if this is needed or just a bug.

It's not strictly needed but it's useful to distinguish the death of the 
port from the death of the worker.


> * All onX objects live on the same object rather than some living
>   on the worker, some living on worker.port.

They still also live on .port, it's just that you're not exposing this 
explicitly now. This is a false simplification IMHO.

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


From jonas at sicking.cc  Fri Aug  8 11:35:42 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 08 Aug 2008 11:35:42 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808081730050.5136@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<489B449B.4020603@sicking.cc>
	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>
	<489BF295.2000206@sicking.cc>
	<Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>
	<489C7E1C.5060006@sicking.cc>
	<Pine.LNX.4.62.0808081730050.5136@hixie.dreamhostps.com>
Message-ID: <489C91FE.2010102@sicking.cc>

Ian Hickson wrote:
> On Fri, 8 Aug 2008, Jonas Sicking wrote:
>> So the API I'm proposing is the following:
> 
> This seems to be a strict subset of what the spec has now; the only 
> difference being that there's no easy way to create a worker and then pass 
> it to someone else to take care of, and there seems to be no easy way for 
> a worker to hear about a new "parent".

Don't really think it's a subset or a superset. The same feature set 
exists in both proposals, the syntax is just different.

The idea is that it's a simpler syntax for the common cases. However I 
think we'll have to agree to disagree what is "simple" at this point.

>> (We might want to add an onconnect property to WorkerGlobalScope, but it 
>> doesn't seem strictly needed)
> 
> How else would you connect to a shared worker?

That is done at an application level. For example:

worker = createSharedWorker("foo", "bar.js");
worker.addEventListener("message", handler, false);
worker.postMessage("wassup dude, i just connected");

Actually, it seems like onconnect as defined in the current spec has a 
race condition. The shared worker example does the following:

    var worker = createSharedWorker('worker.js', 'core');
    function configure(event) {
      if (event.message.substr(0, 4) != 'cfg ') return;
      var name = event.message.substr(4).split(' ', 1);
      // update display to mention our name is name
      document.getElementsByTagName('h1')[0].textContent += ' ' + name;
      // no longer need this listener
      worker.port.removeEventListener('message', configure, false);
    }
    worker.port.addEventListener('message', configure, false);

However what's to say that the 'connect' event hasn't fired inside the 
worker before the 'worker.port.addEventListener' line executes? Note 
that there can already be other listeners to the port, so the port has 
been activated.

Also, what MessagePort object is handed to the connect event if the 
inner or outer port has been handed through postMessage somewhere? I.e. 
if someone does:

var worker = createSharedWorker('worker.js', 'core');
someIframe.postMessage("here's your worker", worker.port);

Does that mean that noone can ever share that worker again? And that 
anyone else currently sharing that worker is going to break?

I would have expected sharing workers would always set up new message 
pipes. So here's my revised proposal:


[NoInterfaceObject] interface WorkerFactory {
    Worker createWorker(in DOMString scriptURL);
    Worker createSharedWorker(in DOMString name, in DOMString scriptURL);
};


interface Worker {
    boolean postMessage(in DOMString message);
    boolean postMessage(in DOMString message,
                        in MessagePort messagePort);

    MessagePort connectNewPipe();

    // event handler attributes
             attribute EventListener onmessage;
             attribute EventListener onload;
             attribute EventListener onerror;
             attribute EventListener onunload;
};

interface WorkerParent {
    boolean postMessage(in DOMString message);
    boolean postMessage(in DOMString message,
                        in MessagePort messagePort);
};

[NoInterfaceObject] interface WorkerGlobalScope {
    // core worker features
    readonly attribute WorkerGlobalScope self;
    readonly attribute WorkerLocation location;
    readonly attribute DOMString name;
    readonly attribute boolean closing;
    readonly attribute WorkerParent parent;
    void close();

    // event handler attributes
             attribute EventListener onunload;
             attribute EventListener onconnect;
};


The change from previous version is the Worker.connectNewPipe function. 
When that function is called, two entangled MessagePorts are created. 
One is returned from the function, and one is provided to the code 
inside the worker by firing a 'connect' event which contains the port. 
Note that calling createSharedWorker does not fire a 'connect' event.

/ Jonas


From ian at hixie.ch  Fri Aug  8 11:56:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Aug 2008 18:56:15 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <489C91FE.2010102@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<489B449B.4020603@sicking.cc>
	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>
	<489BF295.2000206@sicking.cc>
	<Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>
	<489C7E1C.5060006@sicking.cc>
	<Pine.LNX.4.62.0808081730050.5136@hixie.dreamhostps.com>
	<489C91FE.2010102@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808081850051.5136@hixie.dreamhostps.com>

On Fri, 8 Aug 2008, Jonas Sicking wrote:
> > > 
> > > (We might want to add an onconnect property to WorkerGlobalScope, 
> > > but it doesn't seem strictly needed)
> > 
> > How else would you connect to a shared worker?
> 
> That is done at an application level. For example:
> 
> worker = createSharedWorker("foo", "bar.js");
> worker.addEventListener("message", handler, false);
> worker.postMessage("wassup dude, i just connected");

How would the worker distinguish that from the original "parent" sending 
the same message?


> Actually, it seems like onconnect as defined in the current spec has a 
> race condition. The shared worker example does the following:
> 
>    var worker = createSharedWorker('worker.js', 'core');
>    function configure(event) {
>      if (event.message.substr(0, 4) != 'cfg ') return;
>      var name = event.message.substr(4).split(' ', 1);
>      // update display to mention our name is name
>      document.getElementsByTagName('h1')[0].textContent += ' ' + name;
>      // no longer need this listener
>      worker.port.removeEventListener('message', configure, false);
>    }
>    worker.port.addEventListener('message', configure, false);
> 
> However what's to say that the 'connect' event hasn't fired inside the 
> worker before the 'worker.port.addEventListener' line executes?

Doesn't matter. MessagePorts queue up messages until they receiver either 
sets onmessage or calls start(). (This is explained just below the 
example.)


> Note that there can already be other listeners to the port, so the port 
> has been activated.

The port only activates if you set onmessage or call start(). Calling 
addEventListener() doesn't activate it.


> Also, what MessagePort object is handed to the connect event if the 
> inner or outer port has been handed through postMessage somewhere? I.e. 
> if someone does:
> 
> var worker = createSharedWorker('worker.js', 'core');
> someIframe.postMessage("here's your worker", worker.port);
> 
> Does that mean that noone can ever share that worker again?

The createSharedWorker() call always creates a new pipe to hand to the 
'connect' event.


> And that anyone else currently sharing that worker is going to break?

Why would it break anything? I'm confused.


> I would have expected sharing workers would always set up new message 
> pipes.

It does.


> So here's my revised proposal:

Now it's even more complicated, while still not doing everything that the 
current proposal does. I'm not at all convinced this is better.

Is the only problem you have with the current design that it is too 
complicated?

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


From jonas at sicking.cc  Fri Aug  8 12:01:54 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 08 Aug 2008 12:01:54 -0700
Subject: [whatwg] Active workers when user leaves the page
Message-ID: <489C9822.2010001@sicking.cc>

This is something that have been in the back of my brain for a few days: 
How do we deal with the user navigating a way from a page if there's a 
Worker in the middle of some very long running script?

First off, please notice that this discussion is 100% orthogonal to the 
communications API discussion that is ongoing in another thread. I don't 
want to get the two mixed up.

We don't really want to always allow a worker to finish working, even if 
the user leaves the only page that is currently using the worker. I.e. 
if someone has an infinite loop (by accident or intentionally), I don't 
think we want to leave that running until the user shuts down the 
browser. In fact, the user could very well be leaving the page because 
he/she feels that it is sucking up too much CPU power.

One possible solution is to simply set the .closing flag inside the 
worker and hope that the worker will honor that flag and break out ASAP. 
The UA could even at that point give the worker some set amount of time 
before forcefully killing the worker. We have a concept of a 'slow 
script' dialog in firefox that we use if scripts on the main thread take 
too long to run. The dialog asks the user if he/she wants to continue 
running the current script, or forcefully break it.

This will not usually be used for workers (the whole point is that they 
take a long time to finish), but we could engage it once the user tries 
to leave the page.

I do want to be agressive with killing workers when the user leaves a 
page since that makes for better user experience. However I'm also 
worried about stopping scripts halfway through breaking things and 
leaving the site with half-finished operations that are stored in 
databases or localStorage.

Also note that the the presence, or lack of, fastback cache doesn't 
really make a difference. Pages are eventually going to get purged from 
the fastback cache, so it just pushes the problem to a point a little 
later in time.


How has gears dealt with this problem so far? What are your experiences 
with it?

/ Jonas


From jonas at sicking.cc  Fri Aug  8 12:10:50 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 08 Aug 2008 12:10:50 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0808081850051.5136@hixie.dreamhostps.com>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>	<4898CBA7.2080801@sicking.cc>	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>	<489B449B.4020603@sicking.cc>	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>	<489BF295.2000206@sicking.cc>	<Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>	<489C7E1C.5060006@sicking.cc>	<Pine.LNX.4.62.0808081730050.5136@hixie.dreamhostps.com>	<489C91FE.2010102@sicking.cc>
	<Pine.LNX.4.62.0808081850051.5136@hixie.dreamhostps.com>
Message-ID: <489C9A3A.1000807@sicking.cc>

Ian Hickson wrote:
> On Fri, 8 Aug 2008, Jonas Sicking wrote:
>>>> (We might want to add an onconnect property to WorkerGlobalScope, 
>>>> but it doesn't seem strictly needed)
>>> How else would you connect to a shared worker?
>> That is done at an application level. For example:
>>
>> worker = createSharedWorker("foo", "bar.js");
>> worker.addEventListener("message", handler, false);
>> worker.postMessage("wassup dude, i just connected");
> 
> How would the worker distinguish that from the original "parent" sending 
> the same message?

Why would the original parent same the message twice? Of course 
applications following their own application level protocols is going to 
break themselves.

>> Actually, it seems like onconnect as defined in the current spec has a 
>> race condition. The shared worker example does the following:
>>
>>    var worker = createSharedWorker('worker.js', 'core');
>>    function configure(event) {
>>      if (event.message.substr(0, 4) != 'cfg ') return;
>>      var name = event.message.substr(4).split(' ', 1);
>>      // update display to mention our name is name
>>      document.getElementsByTagName('h1')[0].textContent += ' ' + name;
>>      // no longer need this listener
>>      worker.port.removeEventListener('message', configure, false);
>>    }
>>    worker.port.addEventListener('message', configure, false);
>>
>> However what's to say that the 'connect' event hasn't fired inside the 
>> worker before the 'worker.port.addEventListener' line executes?
> 
> Doesn't matter. MessagePorts queue up messages until they receiver either 
> sets onmessage or calls start(). (This is explained just below the 
> example.)
> 
>> Note that there can already be other listeners to the port, so the port 
>> has been activated.
> 
> The port only activates if you set onmessage or call start(). Calling 
> addEventListener() doesn't activate it.

Ah, i missed the fact that calling createSheredWorker always created a 
new Worker object, even if one already existed.

/ Jonas


From tstarling at wikimedia.org  Fri Aug  8 12:13:23 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Sat, 09 Aug 2008 05:13:23 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <67DCC040-C6AB-4D9A-B7A5-CA750E916282@iki.fi>
References: <489A63A5.3060603@wikimedia.org>	
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	
	<489A9C04.9040006@wikimedia.org>	
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>	
	<489ADB2E.50405@wikimedia.org>
	<35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
	<489C232E.9030505@wikimedia.org>
	<67DCC040-C6AB-4D9A-B7A5-CA750E916282@iki.fi>
Message-ID: <489C9AD3.8020807@wikimedia.org>

Henri Sivonen wrote:
>
> HTML5 needs to delegate it to something that is implementable given
> the APIs QuickTime, GStreamer, DirectShow and Phonon provide. A
> standard doesn't help if it doesn't match the APIs.
>
> Does what HTML5 says now match the framework APIs?
>
> The MIME codecs parameter seems to confuse both WebKit and Minefield,
> for instance:
> http://hsivonen.iki.fi/test/moz/video-selection/source-mp4-ogg.html
> vs.
> http://hsivonen.iki.fi/test/moz/video-selection/source-mp4-ogg-params.html
>
>

Well, the Mozilla bug is this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=449363
It's not implemented yet.

Where do I go from here with this? Should I make a concrete proposal? A
sample implementation? Get that Mozilla bug fixed? Or have I been shot
down already?

-- Tim Starling


From jonas at sicking.cc  Fri Aug  8 12:12:42 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 08 Aug 2008 12:12:42 -0700
Subject: [whatwg] Workers feedback
In-Reply-To: <489C9A3A.1000807@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>	<4898CBA7.2080801@sicking.cc>	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>	<489B449B.4020603@sicking.cc>	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>	<489BF295.2000206@sicking.cc>	<Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>	<489C7E1C.5060006@sicking.cc>	<Pine.LNX.4.62.0808081730050.5136@hixie.dreamhostps.com>	<489C91FE.2010102@sicking.cc>
	<Pine.LNX.4.62.0808081850051.5136@hixie.dreamhostps.com>
	<489C9A3A.1000807@sicking.cc>
Message-ID: <489C9AAA.1040705@sicking.cc>

Jonas Sicking wrote:
> Ian Hickson wrote:
>> On Fri, 8 Aug 2008, Jonas Sicking wrote:
>>>>> (We might want to add an onconnect property to WorkerGlobalScope, 
>>>>> but it doesn't seem strictly needed)
>>>> How else would you connect to a shared worker?
>>> That is done at an application level. For example:
>>>
>>> worker = createSharedWorker("foo", "bar.js");
>>> worker.addEventListener("message", handler, false);
>>> worker.postMessage("wassup dude, i just connected");
>>
>> How would the worker distinguish that from the original "parent" 
>> sending the same message?
> 
> Why would the original parent same the message twice? Of course 
> applications following their own application level protocols is going to 
> break themselves.

Sorry, that should say: Of course applications *not* following their own 
application level protocols are going to break themselves.

/ Jonas


From ian at hixie.ch  Fri Aug  8 12:28:43 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Aug 2008 19:28:43 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <489C9AAA.1040705@sicking.cc>
References: <278fd46c0808051329q7fdbb794v5ae26ebd44cb0778@mail.gmail.com>
	<4898CBA7.2080801@sicking.cc>
	<278fd46c0808051533g71eb1244o4cea9ed1c5b73821@mail.gmail.com>
	<Pine.LNX.4.62.0808052357450.5140@hixie.dreamhostps.com>
	<278fd46c0808061912i46b6564g3512176eb8b50776@mail.gmail.com>
	<489B449B.4020603@sicking.cc>
	<Pine.LNX.4.62.0808080416280.5140@hixie.dreamhostps.com>
	<489BF295.2000206@sicking.cc>
	<Pine.LNX.4.62.0808080729550.5136@hixie.dreamhostps.com>
	<489C7E1C.5060006@sicking.cc>
	<Pine.LNX.4.62.0808081730050.5136@hixie.dreamhostps.com>
	<489C91FE.2010102@sicking.cc>
	<Pine.LNX.4.62.0808081850051.5136@hixie.dreamhostps.com>
	<489C9A3A.1000807@sicking.cc> <489C9AAA.1040705@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808081915440.5136@hixie.dreamhostps.com>

On Fri, 8 Aug 2008, Jonas Sicking wrote:
> > >
> > > worker = createSharedWorker("foo", "bar.js");
> > > worker.addEventListener("message", handler, false);
> > > worker.postMessage("wassup dude, i just connected");
> > 
> > How would the worker distinguish that from the original "parent" 
> > sending the same message?
> 
> Why would the original parent same the message twice? Of course 
> applications following their own application level protocols is going to 
> break themselves.

The whole point of capabilities-based systems is that you can pass these 
communcation ports over to unknown entities and don't have to trust that 
they won't screw up your protocol. For example, you could create a shared 
worker to handle all the requests from all the gadgets hosted on a user's 
home page and just pass the worker off to them each time:

   // a new gadget has been created
   var worker = createSharedWorker('gadget-api.js', 'gadgets');
   gadget.postMessage('here is the gadget API', worker.port);

What you're proposing would be way more complex -- now you'd have to 
create the pipe separately, you'd have to have the worker know how to 
handle both a new connection from its parent as well as its parent saying 
it wants a new pipe for a gadget, you'd have lifetime issues as you 
now have extra commucation mechanisms, etc.

(This brings up another point, which is that by having Worker objects also 
be communication end points, we double the complexity of the definitions 
for worker lifetime, since now they have to deal with both types of 
channels, not just the one generic type.)

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


From ian at hixie.ch  Fri Aug  8 12:30:17 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Aug 2008 19:30:17 +0000 (UTC)
Subject: [whatwg] Active workers when user leaves the page
In-Reply-To: <489C9822.2010001@sicking.cc>
References: <489C9822.2010001@sicking.cc>
Message-ID: <Pine.LNX.4.62.0808081929090.5136@hixie.dreamhostps.com>

On Fri, 8 Aug 2008, Jonas Sicking wrote:
>
> This is something that have been in the back of my brain for a few days: 
> How do we deal with the user navigating a way from a page if there's a 
> Worker in the middle of some very long running script?

Right now the spec says that closing becomes true, and if the worker 
doesn't clean up promptly, the "kill a worker" algorithm is invoked and 
the script is killed, the unload handler is handled, and the script is 
killed again if that doesn't end prompty either.


> Also note that the the presence, or lack of, fastback cache doesn't 
> really make a difference. Pages are eventually going to get purged from 
> the fastback cache, so it just pushes the problem to a point a little 
> later in time.

Yup, the spec deals with this already too.

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


From robert at ocallahan.org  Fri Aug  8 15:29:37 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 9 Aug 2008 10:29:37 +1200
Subject: [whatwg] Active workers when user leaves the page
In-Reply-To: <489C9822.2010001@sicking.cc>
References: <489C9822.2010001@sicking.cc>
Message-ID: <11e306600808081529g45ba03cfm4360fee1cb8a899d@mail.gmail.com>

On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> I do want to be agressive with killing workers when the user leaves a page
> since that makes for better user experience. However I'm also worried about
> stopping scripts halfway through breaking things and leaving the site with
> half-finished operations that are stored in databases or localStorage.
>

Aggressive killing of workers without warning when the user navigates away
would actually be a good feature.

There are various reasons outside anyone's control that a worker might die
abruptly. For example, power failure, browser crash, or "slow-script" style
timeout. Applications need to be able to handle those cases, for example by
using database transactions or careful use of atomic operations. But that's
hard to test and authors probably won't design or test well for those cases
since they're relatively uncommon. Expanding abrupt termination scenarios to
include navigate-away makes abrupt termination much easier to test, forces
authors to design for it early, and will ultimately simplify the application
design by reducing the different ways a worker can terminate.

This may sound a bit radical, but it's not a new idea. It's a principle
sometimes called "crash-only software". See e.g.
http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080809/3f02c0c0/attachment.htm>

From martin at betgenius.com  Fri Aug  8 16:14:30 2008
From: martin at betgenius.com (Martin Ellis)
Date: Sat, 9 Aug 2008 00:14:30 +0100
Subject: [whatwg] Active workers when user leaves the page
In-Reply-To: <11e306600808081529g45ba03cfm4360fee1cb8a899d@mail.gmail.com>
References: <489C9822.2010001@sicking.cc>
	<11e306600808081529g45ba03cfm4360fee1cb8a899d@mail.gmail.com>
Message-ID: <EB66F66AA6F30E409F3A8243BA49DCBA72BB56@EXCHANGE.Betgenius.local>

Hi,

 

Could it not be set that a there is a maximum execution time for any workers that are still active, definable by the browser but with a suggested value of say 1000milliseconds in the spec, any processing that takes longer than this is killed, but gives the option for well built scripts and cleanup processes to run gracefully.

 

Martin

 

From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Robert O'Callahan
Sent: 08 August 2008 23:30
To: Jonas Sicking
Cc: whatwg
Subject: Re: [whatwg] Active workers when user leaves the page

 

On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking <jonas at sicking.cc> wrote:

	I do want to be agressive with killing workers when the user leaves a page since that makes for better user experience. However I'm also worried about stopping scripts halfway through breaking things and leaving the site with half-finished operations that are stored in databases or localStorage.


Aggressive killing of workers without warning when the user navigates away would actually be a good feature.

There are various reasons outside anyone's control that a worker might die abruptly. For example, power failure, browser crash, or "slow-script" style timeout. Applications need to be able to handle those cases, for example by using database transactions or careful use of atomic operations. But that's hard to test and authors probably won't design or test well for those cases since they're relatively uncommon. Expanding abrupt termination scenarios to include navigate-away makes abrupt termination much easier to test, forces authors to design for it early, and will ultimately simplify the application design by reducing the different ways a worker can terminate.

This may sound a bit radical, but it's not a new idea. It's a principle sometimes called "crash-only software". See e.g. http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/


Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is 
believed to be clean. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080809/76f61555/attachment.htm>

From eric at webkit.org  Fri Aug  8 17:03:13 2008
From: eric at webkit.org (Eric Seidel)
Date: Fri, 8 Aug 2008 17:03:13 -0700
Subject: [whatwg] CanvasRenderingContext2D::createPattern and partially
	loaded images
Message-ID: <f3f9e0a30808081703p4b425effv68eb20c7c5257297@mail.gmail.com>

http://www.whatwg.org/specs/web-apps/current-work/#createpattern

Notes that:
The first argument gives the image to use as the pattern (either an
HTMLImageElement or an HTMLCanvasElement). Modifying this image after
calling the createPattern() method must not affect the pattern.

What does this mean for images which are not yet fully loaded from the
network?  Safari's current behavior is that the pattern will draw the
image with as much data as we know about that network resource *at the
time the pattern is drawn*.  Instead of at the time the pattern is
created (as the spec seems to imply).  Meaning if you're a web author,
and you don't bother to listen for Image load events, if your user is
on a slow network, each time you draw your pattern, you'll have
slightly more of the image until it completes.

I can disable this feature of Safari (make it so that
"createPattern()" creates a copy of the image, in whatever loaded
state it may be), or we can change the spec to say that incremental
loading images do not count as "modifying the image after calling
createPattern()".

Thoughts?

-eric


From eric at webkit.org  Fri Aug  8 17:04:47 2008
From: eric at webkit.org (Eric Seidel)
Date: Fri, 8 Aug 2008 17:04:47 -0700
Subject: [whatwg] CanvasRenderingContext2D::createPattern and partially
	loaded images
In-Reply-To: <f3f9e0a30808081703p4b425effv68eb20c7c5257297@mail.gmail.com>
References: <f3f9e0a30808081703p4b425effv68eb20c7c5257297@mail.gmail.com>
Message-ID: <f3f9e0a30808081704x13f91859yc2c8deb2602b70a8@mail.gmail.com>

Nevermind:

If the image argument is an HTMLImageElement object whose complete
attribute is false, then the implementation must raise an
INVALID_STATE_ERR exception.

-eric

On Fri, Aug 8, 2008 at 5:03 PM, Eric Seidel <eric at webkit.org> wrote:
> http://www.whatwg.org/specs/web-apps/current-work/#createpattern
>
> Notes that:
> The first argument gives the image to use as the pattern (either an
> HTMLImageElement or an HTMLCanvasElement). Modifying this image after
> calling the createPattern() method must not affect the pattern.
>
> What does this mean for images which are not yet fully loaded from the
> network?  Safari's current behavior is that the pattern will draw the
> image with as much data as we know about that network resource *at the
> time the pattern is drawn*.  Instead of at the time the pattern is
> created (as the spec seems to imply).  Meaning if you're a web author,
> and you don't bother to listen for Image load events, if your user is
> on a slow network, each time you draw your pattern, you'll have
> slightly more of the image until it completes.
>
> I can disable this feature of Safari (make it so that
> "createPattern()" creates a copy of the image, in whatever loaded
> state it may be), or we can change the spec to say that incremental
> loading images do not count as "modifying the image after calling
> createPattern()".
>
> Thoughts?
>
> -eric
>


From dhtmlkitchen at gmail.com  Fri Aug  8 17:05:47 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Fri, 8 Aug 2008 17:05:47 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
	<D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
	<c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>
	<BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com>
	<c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com>
	<1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com>
Message-ID: <c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>

On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
>

I'd like to put this back on the list, and it doesn't contain anything
personal, so I'm taking the liberty here.
>
> I'm not sure what you mean by "in the binding".

I meant the EcmaScript binding.

> Do you mean in Web IDL's
> definition of how to map Web IDL interfaces to the ECMAScript language, or
> one-off in the HTML5 spec for every interface this applies to?

Narrowing the scope in the interest of not creating bugs seems like a
very good idea.

This could potentially be described in the EcmaScript bindings. But it
would be a good idea to explore some edge cases. Particularly, if the
case was the order of definition of properties: One such case would be
an HTMLCollection with an element named "length". In that case, the
readonly "length" property would have to be the actual length of the
collection; the value should not be replaced with an element of that
name/id.

<form><input name="length"></form>

document.forms[0].elements.length

Opera9: [object HTMLInputElement] <-- BUG
FF3: 1
Saf3: 1

Another consideration would be a form element with an attribute
"length". That would be a problem as neither the attribute, nor the
Netscape 4 DOM "named items" are specified as "readonly". So that's
one reason for not specifying the Netscape 4 DOM and for removing that
example from WF 2.0
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default

>
> I think the Web IDL spec should correctly define how to map Web IDL to
> ECMAScript, while not precluding the possibility of mapping to other
> languages.

It's a good idea to understand what is happening in the language we're
concerned with: EcmaScript implementations (browsers) are where the
phenomenon was noticed and from where the concern was raised.

Aren't [IndexGetter] and [ NameGetter] are really doing the same thing
in most cases?

Why differentiate between "number" properties and "name" properties?

Is "added as properties" an accurate description?

For example:
For each item in the collection object, a corresponsding property is
present on that object. The property's name is the ordinal index and
the value is the result of calling the collection's item() method.

>From the Web IDL WD:
http://dev.w3.org/2006/webapi/WebIDL/#IndexGetter

| An ECMAScript implementation would have an internal [[Get]]
| method that allows values to be retrieved from the  map as
| properties, and a corresponding [[Put]] method for setting values
| in the map:
| ECMAScript
|
|  // Assume map is a host object implementing
| //  the OrderedMap interface.
| var map = getOrderedMap();
| var x, y;
|
| x = map[0];                 // Same as: x = map.getByIndex(0)
| map[1] = false;             // Same as: map.setByIndex(1, false)
|
| y = map.apple;              // Same as: y = map.get('apple')
| map.banana = 123;           // Same as: map.set('banana', 123)
`------------------------------------------------------------------

It seems that the expectation is that [[Get]] will differentiate
between and typecheck the Expression. This is not how property access
works. In the above, the Expression in map[0] is 0. This 0 is
converted to the string "0".

| The production MemberExpression :
| MemberExpression [ Expression  ] is evaluated as follows:
|
| 1. Evaluate MemberExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate Expression.
| 4. Call GetValue(Result(3)).
| 5. Call ToObject(Result(2)).
| 6. Call ToString(Result(4)).

In step 4., we call GetValue(Result(3)

| 8.7.1 GetValue(V)
|
|  4.. If Type(V) is not Reference, return V.

Type V is not a reference, it is a Number, 0, so 0 is returned to
property access algorithm step 4. In step 6, property access calls
ToString(Result(4)),

| 9.8.1 ToString Applied to the Number Type

This is a little involved, and includes exponential notation, but the
result of ToString(0), will be "0",

map[0] has the same effect as map["0"].

I don't know if any other languages have this functionality.

Now the same cannot be said for [[Put]] because Arrays have a special
[[Put]] method that does do some checking on the Expression. Array's
[[Put]] can change the length of the Array, or, if the property name
is 'length', can cause indexed properties to be deleted. Special
[[Put]] functionality might apply to the HTMLSelectElement, which in
all browsers will create/remove options when the length is changed.
However, a "[NameSetter]"  seems over the top.
http://dev.w3.org/2006/webapi/WebIDL/#NameSetter

<!DOCTYPE HTML>
<html lang="en">
<head>
    <title>Magic-Select [[Put]]</title>
</head>
<body>
<form><select name=aaa></select></form>
<script>
var a = document.forms[0].elements.aaa;
a.length = 12
a.options[3].text = "pass";
a.selectedIndex = 3;
</script>
</body>
</html>

Wouldn't it be better to just have a simple note in the HTML 5 spec
what happens when a Select's length property is set?

Garrett

> This may include hints that are relevant to ECMAScript but not
> for most other language bindings. Indeed [IndexGetter] is such a hint, and
> the Web IDL spec includes other aspects of IDL markup that would affect
> ECMAScript but have no effect on Java. If you look at the Web IDL spec you
> will see that general issues are well-separated from the ECMAScript language
> mapping for Web IDL.
>
> Regards,
> Maciej
>
>


From chris.double at double.co.nz  Sat Aug  9 14:46:11 2008
From: chris.double at double.co.nz (Chris Double)
Date: Sun, 10 Aug 2008 09:46:11 +1200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489C9AD3.8020807@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org> <489A9C04.9040006@wikimedia.org>
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>
	<489ADB2E.50405@wikimedia.org>
	<35c92870808071059v7d95735ao25b2c14f9242a0ec@mail.gmail.com>
	<489C232E.9030505@wikimedia.org>
	<67DCC040-C6AB-4D9A-B7A5-CA750E916282@iki.fi>
	<489C9AD3.8020807@wikimedia.org>
Message-ID: <c2e346f90808091446n3cf4b3d0lb3edcfd7ec1f06dc@mail.gmail.com>

On Sat, Aug 9, 2008 at 7:13 AM, Tim Starling <tstarling at wikimedia.org> wrote:
> Where do I go from here with this? Should I make a concrete proposal? A
> sample implementation? Get that Mozilla bug fixed? Or have I been shot
> down already?

I think it is important for web sites to be able to detect in some way
what a browser supports. Lot's of sites currently do this (Wikimedia
obviously, but there's also Metavid, the numerous 'video blogging'
scripts, etc). While they could all switch overnight to only
supporting <video> I doubt that suggesting that solution is going to
result in people looking favourably on migrating towards it.

Can the functionality provided by HTML 5 <video> do what is needed for
these sorts of detection scripts? If not, I'd be interested in seeing
a proposal of something that would work.

Chris.
-- 
http://www.bluishcoder.co.nz


From shannon at arc.net.au  Sat Aug  9 22:42:42 2008
From: shannon at arc.net.au (Shannon)
Date: Sun, 10 Aug 2008 15:42:42 +1000
Subject: [whatwg] WebWorkers vs. Threads
Message-ID: <489E7FD2.10202@arc.net.au>

I've been following the WebWorkers discussion for some time trying to 
make sense of the problems it is trying to solve. I am starting to come 
to the conclusion that it provides little not already provided by:

setTimeout(mainThreadFunc,1)
setTimeout(workThreadFunc,2)
setTimeout(workThreadFunc,2)
....

This is especially true if our main function sets up a "thread-safe" 
communication channel of some sort.

Obviously WebWorkers would make all this clearer and possibly easier but 
surely any number of free JS libraries could do that too. The only 
feature of WebWorkers that Javascript can't emulate is the ability for 
the worker to hang around after a page is closed; but I think this 
clearly falls into the category of a "web annoyance". When I close a 
page I want it gone - immediately. Passing workers around between pages 
sounds like something that would be good for advertising banner network 
trackers to avoid privacy settings.

I believe that babysitting developers (through feature elimination) is a 
bad idea. While WebWorkers aims to protect developers from common 
mistakes it will probalt force them into adopting worse hacks and 
workarounds. There is still a common conception of Javascript as a toy 
language, and in many ways that is true. However HTML5 calls itself a 
"WebApplications" language and we are indeed entering a time where many 
sophisticated desktop applications are being ported to Javascript. This 
raises a new issue, which is how do you port a threaded application to a 
language with no real threads or mutexes? With great difficulty I imagine.

One of the Mozilla JS developers has come out gunning against 
traditional threading in JS so it may be we never see an official thread 
object anytime soon ("over his dead body", in his own words). I realise 
WebWorkers tries to solve his concerns (mainly race conditions) by 
preventing  direct shared access to global variables but again this is 
something a threading library or good programming style should be able 
to solve. The workaround for webworker limitations is settimeout hacks 
so I wonder whether this is going to create horrible hybrid 
webworker+setimeout code that is generally unreadable.

Another issue with eliminating threads is that they are very desirable 
to developers. Because they are desirable it's likely that one of more 
browser vendors may go ahead and implement them anyway, essentially 
"embracing and extending" HTML5 and ECMAScript. If this happens then its 
likely a large number of popular multithreaded desktop applications will 
only be ported to those browsers. History has already shown us the 
problems this causes.

I am aware that the use cases and feature set of Web Workers has not 
been agreed on yet and there may be things I've overlooked. However I 
would much rather see an API that gives the developer more options and 
allows them to use or abuse them as required than a crippled API that 
pushes them into proprietary extensions, plugins and hacks to achieve 
something that every other major language already provides.

Shannon


From jonas at sicking.cc  Sun Aug 10 10:37:06 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Sun, 10 Aug 2008 10:37:06 -0700
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <489E7FD2.10202@arc.net.au>
References: <489E7FD2.10202@arc.net.au>
Message-ID: <489F2742.2010205@sicking.cc>

Shannon wrote:
> I've been following the WebWorkers discussion for some time trying to 
> make sense of the problems it is trying to solve. I am starting to come 
> to the conclusion that it provides little not already provided by:
> 
> setTimeout(mainThreadFunc,1)
> setTimeout(workThreadFunc,2)
> setTimeout(workThreadFunc,2)

Web workers provide two things over the above:

1. It makes it easier for the developer to implement heavy complex 
algorithms while not hanging the browser.
2. It allows web pages to take advantage of multicore CPUs.

details:
What you describe above is also known as cooperative multithreading. 
I.e. each "thread" has to manually stop itself regularly and give 
control to the other threads, and eventually they must do the same and 
give control back.

However this means that you have to deep inside your threads algorithm 
return out to the main event loop. This can be complicated if you have a 
deep callstack with a lot of local variables holding a lot of state.

Thus 1. Threading is easier to implement using workers since you don't 
have to escape back out to the main event loop.

Also, web workers allow the browser to spin up real OS threads and put 
off the worker execution there. So if you have a multicore CPU, which is 
becoming very common today, the work the page is doing can take 
advantage of more cores, thus producing better throughput.

I'm also unsure which mozilla developer has come out against the idea of 
web workers. I do know that we absolutely don't want the "traditional" 
threading APIs that include locks, mutexes, synchronization, shared 
memory etc. But that's not what the current spec has. It is a much much 
simpler "shared nothing" API which already has a basic implementation in 
recent nightlies.

/ Jonas


From shannon at arc.net.au  Sun Aug 10 17:54:18 2008
From: shannon at arc.net.au (Shannon)
Date: Mon, 11 Aug 2008 10:54:18 +1000
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <489F2742.2010205@sicking.cc>
References: <489E7FD2.10202@arc.net.au> <489F2742.2010205@sicking.cc>
Message-ID: <489F8DBA.8000706@arc.net.au>

Jonas Sicking wrote:
> Shannon wrote:
>> I've been following the WebWorkers discussion for some time trying to 
>> make sense of the problems it is trying to solve. I am starting to 
>> come to the conclusion that it provides little not already provided by:
>>
>> setTimeout(mainThreadFunc,1)
>> setTimeout(workThreadFunc,2)
>> setTimeout(workThreadFunc,2)
>
> Web workers provide two things over the above:
>
> 1. It makes it easier for the developer to implement heavy complex 
> algorithms while not hanging the browser.
> 2. It allows web pages to take advantage of multicore CPUs.
>
> details:
> What you describe above is also known as cooperative multithreading. 
> I.e. each "thread" has to manually stop itself regularly and give 
> control to the other threads, and eventually they must do the same and 
> give control back.
>
> However this means that you have to deep inside your threads algorithm 
> return out to the main event loop. This can be complicated if you have 
> a deep callstack with a lot of local variables holding a lot of state.
>
> Thus 1. Threading is easier to implement using workers since you don't 
> have to escape back out to the main event loop.
>
> Also, web workers allow the browser to spin up real OS threads and put 
> off the worker execution there. So if you have a multicore CPU, which 
> is becoming very common today, the work the page is doing can take 
> advantage of more cores, thus producing better throughput.
>
> I'm also unsure which mozilla developer has come out against the idea 
> of web workers. I do know that we absolutely don't want the 
> "traditional" threading APIs that include locks, mutexes, 
> synchronization, shared memory etc. But that's not what the current 
> spec has. It is a much much simpler "shared nothing" API which already 
> has a basic implementation in recent nightlies.
>
> / Jonas
>

I assumed setTimeout used real threads but I'm not advocating its use 
anyway. I think Lua co-routines solve every issue you raise. I hope 
WebWorkers will follow this model because I know from experience they 
are very easy to use. The basic features are:

* each coroutine gets a real OS thread (if available).
* coroutines can access global variables; Lua handles the locking itself.
* yield and resume are available, but optional.
* coroutines are garbage-collected when complete.
* coroutines run a function, not a file. There is no need for a separate 
file download.

the syntax is:

function workerThreadFunction()
   ... do stuff ...
end

workerThread1 = coroutine.create( workerThreadFunction )

A Javascript implementation could also assist the programmer by 
automatically skipping threads that are waiting on IO or blocked waiting 
on user input since these actions usually represent a large faction of a 
web page workload.

Maybe I misunderstand the concept of "shared nothing" but I think 
denying access to global objects is unwise. Maybe in a low-level 
language like C that's a bad thing but high-level languages can 
serialise simultaneous access to variables to prevent crashes and 
deadlocks. Performance can be improved by explicitly declaring private 
thread variables using var.

If coroutines are adopted I hope they will be called "coroutines". 
WebWorkers sounds silly and doesn't really assist in understanding their 
purpose (you have to already know what they are to understand the analogy).

I think this proposal belongs in an ECMAScript discussion group but I 
only bring it up here due to my extreme dislike of the current 
WebWorkers proposal. I think the best way forward is to drop WebWorkers 
completely from HTML5 and let the ECMAScript group look at it for JS 2.0 
or 3.0.

Shannon


From jonas at sicking.cc  Mon Aug 11 10:22:52 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 11 Aug 2008 10:22:52 -0700
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <489F8DBA.8000706@arc.net.au>
References: <489E7FD2.10202@arc.net.au> <489F2742.2010205@sicking.cc>
	<489F8DBA.8000706@arc.net.au>
Message-ID: <48A0756C.1010701@sicking.cc>

Shannon wrote:
> Jonas Sicking wrote:
>> Shannon wrote:
>>> I've been following the WebWorkers discussion for some time trying to 
>>> make sense of the problems it is trying to solve. I am starting to 
>>> come to the conclusion that it provides little not already provided by:
>>>
>>> setTimeout(mainThreadFunc,1)
>>> setTimeout(workThreadFunc,2)
>>> setTimeout(workThreadFunc,2)
>>
>> Web workers provide two things over the above:
>>
>> 1. It makes it easier for the developer to implement heavy complex 
>> algorithms while not hanging the browser.
>> 2. It allows web pages to take advantage of multicore CPUs.
>>
>> details:
>> What you describe above is also known as cooperative multithreading. 
>> I.e. each "thread" has to manually stop itself regularly and give 
>> control to the other threads, and eventually they must do the same and 
>> give control back.
>>
>> However this means that you have to deep inside your threads algorithm 
>> return out to the main event loop. This can be complicated if you have 
>> a deep callstack with a lot of local variables holding a lot of state.
>>
>> Thus 1. Threading is easier to implement using workers since you don't 
>> have to escape back out to the main event loop.
>>
>> Also, web workers allow the browser to spin up real OS threads and put 
>> off the worker execution there. So if you have a multicore CPU, which 
>> is becoming very common today, the work the page is doing can take 
>> advantage of more cores, thus producing better throughput.
>>
>> I'm also unsure which mozilla developer has come out against the idea 
>> of web workers. I do know that we absolutely don't want the 
>> "traditional" threading APIs that include locks, mutexes, 
>> synchronization, shared memory etc. But that's not what the current 
>> spec has. It is a much much simpler "shared nothing" API which already 
>> has a basic implementation in recent nightlies.
>>
>> / Jonas
>>
> 
> I assumed setTimeout used real threads but I'm not advocating its use 
> anyway. I think Lua co-routines solve every issue you raise. I hope 
> WebWorkers will follow this model because I know from experience they 
> are very easy to use. The basic features are:
> 
> * each coroutine gets a real OS thread (if available).
> * coroutines can access global variables; Lua handles the locking itself.
> * yield and resume are available, but optional.
> * coroutines are garbage-collected when complete.
> * coroutines run a function, not a file. There is no need for a separate 
> file download.
> 
> the syntax is:
> 
> function workerThreadFunction()
>   ... do stuff ...
> end
> 
> workerThread1 = coroutine.create( workerThreadFunction )
> 
> A Javascript implementation could also assist the programmer by 
> automatically skipping threads that are waiting on IO or blocked waiting 
> on user input since these actions usually represent a large faction of a 
> web page workload.
> 
> Maybe I misunderstand the concept of "shared nothing" but I think 
> denying access to global objects is unwise. Maybe in a low-level 
> language like C that's a bad thing but high-level languages can 
> serialise simultaneous access to variables to prevent crashes and 
> deadlocks. Performance can be improved by explicitly declaring private 
> thread variables using var.
> 
> If coroutines are adopted I hope they will be called "coroutines". 
> WebWorkers sounds silly and doesn't really assist in understanding their 
> purpose (you have to already know what they are to understand the analogy).
> 
> I think this proposal belongs in an ECMAScript discussion group but I 
> only bring it up here due to my extreme dislike of the current 
> WebWorkers proposal. I think the best way forward is to drop WebWorkers 
> completely from HTML5 and let the ECMAScript group look at it for JS 2.0 
> or 3.0.

One problem with what you're proposing is that in a browser environment 
the C host language and the javascript language is heavily intertwined. 
What do you do if a co-routine that lives in a separate thread calls 
into the DOM, which in most (all?) browser implementations isn't 
threadsafe? And what if that DOM call results in callbacks into 
javascript again?

/ Jonas


From aa at google.com  Mon Aug 11 10:43:29 2008
From: aa at google.com (Aaron Boodman)
Date: Mon, 11 Aug 2008 10:43:29 -0700
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <489F8DBA.8000706@arc.net.au>
References: <489E7FD2.10202@arc.net.au> <489F2742.2010205@sicking.cc>
	<489F8DBA.8000706@arc.net.au>
Message-ID: <278fd46c0808111043k282418c5qb7a22c0773e6a99d@mail.gmail.com>

On Sun, Aug 10, 2008 at 5:54 PM, Shannon <shannon at arc.net.au> wrote:
> * each coroutine gets a real OS thread (if available).

<snip>
Coroutines in Lua are not operating system threads or processes.
Coroutines are blocks of Lua code which are created within Lua, and
have their own flow of control like threads. Only one coroutine ever
runs at a time, and it runs until it activates another coroutine, or
yields (returns to the coroutine that invoked it). Coroutines are a
way to express multiple cooperating threads of control in a convenient
and natural way, but do not execute in parallel, and thus gain no
performance benefit from multiple CPU's. However, since coroutines
switch much faster than operating system threads and do not typically
require complex and sometimes expensive locking mechanisms, using
coroutines is typically faster than the equivalent program using full
OS threads.
</snip>

--http://lua-users.org/wiki/CoroutinesTutorial

Is this description incorrect? It seems at odds with what you said
about Lua coroutines getting an OS thread (if one is available).

- a


From rmk93 at yahoo.co.uk  Mon Aug 11 11:12:36 2008
From: rmk93 at yahoo.co.uk (Robert Mk)
Date: Mon, 11 Aug 2008 18:12:36 +0000 (GMT)
Subject: [whatwg] web development approach
Message-ID: <74950.3978.qm@web27207.mail.ukl.yahoo.com>

Dear web developer,
?
I need your help!
?
I am researching into how web developers choose a development approach.
?
It is pure research and not a front for a commercial organisation,? as such the whole survey looks very formal and it seems off putting to web developers.
?
It is 4 screens in length and asks about your influences on choosing how to develop web systems.
?
The survey does not require (it does ask ) for your contact details and so can be completely anonymous.
?
I would really appreciate you taking 10 mins to complete the questionnaire located at www.websurvey.here.ws
?
Many, many thanks
?
Rob k

Send instant messages to your online friends http://uk.messenger.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080811/aad38d11/attachment.htm>

From giecrilj at stegny.2a.pl  Mon Aug 11 12:54:05 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 11 Aug 2008 21:54:05 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com><c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com><20080806072713.GA26711@arc.mcc.id.au><F30E6D37-6380-40BD-866D-51F04430B29B@apple.com><a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com><D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com><c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com><BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com><c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com><1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com>
	<c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>
Message-ID: <F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC>

Neither the expression 'form.elements.$name' nor its expanded form
'form.elements["$name"]' is supposed to be defined even if $name is an
identifier of an embedded control.  The correct way to address the control
is 'form.elements("$name")', which is a shorthand notation for
'form.elements.item("$name")'.  These two should not be confused.
Therefore, the bug in Opera is not about shadowing the length property but
about defining the corresponding property at all (in particular,
'form.elements.ell' should be null no matter what).
OTOH, the expression 'form.length' is a perfect equivalent for
'form.elements("length")', provided a control with such a name is contained.
Have you reported this to Opera technical support?
I can see no harm in principle in assigning a value to 'form.length' because
length is not an intrinsic property the form object.

Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith
Sent: Saturday, August 09, 2008 2:06 AM
To: WHATWG List
Cc: Maciej Stachowiak
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
>

I'd like to put this back on the list, and it doesn't contain anything
personal, so I'm taking the liberty here.
>
> I'm not sure what you mean by "in the binding".

I meant the EcmaScript binding.

> Do you mean in Web IDL's
> definition of how to map Web IDL interfaces to the ECMAScript language, or
> one-off in the HTML5 spec for every interface this applies to?

Narrowing the scope in the interest of not creating bugs seems like a
very good idea.

This could potentially be described in the EcmaScript bindings. But it
would be a good idea to explore some edge cases. Particularly, if the
case was the order of definition of properties: One such case would be
an HTMLCollection with an element named "length". In that case, the
readonly "length" property would have to be the actual length of the
collection; the value should not be replaced with an element of that
name/id.

<form><input name="length"></form>

document.forms[0].elements.length

Opera9: [object HTMLInputElement] <-- BUG
FF3: 1
Saf3: 1

Another consideration would be a form element with an attribute
"length". That would be a problem as neither the attribute, nor the
Netscape 4 DOM "named items" are specified as "readonly". So that's
one reason for not specifying the Netscape 4 DOM and for removing that
example from WF 2.0
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default

>



From giecrilj at stegny.2a.pl  Mon Aug 11 13:07:00 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 11 Aug 2008 22:07:00 +0200
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <489F8DBA.8000706@arc.net.au>
References: <489E7FD2.10202@arc.net.au> <489F2742.2010205@sicking.cc>
	<489F8DBA.8000706@arc.net.au>
Message-ID: <C0601E7C3BF34253912A1BD1831CF55E@POCZTOWIEC>

Guarding concurrent access to global variables is not enough if those
variables hold references to objects because an object can end up in a
logically inconsistent state if two threads try modifying its properties
concurrently.  The objects would have to be lockable to avoid corrupting
global state.
Even if you limit yourself to scalar variables, there is nothing to prevent
a script to define a compound state as a set of scalar variables, each one
with its own name.  While it is not a good programming practice, old code
does it a lot because it is (or was) more efficient to say 'gTransCount'
than 'gTrans.count'.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Shannon
Sent: Monday, August 11, 2008 2:54 AM
To: Jonas Sicking
Cc: WHAT working group
Subject: Re: [whatwg] WebWorkers vs. Threads


Maybe I misunderstand the concept of "shared nothing" but I think 
denying access to global objects is unwise. Maybe in a low-level 
language like C that's a bad thing but high-level languages can 
serialise simultaneous access to variables to prevent crashes and 
deadlocks. Performance can be improved by explicitly declaring private 
thread variables using var.




From dhtmlkitchen at gmail.com  Mon Aug 11 13:37:24 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 11 Aug 2008 13:37:24 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
	<D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
	<c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>
	<BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com>
	<c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com>
	<1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com>
	<c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>
	<F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC>
Message-ID: <c9e12660808111337k3ad1e5vc6f14caf56e65ca7@mail.gmail.com>

On 8/11/08, Kristof Zelechovski <giecrilj at stegny.2a.pl> wrote:

Hi Chris,

Thanks for taking the time to respond to some things I was writing
about. I think these are important things that deserve attention, too.

If it's not too much to ask, have you considered inline style response?
http://en.wikipedia.org/wiki/Posting_style#Inline_replying

I tried to restore posting order, but since you are using Outlook, it
was not effectively possible.

> Neither the expression 'form.elements.$name' nor its expanded form
>  'form.elements["$name"]' is supposed to be defined even if $name is an
>  identifier of an embedded control.  The correct way to address the control
>  is 'form.elements("$name")',

Can you cite a reference for this?

AFAIK, this is an IE feature that was copied.

> which is a shorthand notation for
>  'form.elements.item("$name")'.

No, that is wrong. Doubly wrong, I think. The item method retrieves a
node by ordinal index (based on depth-first traversal).

 now if you had wrote:-

form.elements.namedItem("$name")

That would at least be partially correct. If namedItem is what you
meant, then please supply a reference to back up your claim. I do not
think the claim:

| The correct way to address the control is 'form.elements("$name")'

is true and correct. I think it's an MSIE invention that other
implementations copied.

> These two should not be confused.
>  Therefore, the bug in Opera is not about shadowing the length property but
>  about defining the corresponding property at all (in particular,
>  'form.elements.ell' should be null no matter what).

Are you referring to the example I supplied?

>  This could potentially be described in the EcmaScript bindings. But it
>  would be a good idea to explore some edge cases. Particularly, if the
>  case was the order of definition of properties: One such case would be
>  an HTMLCollection with an element named "length". In that case, the
>  readonly "length" property would have to be the actual length of the
>  collection; the value should not be replaced with an element of that
>  name/id.
>
>  <form><input name="length"></form>
>
>  document.forms[0].elements.length
>
>  Opera9: [object HTMLInputElement] <-- BUG
>  FF3: 1
>  Saf3: 1

There was no element in my example with a id or name 'ell', so I would
have to say that form.elements.ell would be undefined, not null.

Where is this - ell - coming from?

>  OTOH, the expression 'form.length' is a perfect equivalent for
>  'form.elements("length")', provided a control with such a name is contained.

form.elements has a readonly property named length.

That property can't be changed (legally) just because a parse  event
found an element named (or id'd) "length".

The length property of a form - form.length - refers to:

>  Have you reported this to Opera technical support?
>  I can see no harm in principle in assigning a value to 'form.length' because
>  length is not an intrinsic property the form object.
>

Chris, I have stated at least twice prior to this email that an
HTMLCollection has a readonly length property.

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506
| length of type unsigned long, readonly
| This attribute specifies the length or size of the list.

Garrett

>
>  Chris
>
>  -----Original Message-----
>  From: whatwg-bounces at lists.whatwg.org
>  [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith
>
> Sent: Saturday, August 09, 2008 2:06 AM
>  To: WHATWG List
>  Cc: Maciej Stachowiak
>  Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
>
>  On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>  >
>  > On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
>  >
>
>  I'd like to put this back on the list, and it doesn't contain anything
>  personal, so I'm taking the liberty here.
>  >
>  > I'm not sure what you mean by "in the binding".
>
>  I meant the EcmaScript binding.
>
>  > Do you mean in Web IDL's
>  > definition of how to map Web IDL interfaces to the ECMAScript language, or
>  > one-off in the HTML5 spec for every interface this applies to?
>
>  Narrowing the scope in the interest of not creating bugs seems like a
>  very good idea.
>

>
>  Another consideration would be a form element with an attribute
>  "length". That would be a problem as neither the attribute, nor the
>  Netscape 4 DOM "named items" are specified as "readonly". So that's
>  one reason for not specifying the Netscape 4 DOM and for removing that
>  example from WF 2.0
>  http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
>
>  >
>
>


From giecrilj at stegny.2a.pl  Mon Aug 11 14:53:18 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 11 Aug 2008 23:53:18 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808111337k3ad1e5vc6f14caf56e65ca7@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<a9699fd20808060717j3d8fd44cp6124593e1829fcf5@mail.gmail.com>
	<D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
	<c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>
	<BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com>
	<c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com>
	<1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com>
	<c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>
	<F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC>
	<c9e12660808111337k3ad1e5vc6f14caf56e65ca7@mail.gmail.com>
Message-ID: <ABA91900518A48339FC09E48F2CBF42A@POCZTOWIEC>

I have considered inline response.  I have two options: do it by hand (I am
rather busy) and do it for every reply (which makes business people angry).
I am sorry for the inconvenience it causes.  
The item method on a collection when the argument passed is a string that
cannot be coerced to an integer is equivalent to namedItem.  A form element
does not have an intrinsic length property; it can be added as an embedded
named control or by a script.  The elements collection has the intrinsic
length property and it cannot be shadowed.  
My source of information is MSDN, as you have correctly guessed.  If you
have contradictory information on legacy interfaces, please share it with
us.  Note that there is no way we can say it is correct or not; it is an
obsolete interface after all.  However, if it is consistent and all major
implementations support it, there is no reason to think it is false.  
The name 'ell' I used is a name of an embedded control in order to make it
different.  I am not sure about undefined versus null; I rather use Visual
Basic Scripting Edition and I get Nothing (not Empty) for a property an
object does not have.  It may as well be undefined under JavaScript.
Chris
See also <http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx>.

-----Original Message-----
From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] 
Sent: Monday, August 11, 2008 10:37 PM
To: Kristof Zelechovski
Cc: WHATWG List; Maciej Stachowiak
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

On 8/11/08, Kristof Zelechovski <giecrilj at stegny.2a.pl> wrote:

Hi Chris,

Thanks for taking the time to respond to some things I was writing
about. I think these are important things that deserve attention, too.

If it's not too much to ask, have you considered inline style response?
http://en.wikipedia.org/wiki/Posting_style#Inline_replying

I tried to restore posting order, but since you are using Outlook, it
was not effectively possible.

> Neither the expression 'form.elements.$name' nor its expanded form
>  'form.elements["$name"]' is supposed to be defined even if $name is an
>  identifier of an embedded control.  The correct way to address the
control
>  is 'form.elements("$name")',

Can you cite a reference for this?

AFAIK, this is an IE feature that was copied.

> which is a shorthand notation for
>  'form.elements.item("$name")'.

No, that is wrong. Doubly wrong, I think. The item method retrieves a
node by ordinal index (based on depth-first traversal).

 now if you had wrote:-

form.elements.namedItem("$name")

That would at least be partially correct. If namedItem is what you
meant, then please supply a reference to back up your claim. I do not
think the claim:

| The correct way to address the control is 'form.elements("$name")'

is true and correct. I think it's an MSIE invention that other
implementations copied.

> These two should not be confused.
>  Therefore, the bug in Opera is not about shadowing the length property
but
>  about defining the corresponding property at all (in particular,
>  'form.elements.ell' should be null no matter what).

Are you referring to the example I supplied?

>  This could potentially be described in the EcmaScript bindings. But it
>  would be a good idea to explore some edge cases. Particularly, if the
>  case was the order of definition of properties: One such case would be
>  an HTMLCollection with an element named "length". In that case, the
>  readonly "length" property would have to be the actual length of the
>  collection; the value should not be replaced with an element of that
>  name/id.
>
>  <form><input name="length"></form>
>
>  document.forms[0].elements.length
>
>  Opera9: [object HTMLInputElement] <-- BUG
>  FF3: 1
>  Saf3: 1

There was no element in my example with a id or name 'ell', so I would
have to say that form.elements.ell would be undefined, not null.

Where is this - ell - coming from?

>  OTOH, the expression 'form.length' is a perfect equivalent for
>  'form.elements("length")', provided a control with such a name is
contained.

form.elements has a readonly property named length.

That property can't be changed (legally) just because a parse  event
found an element named (or id'd) "length".

The length property of a form - form.length - refers to:

>  Have you reported this to Opera technical support?
>  I can see no harm in principle in assigning a value to 'form.length'
because
>  length is not an intrinsic property the form object.
>

Chris, I have stated at least twice prior to this email that an
HTMLCollection has a readonly length property.

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506
| length of type unsigned long, readonly
| This attribute specifies the length or size of the list.

Garrett

>
>  Chris
>




From joao.eiras at gmail.com  Mon Aug 11 17:12:54 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 12 Aug 2008 01:12:54 +0100
Subject: [whatwg] VIDEO tag height/width best fit
In-Reply-To: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
References: <4a27dd80808032119pb79b724j6ce67b42cfcff2cd@mail.gmail.com>
Message-ID: <op.ufqyvslgjz3wb9@mors>

Hi !

In this regard, <video> should be handled like <img>.
While handling an image, if you specify a width and leave height as auto,  
the UA will resize the height to keep the aspect ratio, because the UA  
known the images intrinsic dimensions. The same behavior happens if you  
specific height and leave width as auto. IF you specifi non, intrinsic  
dimensions will be used.

So, for <video>, the behavior should be the same. The UA knowns the video  
file intrisinc dimensions, so the samebehavior can be applied too.

This way we would not overspecify new behavior, which is good, and IMO  
enough, therefore simplifying the work of the web authors by reusing the  
old algorithm used for images.

Bye.


On , Biju Gm at il <bijumaillist at gmail.com> wrote:

> I apologize if I did not understood
> http://www.whatwg.org/specs/web-apps/current-work/#video
>
> I see a situation where we want to specify the height and width of the
> BOX in which a video need to be displayed. And while writing HTML code
> we dont know the height/width of the video. But when playing we want
> the video to be displayed with maximum size which can fit in the BOX
> without loosing the aspect ratio.
>
> After reading the <video> tag specification I dont see a way to
> achieve this with out javascript code.
>
> We should have one more attribute to tell how to "fit" the image/video
>
> == "fit" attribute values ===
> * center          - if it is small keep at center
> * stretch         - stretch/skew height and width to fit
> * stretch-height  - stretch/skew height only to fit,
>                     adjust width to maintain aspect ratio.
> * stretch-width   - stretch/skew width only to fit,
>                     adjust height to maintain aspect ratio.
> * stretch-best    - stretch/skew height or width to maximum
>                     so that other will fit in
>                     and maintain aspect ratio.
>
> May be we can also have a "tile" option
>
> This problem also exist for <img> tag.




From ian at hixie.ch  Mon Aug 11 17:33:54 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Aug 2008 00:33:54 +0000 (UTC)
Subject: [whatwg] Find a number with "." as the input
In-Reply-To: <DB185323-7A28-4AF8-BC36-18A4E3F5B50A@iki.fi>
References: <DB185323-7A28-4AF8-BC36-18A4E3F5B50A@iki.fi>
Message-ID: <Pine.LNX.4.62.0808120033500.5140@hixie.dreamhostps.com>

On Sat, 18 Nov 2006, Henri Sivonen wrote:
>
> The definition of "find a number" ( http://whatwg.org/specs/web-apps/ 
> current-work/#find-a ) may cause a string containing a single U+002E 
> FULL STOP to be fed to the algorithm entitled "rules for parsing 
> floating point number values" ( 
> http://whatwg.org/specs/web-apps/current-work/#rules1 ). The definition 
> for "find a number" claims that this step can never fail, but step 9 in 
> "rules for parsing floating point number values" returns an error in 
> this case.

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 11 17:54:01 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Aug 2008 00:54:01 +0000 (UTC)
Subject: [whatwg] meter and document conformance
In-Reply-To: <FC38DF9E-D009-4ECD-A914-A2DC949473B3@iki.fi>
References: <FC38DF9E-D009-4ECD-A914-A2DC949473B3@iki.fi>
Message-ID: <Pine.LNX.4.62.0808120053410.5140@hixie.dreamhostps.com>

On Sat, 18 Nov 2006, Henri Sivonen wrote:
>
> Is a document non-conforming if it contains a meter element that does 
> not have a value attribute and the algorithm http://whatwg.org/specs/ 
> web-apps/current-work/#steps fails to return either number1 and 
> denominator or number1 and number2?
> 
> I think such documents should be non-conforming.

Done -- a value is required. Max isn't.

-- 
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 11 17:58:43 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Aug 2008 00:58:43 +0000 (UTC)
Subject: [whatwg] meter and document conformance
In-Reply-To: <7CC5530A-D6E0-40AA-8C3D-2A32E5389D27@iki.fi>
References: <FC38DF9E-D009-4ECD-A914-A2DC949473B3@iki.fi>
	<7CC5530A-D6E0-40AA-8C3D-2A32E5389D27@iki.fi>
Message-ID: <Pine.LNX.4.62.0808120058250.5140@hixie.dreamhostps.com>

On Sat, 18 Nov 2006, Henri Sivonen wrote:
> On Nov 18, 2006, at 14:32, Henri Sivonen wrote:
> 
> > Is a document non-conforming if it contains a meter element that does not
> > have a value attribute and the algorithm http://whatwg.org/
> > specs/web-apps/current-work/#steps fails to return either number1 and
> > denominator or number1 and number2?
> > 
> > I think such documents should be non-conforming.
> 
> The same question and opinion apply to progress as well.

No, a <progress> element with no max and value is just an indeterminate 
progress bar.

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


From joao.eiras at gmail.com  Mon Aug 11 18:28:01 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 12 Aug 2008 02:28:01 +0100
Subject: [whatwg] Treat <video> like an image
In-Reply-To: <op.ufq0p6aljz3wb9@mors>
References: <op.ufq0p6aljz3wb9@mors>
Message-ID: <op.ufq2czumjz3wb9@mors>

Hi !

Not a long time ago, we saw an Opera build which had <video> support. What
was really really cool about it was that <video> was pretty much supported
like any other image format so we could apply filtering and other complex
stuff from svg like in this example.
http://people.opera.com/howcome/2007/video/svg/video-filter.svg

This gives us an entire range of possibilities with <video>, just like
with <svg>, or <img>

I think that video should be supported like any other image:
   - supporting transparencies (if the video codec allows)
   - embedding video files with <video> or <object> element
   - embedding video files with url() in css where images can be used, like
background-image
   - embedding video files with url() in css content rules

If course, this could raise some issues like:
   - performance - the UA should provide a way for the use to toggle video
on and off, or could make decisions based on the platform's overall
performance. Also, with rendering engines progressively migrating to
architectures that support hardware acceleration, blending a background
video with foreground content could be a trivial lightweight operation,
although the same cannot be said for software renderers.
   - fallback in css not possible - if a UA does not support video, then it
would ignore the content embedded in the stylesheet. Such behavior is also
fully supported for other content types, like unrecognized image formats
and the likes. However, the problem of adding fallback content with CSS
not being trivial, is a problem with css itself, and out of scope of the
<video> specification
   - accessibility, usability - by providing new means for authors to add
more video and possibly other annoying animations in webpages, users could
easily be annoyed with excess of animated content. This is more or less
the same problem of performance, so the UA should give the user the option
to disable video, preferably in site specific preferences, if supported.

So, what do you think ?

Bye.




From ddailey at zoominternet.net  Mon Aug 11 19:34:09 2008
From: ddailey at zoominternet.net (ddailey)
Date: Mon, 11 Aug 2008 22:34:09 -0400
Subject: [whatwg] Treat <video> like an image
References: <op.ufq0p6aljz3wb9@mors> <op.ufq2czumjz3wb9@mors>
Message-ID: <E5674E7A61F04853921109150976FCDC@disxgdg31szkx7>

I'm thinking that you're thinking like an author. I like it!

Lots of fun and you're right to point out the possibility for problems. 
Allowing video to be turned off (just like browsers used to -- and probably 
still do --  allow for images to be turned off, when the hardware or user 
isn't up for it) would probably be required until about 2024 when the 
browser will be able to handle 4000 concurrent 6-channel 3-D video feeds, 
each diff-ed against all other pairs, in an omni-time-space analytic 
manifold of some sort that is tweaked by a hyperdimensional differential 
brainwave mouse .

The Opera build with real-time SVG filters applied to video, made me think 
that HTML and SVG ought to be sharing the filter business rather than being 
mired down with the troglodytic <canvas> re-invention of wheel business, but 
then who's to say that wheels need to be round anyhow?

cheers
David Dailey
----- Original Message ----- 
From: "Jo?o Eiras" <joao.eiras at gmail.com>
To: <whatwg at whatwg.org>
Sent: Monday, August 11, 2008 9:28 PM
Subject: [whatwg] Treat <video> like an image


> Hi !
>
> Not a long time ago, we saw an Opera build which had <video> support. What
> was really really cool about it was that <video> was pretty much supported
> like any other image format so we could apply filtering and other complex
> stuff from svg like in this example.
> http://people.opera.com/howcome/2007/video/svg/video-filter.svg
>
> This gives us an entire range of possibilities with <video>, just like
> with <svg>, or <img>
>
> I think that video should be supported like any other image:
>   - supporting transparencies (if the video codec allows)
>   - embedding video files with <video> or <object> element
>   - embedding video files with url() in css where images can be used, like
> background-image
>   - embedding video files with url() in css content rules
>
> If course, this could raise some issues like:
>   - performance - the UA should provide a way for the use to toggle video
> on and off, or could make decisions based on the platform's overall
> performance. Also, with rendering engines progressively migrating to
> architectures that support hardware acceleration, blending a background
> video with foreground content could be a trivial lightweight operation,
> although the same cannot be said for software renderers.
>   - fallback in css not possible - if a UA does not support video, then it
> would ignore the content embedded in the stylesheet. Such behavior is also
> fully supported for other content types, like unrecognized image formats
> and the likes. However, the problem of adding fallback content with CSS
> not being trivial, is a problem with css itself, and out of scope of the
> <video> specification
>   - accessibility, usability - by providing new means for authors to add
> more video and possibly other annoying animations in webpages, users could
> easily be annoyed with excess of animated content. This is more or less
> the same problem of performance, so the UA should give the user the option
> to disable video, preferably in site specific preferences, if supported.
>
> So, what do you think ?
>
> Bye.
>
>
>
> 



From jonas at sicking.cc  Mon Aug 11 21:58:40 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 11 Aug 2008 21:58:40 -0700
Subject: [whatwg] Treat <video> like an image
In-Reply-To: <op.ufq2czumjz3wb9@mors>
References: <op.ufq0p6aljz3wb9@mors> <op.ufq2czumjz3wb9@mors>
Message-ID: <48A11880.5070807@sicking.cc>

Jo?o Eiras wrote:
> Hi !
> 
> Not a long time ago, we saw an Opera build which had <video> support. What
> was really really cool about it was that <video> was pretty much supported
> like any other image format so we could apply filtering and other complex
> stuff from svg like in this example.
> http://people.opera.com/howcome/2007/video/svg/video-filter.svg
> 
> This gives us an entire range of possibilities with <video>, just like
> with <svg>, or <img>
> 
> I think that video should be supported like any other image:
>   - supporting transparencies (if the video codec allows)
>   - embedding video files with <video> or <object> element
>   - embedding video files with url() in css where images can be used, like
> background-image
>   - embedding video files with url() in css content rules
> 
> If course, this could raise some issues like:
>   - performance - the UA should provide a way for the use to toggle video
> on and off, or could make decisions based on the platform's overall
> performance. Also, with rendering engines progressively migrating to
> architectures that support hardware acceleration, blending a background
> video with foreground content could be a trivial lightweight operation,
> although the same cannot be said for software renderers.
>   - fallback in css not possible - if a UA does not support video, then it
> would ignore the content embedded in the stylesheet. Such behavior is also
> fully supported for other content types, like unrecognized image formats
> and the likes. However, the problem of adding fallback content with CSS
> not being trivial, is a problem with css itself, and out of scope of the
> <video> specification
>   - accessibility, usability - by providing new means for authors to add
> more video and possibly other annoying animations in webpages, users could
> easily be annoyed with excess of animated content. This is more or less
> the same problem of performance, so the UA should give the user the option
> to disable video, preferably in site specific preferences, if supported.

I think I agree. But I don't see anything in any current specs that 
contradicts what you are saying. In other words, are you requesting any 
changes to any specific specs, or are you just asking UA developers to 
implement the feature set to full extent that specs allow?

Note that the CSS spec says nothing about what format a url() can point 
to, thus there is no spec-wise reason pointing to a video file wouldn't 
work.

And there is no documented limitation on which elements css transparency 
applies, thus applying it to a <video> element should work just fine, 
and already does in the implementation in recent firefox nightlies.

/ Jonas


From jonas at sicking.cc  Mon Aug 11 22:08:24 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 11 Aug 2008 22:08:24 -0700
Subject: [whatwg] Treat <video> like an image
In-Reply-To: <E5674E7A61F04853921109150976FCDC@disxgdg31szkx7>
References: <op.ufq0p6aljz3wb9@mors> <op.ufq2czumjz3wb9@mors>
	<E5674E7A61F04853921109150976FCDC@disxgdg31szkx7>
Message-ID: <48A11AC8.7080007@sicking.cc>

ddailey wrote:
> The Opera build with real-time SVG filters applied to video, made me 
> think that HTML and SVG ought to be sharing the filter business rather 
> than being mired down with the troglodytic <canvas> re-invention of 
> wheel business, but then who's to say that wheels need to be round anyhow?

You mean like this:

http://www.bluishcoder.co.nz/2008/07/video-bling.html

/ Jonas


From giecrilj at stegny.2a.pl  Tue Aug 12 00:47:26 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 12 Aug 2008 09:47:26 +0200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <489ADB2E.50405@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	<489A9C04.9040006@wikimedia.org>	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	<489AB360.6010408@wikimedia.org><489ABEEB.7080603@peda.net>
	<489ADB2E.50405@wikimedia.org>
Message-ID: <47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>

What is the advantage of using JavaScript to determine a viable embedding
method over using alternative streams and fallback content that can include
the OBJECT element where appropriate?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Tim Starling
Sent: Thursday, August 07, 2008 1:23 PM
To: WHATWG List
Subject: Re: [whatwg] Scripted querying of <video> capabilities

The reason this is needed, as opposed to using multiple <source> tags,
is because inevitably, some clients will support certain formats via
<object> (or in our special case, <applet>) and not via <video>.
Querying the browser's <video> capabilities allows JS to decide what
sort of embedding method to use. It's an essential migration feature.

-- Tim Starling



From drj at ravenbrook.com  Tue Aug 12 01:03:37 2008
From: drj at ravenbrook.com (David Jones)
Date: Tue, 12 Aug 2008 09:03:37 +0100
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <278fd46c0808111043k282418c5qb7a22c0773e6a99d@mail.gmail.com>
References: <489E7FD2.10202@arc.net.au> <489F2742.2010205@sicking.cc>
	<489F8DBA.8000706@arc.net.au>
	<278fd46c0808111043k282418c5qb7a22c0773e6a99d@mail.gmail.com>
Message-ID: <AC6911EA-CC0F-4874-8160-DF8229621281@ravenbrook.com>


On 11 Aug 2008, at 18:43, Aaron Boodman wrote:

> On Sun, Aug 10, 2008 at 5:54 PM, Shannon <shannon at arc.net.au> wrote:
>> * each coroutine gets a real OS thread (if available).
>
> <snip>
> Coroutines in Lua are not operating system threads or processes.
> Coroutines are blocks of Lua code which are created within Lua, and
> have their own flow of control like threads. Only one coroutine ever
> runs at a time, and it runs until it activates another coroutine, or
> yields (returns to the coroutine that invoked it). Coroutines are a
> way to express multiple cooperating threads of control in a convenient
> and natural way, but do not execute in parallel, and thus gain no
> performance benefit from multiple CPU's. However, since coroutines
> switch much faster than operating system threads and do not typically
> require complex and sometimes expensive locking mechanisms, using
> coroutines is typically faster than the equivalent program using full
> OS threads.
> </snip>
>
> --http://lua-users.org/wiki/CoroutinesTutorial
>
> Is this description incorrect? It seems at odds with what you said
> about Lua coroutines getting an OS thread (if one is available).

The description you quoted from lua-users.org is correct.  The  
primary implementation of Lua is 100% portable ISO C, it therefore  
does _not_ use OS threads for coroutines.  I think there may be  
extensions/modifications produced by other parties that provide that.

David Jones
Ravenbrook Limited


From chris.double at double.co.nz  Tue Aug 12 02:13:29 2008
From: chris.double at double.co.nz (Chris Double)
Date: Tue, 12 Aug 2008 21:13:29 +1200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
	<489A9C04.9040006@wikimedia.org>
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>
	<489ADB2E.50405@wikimedia.org>
	<47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>
Message-ID: <c2e346f90808120213w73051578h5d236d6ef241e8@mail.gmail.com>

On Tue, Aug 12, 2008 at 7:47 PM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> What is the advantage of using JavaScript to determine a viable embedding
> method over using alternative streams and fallback content that can include
> the OBJECT element where appropriate?

<video src="foo.ogg">
  fallback content
</video>

On a browser that doesn't support video this will use the fallback
content (OBJECT, etc) to instantiate something that can play the Ogg
file. On a browser that supports video and Ogg it will play the video.
On a browser that supports video but not Ogg, how do you then
instantiate a fallback that can play the Ogg file. Without JavaScript
and without providing an alternative source re-encoded in a different
format.

Chris.
-- 
http://www.bluishcoder.co.nz


From shannon at arc.net.au  Tue Aug 12 02:51:55 2008
From: shannon at arc.net.au (Shannon)
Date: Tue, 12 Aug 2008 19:51:55 +1000
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <AC6911EA-CC0F-4874-8160-DF8229621281@ravenbrook.com>
References: <489E7FD2.10202@arc.net.au>
	<489F2742.2010205@sicking.cc>	<489F8DBA.8000706@arc.net.au>	<278fd46c0808111043k282418c5qb7a22c0773e6a99d@mail.gmail.com>
	<AC6911EA-CC0F-4874-8160-DF8229621281@ravenbrook.com>
Message-ID: <48A15D3B.4090401@arc.net.au>


>>
>>
>> --http://lua-users.org/wiki/CoroutinesTutorial
>>
>> Is this description incorrect? It seems at odds with what you said
>> about Lua coroutines getting an OS thread (if one is available).
>
> The description you quoted from lua-users.org is correct.  The primary 
> implementation of Lua is 100% portable ISO C, it therefore does _not_ 
> use OS threads for coroutines.  I think there may be 
> extensions/modifications produced by other parties that provide that.
>
> David Jones
> Ravenbrook Limited
>
Sorry about the misinformation. I've been working on Lua programs with 
thousands of coroutines running and never noticed any artifacts or 
delays to indicate the execution wasn't truly parallel. What I don't 
understand is why it doesn't appear to block other coroutines on IO but 
since that's not relevant to creating threaded workers I'll leave that 
mystery for future research.

I thought Lua had an implementation of automated locking to use as a 
reference but since it doesn't I have nothing more to offer on the 
subject. Without knowing the internals of existing JS implementations I 
have no idea what would be involved to provide automated locking and 
whether it is impossible or just difficult.

Shannon



 




From ian at hixie.ch  Tue Aug 12 03:18:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Aug 2008 10:18:19 +0000 (UTC)
Subject: [whatwg] lang vs. xml:lang; id vs. xml:id
In-Reply-To: <805CEB1A-9788-46D9-A399-83C6A8D13B8F@michelf.com>
References: <56C84BAC-28D6-4804-8A4C-EAE5AC3CC0EA@michelf.com>
	<45702F3C.7010605@lachy.id.au>
	<BEDDBE0B-E733-4D82-87EF-9BBC03E61DFA@michelf.com>
	<Pine.LNX.4.62.0612011641520.4460@dhalsim.dreamhost.com>
	<805CEB1A-9788-46D9-A399-83C6A8D13B8F@michelf.com>
Message-ID: <Pine.LNX.4.62.0808121016300.5140@hixie.dreamhostps.com>

On Fri, 1 Dec 2006, Michel Fortin wrote:
> Le 1 d?c. 2006 ? 11:44, Ian Hickson a ?crit :
> > On Fri, 1 Dec 2006, Michel Fortin wrote:
> > > 
> > > Okay, so if I understand well, xml:lang in the spec refers to the 
> > > "lang" attribute in the "xml" namespace, not to the "xml:lang" 
> > > attribute in the null namespace that you get with the HTML parser. 
> > > It makes sense from a DOM perspective, but it's misleading from a 
> > > markup perspective, so I still think it should be clarified.
> > 
> > Could you propose some text?
> 
> What about adding at the end of this paragraph:
> 
> "If both the xml:lang attribute and the lang attribute are set, user 
> agents must use the xml:lang attribute, and the lang attribute must be 
> ignored for the purposes of determining the element's language."
> 
> the following sentence:
> 
> "Note that the xml:lang attribute can only be set via scripting for HTML 
> documents, since the HTML parser does not handle namespaces."
> 
> I guess that new sentence is totally obvious when you've read the 
> Terminology section, but I still think it's important because xml:lang 
> is used a lot in XHTML1 documents served as text/html, and people will 
> be referring to this part of the spec to know what browsers do about 
> them so it ought to be clear.

The above is more intended for implementors than authors, so to call this 
out earlier and hopefully more obviously for authors, I changed an earlier 
instance of the string "xml:lang" to read:

   The xml:lang attribute (that is, the lang attribute with the xml prefix 
   in the http://www.w3.org/XML/1998/namespace namespace) is defined in 
   XML. [XML]

Let me know if that's ok.

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

From giecrilj at stegny.2a.pl  Tue Aug 12 04:06:41 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 12 Aug 2008 13:06:41 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808061123j78593fe7va0087c45cb6525ad@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com><a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com><c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com><a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com><c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com><20080806072713.GA26711@arc.mcc.id.au><F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<c9e12660808061123j78593fe7va0087c45cb6525ad@mail.gmail.com>
Message-ID: <E18A8D344E204814A0174222D6544FEA@POCZTOWIEC>

The attribute FORM.length is not parseable: it cannot be defined in the HTML
source and such definition should be ignored.  The intrinsic computed length
attribute should take precedence over the imported control name which can be
retrieved calling form.elements.item("length").
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith
Sent: Wednesday, August 06, 2008 8:24 PM
To: Maciej Stachowiak
Cc: Cameron McCormack; whatwg at whatwg.org
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

Testcases to determine what implementations do and what are the worst
problems to avoid would be the most useful at this point. For example,
a HTMLFORMElement with the name "length", and attribute "length" on
the form.

<form length="10">
  <input name="length">
</form>

Please do make up some test cases. You can post these to the list.
Talk to Ian about where to upload them for reference.





From shannon at arc.net.au  Tue Aug 12 04:50:21 2008
From: shannon at arc.net.au (Shannon)
Date: Tue, 12 Aug 2008 21:50:21 +1000
Subject: [whatwg] WebWorker questions
Message-ID: <48A178FD.9080706@arc.net.au>

A few questions and thoughts on the WebWorkers proposal:

If a WebWorker object is assigned to local variable inside a  complex 
script then it cannot be seen or stopped by the calling page. Should the 
specification offer document.workers or getAllWorkers() as a means to 
iterate over all workers regardless of where they were created?
 
Is it wise to give a web application more processing power than a single 
CPU core (or HT thread) can provide? What stops a web page hogging ALL 
cores (deliberately or not) and leaving no resources for the UI mouse or 
key actions required to close the page? (This is not a contrived 
example, I have seen both Internet Explorer on Win32 and Flash on Linux 
consume 100% CPU on several occasions). I know it's a "vendor issue" but 
should the spec at least recommend UAs leave the last CPU/core free for 
OS tasks?

Can anybody point me to an existing Javascript-based web service that 
needs more client processing power than a single P4 core?

Shouldn't an application that requires so much grunt really be written 
in Java or C as an applet, plug-in or standalone application?

If an application did require that much computation isn't it also likely 
to need a more efficient inter-"thread" messaging protocol than passing 
Unicode strings through MessagePorts? At the very least wouldn't it 
usually require the passing of binary data, complex objects or arrays 
between workers without the additional overhead of a string encode/decode?

Is the resistance to adding threads to Javascript an issue with the 
language itself, or a matter of current interpreters being non-threadsafe?

The draft spec says "protected" workers are allowed to live for a 
"user-agent-defined amount of time" after a page or browser is closed. 
I'm not really sure what possible value this could have since as an 
author we won't know whether the UA allows _any_ time and if so whether 
that time will be enough to complete our cleanup (given a vast 
discrepancy in operations-per-second across UAs and client PCs). If our 
cleanup can be arbitrarily cancelled then isn't it likely that we might 
actually leave the client or server in a worse state than if we hadn't 
tried at all? Won't this cause difficult-to-trace sporadic bugs caused 
by browser differences in what could be a rare event (a close during 
operation Y instead of during X)?

I just don't see any common cases where you'd _need_ multiple OS threads 
but still be willing to accept Javascripts' poor performance, Webworkers 
limited API, and MessagePorts' limited IO. The only things I can think 
of are new user annoyances (like delaying browser shutdown and hogging 
the CPU). Sure UA's might let us disable these things but then some 
pages won't work. The Working Draft 
<http://stuff.gsnedders.com/spec-gen/webworkers.html> lists a few 
examples, most of which appear to use non-blocking network IO and 
callbacks anyway. Other examples rely on the ability for workers to 
outlive the lifetime of the calling page (which is pretty contentious). 
The one remaining example is a contrived mathematical exercise. Is the 
scientific world really crying out for complex theorems to be solved in 
web browsers? What real-world use cases is WebWorkers supposed to solve?

I would like to see WebWorkers happen but as an author and a user I have 
serious concerns about using it in its current form. Is it really worth 
implementing or should more attention be paid to fixing non-thread-safe 
practices in the specification so future UAs can better manage threading 
internally (ie: video, IO, sockets, JS all running on seperate threads 
or even sets of threads per open tab/window)?

Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080812/99910b37/attachment.htm>

From giecrilj at stegny.2a.pl  Tue Aug 12 04:53:31 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 12 Aug 2008 13:53:31 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com><a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com><c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com><a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
Message-ID: <3B0990F66B884008A2EE6AB89CB9AE83@POCZTOWIEC>

It is probably too late for that but I like the concept of a default
property much better than metaattributes like IndexGetter.
For example, document.forms(0) means "call forms on document with argument
0".  That is impossible because forms is not a function so we look into
forms collection and we see that it has the default method named item.  So
we proceed by expanding it to document.forms.item(0) and we see it works.
I like it because it is simple, elegant and generic, whereas IndexGetter and
what you have looks ad-hoc.
I have never seen document.forms.main used to get at the form named "main" 
but probably I have not seen that much.  I wonder how common it is.
Of course, I agree that it is best to be explicit and not to rely on such
tricks at all.  The downside is that, for example, while
a.getAttributeNode("href").value = url is technically superior to a.href =
url, it is much harder to read so care must be taken not to overshoot.  But
form.elements.item("main") is just fine.
Regarding how the named elements get to be true properties, the shadowing
behavior can be specified without recurring to getters.  It is sufficient to
say that an intrinsic property is never replaced by a constructed shortcut
property and we get the same result.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith
Sent: Wednesday, August 06, 2008 8:49 AM
To: Thomas Broyer
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer <t.broyer at gmail.com> wrote:
> On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
>> On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
>>>
>> First off, the IndexGetter behavior on the HTMLCollection[1] is the
>> authors imagination.
>
> Aren't "document.forms[0]" and "document.forms.myform" working?
>

Can you be more specific and direct in your reply? It isn't clear what
your point is.

>> The following example shows that indexed Properties exist on
>> NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
>> There is no [[ IndexGetter ]] as Cameron likes to make pretend.
>
> This is an "implementation detail" of the ECMAScript binding.
>

In EcmaScript, the property access operators seem to look like a
"getter" to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this seems implemented as a "getter". A "getter" is a
method that gets the value of a property of that name.





From joao.eiras at gmail.com  Tue Aug 12 06:49:45 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 12 Aug 2008 14:49:45 +0100
Subject: [whatwg] Treat <video> like an image
In-Reply-To: <48A11880.5070807@sicking.cc>
References: <op.ufq0p6aljz3wb9@mors> <op.ufq2czumjz3wb9@mors>
	<48A11880.5070807@sicking.cc>
Message-ID: <op.ufr0o7vfjz3wb9@mors>

On , Jonas Sicking <jonas at sicking.cc> wrote:

> Jo?o Eiras wrote:
>> Hi !
>>  Not a long time ago, we saw an Opera build which had <video> support.  
>> What
>> was really really cool about it was that <video> was pretty much  
>> supported
>> like any other image format so we could apply filtering and other  
>> complex
>> stuff from svg like in this example.
>> http://people.opera.com/howcome/2007/video/svg/video-filter.svg
>>  This gives us an entire range of possibilities with <video>, just like
>> with <svg>, or <img>
>>  I think that video should be supported like any other image:
>>   - supporting transparencies (if the video codec allows)
>>   - embedding video files with <video> or <object> element
>>   - embedding video files with url() in css where images can be used,  
>> like
>> background-image
>>   - embedding video files with url() in css content rules
>>  If course, this could raise some issues like:
>>   - performance - the UA should provide a way for the use to toggle  
>> video
>> on and off, or could make decisions based on the platform's overall
>> performance. Also, with rendering engines progressively migrating to
>> architectures that support hardware acceleration, blending a background
>> video with foreground content could be a trivial lightweight operation,
>> although the same cannot be said for software renderers.
>>   - fallback in css not possible - if a UA does not support video, then  
>> it
>> would ignore the content embedded in the stylesheet. Such behavior is  
>> also
>> fully supported for other content types, like unrecognized image formats
>> and the likes. However, the problem of adding fallback content with CSS
>> not being trivial, is a problem with css itself, and out of scope of the
>> <video> specification
>>   - accessibility, usability - by providing new means for authors to add
>> more video and possibly other annoying animations in webpages, users  
>> could
>> easily be annoyed with excess of animated content. This is more or less
>> the same problem of performance, so the UA should give the user the  
>> option
>> to disable video, preferably in site specific preferences, if supported.
>
> I think I agree. But I don't see anything in any current specs that  
> contradicts what you are saying. In other words, are you requesting any  
> changes to any specific specs, or are you just asking UA developers to  
> implement the feature set to full extent that specs allow?
>
> Note that the CSS spec says nothing about what format a url() can point  
> to, thus there is no spec-wise reason pointing to a video file wouldn't  
> work.
>
> And there is no documented limitation on which elements css transparency  
> applies, thus applying it to a <video> element should work just fine,  
> and already does in the implementation in recent firefox nightlies.
>
> / Jonas

Hi !
I asked this just to probe some opinions, to make sure the spec does not  
forbid this (and so you've clarified me), and to raise a bit more  
awareness about these new possibilities.
I think that there could be a comment in a non-normative section of the  
specification, for implementors, encouraging them to implement these  
features.

Thank you. Goodbye.




From joao.eiras at gmail.com  Tue Aug 12 06:57:40 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 12 Aug 2008 14:57:40 +0100
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <c2e346f90808120213w73051578h5d236d6ef241e8@mail.gmail.com>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
	<489A9C04.9040006@wikimedia.org>
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>
	<489ADB2E.50405@wikimedia.org>
	<47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>
	<c2e346f90808120213w73051578h5d236d6ef241e8@mail.gmail.com>
Message-ID: <op.ufr02eizjz3wb9@mors>

> On a browser that supports video but not Ogg

Then the browser does not support <video>. The spec mandates both <video>  
element support + ogg theora support. Else the implementation is  
incomplete.
It would be the same like have <img> without the UA not supporting any  
kind of image format.

But I agree though that we need an API to test UA capabilities, because  
the list of supported video and audio formats can grow, and have several  
different implementations in different states in different UAs, therefore  
hiding this information from the web page would result in more bloated  
javascript code doing more broken browser sniffing.

Just 2 cents.

Bye.


On , Chris Double <chris.double at double.co.nz> wrote:

> On Tue, Aug 12, 2008 at 7:47 PM, Kristof Zelechovski
> <giecrilj at stegny.2a.pl> wrote:
>> What is the advantage of using JavaScript to determine a viable  
>> embedding
>> method over using alternative streams and fallback content that can  
>> include
>> the OBJECT element where appropriate?
>
> <video src="foo.ogg">
>   fallback content
> </video>
>
> On a browser that doesn't support video this will use the fallback
> content (OBJECT, etc) to instantiate something that can play the Ogg
> file. On a browser that supports video and Ogg it will play the video.
> On a browser that supports video but not Ogg, how do you then
> instantiate a fallback that can play the Ogg file. Without JavaScript
> and without providing an alternative source re-encoded in a different
> format.
>
> Chris.




From giecrilj at stegny.2a.pl  Tue Aug 12 07:13:12 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 12 Aug 2008 16:13:12 +0200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <op.ufr02eizjz3wb9@mors>
References: <489A63A5.3060603@wikimedia.org>
	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>
	<489A9C04.9040006@wikimedia.org>
	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>
	<489AB360.6010408@wikimedia.org> <489ABEEB.7080603@peda.net>
	<489ADB2E.50405@wikimedia.org>
	<47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>
	<c2e346f90808120213w73051578h5d236d6ef241e8@mail.gmail.com>
	<op.ufr02eizjz3wb9@mors>
Message-ID: <73B7F45828E341799080494FE9EFE2CA@POCZTOWIEC>

Why do we need an API to test UA media capabilities?  What purpose would
such an API serve except for displaying the media to the user - a task which
can already be achieved without a dedicated API?

Chris

-----Original Message-----
From: Joao Eiras [mailto:joao.eiras at gmail.com] 
Sent: Tuesday, August 12, 2008 3:58 PM
To: Chris Double; Kristof Zelechovski
Cc: WHATWG List; Tim Starling
Subject: Re: [whatwg] Scripted querying of <video> capabilities

But I agree though that we need an API to test UA capabilities, because  
the list of supported video and audio formats can grow, and have several  
different implementations in different states in different UAs, therefore  
hiding this information from the web page would result in more bloated  
javascript code doing more broken browser sniffing.





From tstarling at wikimedia.org  Tue Aug 12 07:39:23 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Wed, 13 Aug 2008 00:39:23 +1000
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <73B7F45828E341799080494FE9EFE2CA@POCZTOWIEC>
References: <489A63A5.3060603@wikimedia.org>	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	<489A9C04.9040006@wikimedia.org>	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	<489AB360.6010408@wikimedia.org>
	<489ABEEB.7080603@peda.net>	<489ADB2E.50405@wikimedia.org>	<47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>	<c2e346f90808120213w73051578h5d236d6ef241e8@mail.gmail.com>	<op.ufr02eizjz3wb9@mors>
	<73B7F45828E341799080494FE9EFE2CA@POCZTOWIEC>
Message-ID: <48A1A09B.6010408@wikimedia.org>

Kristof Zelechovski wrote:
> Why do we need an API to test UA media capabilities?  What purpose would
> such an API serve except for displaying the media to the user - a task which
> can already be achieved without a dedicated API?
>   

It is useful for websites that wish to use a new or unpopular format
(such as Ogg Theora). If the client does not support the format in
question using <video>, it can fall back to another method.

I am employed to work on just such a website (Wikipedia). I maintain a
Java applet called Cortado that can be used to play Theora/Vorbis
videos, and I wrote an extension for MediaWiki called OggHandler which
uses JavaScript and an extensive series of client-side fallbacks
(including Cortado and <video>) to display Theora/Vorbis files to the user.

Jo?o Eiras wrote:
>
> Then the browser does not support <video>. The spec mandates both
> <video> element support + ogg theora support. Else the implementation
> is incomplete. 

I'm afraid you have missed the news: the HTML working group balked, and
have removed all references to Theora from the draft (except as an
example alongside MPEG). Thus they have ensured that some <video>
implementations will not support Ogg Theora. That is why we need a query
interface: so that we can fall back to <applet> when the client only
supports proprietary codecs.

-- Tim Starling


From giecrilj at stegny.2a.pl  Tue Aug 12 08:24:02 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 12 Aug 2008 17:24:02 +0200
Subject: [whatwg] WebWorker questions
In-Reply-To: <48A178FD.9080706@arc.net.au>
References: <48A178FD.9080706@arc.net.au>
Message-ID: <D88BD34B868948DBA3ADE2DCD5D39806@POCZTOWIEC>

A very interesting post, too bad nobody from Google bothered to give an
exhaustive reply.  Just a couple of thoughts below.

I think the problem workers are trying to solve is quite practical.  It is
not about processing power (desktop applications rarely use threads for
that) and it is not about using all computing resources available.  Using
workers makes sense even if the browser is allowed to use only one CPU.  In
absence of an existing implementation, developers try to get a similar
functionality with setTimeout (requires stackless code) and hidden windows.
The current specification is an attempt to make it cleaner and more robust.

Problem statement: the browser does not respond when it runs script code; it
does not even update the content area so it is not possible to indicate
progress.  Some useful scripts can work for a long time, either because they
are waiting for data (directly or by periodically examining the document) or
they are computationally intensive (a much rarer phenomenon, but it still
can happen in interactive scientific publications, e.g. plotting a graph
with parameters that the user can adjust, or interactive fractals).  

Aside: Scientists do not call for threads in HTML because they are hardly
acquainted with HTML, even less with its bleeding edge.  However, things may
change when they see the tool is right there and easy to use.  Admittedly,
Java can be used for the purpose, but it has the didactical disadvantage
that Java is a compiled language and tweaking anything would require JDK.
Besides, Java applets do not run everywhere: they do not run in 64-bit
Firefox for Linux (unless they are very old).

The question about native threads in JavaScript would be much better asked
in a JavaScript forum.  Workers are an external mechanism provided by the
host, not by the interpreter.

If a Web browser, being a desktop application, uses all processing resources
from the operating system, either it is the operating system that is at
fault because it should not have allowed this or the application uses a
driver or a service in an unsupported way, which probably means the driver
or the service in question is to blame.  I do not think leaving one CPU free
would help much in this case because there is no guarantee the system
process would use it anyway (it could end up being used by something else).

Chris

 

  _____  

From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Shannon
Sent: Tuesday, August 12, 2008 1:50 PM
To: WHAT working group
Subject: [whatwg] WebWorker questions

 

A few questions and thoughts on the WebWorkers proposal:

Is it wise to give a web application more processing power than a single CPU
core (or HT thread) can provide? What stops a web page hogging ALL cores
(deliberately or not) and leaving no resources for the UI mouse or key
actions required to close the page? (This is not a contrived example, I have
seen both Internet Explorer on Win32 and Flash on Linux consume 100% CPU on
several occasions). I know it's a "vendor issue" but should the spec at
least recommend UAs leave the last CPU/core free for OS tasks?

Can anybody point me to an existing Javascript-based web service that needs
more client processing power than a single P4 core?

Shouldn't an application that requires so much grunt really be written in
Java or C as an applet, plug-in or standalone application? 

If an application did require that much computation isn't it also likely to
need a more efficient inter-"thread" messaging protocol than passing Unicode
strings through MessagePorts? At the very least wouldn't it usually require
the passing of binary data, complex objects or arrays between workers
without the additional overhead of a string encode/decode?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080812/49b10516/attachment.htm>

From giecrilj at stegny.2a.pl  Tue Aug 12 08:35:42 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 12 Aug 2008 17:35:42 +0200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <48A1A09B.6010408@wikimedia.org>
References: <489A63A5.3060603@wikimedia.org>	<11e306600808061959n6f817b09j8789ec68b47852a0@mail.gmail.com>	<489A9C04.9040006@wikimedia.org>	<BC7BA898-EB4C-4A74-BCE9-D03C0A6527E5@iki.fi>	<489AB360.6010408@wikimedia.org><489ABEEB.7080603@peda.net>	<489ADB2E.50405@wikimedia.org>	<47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>	<c2e346f90808120213w73051578h5d236d6ef241e8@mail.gmail.com>	<op.ufr02eizjz3wb9@mors><73B7F45828E341799080494FE9EFE2CA@POCZTOWIEC>
	<48A1A09B.6010408@wikimedia.org>
Message-ID: <E975579801274F79A214CCB34F0E8A96@POCZTOWIEC>

Falling back to another method of displaying media is possible without a
dedicated media API.  In this particular case, you can have a video element
with an ogg source and an object running Cortado to display it.  What other
purpose would such an API serve?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Tim Starling
Sent: Tuesday, August 12, 2008 4:39 PM
To: 'WHATWG List'
Subject: Re: [whatwg] Scripted querying of <video> capabilities

Kristof Zelechovski wrote:
> Why do we need an API to test UA media capabilities?  What purpose would
> such an API serve except for displaying the media to the user - a task
which
> can already be achieved without a dedicated API?
>   

It is useful for websites that wish to use a new or unpopular format
(such as Ogg Theora). If the client does not support the format in
question using <video>, it can fall back to another method.

I am employed to work on just such a website (Wikipedia). I maintain a
Java applet called Cortado that can be used to play Theora/Vorbis
videos, and I wrote an extension for MediaWiki called OggHandler which
uses JavaScript and an extensive series of client-side fallbacks
(including Cortado and <video>) to display Theora/Vorbis files to the user.





From dhtmlkitchen at gmail.com  Tue Aug 12 09:04:02 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 12 Aug 2008 09:04:02 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <ABA91900518A48339FC09E48F2CBF42A@POCZTOWIEC>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com>
	<c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com>
	<BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com>
	<c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com>
	<1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com>
	<c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>
	<F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC>
	<c9e12660808111337k3ad1e5vc6f14caf56e65ca7@mail.gmail.com>
	<ABA91900518A48339FC09E48F2CBF42A@POCZTOWIEC>
Message-ID: <c9e12660808120904t14ba54fbn7e1171cd559000bd@mail.gmail.com>

On Mon, Aug 11, 2008 at 2:53 PM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> I have considered inline response.  I have two options: do it by hand (I am
> rather busy) and do it for every reply (which makes business people angry).

The audience for this list is developers.

> I am sorry for the inconvenience it causes.

It adds more confusion to the misinformation and wrong arguments. It
makes communication more difficult and makes whatever you are trying
to argue seem harder to get the point of. It makes the discussion
harder to follow.

> The item method on a collection when the argument passed is a string that
> cannot be coerced to an integer is equivalent to namedItem.

MSDN is not a reference for web standards information. Thank you for
pointing that out.

> A form element
> does not have an intrinsic length property; it can be added as an embedded
> named control or by a script.  The elements collection has the intrinsic
> length property and it cannot be shadowed.

It would be more correct to say: elements.length is readonly.

> My source of information is MSDN, as you have correctly guessed.

I didn't actually guess.

> If you
> have contradictory information on legacy interfaces, please share it with
> us.  Note that there is no way we can say it is correct or not; it is an
> obsolete interface after all.

the 'elements' property of an HTMLFormElement is not obsolete[1]

An HTMLFormElement, is not an HTMLCollection. elements is an
HTMLCollection. The form has no item() no namedItem(). These are
operations that can be carried out on an HTMLCollection.


> However, if it is consistent and all major
> implementations support it, there is no reason to think it is false.
> The name 'ell' I used is a name of an embedded control in order to make it
> different.  I am not sure about undefined versus null; I rather use Visual
> Basic Scripting Edition and I get Nothing (not Empty) for a property an
> object does not have.  It may as well be undefined under JavaScript.

Undefined is the return value from [[Get]] when a property does not
exist. It seems reasonable to expect that [[Get]] on a Host object
would behave in the same way.

> Chris
> See also <http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx>.
>

That is useful, but should not be a reference as to how the item()
method works or should be expected to work. It is a proprietary
extension that Microsoft took. It isn't something that script authors
rely on because it's not cross browser.

Garrett

[1] DOM Level 2 HTML http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357


> -----Original Message-----
> From: Garrett Smith [mailto:dhtmlkitchen at gmail.com]
> Sent: Monday, August 11, 2008 10:37 PM
> To: Kristof Zelechovski
> Cc: WHATWG List; Maciej Stachowiak
> Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
>
> On 8/11/08, Kristof Zelechovski <giecrilj at stegny.2a.pl> wrote:
>
> Hi Chris,
>
> Thanks for taking the time to respond to some things I was writing
> about. I think these are important things that deserve attention, too.
>
> If it's not too much to ask, have you considered inline style response?
> http://en.wikipedia.org/wiki/Posting_style#Inline_replying
>
> I tried to restore posting order, but since you are using Outlook, it
> was not effectively possible.
>
>> Neither the expression 'form.elements.$name' nor its expanded form
>>  'form.elements["$name"]' is supposed to be defined even if $name is an
>>  identifier of an embedded control.  The correct way to address the
> control
>>  is 'form.elements("$name")',
>
> Can you cite a reference for this?
>
> AFAIK, this is an IE feature that was copied.
>
>> which is a shorthand notation for
>>  'form.elements.item("$name")'.
>
> No, that is wrong. Doubly wrong, I think. The item method retrieves a
> node by ordinal index (based on depth-first traversal).
>
>  now if you had wrote:-
>
> form.elements.namedItem("$name")
>
> That would at least be partially correct. If namedItem is what you
> meant, then please supply a reference to back up your claim. I do not
> think the claim:
>
> | The correct way to address the control is 'form.elements("$name")'
>
> is true and correct. I think it's an MSIE invention that other
> implementations copied.
>
>> These two should not be confused.
>>  Therefore, the bug in Opera is not about shadowing the length property
> but
>>  about defining the corresponding property at all (in particular,
>>  'form.elements.ell' should be null no matter what).
>
> Are you referring to the example I supplied?
>
>>  This could potentially be described in the EcmaScript bindings. But it
>>  would be a good idea to explore some edge cases. Particularly, if the
>>  case was the order of definition of properties: One such case would be
>>  an HTMLCollection with an element named "length". In that case, the
>>  readonly "length" property would have to be the actual length of the
>>  collection; the value should not be replaced with an element of that
>>  name/id.
>>
>>  <form><input name="length"></form>
>>
>>  document.forms[0].elements.length
>>
>>  Opera9: [object HTMLInputElement] <-- BUG
>>  FF3: 1
>>  Saf3: 1
>
> There was no element in my example with a id or name 'ell', so I would
> have to say that form.elements.ell would be undefined, not null.
>
> Where is this - ell - coming from?
>
>>  OTOH, the expression 'form.length' is a perfect equivalent for
>>  'form.elements("length")', provided a control with such a name is
> contained.
>
> form.elements has a readonly property named length.
>
> That property can't be changed (legally) just because a parse  event
> found an element named (or id'd) "length".
>
> The length property of a form - form.length - refers to:
>
>>  Have you reported this to Opera technical support?
>>  I can see no harm in principle in assigning a value to 'form.length'
> because
>>  length is not an intrinsic property the form object.
>>
>
> Chris, I have stated at least twice prior to this email that an
> HTMLCollection has a readonly length property.
>
> http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506
> | length of type unsigned long, readonly
> | This attribute specifies the length or size of the list.
>
> Garrett
>
>>
>>  Chris
>>
>
>
>


From dhtmlkitchen at gmail.com  Tue Aug 12 09:07:41 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 12 Aug 2008 09:07:41 -0700
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <E18A8D344E204814A0174222D6544FEA@POCZTOWIEC>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<20080806072713.GA26711@arc.mcc.id.au>
	<F30E6D37-6380-40BD-866D-51F04430B29B@apple.com>
	<c9e12660808061123j78593fe7va0087c45cb6525ad@mail.gmail.com>
	<E18A8D344E204814A0174222D6544FEA@POCZTOWIEC>
Message-ID: <c9e12660808120907l2c30eb55y27f4c9de29872cba@mail.gmail.com>

On Tue, Aug 12, 2008 at 4:06 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> The attribute FORM.length is not parseable: it cannot be defined in the HTML
> source and such definition should be ignored.  The intrinsic computed length
> attribute should take precedence over the imported control name which can be
> retrieved calling form.elements.item("length").

Please stop posting this type of code. This is nonstandard and will
only work in IE and browsers that strive to closely emulate IE
(Opera). Same goes for document.all or other things you'll see on the
MSDN site. MSDN is useful for other things, but it is not a standard
reference.

> Chris
>
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith
> Sent: Wednesday, August 06, 2008 8:24 PM
> To: Maciej Stachowiak
> Cc: Cameron McCormack; whatwg at whatwg.org
> Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
>
> Testcases to determine what implementations do and what are the worst
> problems to avoid would be the most useful at this point. For example,
> a HTMLFORMElement with the name "length", and attribute "length" on
> the form.
>
> <form length="10">
>  <input name="length">
> </form>
>
> Please do make up some test cases. You can post these to the list.
> Talk to Ian about where to upload them for reference.
>
>
>
>


From giecrilj at stegny.2a.pl  Tue Aug 12 09:43:05 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 12 Aug 2008 18:43:05 +0200
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808120904t14ba54fbn7e1171cd559000bd@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com><D415C0D2-D820-419F-97A8-DED8E6902FC8@apple.com><c9e12660808071351m68f9d4fepb5ba382999f75018@mail.gmail.com><BA24865A-74C4-4ADE-8F6F-A21F2EC1C2B1@apple.com><c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com><1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com><c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com><F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC><c9e12660808111337k3ad1e5vc6f14caf56e65ca7@mail.gmail.com><ABA91900518A48339FC09E48F2CBF42A@POCZTOWIEC>
	<c9e12660808120904t14ba54fbn7e1171cd559000bd@mail.gmail.com>
Message-ID: <AF6CDFDAD2EB4AB0AA6F56918176AD81@POCZTOWIEC>

While 'form.elements' is not obsolete, 'form.elements.something' (to mean
'form.elements.namedItem("something")') is.  Actually, it is some news to me
that such syntax is supported; I was only aware of the syntax
'form.something' (obsolete, but convenient) and
'form.elements("something")'.  That 'form.length' mirrors
'form.elements.length', while still supported, is just ridiculous; I missed
that as well.  Everything you say is true, except that the merrie olde
syntaxe is not that ambiguous as you present it.  Indeed, I cannot see any
ambiguity at all.
I am not using MSDN as the source of information what the Web should look
like; I am using it to understand existing code that the standard does not
cover, e.g. 'form.control' or 'new Image()' (incidentally, this is
'Image.Create()' in Visual Basic Scripting Edition).
Thanks for pointing that out.
Chris





From dhtmlkitchen at gmail.com  Tue Aug 12 10:02:55 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 12 Aug 2008 10:02:55 -0700
Subject: [whatwg] Fwd:  HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808121002l794be48ejc0de73023e31694b@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<c9e12660808071544m7c551b3asc6cfa01ac7019cdf@mail.gmail.com>
	<1B6BA93F-98CC-4245-A4B3-DEF9B4720886@apple.com>
	<c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>
	<F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC>
	<c9e12660808111337k3ad1e5vc6f14caf56e65ca7@mail.gmail.com>
	<ABA91900518A48339FC09E48F2CBF42A@POCZTOWIEC>
	<c9e12660808120904t14ba54fbn7e1171cd559000bd@mail.gmail.com>
	<AF6CDFDAD2EB4AB0AA6F56918176AD81@POCZTOWIEC>
	<c9e12660808121002l794be48ejc0de73023e31694b@mail.gmail.com>
Message-ID: <c9e12660808121002p335f10b0i4643828f9198aaaf@mail.gmail.com>

---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen at gmail.com>
Date: Tue, Aug 12, 2008 at 10:02 AM
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
To: Kristof Zelechovski <giecrilj at stegny.2a.pl>


On Tue, Aug 12, 2008 at 9:43 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> While 'form.elements' is not obsolete, 'form.elements.something' (to mean
> 'form.elements.namedItem("something")') is.  Actually, it is some news to me
> that such syntax is supported; I was only aware of the syntax
> 'form.something' (obsolete, but convenient) and
> 'form.elements("something")'.

You really ought to read the specs; I've posted numerous links in this thread..

> That 'form.length' mirrors
> 'form.elements.length', while still supported, is just ridiculous; I missed

Read the HTML DOM 1 and 2 specs.

> that as well.  Everything you say is true, except that the merrie olde
> syntaxe is not that ambiguous as you present it.  Indeed, I cannot see any
> ambiguity at all.

What ambiguity?

> I am not using MSDN as the source of information what the Web should look
> like; I am using it to understand existing code that the standard does not
> cover, e.g. 'form.control' or 'new Image()' (incidentally, this is
> 'Image.Create()' in Visual Basic Scripting Edition).
> Thanks for pointing that out.
> Chris
>
>
>
>


From aa at google.com  Tue Aug 12 10:34:59 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 12 Aug 2008 10:34:59 -0700
Subject: [whatwg] WebWorkers vs. Threads
In-Reply-To: <48A15D3B.4090401@arc.net.au>
References: <489E7FD2.10202@arc.net.au> <489F2742.2010205@sicking.cc>
	<489F8DBA.8000706@arc.net.au>
	<278fd46c0808111043k282418c5qb7a22c0773e6a99d@mail.gmail.com>
	<AC6911EA-CC0F-4874-8160-DF8229621281@ravenbrook.com>
	<48A15D3B.4090401@arc.net.au>
Message-ID: <278fd46c0808121034y39412ef1keec6199b6ef6afad@mail.gmail.com>

On Tue, Aug 12, 2008 at 2:51 AM, Shannon <shannon at arc.net.au> wrote:
> I thought Lua had an implementation of automated locking to use as a
> reference but since it doesn't I have nothing more to offer on the subject.
> Without knowing the internals of existing JS implementations I have no idea
> what would be involved to provide automated locking and whether it is
> impossible or just difficult.

It seems like the best you could do is use a system-wide lock. Python
does this I believe (http://docs.python.org/api/threads.html). It
helps for IO (the lock can be released during synchronous IO), but it
doesn't allow you to make use of multicore CPUs.

- a


From dhtmlkitchen at gmail.com  Tue Aug 12 11:02:29 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 12 Aug 2008 11:02:29 -0700
Subject: [whatwg] Fwd:  HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808121100h3b40d129kc6df56686368824e@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<3B0990F66B884008A2EE6AB89CB9AE83@POCZTOWIEC>
	<c9e12660808121100h3b40d129kc6df56686368824e@mail.gmail.com>
Message-ID: <c9e12660808121102j36d656fcpa19e3eea187ab3cc@mail.gmail.com>

(to list)


---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen at gmail.com>
Date: Tue, Aug 12, 2008 at 11:00 AM
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
To: Kristof Zelechovski <giecrilj at stegny.2a.pl>


On Tue, Aug 12, 2008 at 4:53 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> It is probably too late for that but I like the concept of a default
> property much better than metaattributes like IndexGetter.

Browsers implement items as properties. It is safe for them to do so,
because elements shouldn't have numeric names like - 0 -.

IndexGetter, is as Maciej put it, "spec fiction".

> For example, document.forms(0) means "call forms on document with argument
> 0".  That is impossible because forms is not a function so we look into

No, that is not correct. document.forms is a collection. Some browsers
allow HTMLCollection to implement [[Call]]. Some browsers may even
allow the form element to be callable as in - document.forms(0)(0) -.
It's not relevant or useful. Just a browser oddity.

> forms collection and we see that it has the default method named item.  So

Whether 'item' is a method or not cannot be determined. Whether a form
has an item property can be determined. A somewhat tangential but
interesting bug: MSIE 6-8, getting the - item - property returns a
string value.

javascript:alert(document.childNodes.item === "[object]");

This is a bug, but regardless, the item property itself has no
properties, so cannot be further inspected beyond using typeof
operator.

javascript:alert(typeof document.childNodes.item);

"string" in IE.

> we proceed by expanding it to document.forms.item(0) and we see it works.

That would return the 0th form in the document, not any element in the form.

> I like it because it is simple, elegant and generic, whereas IndexGetter and
> what you have looks ad-hoc.
> I have never seen document.forms.main used to get at the form named "main"
> but probably I have not seen that much.
> I wonder how common it is.

It is fairly common.

> Of course, I agree that it is best to be explicit and not to rely on such
> tricks at all.  The downside is that, for example, while
> a.getAttributeNode("href").value = url is technically superior to a.href =
> url, it is much harder to read so care must be taken not to overshoot.

Swiching gears to attributes, the attributes-as-properties is
deprecated[2]* but still heavily used because it is easier to use.

> But
> form.elements.item("main") is just fine.

It is not fine. It is non-standard and won't work across many
implementations. There is no reason to use this.


> Regarding how the named elements get to be true properties, the shadowing
> behavior can be specified without recurring to getters.  It is sufficient to
> say that an intrinsic property is never replaced by a constructed shortcut
> property and we get the same result.

The term "intrinsic property" is made up.

The reason length can't be replaced is because it's readOnly. The same
should probably hold true for the "namedItem" property, though that
property is not specified to be readonly. That should change. The
namedItem property should not be read/write. I can't see any harm in
adding the readonly restriction. Code that depends on replacing the
namedItem value with something else would be unreliable in today's
browsers (and would be of questionably poor design).

Other properties like "toString" aren't standardized. In some cases,
the implementation will add proprietary properties e.g. "constructor".
In some implementations, there may be a prototype chain with other
properties that could be shadowed.

It is unlikely that a form element would have the name or id
"namedItem" but it is conceivably possible.

For example:

<!DOCTYPE HTML>
<html lang="en">
<head>
 <title>namedGetter</title>
 <style type="text/css">
 .pass { background: #0f0; }
 .fail { background: #f43; }
 .warn { background: #FC5; }
 </style>
</head>
<body>
<form>
<input name="namedItem" />
<input name="length"/>
<input name="toString"/>
<input name="constructor"/>
</form>

<div id="result"><li>no result</li></div>

<script type='text/javascript'>
var r = document.getElementById('result'), failed;

var f = document.forms[0];
var namedItem = f.elements.namedItem,
   length = f.elements.length,
   toString = f.elements.toString,
   constructor = f.elements.constructor;

r.innerHTML = '';
if(namedItem.getAttribute)
 warn('elements.namedItem was replaced by an element. Found: ' +
namedItem.name);
if(typeof length != "number")
 fail("elements.length was not a number. Found: " + length);

if(toString.name != "toString")
 fail("elements.toString was not an element. Found: " + toString);
if(constructor.name != "constructor")
 fail("elements.constructor was not an element. Found: " + constructor);

if(!failed)
 r.innerHTML += "<li class='pass'>PASS<\/li>";


function fail(s) {
 s = "<li class='fail'>"+s+"<\/li>";
 if(!failed)
    failed = s;
 r.innerHTML += s;
}

function warn(s) {
  r.innerHTML += "<li class='warn'>"+s+"<\/li>";
}
</script>
</body>
</html>


Opera 9, IE8:
1 warning:
* elements.namedItem was replaced by an element. Found: namedItem
1 failure:
* elements.length was not a number. Found: [object HTMLInputElement]

1 failure:
Firefox 3, Webkit nightly (525)
* elements.constructor was not an element. Found: function Object() {
[native code] }

The warning "elements.namedItem was replaced by an element." is not a
spec violation; it is perfectly standards compliant. I don't see harm
in changing the spec to make namedItem readonly.

An implementation optionally could provide, for HTMLCollection (or
whatever the new interface is called in HTML5), a specialized
algorithm for "[[Get]]" that delegates to namedItem. This wouldn't
matter either way. Fx does provide a special get that delegates to
namedItem, and does not add named properties to the form. I don't see
any problem with this.

As for property access delegating to item, the properties should
probably exist on the object. That is what implementations today do.
Defining a new behavior for typechecking on property access operator [
] would be complicated and confusing. Such change might introduce bugs
in implementations. and would create bugs in webapps that attempt to
use node.childNodes['0']. The other way to implement [indexGetter]
would be to Have HTMLCollection's special [[Get]] try to parse the
string value. This would introduce awkward complications and require
too many implementation details to be specified in web-idl.

Not everything needs to be or should be standardized.

Garrett

[2] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-1958798402

* Top posts are destroying the thread flow. I included linked
reference(s) incremented from the last number.

> Chris
>
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith
> Sent: Wednesday, August 06, 2008 8:49 AM
> To: Thomas Broyer
> Cc: whatwg at whatwg.org
> Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
>
> On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer <t.broyer at gmail.com> wrote:
>> On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
>>> On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
>>>>
>>> First off, the IndexGetter behavior on the HTMLCollection[1] is the
>>> authors imagination.
>>
>> Aren't "document.forms[0]" and "document.forms.myform" working?
>>
>
> Can you be more specific and direct in your reply? It isn't clear what
> your point is.
>
>>> The following example shows that indexed Properties exist on
>>> NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
>>> There is no [[ IndexGetter ]] as Cameron likes to make pretend.
>>
>> This is an "implementation detail" of the ECMAScript binding.
>>
>
> In EcmaScript, the property access operators seem to look like a
> "getter" to Cameron. What they really do is provide access to
> properties added to the collection, or, in one case (on one
> implementation), this seems implemented as a "getter". A "getter" is a
> method that gets the value of a property of that name.
>
>
>
>


From aa at google.com  Tue Aug 12 11:26:07 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 12 Aug 2008 11:26:07 -0700
Subject: [whatwg] WebWorker questions
In-Reply-To: <48A178FD.9080706@arc.net.au>
References: <48A178FD.9080706@arc.net.au>
Message-ID: <278fd46c0808121126x4e80c9b3x76eb24e5869f121e@mail.gmail.com>

On Tue, Aug 12, 2008 at 4:50 AM, Shannon <shannon at arc.net.au> wrote:
> If a WebWorker object is assigned to local variable inside a  complex script
> then it cannot be seen or stopped by the calling page. Should the
> specification offer document.workers or getAllWorkers() as a means to
> iterate over all workers regardless of where they were created?

I don't follow the first phrase here, but I can still answer the
overall quetsion...

There is currently no API to stop a worker from the outside, only from
the inside. Providing an API to kill a worker from the outside is a
little weird because we also want to be able to share workers between
multiple pages. If we did both of these things then one page could
kill a worker that other pages are relying on. Not saying this is
unreasonable, just something to think about.

As for getAllWorkers(), yes, I think this would be cool (perhaps for a
future version of the API). If for no other reason than that there are
interesting applications for diagnostics and introspection.

> Is it wise to give a web application more processing power than a single CPU
> core (or HT thread) can provide? What stops a web page hogging ALL cores
> (deliberately or not) and leaving no resources for the UI mouse or key
> actions required to close the page? (This is not a contrived example, I have
> seen both Internet Explorer on Win32 and Flash on Linux consume 100% CPU on
> several occasions). I know it's a "vendor issue" but should the spec at
> least recommend UAs leave the last CPU/core free for OS tasks?

You are right that workers and other things that are controllable by
authors but use threads should be pooled and limited. It shouldn't be
possible to DOS a browser using workers. Currently, Gears doesn't do
this, but we definitely should. I agree the spec should have a warning
to this effect.

> Can anybody point me to an existing Javascript-based web service that needs
> more client processing power than a single P4 core?

It's easy to imagine examples, but of course none exist today since
this capability doesn't exist in browsers.

100ms is generally considered to be absolute maximum amount of time a
UI can take to update after direct interaction. After that, users
think it is hung. It's not that hard to imagine applications for JS
computation which surpass this amount of time, particularly when you
consider that the cpu(s) might be busy doing something else!

But I think that computation is the least interesting of the benefits
that workers provide. The others ones are:

a) Workers allow applications to perform blocking IO. Currently this
isn't possible because it would block the UI too. In the current
database proposal, every single SQL statement is asynchronous.

b) Workers allow you to share parts of your application between
windows. So for example, if you open Google Docs in two windows, they
can't share any code today. Google docs is a pretty significant JS
app, so this is already crazy inefficient. But if the user has Google
Docs Offline enabled, then both copies of the app are also both trying
to synchronize to the same local database. The only way to get around
this is to implement a watchdog system where each window tries to
detect each other through updates to the shared database. Shared
workers allow you to solve this in a more natural way. Just put the
synchronization code in a shared worker. All the instances of the app
can access it.

> Shouldn't an application that requires so much grunt really be written in
> Java or C as an applet, plug-in or standalone application?

No. Web applications have many benefits over native apps. We should
try to increase the number of apps that can be written on the web.

> If an application did require that much computation isn't it also likely to
> need a more efficient inter-"thread" messaging protocol than passing Unicode
> strings through MessagePorts? At the very least wouldn't it usually require
> the passing of binary data, complex objects or arrays between workers
> without the additional overhead of a string encode/decode?

We (Google) have proposed the addition of being able to pass complex
JS objects without manually encoding/decoding, and I think that this
will be added eventually.

But even with just strings passing, it is easy to imagine applications
where there is a large amount of background work that needs to be done
given a small amount of input. For example, "download all the
documents for user X and store them in the database".

> Is the resistance to adding threads to Javascript an issue with the language
> itself, or a matter of current interpreters being non-threadsafe?

Threads as they exist in java and c are widely understood to be difficult:

http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/2006/05/r5toc.xml&DOI=10.1109/MC.2006.180

I don't have a problem with coroutines personally, but I think that
there is still a place for full processes in any programming
environment. Sometimes it's just natural to break up an application
into UI and background processes. Unix applications have traditionally
been built with this model, and modern windows applications also use
it.

> The draft spec says "protected" workers are allowed to live for a
> "user-agent-defined amount of time" after a page or browser is closed. I'm
> not really sure what possible value this could have since as an author we
> won't know whether the UA allows _any_ time and if so whether that time will
> be enough to complete our cleanup (given a vast discrepancy in
> operations-per-second across UAs and client PCs). If our cleanup can be
> arbitrarily cancelled then isn't it likely that we might actually leave the
> client or server in a worse state than if we hadn't tried at all? Won't this
> cause difficult-to-trace sporadic bugs caused by browser differences in what
> could be a rare event (a close during operation Y instead of during X)?

I agree that workers should be immediately killed on page unload, just
like XHRs are.

> I just don't see any common cases where you'd _need_ multiple OS threads but
> still be willing to accept Javascripts' poor performance, Webworkers limited
> API, and MessagePorts' limited IO. The only things I can think of are new
> user annoyances (like delaying browser shutdown and hogging the CPU). Sure
> UA's might let us disable these things but then some pages won't work. The
> Working Draft lists a few examples, most of which appear to use non-blocking
> network IO and callbacks anyway. Other examples rely on the ability for
> workers to outlive the lifetime of the calling page (which is pretty
> contentious). The one remaining example is a contrived mathematical
> exercise. Is the scientific world really crying out for complex theorems to
> be solved in web browsers? What real-world use cases is WebWorkers supposed
> to solve?

I hope I've addressed some of these questions above. I'm sure you'll
let me know if you're still unconvinced.

- a


From aa at google.com  Tue Aug 12 11:28:03 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 12 Aug 2008 11:28:03 -0700
Subject: [whatwg] WebWorker questions
In-Reply-To: <D88BD34B868948DBA3ADE2DCD5D39806@POCZTOWIEC>
References: <48A178FD.9080706@arc.net.au>
	<D88BD34B868948DBA3ADE2DCD5D39806@POCZTOWIEC>
Message-ID: <278fd46c0808121128q25e0b03eocc7c183c7cf2880a@mail.gmail.com>

On Tue, Aug 12, 2008 at 8:24 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> A very interesting post, too bad nobody from Google bothered to give an
> exhaustive reply.  Just a couple of thoughts below.

Just as an FYI, most of the Gears team is located in Mountain View
which is PST. This message was sent at 4:50 AM for us, and as we are
programmers, the first of us saw it approx 5 hours later :).

- a


From cprince at google.com  Tue Aug 12 11:44:33 2008
From: cprince at google.com (Chris Prince)
Date: Tue, 12 Aug 2008 11:44:33 -0700
Subject: [whatwg] WebWorker questions
In-Reply-To: <48A178FD.9080706@arc.net.au>
References: <48A178FD.9080706@arc.net.au>
Message-ID: <cd580da00808121144l301aa94l4ae52e72abc551ad@mail.gmail.com>

> What stops a web page hogging ALL cores (deliberately or not)
> and leaving no resources for the UI mouse or key actions required
> to close the page?

Any modern operating system enforces this, using standard thread /
process task scheduling.

> I know it's a "vendor issue" but should the spec at least recommend
> UAs leave the last CPU/core free for OS tasks?

That doesn't make much sense.  For one, it would forbid parallel
execution on single-core machines.  Also, it's not necessary, due to
OS task scheduling as described above.

Throttling other ways (e.g. "90% of system capacity") doesn't make
much sense either.  If this is the only task running on my machine, I
really do want it to execute at full speed.  Again, the OS task
scheduler was designed to handle exactly this case.


From dhtmlkitchen at gmail.com  Tue Aug 12 13:22:35 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 12 Aug 2008 13:22:35 -0700
Subject: [whatwg] Fwd:  HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808121255j2167b2d6x3e2e970aabb49668@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<c9e12660808081705h691a74apaa49ef0a5d2631ce@mail.gmail.com>
	<F5C7AD4BE43D43C8961699FC24350F8B@POCZTOWIEC>
	<c9e12660808111337k3ad1e5vc6f14caf56e65ca7@mail.gmail.com>
	<ABA91900518A48339FC09E48F2CBF42A@POCZTOWIEC>
	<c9e12660808120904t14ba54fbn7e1171cd559000bd@mail.gmail.com>
	<AF6CDFDAD2EB4AB0AA6F56918176AD81@POCZTOWIEC>
	<c9e12660808121002l794be48ejc0de73023e31694b@mail.gmail.com>
	<D4A147BFE9E14011828D69F088A977C7@POCZTOWIEC>
	<c9e12660808121255j2167b2d6x3e2e970aabb49668@mail.gmail.com>
Message-ID: <c9e12660808121322h47743cebr72d301757b01ed89@mail.gmail.com>

[back to whatwg list.]


---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen at gmail.com>
Date: 2008/8/12
Subject: Fwd: [whatwg] HTML 5 : Misconceptions Documented
To: CSS 3 W3C Group <www-style at w3.org>


2008/8/12 K?i?tof ?elechovski <giecrilj at stegny.2a.pl>:

Another top post.

> Reading the specification does not help; the trick is described in a note in
> appendix D

of what?

> which I have not read because it is hardly necessary (otherwise
> it would not have been a note in an appendix).  It mentions 'coll["$name"]'
> but not 'coll.$name'.  I understand the notations are equivalent under
> JavaScript; however, 'coll["$name"]' makes no sense in Visual Basic but
> 'coll.$name' is still supported (surprise!).  The construct 'coll("$name")'
> must be necessarily equivalent to 'coll.item("$name")' because only one
> property can be the default; that is why overloading collection.item is
> necessary.

An HTMLCollection is not standardized to be a callable object, e.g. so
coll('$name') can't be expected to work and will not work in a few
compliant implementations. Firefox, for one, doesn't make a collection
callable.

OTOH, if a collection is callable, it means that it should probably
return "function" for typeof. EcmaScript typeof operator should result
in "function" when used with a native callable object. An
HTMLCollection is a "Host" object. When used with a Host object typeof
may legally return anything. Although IE's implementation might seem
against the intent of the spec by returning "object" for callable host
objects, it is a legal behavior.

> Neither specification contains an argument that it is not ridiculous to have
> form.length mirror form.elements.length.  The need for form.length dates
> back to Netscape DOM because the collection form.elements was not there, I
> guess.  You are just wasting my time.

I don't think there's any disagreement that form.length is redundant.
But like it or not, form.length is part of that DOM 1 spec I linked
to. If it were to be removed from the spec, it might break sites. It
could potentially be deprecated in HTML5 and removed in a future
version of HTML.

> Your original post criticized the code sample provided because the
> constructs used there were ambiguous.

The original post pointed out three problems:
 1) Treating a form element as an HTMLCollection.
 2) The use of - with - to augment the scope chain is not necessary.
 3) Calling the "elements" HTMLCollection an "array

#1 has been discussed a lot. There is evidence that treating a form
element as an HTMLCollection is non-standard, but not yet a strong
consensus that this practice is bad and should be discouraged. I think
more solid examples and reasoning is needed on why it is bad.

#2 got some agreement

#3 did not get debated at all. Clearly, HTMLCollection is not an
array. This is a pretty serious mistake. It is the misconception that
I first had in mind. This should have been changed two weeks ago, soon
after it was pointed out to Ian. HTML 5 should not propagate
misinformation.

[regarding form.lenth vs form.elements.length: ]
> They may be ambiguous to a casual
> reader but the host can, in theory, interpret them unambiguously and
> consistently.  I admit Internet Explorer does it all wrong though.  I am
> disappointed.

IE and Opera seem to replace the HTMLCollection's length property's
value. It is also possible that they have another unobservable
internal mechanism that makes this appear so. Either way, the result
is a bug when elements.length or form.length results in an object (a
collection of form controls). In IE and Opera, the length property can
return an object. This is a non-standard spec violation.

Replacing the 'namedItem' property is perfectly standards compliant.
The standard should probably change to make the 'namedItem' property
readonly.

Having these extra properties also exist on an HTMLFormElement is
unnecessary. It complicates matters because a form element has other
DOM properties, such those from Node, et c. It would create the
problem of trying to refer to an element:-

/** Error prone */
getAnElement(form, controlName) {
 return form[controlName];
}

getAnElement(document.forms[0], "parentNode");
getAnElement(document.forms[0], "addEventListener");

Look at the Node interface, Element interface, EventTarget interface,
and any other interface that the HTMLFormElement might likely
implement and see that there are many properties that could
potentially create conflict. It is not only redundant, but it is error
prone to have such properties on the form element. Form control names
as form object properties creates pollution and makes resolving
properties more difficult.

It is error prone:
 * For implementations, because it requires a more complicated algorithm.
 * For page authors, who cannot expect form controls to become DOM
properties of the form object (because it is possible that a property
of the form already exists).

It is not reasonable to expect that implementations will support
special getters because only one implementation has been observed to
exhibit that type of behavior (Firefox). Such a getter would be
subject to the same sort of conflict resolution.

Garrett

> Yours sincerely
> Chris
>
> -----Original Message-----
> From: Garrett Smith [mailto:dhtmlkitchen at gmail.com]
> Sent: Tuesday, August 12, 2008 7:03 PM
> To: Kristof Zelechovski
> Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
>
> On Tue, Aug 12, 2008 at 9:43 AM, Kristof Zelechovski
> <giecrilj at stegny.2a.pl> wrote:
>> While 'form.elements' is not obsolete, 'form.elements.something' (to mean
>> 'form.elements.namedItem("something")') is.  Actually, it is some news to
> me
>> that such syntax is supported; I was only aware of the syntax
>> 'form.something' (obsolete, but convenient) and
>> 'form.elements("something")'.
>
> You really ought to read the specs; I've posted numerous links in this
> thread..
>
>> That 'form.length' mirrors
>> 'form.elements.length', while still supported, is just ridiculous; I
> missed
>
> Read the HTML DOM 1 and 2 specs.
>
>> that as well.  Everything you say is true, except that the merrie olde
>> syntaxe is not that ambiguous as you present it.  Indeed, I cannot see any
>> ambiguity at all.
>
> What ambiguity?
>
>> I am not using MSDN as the source of information what the Web should look
>> like; I am using it to understand existing code that the standard does not
>> cover, e.g. 'form.control' or 'new Image()' (incidentally, this is
>> 'Image.Create()' in Visual Basic Scripting Edition).
>> Thanks for pointing that out.
>> Chris
>>
>>
>>
>>
>
>

From chris.double at double.co.nz  Tue Aug 12 15:46:10 2008
From: chris.double at double.co.nz (Chris Double)
Date: Wed, 13 Aug 2008 10:46:10 +1200
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <E975579801274F79A214CCB34F0E8A96@POCZTOWIEC>
References: <489A63A5.3060603@wikimedia.org> <489AB360.6010408@wikimedia.org>
	<489ABEEB.7080603@peda.net> <489ADB2E.50405@wikimedia.org>
	<47189E6C17FE412494F56EF7A38E903E@POCZTOWIEC>
	<c2e346f90808120213w73051578h5d236d6ef241e8@mail.gmail.com>
	<op.ufr02eizjz3wb9@mors> <73B7F45828E341799080494FE9EFE2CA@POCZTOWIEC>
	<48A1A09B.6010408@wikimedia.org>
	<E975579801274F79A214CCB34F0E8A96@POCZTOWIEC>
Message-ID: <c2e346f90808121546x3e1bf05t9b02cc050ce0d7b6@mail.gmail.com>

On Wed, Aug 13, 2008 at 3:35 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> Falling back to another method of displaying media is possible without a
> dedicated media API.  In this particular case, you can have a video element
> with an ogg source and an object running Cortado to display it.

I don't believe this to be the case. See my previous message about
this. There's one specific instance of it not working as far as I
know:

<video src="foo.ogg">
 <object>....fallback for Ogg playback using plugin</object>
</video>

A browser that supports <video> but not Ogg will not use the fallback
<object>. Instead it will just give an error when loading the foo.ogg
file. If some way of having this case work is supplied then a media
sniffing API is possibly not needed. Tim, can you confirm that?

Chris.
-- 
http://www.bluishcoder.co.nz


From ian at hixie.ch  Tue Aug 12 16:11:56 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Aug 2008 23:11:56 +0000 (UTC)
Subject: [whatwg] .localName shouldn't change case
In-Reply-To: <A60AE9ED-CDB8-471F-8AEE-D0BF9780AF7F@apple.com>
References: <op.tuox3wle7a8kvn@hp-a0a83fcd39d2>
	<a9699fd20706291022r559840e0x3cacfb00000ab571@mail.gmail.com>
	<A60AE9ED-CDB8-471F-8AEE-D0BF9780AF7F@apple.com>
Message-ID: <Pine.LNX.4.62.0808122307320.5140@hixie.dreamhostps.com>

On Fri, 29 Jun 2007, Darin Adler wrote:
> On Jun 29, 2007, at 9:15 AM, Simon Pieters wrote:
> 
> > For HTML elements in HTML documents, why is Element.localName 
> > uppercased for tag names and lowercased for attribute names? I 
> > wouldn't expect it to, and it makes it harder to write scripts that 
> > work for both HTML and XHTML. For example, if you want a script to 
> > work in both legacy HTML UAs and HTML5 UAs as well as in XHTML, you 
> > may want to do something like if ((elm.tagName == "A" && 
> > !elm.namespaceURI) || (elm.localName == "a" && elm.namespaceURI == 
> > "http://www.w3.org/1999/xhtml")) to check that a given element is an 
> > HTML "a" element.
> 
> Good timing, mentioning this.
> 
> WebKit uses lowercase for localName for HTML elements in HTML documents 
> for the reasons you mention.
> 
> We received a bug report about a library, "Jira", that doesn't work with 
> Safari 3 because of this <http://bugs.webkit.org/show_bug.cgi?id=14114>. 
> We were surprised to learn that Mozilla uses uppercase.

On Fri, 29 Jun 2007, Maciej Stachowiak wrote:
> On Jun 29, 2007, at 10:22 AM, Thomas Broyer wrote:
> > 
> > Because of this:
> > http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-5353782642
> > and this:
> > http://www.w3.org/2000/11/DOM-Level-2-errata#html-2
> 
> If you look at the part of the spec that is actually normative for HTML, 
> it only requires this behavior for tagName and nodeName. There is no 
> such requirement for localName.
> 
> "1.6.3. Exposing Element Type Names (tagName, (nodeName))
> 
> If the document is an HTML 4.01 document the element type names exposed 
> through a property are in uppercase. For example, the body element type 
> name is exposed through the tagName property as BODY. If the document is 
> an XHTML 1.0 document the element name is exposed as it is written in 
> the XHTML file. This means that the element type names are exposed in 
> lowercase for XHTML documents since the XHTML 1.0 DTDs defines element 
> type names as lowercase, and XHTML, being derived from XML, is case 
> sensitive."
> 
> DOM Level 2 Core does not call for any special case behavior for 
> localName either. Although it says that localName should be null for 
> HTML elements created with createElement, which seems wrong: "For nodes 
> of any type other than ELEMENT_NODE and ATTRIBUTE_NODE and nodes created 
> with a DOM Level 1 method, such as createElement from the Document 
> interface, this is always null.". It would be silly to have a null 
> localName for dynamically created HTML elements only, and even more 
> silly to do so for all HTML elements.
> 
> We originally made tagName/nodeName uppercase but localName lowercase in 
> WebKit so that you'd get the required HTML behavior for the first two, 
> but localName would show through to a more XML-like view, so it could be 
> used together with namespaceURI and you wouldn't have to care whether 
> the document was XML or not.
> 
> I still t