Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:

> At the upcoming TPAC, there is an opportunity for F2F coordination  
> between these two groups, and the time slot between 10 O'Clock and  
> Noon on Friday has been suggested for this.
>
> To help prime the pump, here are four topics suggested by ECMA TC39  
> for discussion.  On these and other topics, there is no need to wait  
> for the TPAC, discussion can begin now on the es-discuss mailing list.
>
> - - -
>
> The current WebIDL binding to ECMAScript is based on ES3... this  
> needs to more closely track to the evolution of ES, in particular it  
> needs to be updated to ES5 w.r.t the Meta Object Protocol.  In the  
> process, we should discuss whether this work continues in the W3C,  
> is done as a joint effort with ECMA, or moves to ECMA entirely.

It seems like this is a Web IDL issue. I don't see any reason for Web  
IDL to move to ECMA. It is a nominally language-independent formalism  
that's being picked up by many W3C specs, and which happens to have  
ECMAScript as one of the target languages. Much of it is defined by  
Web compatibility constraints which would be outside the core  
expertise of TC39. Probably the best thing to do is to provide  
detailed technical review of Web IDL via the W3C process.

>
> - - -
>
> A concern specific to HTML5 uses WebIDL in a way that precludes  
> implementation of these objects in ECMAScript (i.e., they can only  
> be implemented as host objects), and an explicit goal of ECMA TC39  
> has been to reduce such.  Ideally ECMA TC39 and the W3C HTML WG  
> would jointly develop guidance on developing web APIs, and the W3C  
> HTML WG would apply that guidance in HTML5.
>
> Meanwhile, I would encourage members of ECMA TC 39 who are aware of  
> specific issues to open bug reports:
>
>  http://www.w3.org/Bugs/Public/
>
> And I would encourage members of the HTML WG who are interested in  
> this topic to read up on the following emails (suggested by Brendan  
> Eich):
>
> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
>  and the rest of that thread
>
> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
>  (not the transactional behavior, which is out -- just the
>  interaction with Array's custom [[Put]]).
>
> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
>   on an "ArrayLike interface" with references to DOM docs at the  
> bottom
>
> https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
>   about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can  
identify issues in the threads at all).

>
> - - -
>
> There are larger (and less precise concerns at this time) about  
> execution scope (e.g., presumptions of locking behavior,  
> particularly by HTML5 features such as local storage).  The two  
> groups need to work together to convert these concerns into  
> actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking  
on the <whatwg@whatwg.org> mailing list. We could continue here if it  
would be helpful. I'm not sure it's useful to discuss in person  
without being up to speed on the email discussion. Here are some  
relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html 
 > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html 
 > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html 
 > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html 
 >.

I'm not sure what the other concerns about "execution scope" are -  
seems hard to discuss fruitfully without more detail.

> - - -
>
> We should take steps to address the following "willful violation":
>
>  If the script's global object is a Window object, then in JavaScript,
>  the this keyword in the global scope must return the Window object's
>  WindowProxy object.
>
>  This is a willful violation of the JavaScript specification current  
> at
>  the time of writing (ECMAScript edition 3). The JavaScript
>  specification requires that the this keyword in the global scope
>  return the global object, but this is not compatible with the  
> security
>  design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this? I know the feedback was passed along.

Regards,
Maciej

Received on Thursday, 24 September 2009 14:56:26 UTC