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