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

On Friday 2002-05-10 20:36 -0700, Etan Wexler wrote:
> Chris Lilley responded to me:
> > 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'.

One reason that the computed value should be the keyword itself is that
on some systems, system "colors" aren't really as simple as colors -- a
colored border may have multiple layers, a colored background may really
be a gradient, and the colors for the concepts described by system
colors may vary between widgets (in different ways on different systems
that would be too difficult to fully capture in a list of system color
keywords).  Specifying that system colors have the keyword as the
computed value allows implementations to innovate here and come up with
good solutions, whereas requiring that system colors have a computed
value that is a color value would forbid such innovation.  (I think the
UI module is an area where we want innovation---consistency between
implementations is already impossible since these values are already
explicitly system-specific.)

Making the computed value be the system color keyword also solves the
issue that a color computed value for a system color would involve
inverse gamma-correction.  This means that it may be quite difficult to
ensure that round-tripping such computed values through the DOM is not
lossy.  Even if the rgb() notation is used for the color values, there
would still be some problems dealing with systems where the gamma
function is defined as a ramp, i.e., by giving all 256 or 768 values,
although I think they could be solved in a rather hacky way by making
the reported computed values slightly incorrect.  I think it's
impossible to do both lossless round-tripping and exactly correct color
computed values given such a gamma API.

-David

-- 
L. David Baron        <URL: http://www.people.fas.harvard.edu/~dbaron/ >

Received on Saturday, 11 May 2002 00:54:26 UTC