ECMA TC 39 / W3C HTML and WebApps WG coordination

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.

  - - -

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.

  - - -

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.

  - - -

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]

- Sam Ruby

Received on Thursday, 24 September 2009 12:37:38 UTC