Re: Color module comments (WD-css3-color-20020418)

Chris Lilley responded to me:

> esc> "CSS3 adds numerical Hue Saturation Lightness (HSL)"
> 
> esc> Change to "CSS3 adds numerical hue-saturation-lightness (HSL)".
> 
> It is written like that to introduce the acronym HSL, and also to
> indicate that subsequent mentions of Hue refer to the definition from
> HSL rather than (for example) the definitions of hue from Munsell or
> CIE or whatever.

This was unclear to me and, I suspect, to some others.  I invite people to 
comment on their understanding or lack thereof.  I also suggest a note in 
the prose that Hue, Saturation, and Lightness here carry particular, 
technical meanings that differ from their other common meanings.  A 
normative reference would be nice.

> esc> "100% is full saturation, and 0% is a shade of grey. 0% lightness is 
> esc> black, 100% lightness is white, and 50% lightness is 'normal' "
> [...]
> 
> [...] perhaps "normal" is not so clear[...]

I found the wording clear: fifty percent lightness achieves a color that 
people would not be inclined to qualify as "light" or "dark".

> esc> "The computed value of a System Color keyword value is the keyword 
> esc> itself."
> 
> esc> Why is this?
> 
> So that what is inherited means something, and so that DOM calls get
> useful information. The actual RGB values will vary according to OS
> and user preference.

I fail to understand how an inherited keyword is more useful than an 
inherited RGB triplet.  Nevertheless, if we need to inherit keywords, we 
can specify that system color keywords inherit from specified values, not 
from computed values.  Certainly the mapping of system color keywords 
to RGB values will vary between platforms, but so does the mapping of 
font size keywords to physical sizes.  That does not mean that a 
specified 'font-size' value of 'medium' computes to the keyword 
'medium'.

> [...] the term camel  case should still be introduced, I feel.

I am apathetic about the term, so go ahead if it makes you feel good.

> esc> Change to "When setting a background image or background color, set 
> esc> the text color in the same rule set and at the same weight (e.g., 
> esc> '!important').  When setting a text color, set the background in the same 
> esc> rule set and at the same weight."
> 
> I agree that is more precise, though it is perhaps too prescriptive.

Indeed, one private respondent took my wording as a normative 
regulation, which is not what I meant to write.  I any case, I am 
rethinking the utility of adding such a note.  I suspect that most of the 
people who make the foreground/background mismatch mistake do not 
read W3C specifications.

> esc> [...] A CSS1 implementation written at this time could 
> esc> legitimately incorporate the [CSS2/CSS3 color] keywords
> esc> and offer the associated functionality. [...] It would 
> esc> be best to move those four items out of "Excludes" and into a note.
> 
> Hmm, good point. Do we really want to propagate the vagueness of this
> point of the specification, however? I guess it depends on whether the
> CSS1 profile is supposed to represent what CSS1 specified the meaning
> of, or what it syntactically allowed.

Would we say that CSS1 excludes images just because it is not explicit 
about how to include images?  No, and likewise CSS1 does not exclude 
any keyword color value.  Rather than propagate the vagueness in 
CSS1, the Color module should encourage new CSS1 implementations 
to adopt the color keyword semantics given in later specifications.

-- 
Etan Wexler <mailto:ewexler@stickdog.com>

Received on Friday, 10 May 2002 23:50:32 UTC