W3C home > Mailing lists > Public > www-style@w3.org > May 2002

Re: X11 Colors (was Last call comments on CSS3 module: color)

From: Coises <Randy@coises.com>
Date: Thu, 30 May 2002 17:51:38 -0700
To: www-style@w3.org
Message-ID: <f1ddfuo1ocmq6n9sk73fb90vv1bnneshti@4ax.com>

[Thu, 30 May 2002 10:42:40 -0400 (EDT)] Jon Ferraiolo:

>So, it might be good to look at strategies that are most likely bring 
>discussion to a close as quickly as possible, such as "just accept what SVG 
>1.0 did" or "deprecate all color keywords everywhere". Defining new color 
>keywords seems likely to produce the longest possible discussion.

For whatever they're worth, here are the (possibly quite na´ve) comments
of someone not particularly versed in perceptual theory regarding the
discussion of the <http://www.w3.org/TR/2002/WD-css3-color-20020418
working draft and color names and designations:

This seems to me to be "much ado about nothing" --- for the most part:

1. If the X11 colors are already in common use, it's going to make little
difference whether they're formally included, omitted or deprecated:
practical user agents are still going to have to support them.  The major
difference would be whether validators flag them or not --- I'd say it's
better to let the validators distinguish "correct" color names from errors
than to lead authors to ignore all validator messages about color names.

Deprecation, or even official "non-standardization," doesn't get people to
stop using something that works, or to re-write existing pages that work.
What *does* get people to change is the invention of easier and/or more
effective ways to accomplish what they want to do.  Folks are using styles
to define font properties, because they're more comprehensive and easier
to manage than a tag-soup of repetitive <FONT> elements.  Folks are still
using tables for layout, though, because they *work* (no matter how much
they're frowned upon) --- while getting a complex CSS-based layout
to display appropriately with different browsers, window sizes and users'
font settings is an exercise in hair-pulling.

2. I fail to see the great advantage of color names.  Regardless of what
system is used for designating colors, I'm not going to know what the page
I'm designing looks like until I look at it!  RGB may not be entirely
natural, but it's not exactly difficult to grasp, either.  It never seems
to take me that long to "tweak" a #rrggbb value to get the color I want ---
and, of course, authoring tools will provide "color pickers" no matter what
system is used.  Also, color names can't be "tweaked"; so unless a naming
scheme that includes (or generates) 2^24 color names is invented, it will
always be necessary to abandon the names and use a numeric system to
specify a desired color precisely anyway.

3. What *does* matter is that whatever method is used produces "the same"
colors (meaning, I suppose, perceptually equivalent results, within the
tolerance of the devices and environments in question) on all devices.  The
limitations of my knowledge don't allow me to guess whether any system is
any more or less able to accomplish this than any other, or if that problem
lies totally outside the scope of behaviors CSS can hope to define.  If CSS
has any bearing on this, though, then I'd say adopting a specification that
maximizes cross-platform and cross-environment fidelity to the colors
originally chosen by the designer is infinitely more important than how
"friendly" the system of specification appears at first glance.

There are a few specifics about this working draft that bother me:

4. Why is there a definition of the "color" property, but not of
"background-color" or "border-top-color" and so on?  I think because this
specification isn't defining the color property, but the "<color>" set
of values.  The "color" property itself surely belongs with the definition
of font properties (or possibly box properties).

5. What's with "attr(X,color)"?  The concept seems useful --- an extension
of the way "attr" is used in the "content" property --- but is this the
place to define it?  Shouldn't this be a matter of general syntax: allowing
some variant of "attr(X)" in any property to derive the specified value of
the property from the corresponding attribute?  It strikes me like a bad
idea to incorporate this concept here, where some detail might turn out to
interfere with a better way of implementing the idea across all properties.

I also don't quite get why the ",color" is needed.  Perhaps that's meant to
prevent conflicts with other modules --- but again, it seems to me a
concept like this that has "cross-module" applicability should be defined
in some general module that can consider the effect on all properties, not
in a specific module where the results might interfere with later work.

6. The "color-profile" and "rendering-intent" and "@color-profile" material
is all terribly obscure to a novice such as myself.  From a direct reading
of this specification, I have no idea what these things are all about.

Particularly odious is that the effective *default* value of color-profile,
sRGB, is apparently defined in a specification that is not available on the
free web, and can only be accessed by paying a fee to a third party!  Is
this really acceptable for a W3C standard?

7. The system colors seem to me to be unnecessarily confusing.  If I want
to make, say, a button "look like" buttons normally look on users' systems,
why not have a single style rule, such as:
     button  {system-style: button}
that (re-)sets all colors, borders, fonts, sizes, etc. to the current
system standard appearance?  Details could still be overridden by later or
higher-specificity style rules.

The same concept could be used to return other properties to the values
that would be derived from the user style sheet and the user agent default
style sheet alone, or to apply them to other elements; e.g.:
     a[href] {system-style: a[href]}
could be expected typically to restore the (user+system) defaults for link
colors and underlining (though other properties could be affected); this:
     .inputexample {system-style: input[type=text]}
would make an element of class "inputexample" mimic the standard appearance
of a text input field.

It just seems to me very unlikely that anyone would want to apply
individual system colors, apart from the other colors and style elements
that apply to the same controls.  How many colors, border widths, etc.
would it take to "mimic" a standard button?  Why not simply leave it to the
user agent to restore the default appearance, if that's what's wanted?

Randall Joseph Fellmy aka Randy@Coises.com
Received on Thursday, 30 May 2002 20:51:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:02 UTC