Re: [css-om][css-variables] exposing variables through CSSStyleDeclaration

On Fri, Sep 6, 2013 at 3:12 AM, Simon Pieters <> wrote:
> On Wed, 28 Aug 2013 16:55:47 +0200, Tab Atkins Jr. <>
> wrote:
>> On Wed, Aug 28, 2013 at 1:41 AM, Simon Pieters <> wrote:
>>> I'm not sure what getComputedStyle should do. I guess include all
>>> "supported
>>> CSS properties" (i.e. excluding variables) and then include the specified
>>> variables.
>> No, we can't do this.  getComputedStyle returns an object with keys
>> being the camelCased transformations of the property names.
> All CSSStyleDeclaration objects do that. It has no relationship with what
> the object holds in its "declarations". Since the methods like
> getPropertyValue operate on the "declarations", they need to be there for
> variables to work at all (they currently aren't and don't).
>> The getComputedStyle object should just have a .var attribute, like
>> what you get from a normal style rule, with a readonly CSSVariablesMap
>> hanging off of it.
> CSSVariablesMap is defined in terms of getPropertyValue et al, so they also
> don't work currently.

Yeah, sure, keep them around in the abstract set of "declarations",
just don't expose them as named properties with that camelCase
transform.  That's all I'm saying.

>> Variables
>> *can not* be transformed in this way, which is part of the reason I
>> added CSSVariablesMap in the first place.  They also can't be
>> reasonably sorted without getting into all the unicode collation
>> issues we *specifically* tried to avoid.
> We could just sort by code unit, no?

Yeah, discussion in #whatwg came up with this.  That's fine with me.
It's not a "useful" sort, but neither is alphabetically sorting the
normal properties, really - all we need is a cheap and interoperable

Unrelated note: the IDL definition for "setProperty()" is now long
enough to extend out of the IDL box and produce a horizontal scrollbar
on my laptop screen.  Mind manually wrapping it?


Received on Friday, 6 September 2013 19:17:48 UTC