Re: Comments on CSS Variables r1.0 (2008-04-08)

On Jun 16, 2008, at 4:22 PM, Adam Roben wrote:

> Comments/questions about < 
> >
> 2. The proposal doesn't define what happens when a variable is  
> defined more than once.

The last one should win in my opinion.

> 3. The proposal doesn't define the behavior of item(unsigned long  
> index) when passed an out-of-bounds index.

It actually does.  It uses the same wording as CSSStyleDeclaration.

See under return value: "The empty string if no property exists at  
this position."

> 4. The proposal doesn't define the behavior of getVariableValue,  
> removeVariable, and setVariable when passed a variable name that  
> doesn't exist, or one that can't be parsed, etc., etc.

It does specify what happens if the parse fails.  A SYNTAX_ERR  
exception is raised.  I agree that removeVariable is confusing, since  
it claims to raise an exception but no mention is made of why.  I  
assume maybe it could raise one if no variable exists.

> 5. It seems unfortunate that you can't set the value attribute of a  
> CSSVariable object. But perhaps this is consistent with the existing  

This entire interface is problematic (see my other email).   The value  
attribute can't return a meaningful answer without a media context.    
Setting it would be nonsensical, since what are you actually setting?   
The original variable back in the @variables rule?  You could just  
grab the @variables rule and use setVariable.  I don't think you  
should be allowed to edit the value of the variable only at a call  
site (which is what CSSVariable is).

> 6. I don't understand the description in section 5.5 Interface  
> CSSVariable:
>> The CSSVariable interface represents a call to CSS Variable.
> What's a "call to CSS Variable"?

CSSVariable represents the use of a variable (as opposed to its  
definition), e.g.,

background-color: var(myBGColor);

The idea was to have a CSSVariable represent the var(myBGColor) call  
site.  As I said in my other message, though, I think this interface  
needs to be scrapped, since it really messes up stuff like:

text-shadow: var(myBlur) var(myOffset).... etc.

I think it's better to just have a single unresolved value for the  
entire text-shadow expression above and have a way of resolving the  
entire value at once by passing in the appropriate media context.


Received on Monday, 16 June 2008 21:36:52 UTC