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

On Sep 25, 2009, at 2:38 AM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
>>> That sounds reasonable. There are really two issues. One is that  
>>> there are parts of WebIDL that are unused. Another is that the  
>>> parts of the spec themselves are fairly arcane and very  
>>> implementor-specific. Consider:
>>>
>>> interface UndoManager {
>>>  readonly attribute unsigned long length;
>>>  getter any item(in unsigned long index);
>>>  readonly attribute unsigned long position;
>>>  unsigned long add(in any data, in DOMString title);
>>>  void remove(in unsigned long index);
>>>  void clearUndo();
>>>  void clearRedo();
>>> };
>>>
>>> I almost forget that I'm looking at something most widely  
>>> implemented in a dynamic language when I look at that. Since this  
>>> is most likely to be implemented in terms of ECMAScript, why not  
>>> provide an ECMAScript reference implementation?
>> These methods do things that can't actually be implemented in pure  
>> ECMAScript, since they need to tie into the browser implementation  
>> and system APIs. So a reference implementation in ECMAScript is not  
>> possible.
>
> I'll accept that it is a true statement that in an pure ECMAScript  
> implementation of these interfaces in Safari on Mac OSX such  
> wouldn't be possible.
>
> Alternate perspective, one that I believe more closely matches the  
> view of TC39: one could image an operating system and browser  
> implemented in either in ECMAScript or in a secure subset thereof.   
> In such an environment it would be highly unfortunate if the the  
> WebIDL for something as important as HTML5 and WebApps were written  
> in such a way as to preclude the creation of a conforming ECMAScript  
> implementation.

Unfortunately, this is the case. But in many cases this is due to  
legacy compatibility requirements combined with certain features that  
do not (yet) exist in ECMAScript. See below.

> At this point, I'm not personally interested in discussions as to  
> whether WebIDL is or is not the right way forward.  Anybody who  
> wishes to invest their time in producing more useful documentation  
> and/or reference implementations is not only welcome to do so, they  
> are positively encouraged to do so.
>
> Meanwhile, what we need is concrete bug reports of specific  
> instances where the existing WebIDL description of key interfaces is  
> done in a way that precludes a pure ECMAScript implementation of the  
> function.

I think the main cases where this is true are interfaces with catchall  
getters and setters, or interfaces that are callable (but also have  
various methods and properties and are not Functions). I believe most  
of these are due to legacy compatibility constraints. Thus, ECMAScript  
will need to change to be able to plausibly implement equivalent  
interfaces. A change to Web IDL to match current ECMAScript  
capabilities would mean it can't actually describe the APIs that exist  
in browsers today, and such a description of these APIs would be,  
essentially, false. This seems like putting the cart before the horse.

Let me give a concrete example, the HTMLCollection interface from  
HTML5: <http://dev.w3.org/html5/spec/Overview.html#htmlcollection-0>.

This interface is defined to have "getter" properties which imply  
catchall getters for index and non-index properties. This is  
implemented by all existing browsers and is needed for compatibility  
with a lot of Web content. It is also required by DOM Level 2 HTML's  
ECMAScript bindings: <http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html 
 >. The fact that ECMAScript 5 can't implement an interface that  
behaves like this is an ECMAScript issue, not an HTML issue, in my  
opinion, and one that will hopefully be fixed in future editions.

Now, it may be that some non-legacy APIs require special host object  
behavior that wouldn't otherwise be implicated by legacy APIs. If  
anyone identifies such APIs, then we can look at fixing them.

Regards,
Maciej

Received on Friday, 25 September 2009 10:15:49 UTC