ECMA TC 39 / W3C HTML and WebApps WG coordination

David-Sarah Hopwood david-sarah at
Sat Sep 26 00:20:56 PDT 2009

Maciej Stachowiak wrote:
> I think there are two possible perspectives on what constitutes
> "magnify[ing] the 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 firmly B, for the reasons given below.

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

Yes it does:

 - In many cases, APIs are partially redundant, in such a way that
   developers can choose to avoid some of the legacy interfaces without
   any significant loss of functionality. By doing so, they can avoid the
   problems caused by clashes between names defined in HTML, and names of
   ECMAScript methods. If new APIs also use catch-alls, they are less
   likely to be able to do this.

 - The potential name clashes created by catch-alls also create a forward
   compatibility issue: if a new method is added to an interface, it
   might clash with names used in existing HTML content. In the case of
   legacy interfaces, it is less likely that we want to add new methods
   to them, and so this forward compatibility issue is less of a problem.

 - Implementors of subsets in which the DOM APIs are "tamed" for security
   reasons can choose not to implement some APIs that are problematic for
   them to support; but if new APIs are equally problematic, they will be
   unable to provide access to that functionality.

David-Sarah Hopwood  ⚥

More information about the es-discuss mailing list