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

On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

> Maybe this would be a good opportunity to revisit the utility of  
> WebIDL in specifications (as formal specifications were re-examined  
> for ES-Harmony). The WebIDL spec is pretty large, and I personally  
> have found its use a confounding factor in understanding other specs  
> (like HTML5).

Its utility is in providing a way to specify API behavior in a way  
that is consistent between specifications, language-independent, and  
reasonably concise. It's true that it adds an additional thing you  
have to learn. That's regrettable, but there are a lot of details that  
need to be specified to get interoperability. Pre-WebIDL specs such as  
DOM Level 2[1] left many details undefined, leading to problematic  
behavior differences among browsers and a need for mutual reverse- 
engineering.

Regards,
Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/


>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@mozilla.com>  
> wrote:
> On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:
>
> 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.
>
> Some of us on TC39 have lots of Web compatibility experience :-P.
>
>
>
> Probably the best thing to do is to provide detailed technical  
> review of Web IDL via the W3C process.
>
> Expertise on both sides of the artificial standards body divide may  
> very well be needed. The rest of this message convinces me it is  
> needed.
>
> One problem with inviting review via the W3C process is getting  
> attention and following too many firehose-like mailing lists. es-discuss@mozilla.org 
>  is at most a garden hose, which is an advantage.
>
> Another problem is that not all Ecma TC39 members are W3C members  
> (their employers are not members, that is).
>
> There are transparency problems on both sides, IMHO. People in dark- 
> glass houses...
>
>
>
> 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).
>
> TC39 members, Mark Miller articulated this yesterday, hope to  
> restrict host objects in future versions of the JavaScript standard  
> from doing any nutty thing they like, possibly by collaborating with  
> WebIDL standardizers so that instead of "anything goes" for host  
> objects, we have "only what WebIDL can express".
>
> Catch-all magic where host object interfaces handle arbitrary  
> property gets and puts are currently not implementable in ES -- this  
> may be possible in a future edition, but even then it will carry  
> performance penalties and introduce analysis hazards. We hope to  
> steer ES bindings for WebIDL-expressed interfaces away from catch- 
> all patterns.
>
> Beyond this tarpit, we're interested in the best way to linearize  
> multiply-inherited WebIDL interfaces onto prototype chains, or  
> whether to use prototype chains at all -- or in the seemingly  
> unlikely event ES grows first-class method-suite mixins, binding  
> WebIDL inheritance to those. We would welcome use-cases and  
> collobaration, at least I would. Who knows what better system might  
> result?
>
>
>
> 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 
> >.
>
> Thanks for the links, I was aware of these but hadn't read them.
>
> Mandatory try-locks in JS, just say no.
>
>
>
> I'm not sure what the other concerns about "execution scope" are -  
> seems hard to discuss fruitfully without more detail.
>
> The term I used was "execution model". "scope" is a mis-transcription.
>
>
>
> 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?
>
> No, nothing was changed in ES5 and it is not clear without more  
> discussion with various experts active in whatwg, w3, and Ecma what  
> to do.
>
> Since you asked, I think you make the case that we should  
> collaborate a bit more closely.
>
>
>
> I know the feedback was passed along.
>
> Yes, but describing the problem does not give the solution.
>
> /be
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> -- 
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325