Re: author-defined color aliases

On Sun, Jun 15, 2003 at 09:45:11 -0400, Eric A. Meyer wrote:

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

Preprocessing doesn't have to occur on the webserver unless you need
it "on demand". Running the preprocessor on the developer's
workstation is satisfactory in most cases (or possibly even the better
solution, as static files are easier to handle cache control headers
for).

>    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 CSS was to gain some form of support for variables you would have
to learn the new syntax. What's the big issue about learning the
syntax of a preprocessor?
 
> >> * 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?  

From the GCC manual:

       -E     Stop after the preprocessing stage; do not run the compiler
              proper.  The output is preprocessed source code, which
              is sent to the standard output.


> Do I have gcc on my Macintosh Web server?

Maybe, if its probably installable (gcc is available for Mac OSX)

> Does Geocities provide it?

I very much doubt it

>  And so on.

As I said - the _server_ doesn't need to support
preprocessing. Preprocessing can take place at any stage between the
author writing and input file and the webserver sending output to a
client.

>  (And no, I have no idea what 'gcc -E' does.  As far as I'm
> concerned, I shouldn't have to know.)

Why not? Do you think that users shouldn't have to know what any piece
of software on their system does to be able to use it?

>    What's sed? 

Stream editor. It does pattern matching and edits incoming data based
on parameters.

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

The colours would have to be translated in to colours the browser can
recognise at some stage. There are three places this could be done:

(1) Once before the webserver reads the file
(2) By the server every time it reads the file
(3) By the client every time it reads the file (which means throwing
    away backwards compatibility)

Which is the more efficient?

> 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

Which is where the development environment comes in. Learning how to
use a preprocessor (such as the aforementioned gcc) doesn't take
long. Its rather basic syntax. Then a good editor can be configured to
run a macro when css files are saved, so you don't even need to
explicitly run it every time.

It takes a little initial effort, but then the process becomes
invisible.

If the JavaScript or server side scripting options are taken, again it
mearly requires a little initial set up time.

-- 
David Dorward                                     http://david.us-lot.org/
         Redesign in progress: http://stone.thecoreworlds.net/
  Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/2003/5/30/microsoft-announces-ie-is-dead

Received on Monday, 16 June 2003 08:06:22 UTC