Re: [css4-color] @color Custom Color Keywords

On Sun, Sep 19, 2010 at 2:44 PM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> On Fri, Sep 17, 2010 at 3:33 AM, Christoph Päper
>>> Tab Atkins Jr.:
>>>
>>> [Color scoping] is inspired by ‘@page’ which can differ for odd and even
>>
>> @page is a separate processing construct …
>
> Yes. I said “inspired by”, not “copied from”.

What I meant, though, is that @page is *nothing like* this.
@font-face is vaguely similar to other variable mechanisms.  @page
isn't a variable mechanism at all; it's a way to target things that
can't be targeted by selectors.


>>>> I think this should just be addressed via a general Variables mechanism.
>>>
>>> General variables cannot offer the fallback mechanism colors could do. Backwards compatibility is a major concern here.
>>
>> Can you elaborate?  What's the backwards-compat concern?
>
>  color: var(darkred); /* or some such */
>
> will fail (and authors *will* forget or refuse to provide a fallback).
>
>  color: darkred;
>
> on the other hand will work even in most CSS1 browsers (because they supported the stupid X11 names before SVG or CSS did). Now mix foreground and background color and you will much easier get unreadable text with a generic variable mechanism (which cannot use mere keywords).
>
> Of course,
>
>  color: var(CIred);
>
> and
>
>  color: CIred;
>
> will both fail in current UAs.

Reusing existing color keywords is probably a bad idea in general.  It
would be confusing if "color:darkred" meant something in one
stylesheet, and a different thing in another stylesheet.  It's not
expected that that expression can be mutable, like it would be with an
explicit var() value.

And, as you note, this is of very limited utility in the first place.
If you use *appropriate* color variable names (like HeaderColor or
similar, that indicate the use to which the color is put), they fail
in legacy UAs the same as an explicit var() value.


>> I said above that I don't believe colors will be extended much, so fallback isn't much of a concern.
>
> What do you mean by “extend”?

I mean that I don't think new ways to express a <color> value will occur often.


>>> John Daggett today effectively proposed variables for font-specific features
>>
>> Like @font-face, it's defining higher-level objects that then interact with CSS, not just a substitution.
>
> So, how are colors not “higher-level objects” (if they supported scoping as proposed)?

Because colors don't currently have any additional structure to them.
A color is a color; it acts the same everywhere.  A font doesn't - the
same font-name may refer to different faces depending on the value of
other properties.  You're proposing adding additional structure, but
in a way that I think is a bad idea.

~TJ

Received on Monday, 20 September 2010 00:09:08 UTC