Media queries and CSS Variables, was: Re: [CSSWG] action 38, CSS Variables

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.
>
> 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.)
>
> (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?
>
>
> I'm worried that issues like these could make this proposal very
> hard to implement.
>
> (Has anybody looked into how many of the use cases for variables,
> constants, or macros would be addressed by a proposal like this for
> dynamic variables with limited syntax, versus a proposal for static
> constants/macros with broader syntax permitted?)
>
>   
I think too that dynamic values are somehow conflicting with the idea of 
CSS model.
I've implemented similar feature - parse time @const  [1]. That model is 
really easy
to implement and understand and it does not create any logical conflicts 
you have mentioned.

There is another thing that appears as a close issue.
Consider mobile device that may change screen orientation on the fly so 
in principle following two
declarations must *always* be parsed into CSSOM and applied dynamically.

@import url.css screen and (width: 480px) {...}
@import url.css screen and (width: 640px) {...}


That conflicts with "So that user agents can avoid retrieving resources for unsupported
media types <http://www.w3.org/TR/CSS21/media.html>" [2]

It appears as @mediqueries and @variables require to change the whole model/idea  
of CSS parsing. Huh?


[1] http://csswg.inkedblade.net/ideas/constants
[2] http://www.w3.org/TR/CSS21/cascade.html#at-import

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Wednesday, 9 April 2008 20:00:48 UTC