Re: [Css Variables] Variable Declaration Blocks

> 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 
"extends:"

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"

+1

>
> 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