Re: author-defined color aliases

At 17:24 -0700 6/15/03, Kynn Bartlett wrote:

>On Sunday, June 15, 2003, at 04:30 PM, Andrew Thompson wrote:
>
>>  This subject has come up about every 18 months since this I've 
>>been on this list, which has been quite a while now.
>
>And it gets shot down, because it's not a useful idea.

    Perhaps not in your world.  I personally think it is a useful 
idea, and I wish CSS had something like it already.

>>  Every time someone 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? 
There are many situations where this is the case: think universities, 
large corporate environments, and similar setups.
    Then there are those without the skills, or the interest, to 
install and run a preprocessor.  I fit into that category, as it 
happens.

>>  * If a pre processor is the solution, then the Working Group needs 
>>to define a standard for one and get someone to implement it
>
>Why does the working group need to do this?  There's no standard defined
>for generating HTML, either, and it's not up to the HTML Working Group
>to get someone to implement it.

    There I agree: there's no reason for the W3C to define a "standard 
pre-processor."  Then again, I think aliases are a good idea, so I 
probably I don't know what I'm talking about, eh?

>>  * Web designers are not programmers. They have *no* idea what a 
>>preprocessor is. gcc -E is not an acceptable option
>
>Why isn't it?

    What does it do?  Do I have gcc on my Macintosh Web server?  Does 
Geocities provide it?  And so on.  (And no, I have no idea what 'gcc 
-E' does.  As far as I'm concerned, I shouldn't have to know.)

>>  * Until there's a standard ("official" or de-facto), any solution 
>>one design shop uses won't be used at the next. That's a 
>>non-transferable job skill and thus not very attractive for your 
>>average web designer
>
>You know, a nice sed script is not all that hard to put together, and if a
>sed script doesn't transfer nicely to your next job, you're in the wrong
>line of work.

    What's sed?  Okay, I vaguely know the answer to that one, but a 
lot of authors and designers don't.  And, again, shouldn't have to 
know.

>>  * Demand for font and color name aliasing isn't going away.
>
>Let's see, it shows up once every eighteen months.  Oh no!  That's clearly in
>GREAT DEMAND!
>
>Please.

    I suspect it only comes up that often because whenever it does, 
somebody goes to great effort to belittle and ridicule whoever 
brought it up.  Kind of puts a damper on the flow of ideas.

>>  Most people seem to think it would lead to more readable and more 
>>logically specified stylesheets.
>
>...which is a benefit only to the developer, and it's a benefit only because
>the developer isn't working in a sensible development environment.

    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.
    Of course, one can simply wave this away as "Eric should get a 
better development environment," but I don't accept that line of 
argument.  Not because my environment is perfect-- it isn't-- but 
because it's too much of a dodge.  It's basically saying, "If you 
don't like the limitations, hack your way around them instead of 
looking for ways to reduce or eliminate those limitations."  Every 
new idea could be deflected in that manner, and thus stifle any 
forward movement.

>>  * Javascript and server side generation have their uses, but they 
>>suffer from the same drawbacks or worse in many cases of actual use.
>
>What's the drawback?  That some author might not be able to specify colors
>easily?

    Well-- yes.  It turns out that CSS is a technology used by 
authors, strangely enough.  So making their lives easier is always 
something that should be seriously considered, as opposed to just 
dismissing convenience as if it were a silly idea that only children 
might desire.

>>  David: I'm not really replying directly to your comments, you just 
>>happened to be the latest person to state a position that's been 
>>discussed at length in the past. The discussion refuses to die 
>>because - I believe - there's a real unsatisfied need for some kind 
>>of aliasing facility that's never been addressed.
>
>It's unaddressed because it's easily recognized by most nearly anyone
>to be a pointless matter.  There's no need, apart from developer
>convenience, for such a system.  The end user in no way needs to know
>that you consider "light green" to be #33CC55 or whatever.

    No, the end user doesn't.  The end user also doesn't need to know 
that a color has been represented as rgb(50%,20%,80%) instead of 
#8033CC, so should we get rid of the former?  Of course not.  All of 
CSS is predicated, to at least a large degree, on developer 
convenience.  If we wanted to make things harder for developers, we 
would have just stuck with HTML-based presentation.  Or left out 
@import and the ability to link stylesheets, so that the CSS had to 
be embedded in the 'head' of every document.  After all, that's an 
insertion method the server could easily handle-- why force the end 
user's browser to open another network connection to get a separate 
stylesheet?  Such things are only for author convenience anyway, 
right?  Obviously they're useless.

>Now, which makes more sense to you?  If you said "oh, make it easy for
>the poor developers who are DEMANDING this every year and a half!"
>then you've gotta get your developer-centric head out of your
>developer-centric butt -- there's absolutely no justification for
>passing this processing burden on to the end users.

    It looks to me like there's more than one recto-cranial extraction 
that needs to be performed here.  Andrew made some perfectly 
reasonable points in an adult manner.  Your abuse is less than 
justified-- it's juvenile.

--
Eric A. Meyer  (eric@meyerweb.com)  http://www.meyerweb.com/eric/
Author, "Cascading Style Sheets: The Definitive Guide,"
  "Eric Meyer on CSS," "CSS 2.0 Programmer's Reference," and more
   http://www.meyerweb.com/eric/books/

Received on Sunday, 15 June 2003 21:45:15 UTC