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

Is it really true that WebIDL and the vague way DOM2 was described are the
only two options? Surely that's a false dilemma?
-- 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 22:18:12 UTC