Re: CSS validator bugs

Simetrical wrote:
> 
> Sure it is, from your own link:
> 
> pink #FFC0CB 255,192,203
> http://www.w3.org/TR/2008/WD-css3-color-20080721/#svg-color

I guess I should have stuck at CSS 2.1, and not tried to track down the 
leading edge draft as well.  (Why I misread CSS3, below.) However, on 
the principle that people who don't specify the technology are more 
likely than just statistically, to be using the most common, I think the 
CSS 2.1 reference and profile actually apply to the questioner and what 
they are really saying is that many browsers support colour names that 
are not in the standard.  It seems there was a problem with validator, 
but probably not the one being reported.

This does, however, seem to me to highlight a problem in the structure 
of the whole colour section of the CSS3 document, although, as that 
document is last call it may be too late to do anything.

Basically the structure is:

Keyword scheme
Coordinate scheme
Digression on transparency
Another coordinate scheme
Another keyword scheme.

Particularly for the keyword parts, the ordinary web designer is not 
going to make a distinction between the HTML and X-Windows colours, so 
they should be given in a single section, containing the complete list, 
followed, if necessary, by an informative note that only sixteen of the 
names provide any guarantee of backwards compatibility.

Moreover, these colours are defined in terms of RGB colour syntax, so 
the definition of that syntax should precede the named colours.  HSL as 
another colour space should immediately follow RGBA.  As a special sort 
of keyword, the section on "trasnparent" should follow the other 
keywords.  It probably needs its own subsection, because it is 
sufficiently different, but I think that, for generality, the keyword 
colours should be defined in full RGBA terms, not just RGB ones.

My problem here was that I was primarily responding in terms of the 
current standard, but wanted to include the future standard for 
completeness.  When I looked at it, I saw a set of colour names, then a 
section on numeric colours.  I stopped reading at that point, not 
expecting to find more keywords further down.

I seem to remember that there are two camps on colour.  One of them 
wants a superset of all the colour names used in X, Windows, and 
browsers, and the other says that, once you go beyond a small set of 
colours, the relationship between colour names and colours is rather 
arbitrary, and it is much better to specify the exact colour space 
coordinates.  (The 16 HTML 4 colours use just 4 intensities, so the 
colours are actually set by the coordinates, and then, except for the 
the three primaries, black and white, have had names chosen according to 
colours that approximate the resulting values.)

In my view, it is still unsafe to use all but the core 16 colours, as 
there are browsers locked in silicon that conform to CSS on colours, but 
don't support the de facto extensions.  I have one of them, a Netgem 
digital TV set top box which has been abandoned by its mnanufacturer, 
but is likely to stay in use for the best part of a decade[A].  It is 
not as though one needs to use the colour names, as it is quite happy 
with the RGB values.  (This device also produces an unreadable rendering 
of the CSS3 specification, due to the large number of overprinted and 
overlapped lines - I haven't analyzed the reason for that, but it raises 
accessibility issues.  It has very little difficulty with the HTML 4.01 
specification.)

Another problem with using colour names, although a lost cause here, is 
that there will be names for which the real world meaning of that name 
is not actually representable in the RGB colour space (typically it 
needs negative values).  I'm not certain, but I think brown is a case in 
point.  If someone develops a display technology that can accurately 
reproduce the spectrum of an arbitrary dye, one will end up with a 
future CSS requiring the use of numeric colours to accurately represent 
a colour for which it has a name.

[A] Although given the failure of the web to adopt TB-L's lowest common 
denominator browser model, it will only be usable as a digital TV receiver.
-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Received on Saturday, 5 September 2009 10:38:36 UTC