Re: author-defined color aliases

Hi Kynn,
Dear list members,

On Monday 16 June 2003 02:24, Kynn Bartlett wrote:
> > Every time someone always says "just use a preprocessor".
> ...because that's the right solution.
Tell this to the average web designer, he / she, who already has problems 
using HTML / CSS the way they are defined in the specs... ;-)

gcc -E really isn't a solution.
I know to use gcc -E -x c -P in a Makefile like this:

copy: $(patsubst src/%.css, dest/%.css, $(shell find src -name "*.css"))

dest/%.css: src/%.css
	gcc -I src/conf/ -E -x c -P $< >$@

Also you need to use expressive id selectors instead of their short form:
#someid
will be reported as error by any serious C preprocessor I know, so
*#someid
has to be used instead.
(Of course that's not a real problem, just something the author of stylesheets 
that are preprocessed needs to be aware of)
Now it's even possible to use #include, e.g. #include <colors.h>.

But ... try to tell this to the average web designer... Many if not most of 
them already get confused very easily:
"What? XHTML? CSS Selectors? DTD? What the hell are you talking about!".

I think a common solution part of a CSS spec supported by major web browsers 
(in a few years - er decades <g> ... how long will it take the vendors to 
properly implement CSS Level 1 and 2?) is far more appropriate for these than 
a C preprocessor.


> 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 is such a standard and it's called XSLT.  It is not only for generating 
HTML, but it is, amongst other tasks, for generating HTML. <xsl:output 
method="html"/> :-)
And that's what I mainly use it for. Today, >50% of all web pages I create are 
created using XSLT. (The rest are either hand made examples for courses or 
generated by javadoc or doxygen)

I think XSLT is a very convenient and fitting tool for creating web pages, 
especially if it's more than 3 and a content management system is not wanted 
or required or whatsoever.

> > * 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 think there really is demand for that. I also have demand for color and font 
name aliasing.

I didn't come up with name alias definitions on this list yet because I think 
there are more important topics to solve, e.g. graphical borders (which 
already are addressed perfectly fine in CSS 3, I think) or maybe a 
homogenisation between XPath and CSS Selectors. And because I know how to use 
a preprocessor and at least for my environment, the problem is solved.

Still I sympathise with those complaining about "use a preprocessor" isn't a 
satisfactory answer because though I know how to use a preprocessor I agree 
with them in the point that a standard for CSS about that issue would be more 
convenient to use.

> > 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.
Oh.
So, why don't we just use plain machine language then?
Readable code isn't only a benefit to the developer, it's also a benefit to 
users and customers.
customers profit because readable code is easier to write and maintain, so the 
quality and the price benefit, and that again is a benefit for the end user.

> 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.
I absolutely disagree. Similar situation. The user will never see wether a 
variable in Java has been declared private or public. So why add access 
limiters to a programming language like public / protected / - / private in 
Java? Just for programmer's convenience, yes. Why not program in machine 
language, anyway ;-)

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

And if I host my page on a cheap web hoster who doesn't give me the 
capabilities to do so?

Using a C preprocessor or doing some server side processing will solve the 
problems, but they are isolated applications and as such they address the 
effect of the problem, not the root. I understand those demanding general 
implementation as part of CSS.

> 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.
Oh, but CSS is full of processing burden passed on to the end users. The whole 
cascade is a processing burden passed on to the end users... :-D

So I a sort of "value aliasing", which should extent to cover more than just 
font name and color name aliasing, currently has my vote.


Greetings
--
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/