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: Fri, 17 Sep 2010 07:55:36 -0700
Message-ID: <AANLkTikT98nFRtZKSLHgHSmj5=7YM1gEo8OVpJQD3iO1@mail.gmail.com>
To: Christoph Päper <christoph.paeper@crissov.de>
Cc: "www-style@w3.org list" <www-style@w3.org>
On Fri, Sep 17, 2010 at 3:33 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> A context-sensitive "color" seems pretty weird to me.  It's odd that attempting to use a particular "color" for color and background-color would give different results.
>
> This is inspired by ‘@page’ which can differ for odd and even (or left and right) pages. It may seem odd at first and you would probably not use very different colors, but just change saturation for instance. I believe it could become very handy in some situations. It’s not a vital part of the proposal, though.

But this is nothing like @page.  @page is a separate processing
construct that targets "pages", something which doesn't exist in
vanilla CSS, and is completely unrelated to variables (in essence,
@page is a specialized selector with some magical behavior - normal
selectors can't do the job because pages don't exist in the
element-tree).  One doesn't use a single defined page in different
places with different results, one defines different pages.


>> I think this should just be addressed via a general Variables mechanism.
>> I don't see much reason to special-case color variables.
>
> 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?  I said above
that I don't believe colors will be extended much, so fallback isn't
much of a concern.

> John Daggett today effectively proposed variables for font-specific features:  <http://lists.w3.org/Archives/Public/www-style/2010Sep/0473.html>. Maybe custom at-rules for each type of variable are the most CSS-like way to do it. They should follow a common pattern, though: ‘@page’ and ‘@font-face’ already differ. (That’s why I wrote <http://lists.w3.org/Archives/Public/www-style/2010Sep/0331.html> this week and had three syntax variants in the initial post of this thread.)

Nah, that has special constraints too.  Like @font-face, it's defining
higher-level objects that then interact with CSS, not just a
substitution.

~TJ
Received on Friday, 17 September 2010 14:56:34 GMT

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