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

RE: [Css Variables] Variable Declaration Blocks

From: Mike Wilson <mikewse@hotmail.com>
Date: Tue, 30 Sep 2008 18:08:24 +0200
Message-ID: <BAY116-DAV7EF6AB3BACDA6CCE5DBB0A4430@phx.gbl>
To: "'L. David Baron'" <dbaron@dbaron.org>
Cc: <www-style@w3.org>
Message-ID: <006301c92316$c437be50$0a01a8c0@mikedeskxp>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:12 GMT