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

Tab Atkins Jr.:
> 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).

Sounds good.

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

Oh, yes, that would be a change in behaviour.  Is this a practical 
problem, though?

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

Named properties are exposed as data properties by defining special 
behaviour for [[GetOwnProperty]], [[DefineOwnProperty]] etc. on platform 
objects.  If we move them up to the prototype, then they cannot remain 
as data properties since they won't be able to have different values 
depending on which actual CSSStyleDeclaration you performed the property 
lookup on.  If they were exposed as accessor properties, then this would 
work.  Now this is a bit more overhead, but we've already committed to 
this given that's how IDL attributes are exposed.

Exposing named properties somewhere on the prototype chain like with 
[NamedPropertiesObject] also requires us to have the same set of 
property names.  For objects like HTMLCollection that's obviously not 
possible, but for CSSStyleDeclaration that would be OK, since the set is 
the same for every object.

I am however not keen on CSSStyleDeclaration using a different mechanism 
to expose named properties than other objects (ignoring Window, the only 
user of [NamedPropertiesObject] at the moment).

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

Although it is a change, is there a real problem with 
CSSStyleDeclaration named properties being exposed on the object itself? 
  Remember that as a platform we've only "just" moved (or really are 
still in the process of moving) IDL attributes to be accessors on the 
prototype.  So I wonder whether there really would be a compat problem.

You could certainly write the above "assume a partial interface 
declaration like blah" if you want, if you are concerned about 
boilerplate copy/pasting of an actual partial interface declaration over 
all specs that define CSS properties.

Received on Friday, 24 February 2012 01:41:34 UTC