Re: author-defined color aliases

On Sunday, June 15, 2003, at 04:30 PM, Andrew Thompson wrote:
> On Sunday, Jun 15, 2003, at 15:00 America/New_York, David Dorward 
> wrote:
>> HTML doesn't have them either, but people don't complain about that
>> too much. The solution for CSS is the same as for HTML - generate the
>> CSS programmatically (I'd use a preprocessor, others might prefer CGI
>> or another server side process, client side JavaScript might also be a
>> possibility)

For the record, David's response, quoted above, is 100% on target, in my
opinion.

> 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.

> Every time someone always says "just use a preprocessor".

...because that's the right solution.

> So I'll respond the usual way too:
>
> * 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.

> * Web designers are not programmers. They have *no* idea what a 
> preprocessor is. gcc -E is not an acceptable option

Why isn't it?

> * One could try convincing Adobe and/or Macromedia to develop a 
> de-facto standard for a preprocessor and then once it works, work to 
> standardize that

Why this obsession with a standard for how to generate standard stuff?  
The
standard is CSS.  How you create it is up to the individual tool 
developers.
It would actually hurt the development of such a tool to prematurely 
decide
on such a "standard" before the industry decides to create such a thing.

> * There's been no indication of any movement in the tool vendor or web 
> design communities that they want to use or develop pre-processing as 
> a solution

Hey, that's provably wrong.  Look at MovableType, for example, which 
uses
templates and tags to create Web sites.  It's entirely pre-processed, 
and
the style sheet is one of the things that is generated by the server.

You could very easily create <MTStyle*> tag plugins and fit them into 
the
style sheet templates.

> * 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.

> * 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.

> 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.

> Introducing classes with no semantic meaning purely to achieve "fake" 
> variables is a poor workaround at best

Right, so don't do that.

> * 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?

Here, do this:

1.  Write all your color names as MyColor(foreground) or whatever.
2.  Write a sed script to translate MyColor(foreground) into color
     codes or names.
3.  Run your style sheet through the script before placing it on your
     Web site.
4.  Make this script available to the general public so there aren't
     complaints that "we're not programmers, we couldn't possibly
     think about something as complex as s/foo/bar/g!"
5.  ???
6.  Profit!

> 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.

The only valid reason for adding something to the CSS spec is if it
will be used by the end user's user agent.  If it won't -- then it's
a problem that needs to be solved in the development environment.

 From a simple reasonableness argument:  We're talking about doing
find-replace operations to turn one string constant into another
string constant.  You can do it on the server, and it has to be done
once, ever, until the style sheet is updated again.

Or you can do it on every single browser that accesses a site, every
single time that style sheet is parsed.

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.

> AndyT (lordpixel - the cat who walks through walls)
> A little bigger on the inside
>
>         (see you later space cowboy ...)
>
>
>
--
Kynn Bartlett <kynn@idyllmtn.com>                     http://kynn.com
Chief Technologist, Idyll Mountain                http://idyllmtn.com
Author, CSS in 24 Hours                       http://cssin24hours.com
Inland Anti-Empire Blog                      http://blog.kynn.com/iae
Shock & Awe Blog                           http://blog.kynn.com/shock

Received on Sunday, 15 June 2003 20:19:01 UTC