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

On Fri, 25 Sep 2009 16:26:21 +0200, Mark S. Miller <erights@google.com>  
wrote:
> 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.

That is the most essential part of Web IDL for most consumers though.  
Maybe one should hope for the best, but I think the WebApps WG is a much  
better place in terms of transparency and I do not see any reason why the  
ECMAScript committee cannot simply provide public feedback just like  
everyone else. Even if a person cannot be on the WG for whatever reason he  
is still allowed to join the mailing list and participate in discussion.

I think it is better in terms of transparency because all the decisions  
are made on a public list, the draft is in version control (and written in  
HTML), and it is very easy for people to participate by just emailing  
public-webapps@w3.org or chatting with the editor on IRC.

(Admittedly I also have my reservations on how certain decisions regarding  
ECMAScript have been made running contrary to deployed implementations.  
E.g. with regards to the de facto getters and setters standard. I think  
something like that would be much less likely to happen at the W3C though  
in the end of course it depends on who is involved.)


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

I'm not sure I agree they are problems, though it might help if some  
explicit examples were given.


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

Where exactly was the gap widened?


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

While N languages might not be possible doing it for the 2 we care about  
does make sense I think. The specific language details also influence the  
design of Web IDL. And especially in case of ECMAScript makes reviewing  
the draft much easier because you can easily check if it matches what  
contemporary implementations do.


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


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Friday, 25 September 2009 14:59:59 UTC