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

Re: [CSSWG] action 38, CSS Variables

From: David Hyatt <hyatt@apple.com>
Date: Tue, 08 Apr 2008 15:36:39 -0500
To: "L. David Baron" <dbaron@dbaron.org>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-id: <26D990FE-87A3-4D1D-9031-CFA8CB602D1E@apple.com>

On Apr 8, 2008, at 2:37 PM, L. David Baron wrote:

> On Tuesday 2008-04-08 21:14 +0200, Daniel Glazman wrote:
>> Daniel had an action item from last CSS WG face-to-face meeting about
>> writing a proposal for CSS variables, an oooooold request from the  
>> web
>> authors' community, and get feedback from that community.
>> We're then very happy to submit today the following proposal and we  
>> hope
>> the CSS WG will take it under its wings to make it become a standard
>> implemented soon by all browsers. Feedback HIGHLY welcome.
>>  http://disruptive-innovations.com/zoo/cssvariables/
>> Daniel Glazman (Disruptive Innovations)
>> David Hyatt (Apple, Inc.)
> This doesn't say a whole lot about what values are allowed for
> variables, which seems like a pretty key part of both how useful
> it's going to be and how easy it will be to implement.  It seems
> like the range of allowed values has to be rather limited in order
> to be represented by the CSSValue DOM interface, though.

The parsed CSSValue could end up being of type CUSTOM if it's  
something more complicated.

I do think common use cases are going to involve CSSPrimitiveValues,  
so restricting to those might end up being acceptable.

> In order for user agents to represent a value with the CSSValue DOM
> interface, they have to be able to parse it.  This raises the
> question, then, of what happens when they're given a value they
> don't understand.
> The spec needs to answer the following questions clearly:
> (1) If a style sheet does:
>  @variables { myvar: unknown-keyword; }
>  p { color: var(unknown-keyword); }
> what happens?  In particular, does the @variable rule exist in the
> DOM so that the author can change it to a valid value later?  (This
> has a pretty significant effect on forward-compatibility.)

The @variable rule simply stores strings, not parsed values.  Parsed  
values are only obtainable where variables are used (from the  
CSSVariable interface).   We are advocating an approach where the  
variable string will be reparsed every time it is used (in the context  
where it is referenced).  You are right, though, that the property/ 
value pair should probably remain in the CSS OM even when the result  
has been rejected as invalid.

> (2) Furthermore, if a style sheet does:
>  @variables { myvar: red; }
>  p { font-size: var(myvar); }
> what happens?  Is the font-size rule ignored temporarily?  And then
> if the author uses the DOM to change myvar to "12px", it suddenly
> stops being ignored?

Yes, good point.  We need to address this explicitly.  I do agree that  
"liveness" of variables makes this harder to implement.  It's also  
very powerful though.

 From an implementation perspective you'd need to know which  
individual property/value pairs in a declaration depend on certain  
variables and reparse them whenever that variable changed.

Received on Tuesday, 8 April 2008 20:37:39 UTC

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