Re: author-defined color aliases

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Ernest,
Dear list members,


On Saturday 21 June 2003 10:55, Ernest Cline wrote:
> The main reasons for not allowing defined aliases are as follows:
> 1) The use of aliases adds complexity to the parsing of CSS.
<ironic>Uh yeah. And CSS already is complex, ... phew!</ironic>
Sorry, imho that's not a valid argument ;-)

> 2) The use of a preprocessor or an equivalent can get the job done.
The generalisation of this argument would be valid against most improvements 
and enhancements. The basic job is "sing, f***, and have fun" (oh, and eat 
and drink and breath, of course, but that's it so far), so why're we talking 
about CSS anyway...
Just because there already is something that get's the job done, I won't stop 
searching solutions that get the job done better, faster, cheaper, more 
convenient, more maintainable, more compatible, more interoperable, more 
common...
So sorry, imho 2) also is not a valid argument ;-)

But:
> 3) The use of aliases causes problems with backwards compatability.
Reason 3 could be, or more, it *is* a problem.
Even, imho, this is the *most important* argument against color aliases I've 
read so far.
To resemble some example Jukka gave:
@define mypink { #ff4488 }
html {
    color:mypink;
    background-color:black;
}
Ups... this will be black on black in nearly all UA's that don't know how to 
handle color aliases and use a default stylesheet with black foreground 
color.
All solutions for that come to my mind would
- - either require changing existing UAs... so that's not really solutions...
- - or add so much complexity that the values of author-defined color aliases 
lapse.

There we see, a) demanding a feature is one thing.
b) Writing a convenient viable spec fitting the needs of the world is a 
completely different thing.

Luckily most of us belong to group a) ;-)


> 4) The use of aliases leads to unavoidable conflicts between author and
> and user stylesheets in those user agents which do support aliases.
Afaik this is solvable / already solved.

User stylesheets are applied first. So if only user stylesheets are applied, 
there's no problem.
Author stylesheets are applied second. If there are no user stylesheets, 
there's no problem, too.

If there are both, user stylesheets, and author stylesheets, several 
situations can occur:
1. user stylesheets and author stylesheets don't use the same color names. No 
problem.
2. user stylesheets and author stylesheets use the same color names. Conflict 
resolution is done by automatically first parsing the user stylesheet, 
building the cascade, then parsing the author stylesheet and extending the 
cascade. Color aliases should be applied by replacing the alias with its 
value (similar to #define in C). Then this won't be a problem.
3. author stylesheets use color aliases that aren't defined in the author 
stylesheet. That's the author's problem, this leads to undefined behaviour.

As far as I see it, this isn't really a problem.


>  Anyone with the
> knowledge of the advantages of aliases and the need for their use is
> surely going to have access to some tool that will do preprocessing and
> know how to use it since it is hardly the most demading of concepts.
No. Several web designers know CSS quite well, but don't even know that 
preprocessors exist or what they are, not talking about how to handle them.

I'm still pro author-defined color aliases, but really, you made me doubt 
about them. Especially the backwards compatibility argument is important. 
Without solving that issue, a @define will be really hard to implement.

But what I want to repeat: If there's a need to break with compatibility, the 
best moment to do so is right now, since XHTML 2 breaks compatibility with 
XHTML, too. It's not clear when there will be another chance like this...

By the way, the backwards compatibility issue could be solved by using a 
version parameter for the text/css MIME type, perhaps. Just an idea, but 
don't think I'd defend it in a discussion.


Bye

P.S.:
For those interested, I have put a little "how to preprocess CSS" on the web.
It can be found at <http://www.hujer.com/www/csspreprocessing>.
If you're interested in preprocessing CSS and didn't know how to, be sure to 
check it.
- --
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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE+9gd1zu6h7O/MKZkRAraUAJ4qpf/uPoYIwfsOuOkjVl2Ieh4KTQCfVAHv
5y2ZruGGzE5I0epY7Aety50=
=IQs0
-----END PGP SIGNATURE-----

Received on Monday, 23 June 2003 04:01:25 UTC