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

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

Tab Atkins Jr.:
> I'm pretty sure the CSSStyleDeclaration props are defined as accessor
> properties in practice, so they can lazily generate their values when
> necessary.  I'm not sure how much of that is magic vs
> needs-to-be-observable behavior.

OK, and that's entirely consistent with their being currently defined as 
IDL attributes (and not as named properties).

>> 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.
>
> Once impls support Variables this'll be a little different; the set is
> open-ended/infinite then.

Interesting.  And they will be different sets for different 
CSSStyleDeclaration objects, yes?

I think there will be no need to monkeypatch the properties for 
Variables exposed on CSSStyleDeclaration objects, like there might be 
for CSS properties, so I think it would be OK to expose them as own 
properties even if CSS properties are accessor properties defined named 
properties and exposed on the prototype somehow.

>> 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).
>
> I would also prefer it act similar to the rest of the platform in
> author-visible behavior.  I'm just not sure what that means, or how I
> should go about doing it. ;_;

"similar to the rest of the platform" and "author-visible behavior" are 
conflicting here, if we want them to be exposed as named properties.  To 
be similar to the rest of the platform, named properties should be 
exposed as own, data properties on the object.  To maintain the same 
author-visible behaviour, they need to be exposed as accessor properties 
on CSSStyleDeclaration.prototype.

It seems like there might be some usefulness in exposing CSS properties 
are accessor properties on the prototype, so that they can be 
monkeypatched.  This can't be done using named properties currently.  I 
suggest either doing as you said Aryeh suggested, which is to say in 
some CSS spec

   The implementation MUST support the following Web IDL partial
   interface definition, where for each CSS property the implementation
   recognises there is a corresponding IDL attribute on the partial
   interface definition of type DOMString and whose name is the _camel-
   cased version_ of the property's name.

     partial interface CSSStyleDeclaration {
       ... attributes for the CSS properties ...
     };

   For example, if the implementation recognises just the three CSS
   properties named color, font-size and background-image, then the
   partial interface definition would be considered to be as follows:

     partial interface CSSStyleDeclaration {
       attribute DOMString color;
       attribute DOMString fontSize;
       attribute DOMSTring backgroundImage;
     };

   /* And then explain what it means to get and set these attributes */

or to require each spec that defines a property to include a concrete 
CSSStyleDeclaration partial interface definition.  I think the "do it 
once in a CSS spec" approach would be fine, though.

Received on Saturday, 25 February 2012 04:59:13 UTC