Re: author-defined color aliases

Well Kynn, I'm sorry your response could only be taken slightly 
seriously due to the manner in which you gave your arguments.

Childishness aside, I think that CSS aliases are a great idea.  The 
demand is probably higher than we know.  Not every person in the world 
who would want such a feature posts it to this mailing list, let alone 
know such a mailing list exists.  We can't judge this as some kind of 
universal voting booth.  I was wanting to raise the idea as well, but I 
hadn't made time yet.

Now, it's my understanding that any language (should we call CSS a 
language) has syntax-readability as one of its goals.  Even your 
preprocessor "solution" probably has such a feature.  PHP?  It would 
look like this:
<?php define(kThisIsAColor,'red'); ?>

Then you'd scatter "kThisIsAColor" throughout your code instead of 
typing "red".  Most languages (C, C++, Pascal, BASIC, etc) have a 
similar functionality.  Seems reasonable to change something in one 
spot instead of a few dozen or so.  Which leads to a way for the 
feature to benefit the end users.

Perhaps you want to provide different color schemes for the visually 
impaired, or perhaps just for aesthetics.  You don't wanna change the 
whole stylesheet.  Just the colors.  So you'd keep your color alias 
definitions separate from the main CSS, and you'd just change that, 
probably through @import or a <link> element.  Saves bandwidth, too.

Your alias names would ideally not represent actual colors so much as 
what the colors are for.  Keep it generic.  For example, aliases would 
be named "baseColor", "highlightColor", "accentColor", etc, as needed.

I think that's reasonably beneficial to both the end user and the 
styler.

-----
Irony is a volunteer survey with required fields.
	~ Dris ~
Random Signature 16

Received on Sunday, 15 June 2003 23:23:32 UTC