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

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