W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

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

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Fri, 26 Aug 2011 07:43:11 -0700
Cc: "Jonas Sicking" <jonas@sicking.cc>, public-script-coord@w3.org
Message-Id: <087B1E33-160F-4B50-B0F3-231ED509FA34@wirfs-brock.com>
To: Simon Pieters <simonp@opera.com>

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

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.


Received on Friday, 26 August 2011 14:43:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC