W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css-variables] CSS Variables are a NEW kind of variable

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 14 Jun 2012 14:16:33 -0700
Message-ID: <CAAWBYDAwgLkqzC3+MgM+ziYER-d4SAwAfj8vLS+4SBxiG4GrLw@mail.gmail.com>
To: François REMY <fremycompany_pub@yahoo.fr>
Cc: Divya Manian <manian@adobe.com>, CSS 3 W3C Group <www-style@w3.org>
On Thu, Jun 14, 2012 at 2:04 PM, François REMY
<fremycompany_pub@yahoo.fr> wrote:
> | I am not sure what you mean by implementation level. At implementation
> | level I am pretty sure variables are worked on differently compared to
> | other properties. The recent commits on the WebKit nightly builds suggest
> | that to be the case http://trac.webkit.org/changeset/120154
>
> Give the relatively small number of changes in this set, I guess this is
> only a minimal CSS OM, a modified version of the tokenizer and the mechanism
> used to replace the variable tokens by their value at computation time
> (which requires to modify multiple files). Also, variables are probably
> stored differently than usual properties because they are not immediately
> converted to values. I guess 95% of the code remained shared with normal css
> properties if you consider cascade & co.

The different handling is mainly because (a) the set of vars is
open-ended, so you can't pack them into a bitfield like we do for all
the other properties, and (b) we want efficient inheritance of
variables, rather than having to clone a hashtable for every element
in the document.

They're just implementation efficiency issues.  There's nothing
preventing us from handing them just like normal properties, it would
just be slower.


> | 3. CSSOM representation that defines how variables can be accessed via
> | JavaScript.
>
> Can't agree more! If you want my point of view on the matter, we just need
> to tweak to tweak
>
>   + DOMString getPropertyValue(DOMString property);
>   + DOMString getPropertyPriority(DOMString property);
>   + void setProperty(DOMString property, DOMString value, optional DOMString
> priority);
>   + DOMString removeProperty(DOMString property);
>
> to notice say they should thread variables like any other properties. Then
> we're done very quickly and it will work like a charm.
>
>   myElement.style.getPropertyValue("my-preferred-color","lime");
>   //or: myElement.style["my-preferred-color"] = "lime";

I abhor those get/set pairs, but the way I'll define it will indeed
work like that.

~TJ
Received on Thursday, 14 June 2012 21:17:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT