- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 06 Sep 2013 12:12:59 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "Cameron McCormack" <cam@mcc.id.au>, "www-style list" <www-style@w3.org>
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). > 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? > 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. -- Simon Pieters Opera Software
Received on Friday, 6 September 2013 10:06:33 UTC