W3C home > Mailing lists > Public > www-style@w3.org > September 2010

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 20 Sep 2010 08:01:25 -0700
Message-ID: <AANLkTinKaaYz6PoW3yn+Spg9M9MxUAEsDGKKzdWEuwJQ@mail.gmail.com>
To: Christoph Päper <christoph.paeper@crissov.de>
Cc: www-style list <www-style@w3.org>
On Mon, Sep 20, 2010 at 1:34 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> It would be confusing if "color:darkred" meant something in one stylesheet, and a different thing in another stylesheet.
>
> What’s the difference to “font-family: Helvetica” (or “font-family: serif”)?

Expectations, mostly.  We're used to a single font representing
multiple faces, for plain, italics, bold, etc.  I'd suspect that a lot
of authors don't actually know that 'serif' means "use the platform
default serif font" and can change between users, but at least they
know it acts like other fonts and represents multiple faces at once.


>> It's not expected that that expression can be mutable,
>
> It’s expected that ‘darkred’ yields a dark red, not that it actually results in exactly the same color as ‘#8B0000’ or ‘rgb(55%, 0%, 0%)’. Also, expectations change all the time.

The real problem isn't that 'darkred' might yield a slightly different
dark red than the keyword normally provides.  The problem is when
you're using 'darkred' as your header color, then decide to change it
to blue.  You then have to either (a) go through your stylesheets and
change all occurences of the color, in which case why are you using
variables in the first place, or (b) make 'darkred' represent a blue
color, which is very obviously bad.

Reusing the existing color keywords is roughly equivalent to using
".darkred" as a class.  It doesn't carry any meaning, and if your
presentation changes, you have to make a choice like above, where both
options suck.  It's better to avoid the situation entirely with
meaningful names.


>> I mean that I don't think new ways to express a <color> value will occur often.
>
> Sorry, I’m still not sure I understand what you mean. Do you believe color variables won’t be used often or do you believe HSL etc. won’t be used often or do you believe color scoping wouldn’t be used often?

I think new syntaxes for expressing a color won't be used often.
hsl() is already around and supported by several browsers (maybe all
by now?  I dunno).  Variables will cause a 'problem' for *every*
property, so colors aren't special.  I'm still not quite sure what you
mean by 'color scoping' - are you referring to your desire to have one
color keyword mean different colors in different properties?


>> A color is a color; it acts the same everywhere.
>
> ‘currentColor’ and possibly system colors don’t. (Well, it /acts/ the same, but doesn’t /look/ the same everywhere.)

True, those are explicit exceptions.  They don't look like the name of
a color, though, so an author already knows they're somewhat
'different', even if they don't understand anything else about them.
Again, expectations here.

~TJ
Received on Monday, 20 September 2010 15:02:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT