W3C home > Mailing lists > Public > www-style@w3.org > June 2003

Re: author-defined color aliases

From: Terje Bless <link@pobox.com>
Date: Mon, 16 Jun 2003 06:03:26 +0200
Message-ID: <003701c333bd$643d2470$74429dc1@rito.no>
To: "www style" <www-style@w3.org>

"Eric A. Meyer" <eric@meyerweb.com> wrote:

>Kynn Bartlett wrote:
>>>[S]omeone always says "just use a preprocessor".
>>...because that's the right solution.
>    Even for people who don't have shell access to their own servers,
>or are not permitted to run scripts, and so can't use a preprocessor?

No, these people use the facilities built into their text editor to
preprocess their CSS; like BBEdit which will let you insert colors in
CSS by way of a Color Picker widget, a persistant include, or any number
of other ways.

I don't think there is any need to speculate on user scenarios or "the
user will surely..." in this issue; it should be sufficient to argue it
on the merits. It is clear that there is no absolute necessity for this
facility so it remains to imagine what possibilities it would provide
and whether those are worth the presumed cost of implementation.

>Do I have gcc on my Macintosh Web server?

Yes, actually, you do. :-)

>     In the process of doing recent redesigns for meyerweb.com, I found
> several situations where defined aliases would have been very nice,
> and made my CSS both more compact and nicer to read.  For example, in
> one of the themes ("Mondrian") I re-use the same shade of brown for
> several element borders and foregrounds.  It would have been much
> easier to be able to do something like:
>     @alias "brown-1" = "rgb(32%,30%,15%)"
> ...or whatever.  Instead, I ended up writing some largish grouped
> selectors, which made it harder to make and track changes.

Which, if you're paying attention, is remarkably similar to the reasoning
behind variables in programming languages. It's a convenient level of
abstraction and encapsulation for both the reader and writer of the code
in question (well, and other things, but those are the ones relevant to
the discussion at hand).

It does make the parsing more complex for browsers, but I hardly think
prohibitively so; and certainly not to such a degree that it outweighs
the immediate benefits in terms of more robust "code". The biggest
drawback I can see is that it may interact poorly with the cascade and
CSS' inheritance model when it encounters the real world.

In other words, I think this is a splendid idea and should like to see it
made even a general facility in CSS, so that I shan't have to keep setting
the margin-right of every block box to match the width of my float:right
navigation menu[0]. :-)

[0] - To conveniently lump example and counterexample into one. :-)

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:07 UTC