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

(re-including www-svg)

On 5/30/02 5:51 PM, "Coises" <Randy@coises.com> wrote:

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

Or even better to let validators distinguish between "correct",
"deprecated", and "incorrect" values for that matter.

The current CSS validator

 http://jigsaw.w3.org/css-validator/validator-uri.html

has a select that allows you to choose the profile to validate your CSS
against: CSS1 or CSS2 or CSS Mobile 1.0.

similarly, the validator could have a checkbox permitting you to
warn/notwarn about deprecated values and properties.

Feedback and recommendations for the validator can be sent to

 www-validator-css@w3.org

Two things I noticed (which I am also sending to the above address
separately):

  1. The validator says it accepts "HTML with CSS or CSS only". Why not SVG
or arbitrary XML for that matter? I suppose I am agreeing with previous
posts.[1][2]

  2. The profile select should also have something like "CSS2 + SVG", and
perhaps "no profile" should validate CSS rules, properties, values as
defined by any W3C specification.


> Deprecation, or even official "non-standardization," doesn't get people to
> stop using something that works,

It may not be the best discouragement, but it does point people in the right
direction, and gets some number of them to stop using deprecated features.
HTML4 is a good example - there are more and more web developers / authors
writing _strict_ HTML4 rather than _transitional_ HTML4.  And for that
matter, some of them have moved on to writing _strict_ XHTML1 as well.


> or to re-write existing pages that work.

Agreed - that does take a bit more effort.

Eventually deprecated features get dropped (e.g. XHTML 1.1 dropped all the
deprecated features of HTML4), and as new user agents are developed to the
new standards, old invalid pages stop working which causes some number of
them to be re-written.


> What *does* get people to change is the invention of easier and/or more
> effective ways to accomplish what they want to do.

Agreed - mostly.  It takes invention and development and some degree of
_deployment_ before people adopt such new ways of accomplishing 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.

It does feel like we have turned the corner on using CSS instead of <FONT>,
as the vast majority of new web content I see seems to use CSS rather than
<FONT>.

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

I won't disagree - having spoken with many web developers about this, and
tried to help with a few suggestions, I recognize the point you are making.
The situation is improving but we have yet to turn the corner on using
semantic markup with CSS layout rather than a mix of TABLE markup/layout.


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

Some folks don't find RGB intuitive, and find (at least some of) the color
names more intuitive.  The addition of HSL colors should help as well, as
its use seems much more intuitive than RGB.  However, HSL colors are far
from being supported in any user agents, whereas the named colors are well
supported (deployed).


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

Agreed - if you see anything in CSS3 color which contradicts this, please
let me know.  The named colors are all specified with precise RGB
equivalents, and thus will be rendered as perceptually equivalent as RGB
colors themselves are.


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

"background-color" is defined in the CSS3 Background module.

 http://www.w3.org/TR/css3-background/

> or "border-top-color"

"border-top-color" is defined in the (yet to be published) CSS3 Border
module.

> and so on?

The CSS working group decided that all other properties which take color
values are better suited to other modules.

> I think because this
> specification isn't defining the color property, but the "<color>" set
> of values.

and color-profile, rendering-intent and opacity etc.

> The "color" property itself surely belongs with the definition
> of font properties (or possibly box properties).

Those possibilities were discussed in the working group, and we decided to
put it in the color module instead for a couple of reasons (off the top of
my head).
 1. the color property not only sets the color of text (stroke and fill
AFAIK), but also the color of the text-decoration, and the default color of
borders.
 2. by name alone it seemed more appropriate to define the 'color' property
in the CSS3 color module rather than any other module.


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

In short - yes.  It will be more fully defined in the CSS3 Values and Units
module:

 http://www.w3.org/TR/css3-values/#attribute

I would expect the next version of that module to provide a more complete
description of "attr(X,<type>)".

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

Unfortunately, until the CSS working group updates the CSS3 Values and Units
module to include the full description of "attr(X,<type>)", any module
requiring that functionality must include it itself in order to go to CR
etc.

I understand and agree with your concern that by putting it CSS3 color we
may miss something more general about it, except for the fact that the
concept of "attr(X,<type>)" has been discussed for at least three years in
the CSS working group, and we have always discussed it in the context of
potentially applying to many different properties and value types.

In any case, hopefully there can be an updated draft of the CSS3 Values and
Units module which should help allay such fears.


> I also don't quite get why the ",color" is needed.

The ",color" indicates that the attribute is to be parsed for a <color>
value, rather than for any arbitrary type of data.  This was necessary to
disambiguate in some situations - and precisely one of the changes we made
to make the syntax work for properties in general rather than just color.

> Perhaps that's meant to
> prevent conflicts with other modules

Other properties/value-types, but yes.

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

Agreed as stated.

> not
> in a specific module

It's only in the specific module for timing reasons.  If the CSS3 Values and
Units module was already a CR (or at least well on its way through Last
Call), we wouldn't need to include in Color.  There are other clients of the
Color module however that cannot wait for Values and Units, and thus it is
included directly in CSS3 Color.

> where the results might interfere with later work.

The CSS WG has gone to great lengths to ensure that the "attr(X,<type>)"
used in the CSS3 Color is the same that is going into the CSS3 Values and
Units module for precisely this reason.


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

Good question - certainly beyond the scope of this discussion.  The CSS3
Color Module used the same reference for sRGB that SVG 1.0 did for
consistency.  If there is a better reference for sRGB, please let us know.


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

Your reasoning and conclusion is the same that the CSS working group has
come to as well, and for that matter we are doing two things:
 1. NOT extending the list of CSS2 System Colors.
 2. adding an "appearance" property to the CSS3 Basic UI module which does
exactly what you have suggested for "system-style".

Glad to see someone independently come to the same conclusion.


> 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]}

Where's Daniel?  Hey Daniel - look - selectors on the right hand side!

> could be expected typically to restore the (user+system) defaults for link
> colors and underlining (though other properties could be affected);

But seriously, I think we decided to use "appearance: hyperlink" for this
functionality.


> this:
>    .inputexample {system-style: input[type=text]}
> would make an element of class "inputexample" mimic the standard appearance
> of a text input field.

I believe we chose something like "appearance: field" for text input fields.


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

A lot - say 210 or more for buttons and other UI elements.  See the current
version of the CSS3 UI module for more info[3].  Note that the added system
colors in the current public CSS3 UI draft are being dropped in the next
version of CSS3 Basic UI due to feedback received on this list (yes, the CSS
working group does listen to feedback on this list) and the fact that we are
replacing them with the "appearance" property which will be much easier to
use and implement and make more sense all around.


> Why not simply leave it to the
> user agent to restore the default appearance, if that's what's wanted?

Yes - keep an eye out for the next draft of CSS3 Basic User Interface,
specifically the "appearance" property which should do exactly what you are
asking for.

Thanks,

Tantek


[1]
 http://lists.w3.org/Archives/Public/www-validator-css/2001Dec/0331.html

[2]
 http://lists.w3.org/Archives/Public/www-validator-css/2002Jan/0472.html

[3]
 http://www.w3.org/TR/css3-userint#color

Received on Thursday, 30 May 2002 22:23:15 UTC