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

CSS Variables Comments

From: David Hyatt <hyatt@apple.com>
Date: Mon, 16 Jun 2008 16:03:57 -0500
To: www-style list <www-style@w3.org>
Message-id: <3D7136EB-2358-4943-8E43-D6DE897A507E@apple.com>
I have been working on an implementation of CSS Variables for a while,  
and these are the comments I have so far on the draft at

http://disruptive-innovations.com/zoo/cssvariables/

(1) In section 4.1, the grammar is incorrect.  LBRACE is part of both  
"variables" and "variableset", when it needs to only be declared in  
one of them.

(2) In section 5.3, removeVariable is specified as raising an  
exception, but no mention is made of when or why it would raise one.

(3) In section 5.4, CSS_VARIABLE is specified as having a value of 4.   
This conflicts with the value used for INITIAL in WebKit.  We could  
probably move INITIAL to 5, but it might be  worth thinking about how  
to handle DOM conflicts when CSS drafts all want to proceed along a  
standardization track at their own pace (and may all want to add new  
rule types and value types).

(4) The CSSVariable interface needs to be removed.  The CSSVariable  
interface's existence greatly complicates *everything*.

(a) It can appear as a component of a compound value.  It will make  
the implementation extremely difficult if I have to actually parse  
complex values like text-shadow while hanging on to CSSVariable values  
for pieces of that value.

(b) An actual media context must be given in order to perform variable  
lookups.  The CSSVariable interface can't simply have a CSSValue  
"value" attribute, since that value is media-dependent.

To resolve these two issues, I think it would be much better to simply  
have a CSSVariableDependentValue interface (CSSUnresolvedValue?) that  
represents the entire "unresolved" right-hand side of a property/value  
pair.  It would look something like this:

interface CSSVariableDependentValue : CSSValue {
	CSSValue getResolvedValue(stylesheets::MediaList mediaList);
}

This makes life much easier for implementors.  You can basically store  
unresolved information (either the original string, or a "half-parsed"  
set of terms/expressions).  Resolving the value consists of replacing  
the variables with real values (using the correct media query) and  
completing the parse.

(5) The draft makes no mention of where @variables rules fit in  
relation to @namespaces.  The order needs to be specified.  I suggest  
saying @variables occur before @namespaces.

(6) The draft makes no mention of whether variable lookups occur using  
every variable defined on the document or only variables that occurred  
earlier in a depth first parse of the stylesheets.  I believe it's  
much easier (and more intuitive for authors) if lookups occur using  
every variable available for the current media (since dynamic re- 
evaluation when methods like setVariable get called would be much more  
problematic otherwise).

dave
(hyatt@apple.com)
Received on Monday, 16 June 2008 21:04:46 GMT

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