Re: [WebIDL] troublesome names, property attributes and related issues

On Aug 26, 2011, at 4:00 AM, Simon Pieters wrote:

> On Fri, 26 Aug 2011 09:15:20 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> ...
> It's ELEMENT_NODE, not NODE_ELEMENT. :-)

so much for late night typing...


> 
> 
>> Ah, ELEMENT_NODE doesn't live on the Document interface, it lives on
>> the Node interface. So both the Node constructor and all instances of
>> the Node interface (such as document) have the ELEMENT_NODE property.
>> 
>> I'm not married to having instances contain constants though. If no
>> other browsers do that, then it's likely not required for webcompat
>> and could be dropped.
> 
> javascript:alert(document.ELEMENT_NODE)
> 
> alerts 1 in firefox, chrome and opera. I think it's likely required for web compat.


I agree.  My original point was regarding whether the replication of constants on both interface objects and interface prototype object be wired into WebIDL (as it current is specified) or should it be done explicitly on a case by case basis  where it is needed for web compat for existing APIs.   For example we could allow a "static" prefix on const definitions in which case Node might be coded as:

interface Node {
   ...
   const unsigned short ELEMENT_NODE = 1;
   static const unsigned short ELEMENT_NODE = 1;
   ...
}

making it explicit that ELEMENT_NODE exists "on both sides".  New API's could be encouraged to adopted the more normal ECMAScript convention and only define the "static" constant.

Allen