- From: Mike Wilson <mikewse@hotmail.com>
- Date: Tue, 30 Sep 2008 18:08:24 +0200
- To: "'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 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 Tuesday, 30 September 2008 16:09:18 UTC