Re: author-defined color aliases

Herr Christian Wolfgang Hujer wrote:

> 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 ;-)

I take the opposite viewpoint, namely that just because something is 
already complicated, does not mean that making things more complicated 
won't make things worse.

> > 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 ;-)

Argument 2) was not intended to stand on its own, however it does mean 
that any proposal for adding onto CSS that can be done by other means 
must show that it can get the job done "better, faster, cheaper, more 
convenient, more maintainable, more compatible, more interoperable, 
more common...".  So far I haven't seen an alias proposal that does 
that IMO.

> But:
> > 3) The use of aliases causes problems with backwards compatability.
> Reason 3 could be, or more, it *is* a problem.
<snip class="example">
> 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.
<snip class="humor">

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

Actually there are five layers of CSS rules:
Layer 1: User agent default values (may or may not be expressed as CSS)
Layer 2: User stylesheet regular rules
Layer 3: Author stylesheet regular rules
Layer 4: Author stylesheet !important rules
Layer 5: User styleshhet !important rules

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

To fit in with current CSS parsing, this would require an @rule similar 
to the @media rule like the following:  

@define foo #e5e5e5 bar #050505 {
  .yahoo       (background-color:foo;   color:bar}
  .houyhnhnm   (background-color:bar;   color:foo}
  .lilliputian {background-color:green; color:foo}
}

This would also solve the problem with backward compatibility in a 
strict technical sense, since user agents that don't understand the 
@define rule would skip the entirety of these rules. In a practical 
sense tho, this would entail much more work on the part of web document 
authors to support user agents that don't implement @define than would 
be required for them to use some sort of pre-processor.

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

If they don't know or can't handle using "find and replace" with a text 
editor which I suggested in my original post was the simplest form of 
pre-processing that they could use, then they need to learn more about 
how to use the tools they already have in my opinion.

Received on Wednesday, 25 June 2003 16:40:21 UTC