ECMA TC 39 / W3C HTML and WebApps WG coordination
mjs at apple.com
Fri Sep 25 16:54:53 PDT 2009
On Sep 25, 2009, at 7:26 AM, Mark S. Miller 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.
The design of Web IDL itself is highly informed by the ECMAScript
language binding - in fact, many Web IDL constructs exist solely for
modeling ECMAScript APIs. So I don't think this split is useful
> 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.
I think there are two possible perspectives on what constitutes
"magnify[ing] tthe problem" or "widening the gap"
A) Any new kind of requirement for implementations of object
interfaces that can't be implemented in pure ECMAScript expands the
scope of the problem.
B) Any new interface that isn't implementable in ECMAScript widens the
gap, even if it is for a reason that also applies to legacy
My view is A. That's why I pointed to legacy interfaces - if the
construct can't go away from APIs in general, but we wish to implement
all APIs in ECMAScript, then ultimately it is ECMAScript that must
change, so using the same construct again doesn't create a new
problem. Avoiding it in new APIs would provide a small amount of
temporary relief for the brave person who seeks to implement the whole
Web platform in pure ECMAScript, but in the long run would make no
difference to the feasibility of the overall goal.
Now, there may be pragmatic reasons for avoiding catchall getters and
1) Difficulty of efficient implementation (this is less true for index-
only catchall getters).
2) Potential confusingness to authors (probably also less true for
3) Namespace collisions between the magical attributes and the
object's built-in attributes and methods - this makes it harder to
specify and explain the interface and creates hazards for use (does
not apply to the index access pattern afaict).
I think these are reasonable arguments (though I wouldn't rule out a
priori that there may be situations where the API convenience of
catchalls outweighs these concerns).
But I think these are totally separate from the "implementability in
pure ECMAScript" concern. And in particular, I think index access to
array-like objects is a good pattern that we should not stop using in
APIs just because it's not implementable in pure ECMAScript today.
Past interfaces use this pattern, and future interfaces should clearly
use it once ECMAScript supports it. A temporary moratorium on using it
would not be a wise tradeoff.
More information about the es-discuss