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

That sounds reasonable. There are really two issues. One is that there are
parts of WebIDL that are unused. Another is that the parts of the spec
themselves are fairly arcane and very implementor-specific. Consider:
interface UndoManager {
  readonly attribute unsigned long length;
  getter any item(in unsigned long index);
  readonly attribute unsigned long position;
  unsigned long add(in any data, in DOMString title);
  void remove(in unsigned long index);
  void clearUndo();
  void clearRedo();
};

I almost forget that I'm looking at something most widely implemented in a
dynamic language when I look at that. Since this is most likely to be
implemented in terms of ECMAScript, why not provide an ECMAScript reference
implementation?

-- Yehuda

On Thu, Sep 24, 2009 at 1:49 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Sep 24, 2009, at 12:00 PM, Yehuda Katz wrote:
>
> 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.
>
>
> My inclination would be to address this by improving the current Web IDL
> spec,  or to write an informative "primer" style document to accompany it. I
> also think some of the complexity of the Web IDL spec can probably be
> removed without losing anything important - I think it offers some
> constructs that are not used by any spec relying on it.
>
>  - Maciej
>
>
> -- 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
>
>
>


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