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

On Thu, Sep 24, 2009 at 7:55 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:
>> The current WebIDL binding to ECMAScript is based on ES3... this needs to
>> more closely track to the evolution of ES, in particular it needs to be
>> updated to ES5 w.r.t the Meta Object Protocol.  In the process, we should
>> discuss whether this work continues in the W3C, is done as a joint effort
>> with ECMA, or moves to ECMA entirely.
>
> 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. Probably the best thing
> to do is to provide detailed technical review of Web IDL via the W3C
> process.


To clarify, AFAIK, no one on the EcmaScript committee is proposing
that WebIDL itself be moved to ECMA, but rather the WebIDL->EcmaScript
language binding.

To answer a concern brought up later in the thread, neither is anyone
of the EcmaScript committee proposing that anything be removed from
WebIDL, or that the definition of these binding change in ways that
create incompatibilities with current pre-HTML5 browser APIs. Whatever
problems are created by legacy uses of WebIDL, we all accept that we
have to live with these problems for the foreseeable future
(essentially forever). Rather, the concern is that new APIs defined
using WebIDL should not magnify these problems.

These are two separate points. The second point constitutes only
advice from ECMA to W3C, and demonstrates a need for dialog. The
EcmaScript committee has been evolving EcmaScript with one of our
goals being to close the gap between what DOM objects can do and what
EcmaScript objects can emulate. While we were busy trying to close the
gap, html5 was busy widening it. This is largely our fault by not
having communicated this goal. We seek dialog repair this mistake and
to avoid repeating it.

The first point may be more contentious, but I think is also clearer.
Say Joe creates JoeLang and creates a browser plugin or something that
gives JoeLang access to the DOM. Joe should not expect W3C to define
the WebIDL->JoeLang binding. As you say, WebIDL is a nominally
language-independent formalism. As such, it should serve precisely as
the abstraction mechanism needed to allow work on host environment
APIs like browsers to proceed loosely coupled to the design on the
languages that run in such host environments.

Catchalls are an excellent example issue for both points, in opposite
directions. Regarding the second point, yes, we believe that new host
APIs should generally seek to avoid requiring catchalls, since new
native (i.e., written in EcmaScript) APIs must, and since there are
many benefits to being able to emulate more host APIs more easily in
EcmaScript (such as the ability to interpose intermediary wrappers).
Regarding the first point, since legacy host APIs do require
catchalls, EcmaScript must eventually too. The definition of how
WebIDL-expressed catchalls map to future EcmaScript should co-evolve
with the changes to EcmaScript needed to support this mapping.


>>
>> - - -
>>
>> A concern specific to HTML5 uses WebIDL in a way that precludes
>> implementation of these objects in ECMAScript (i.e., they can only be
>> implemented as host objects), and an explicit goal of ECMA TC39 has been to
>> reduce such.  Ideally ECMA TC39 and the W3C HTML WG would jointly develop
>> guidance on developing web APIs, and the W3C HTML WG would apply that
>> guidance in HTML5.
>>
>> Meanwhile, I would encourage members of ECMA TC 39 who are aware of
>> specific issues to open bug reports:
>>
>>  http://www.w3.org/Bugs/Public/
>>
>> And I would encourage members of the HTML WG who are interested in this
>> topic to read up on the following emails (suggested by Brendan Eich):
>>
>> 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).
>
>>
>> - - -
>>
>> 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>.
>
> I'm not sure what the other concerns about "execution scope" are - seems
> hard to discuss fruitfully without more detail.
>
>> - - -
>>
>> 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? I know the feedback was passed along.
>
> Regards,
> Maciej
>
>
>



-- 
    Cheers,
    --MarkM

Received on Friday, 25 September 2009 14:27:02 UTC