Re: author-defined color aliases

On Sun, 15 Jun 2003, Eric A. Meyer wrote:

>     I personally think it is a useful
> idea, and I wish CSS had something like it already.

I'm afraid the worst problem here is that CSS hasn't got anything like it
now, and adding any macro-like features (that's actually what we're
talking about) would create serious incompatibility with user agents that
don't support them. Just ignoring things that the user agent does not
understand won't work well. If an element is declared to have black
background and pinky content, it won't be nice if a browser understands
that "black" part but not the "pinky" part. Further confusion would be
caused by the existing pollution of color name space - browsers recognize
a large number of predefined color names that aren't defined in any
specification, and they are largely natural names that authors would often
use for author-defined colors.

I think the dispute can be described as follows. There are people who
would prefer a simple, natural way of writing style sheets, with as many
features embedded into the style sheet "language" as possible. They wish
to be able to write a style sheet using any editor, without needing to
learn and get any special software. I'm pretty sure that most authors who
use or wish to use CSS fall into that category. Well, they might wish to
use a wysiwyg editor that creates the CSS for them, but they probably
realize that they need to understand the CSS code anyway, and especially
in that case the CSS code must be simple, with e.g. named constants rather
than literals scattered around. The second school of thought, probably the
majority of people on this list, also wants CSS to be simple - to user
agents. I cannot avoid the feeling that such thinking reflects an idea of
CSS as comparable to compiled object code. And surely there's a point
in the note that user agents shouldn't be forced to perform operations
that could have been performed on the authoring (server) side. On the
other hand, CSS has been designed to be human-writeable and human-readable
(it's text/css, not application/css), and this means that a CSS parser
is inevitably complicated and "slow".

Simplest macro expansion features, which mean just string substitution,
wouldn't really add to the complexity of a user agent or slow it down.
(Actually they might speed things up a bit in the sense that CSS files
could be smaller, when declarations could be grouped together and
"invoked" via defined names.) Problems arise if macro parameters are to be
supported. And maybe it would be difficult to resist the idea of adding a
full counterpart to C's #define if you had already added a counterpart
to a simple #define.

> It would have been much
> easier to be able to do something like:
>
>     @alias "brown-1" = "rgb(32%,30%,15%)"
>
> ...or whatever.

Maybe
@define brown-1 { rgb(32%,30%,15%) }

If anything like that will ever be added to CSS, I think it's clear that
it should be a general macro feature, not a separate mechanism for
defining color names. The same issues arise when you wish to use, say,
a certain thickness of a border in different CSS rules, or a specific
combination of properties in different parts of a style sheet. Even if
using a single rule with a long list of selectors could be used in most
cases, it forces into a particular grouping of rules and structuring of a
style sheet - on a per-property basis rather than per-element or per-class
basis.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Monday, 16 June 2003 00:41:42 UTC