Re: [css4-color] @color-keyword Color Keywords

On Dec 11, 2010, at 6:15 AM, Eli Morris-Heft wrote:

> While working on a website that is about to suffer a subtle but wide- 
> reaching color scheme change, I was thinking about how nice it would  
> have been to be able to create color keywords for my color scheme  
> colors. Then I recalled that I had read something similar on this  
> list a while back, so I went and read the relevant thread in the  
> archives[1]. It seems like there was a lot of discussion but that it  
> didn't go all that far. So I'm throwing my proposal into the mix.  
> This proposal is exactly what it says on the tin: a way to define  
> new color keywords.
>
> @color-keyword {
>     keyword: ochre;
>     color: hsl(6, 82%, 37%);
> }
>
> a {
>     color: ochre; /* is the same as color: hsl(6, 82%, 37%); */
> }
>
> The value for keyword must be a proper CSS keyword. (Which I believe  
> means it must match /[a-zA-z0-9-]+/.)
> The value for color must be a <color>.
>
> While I can see that this is almost exactly a proper subset of the  
> use cases for CSS variables, there doesn't seem to be a lot of  
> movement on variable and this is a specific use case that I feel is  
> common enough and simple enough that a separate treatment is fine. I  
> think that the main practical use will be to make using color  
> schemes easier (so you don't have to remember your color's RGB and  
> HSL values) and to make skinning and theming easier: instead of  
> having to reproduce all the selectors for the whole site in a  
> different file and override their colors, one can simply name the  
> colors and swap out the CSS file that defines those colors.
>
> Whether or not the existing color keywords can be redefined is a  
> matter for debate. On the one hand, there is potential for bad code  
> there. On the other hand, color keywords are already defined in this  
> way, unless they have some magic about them. Though it occurs to me  
> when writing this that the potential for bad code combined with the  
> existence of magical color keywords means that perhaps not allowing  
> existing color keywords to be used is the better course of action.  
> That said, the proposal itself gives the opportunity for some  
> horrible code anyway:
>
> @color-keyword {
>     keyword: cerulean;
>     color: hsl(6, 82%, 37%);
> }
>
> But I am willing to take this as a price, since any variable-like  
> mechanism can be used for bad code like this.
>
> Thoughts?

As others have said a better (ie: more CSS like) syntax for specifying  
the colors would be something like (using pseudo CSS grammar notation):
@color [ IDENT | STRING] <color> ';'
or
@colors '{'
   [ IDENT | STRING] ':' <color> [ ';' [ IDENT | STRING] ':' <color>]+
'}'

Specifying color names as keywords and then allowing their use as  
regular keywords is extremely dangerous, and not forward-compatible.  
It can lead to ambiguously parsable properties, think shorthand  
properties that take colors along with other keywords. You have to add  
a point of use syntax, like:
color: @foo;
or:
color: color(foo);

Implementing something like this (or variables in general) seems  
straightforward on first blush, but the devil is in the details (and  
why this hasn't been added to CSS years ago).

Is the at-rule exposed in the CSSOM?
What happens if the value is changed via script at runtime?
What happens if a new at-rule is injected at runtime?
What happens if an at-rule is removed at runtime?
What happens if the color keyword is unrecognized?
What happens it the color keyword was unrecognized at parse time, but  
then an at-rule defining it is inserted later?
Do @color rules cross @import boundaries? (ie: if defined in an  
@import-ed stylesheet can they be referred to in the parent?)

Gives us good answers to these questions (and probably a few more that  
I missed off the top of my head) and we'd all love to add a feature  
like this to CSS (or even general purpose variables). Provided of  
course that you didn't just introduce an extreme amount of  
implementation complexity in how you answered those questions...

As you can hopefully see, the problem to adding this isn't alleviated  
by making it a subset of general purpose variables. The same reasons  
that have kept variables from being added still exist here. The  
difference in complexity between a limited use substitution and full- 
blown variables is quite small when compared to all the other support  
needed for either (in fact, restricting it to colors would probably  
_add_ code).

Peter

Received on Monday, 13 December 2010 19:38:06 UTC