Re: Proposal for adding variable declaration blocks

David Hyatt wrote:
> 
> Here are a couple of ideas for how to extend CSS variables to deal with 
> declarations.

I'm glad you're thinking about this, because I think it's
one of the major limitations in the existing proposal and
something I hope will be able to solve some of the common
requests we collected on webstandards.org.

> (1) Declaring the declaration block:
> 
> (a) A second type of block could be introduced that represents a named 
> declaration.
> 
> @variable-group headers screen {
>       color: green;
>       background-color: white;
> }
> 
> (b) A nested declaration could be added to existing @variables rules:
> 
> @variables {
>   foregroundColor: blue;
>   @declaration headers {
>     color: green;
>     background-color: white
> }
> 
> My preference would be for option (b), since you would not have to 
> redeclare the media types, and the existing CSSVariablesDeclaration 
> interface could be extended to have a method that would hand back a 
> CSSStyleDeclaration for a variable name (that would succeed if the 
> variable in question is a declaration).
> 
> Note that there would have to be a note in the spec that the var() 
> notation can't be used with a declaration variable (and would basically 
> cause the var() to be ignored.

Another idea:

   /* http://lists.w3.org/Archives/Public/www-style/2008Apr/0183.html */

   @define for screen {
     foregroundColor: blue;
     backgroundColor: green;
   }

   @define boxStyle {
     border: 3pt solid;
     padding: 6pt;
   }

   @define buttonStyle for screen {
     border: outset silver;
     background: silver;
   }

and if you want to group by media, use @media.

> (2) How to use the declaration block:
> 
> (a) Make up a fake property.
> 
> h1 {
>   includes: headers;
>   font-size: 24px;
> }
> 
> (b) Make up a selector "annotation" notation
> 
> h1 includes headers {
>   font-size: 24px;
> }
> 
> (c) Make up some other kind of syntax
> 
> h1 {
>   @includes headers;
>   font-size: 24px;
> }
> 
> I believe (b) is the most elegant notation.  The only disadvantage of 
> (b) is that you would not be able to control the precise ordering (i.e., 
> the properties would just occur at the front always and could not be 
> precisely placed).

I'd go with (c). (a) is a hack on property syntax. And (b) is a hack
on selector syntax, which is worse because, as Zachary points out,
it's actually a valid selector. Plus lack of control and a worse
fallback story... 3 strikes against.

I can't think of anything against (c). Another possibility is to pick
a character and use that for all dereferences, similar to the scripting
language $.

h1 {
   $headers;
   background: $backgroundColor;
}

~fantasai

Received on Tuesday, 1 July 2008 23:08:12 UTC