[WebIDL] troublesome names, property attributes and related issues

Because the use of 'prototype',  'constructor', and probably 'toString' as attribute or operation names is problematic for ES, WebIDL section 3 should probably simply reserve those names and say that they can't be used as attribute, operation, or constant names.  If you want to be more precise 'prototype' probably only needs to be reserved from use as a static operation name and 'constructor' as a non-static operation, attribute or constant name.

4.3.8 [NoInterfaceObject]

What if an [NoInterfaceObject] interface has static operations?  Would this be an invalid WebIDL fragment?  This case also doesn't appear to be covered by 4.5.6.

4.5.4 Constants

This section says that constants must be defined as properties on both the interface prototype object and the interface object.  Browsers don't currently seem to do this.  Try document.ELEMENT_NODE and Document.ELEMENT_NODE (http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1950641247 ).
While Java does this, it isn't a normal JavaScript coding convention to duplicate constant properties on both the constructor and prototype object. (See for example Number.MAX_VALUE and similar properties).  A more typical JS convention would be to only define constants on the constructor object and not on the prototype object but this is not what current browser DOM implementations seem to do.

It would be good for new API designs to use the more normal JS constructor only convention for constants.  You could encourage this by specify in  4.5.6 that constants normally only appear as properties on the interface object.  For compatibility with existing web APIs that have constants on the instances you could use a new extended attributes, perhaps [PrototypeProperty], to indicate that the constant should also be defined on the interface prototype object. This gives you backwards compatibility and migrates existing APIs to expose constants on interface objects.

4.5.4 defines the ES property attributes for constants as { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.  While I don't particularly disagree with the settings for [[Writable]] and [[Configurable]] I do need to point out that this is different from what is currently implemented by FF, IE9, and Chrome for ELEMENT_NODE and probably other constants.  If this is seen as an acceptable change from current browser practice then I have to also question the [[Enumerable]] setting.  The ES norm is for properties that represent constants to be  non-enumerable.  See for example ES5.1 15.7.3.2-15.7.3.6 and 15.8.1.1-15.8.18.  This precedent suggests that the ES binding for WebIDL constants should define them as [[Enumerable]]: false.

Similarly, 4.5.6 says that operations turn into properties that are [[Enumerable]]: true while the ES convention for built-in object abstractions is for method properties to be  [[Enumerable]]: false. Future versions of ES that will provide direct support for defining methods and/or class-like abstractions will also default user defined methods to [[Enumerable]]: false.  It would be more forward looking for WebIDL to do the same for operations.

If you use the ES built-in objects as examplars you will generally see that it is only properties that in some way represent actual program data that are made  [[Enumerable]]: true.