W3C home > Mailing lists > Public > www-style@w3.org > October 2008

Re: [Css Variables] Variable Declaration Blocks

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Wed, 1 Oct 2008 16:01:42 +0200
Message-ID: <2C9AE4919039475588F5A65384AA8750@fremycompany>
To: "Mike Wilson" <mikewse@hotmail.com>, "'L. David Baron'" <dbaron@dbaron.org>
Cc: <www-style@w3.org>

> L. David Baron wrote:
>> Mike Wilson wrote:
>> > It would be great if you could expand a little on why having
>> > changeable variables breaks the cascading order?
>> I expanded on it a bit in
>> http://lists.w3.org/Archives/Public/www-style/2008Aug/0169.html
> Ah, thanks. I did read it at the time but apparently I failed to
> make a mental note to come back to it, sorry about that.
> I'm inlining below to continue the discussion:
> On Fri, 22 Aug 2008 16:21:40 +0100 L. David Baron wrote:
>> If the complex variable can be changed later, I'm not
>> sure how to reflect in the CSS object model that there's a
>> declaration block a declaration like:
>> @define {
>>   complexVariable {
>>     color: blue;
>>   }
>> }
>> p { var(complexVariable); color: green; }
>> q { color: purple; var(complexVariable); }
>> such that p elements are green, q elements are blue, but if we
>> dynamically change complexVariable to no longer declare the color
>> property, q elements would change to purple.  (And consider
>> especially dynamic mutation of sheet.cssRules[i].style.color on the
>> p and q rules, which is already permitted.)
> If I understand you correctly here, your picture of how this would
> function is that the var(complexVariable) reference would inline
> all its properties right into p and q, resulting in the following
> view for the user code:
>  p { color: blue; color: green; }
>  q { color: purple; color: blue; }
> which indeed would break the one-value-per-property-per-declaration-
> block rule if we want to access both with CSSOM. (I guess this is
> the problem there has been talk about, and not the one I outlined
> in my previous mail to Dave Hyatt.)
> The way I have thought about this is that variable references would
> actually be exposed to CSSOM client code just like they are:
>  complexVariable { color: blue; }
>  p { <ref to complexVariable>; color: green; }
>  q { color: purple; <ref to complexVariable>; }
> When the user code calls sheet.cssRules[i].style.color it will always
> be the rule's own color property being addressed and there is only
> one value per property. (The resulting style on dependent elements
> will of course include stuff from variables though.)
> The variable itself is accessed through CSSOM like if it was a
> separate rule.
> References to complex variables could be exposed in many ways, from
> dedicated API all the way down to a simple "variables" property
> containing a white-space delimited list of variable names (like
> the "classes" property in HTML elements):
>  p { variables: complexVariable; color: green; }
>  q { color: purple; variables: complexVariable; }

I agree with you.
The complex variable should not be merged with the real selector.
But at this time, I think "variables:" is not as good as "imports:" or 

And if we look at a previously defined problem,

    @define {
        complex: {
            color: red;

should be replaced by

    @define complex {
            color: red;

> I guess the variables could also be kept out of the property list
> in the CSSOM API. Something like the following could be possible:
>  p { color: green; }
>  and the corresponding
>  CSSStyleRule.variables.item(0) = "complexVariable"


> That would lose the positional priority from your example where
> p's color wins over complexVariables's, but q doesn't, but maybe
> that is not an important point for variables. If it's not then
> we could f ex decide that all properties defined in a rule will
> win over assignments in a referenced variable (just like "style"
> wins over referenced classes in HTML elements).
> Did all this make sense, or maybe there are other things in this
> that I am missing and that cause further problems?
> Best regards
> Mike Wilson
Received on Wednesday, 1 October 2008 14:02:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:40 UTC