ECMA TC 39 / W3C HTML and WebApps WG coordination
david-sarah at jacaranda.org
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
> 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 ⚥ http://davidsarah.livejournal.com
More information about the es-discuss