W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 24 Sep 2009 11:17:30 -0700
Cc: Brendan Eich <brendan@mozilla.com>, public-webapps@w3.org, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-id: <34FE1E9B-6127-453A-8483-F06E3186E71A@apple.com>
To: Yehuda Katz <wycats@gmail.com>

On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:

> Is it really true that WebIDL and the vague way DOM2 was described  
> are the only two options? Surely that's a false dilemma?

I'm not saying those are the only two options. I'm explaining how  
WebIDL solves a problem. Are there other ways to solve the problem?  
Probably. Do you have a specific proposal?

Regards,
Maciej

>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>
> 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
>
>
>
>
> -- 
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
Received on Thursday, 24 September 2009 18:23:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT