- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 25 Feb 2012 15:58:36 +1100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: public-script-coord@w3.org
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