Getters establish own properties, or why is [NamedPropertiesObject] discouraged?

For context, the CSSStyleDeclaration interface defined at
<http://dvcs.w3.org/hg/cssom/raw-file/tip/Overview.html/#the-cssstyledeclaration-interface>
currently explicitly lists the supported CSS properties as attributes
on the interface.  This list is obviously incomplete, and basically
required to be so, unless we force every CSS spec to apply deltas to
this interface just to add their properties.

I had thought that the best way to fix this would be by using WebIDL's
getter/setter/etc special operations, simply defining that the list of
supported property names is the names of all the properties that the
browser supports (suitably transformed from dashes to camelcase, and
with the rare explicit exception like cssFloat).

However, it was pointed out that this would produce a change in
behavior.  The current definition puts all the properties on the
prototype object, while using getter/setter instead makes them own
properties, which in general means they would be put on the object
itself.  The [NamedPropertiesObject] extended attribute makes them not
own properties again, but that's marked as deprecated and only to be
used for legacy behavior.

What's the reasoning for this behavior difference between the two methods?

If there's a good reason, what's another good way to solve my
use-case?  Aryeh Gregor suggested just adding some text to CSSOM that
says that when CSS defines a new property it implies WebIDL like
"partial interface CSSStyleDeclaration { attribute DOMString newProp;
};" with the appropriate behavior definition.

~TJ

Received on Thursday, 23 February 2012 19:29:16 UTC