W3C home > Mailing lists > Public > www-style@w3.org > September 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 6 Sep 2013 12:17:01 -0700
Message-ID: <CAAWBYDC=TNKDim3+kMjYTD=ytnZagWrMyZ+0yiPunkpuhWw1Bw@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Cameron McCormack <cam@mcc.id.au>, www-style list <www-style@w3.org>
On Fri, Sep 6, 2013 at 3:12 AM, Simon Pieters <simonp@opera.com> wrote:
> On Wed, 28 Aug 2013 16:55:47 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Wed, Aug 28, 2013 at 1:41 AM, Simon Pieters <simonp@opera.com> 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
sort.


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?

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:34 UTC