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

I'll think about it. I was mostly hoping to start a discussion about
alternatives. I think the bottom line here is that while the spec is
well-optimized for implementors, it is not very well optimized for
consumers. I suppose it would be possible to say that this stuff is *only*
for implementors. I'd prefer if it were also readable for those trying to
use the specification.
-- Yehuda

On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak <mjs@apple.com> wrote:

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


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325