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

On Sep 24, 2009, at 9:47 AM, Brendan Eich 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).

The converse of all these problems would arise if the spec became an  
ECMA spec. Indeed, possibly worse, because ECMA has no formally  
defined process for external review of a specification (though ECMA  
subgroups could define their own process presumably).

>
> 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.

We could recommend avoiding catch-alls as a best practice. However,  
many legacy DOM interfaces require catch-all behavior, so it can't be  
completely eliminated. If we want to restrict host objects to what  
WebIDL allows, but not break the Web, then catch-all getters and  
putters have to be among the things it allows.

>
> 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?

Yes, linearization of multiply-inherited interfaces (and multiple  
interfaces that are present but not inherited) is something that could  
use careful review and a better design. When I said "these are largely  
Web IDL issues" I mean "not directly issues for the HTML Working  
Group". I did not mean to imply that TC 39 shouldn't have input - it  
should.


>
>>> 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 didn't like most of the proposed designs either.

>
>
>> 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.

Are there specific issues other than the concurrency model for storage  
APIs?

>
>
>>> 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.

Sounds like a good issue to discuss then.

>
>> I know the feedback was passed along.
>
> Yes, but describing the problem does not give the solution.

If ES5 has requirements on this that match ES3, then it has a  
requirement that Firefox, Safari and Chrome (and I think Opera?) are  
all violating, and likely will continue to violate for the foreseeable  
future. That seems like a problem. (Unless we convince ourselves that  
the split global object pattern somehow doesn't actually violate the  
ECMAScript spec.)

Regards,
Maciej

Received on Thursday, 24 September 2009 17:48:53 UTC