Re: css validator issues 2344 and 2421 (color, no background-color and transparent)

Hi Peter,

I'm responding to that part of your mail in the mailing-list too, and  
copying Bert Bos, who you probably know as the W3C's staff contact on  
all things CSS.

On Jul 13, 2006, at 19:28 , Peter Zhelezniakov wrote:
> I'm currently looking into Validator bug #2344 and come up with a
> question. There is a warning if for a selector a color is defined  
> but no
> background-color. Why is this warning?

This has indeed been discussed in several occasions, notably in [1],  
and I think you can find quite a few threads on the topic in the CSS  
validator's mailing-list [2].


> I think this is a common case when background is defined once for the
> whole document (e.g. for <body>), and background for other page  
> elements
> is left transparent by default. Is this not recommended? Are we
> motivating CSS authors to always define both color and background- 
> color?

I think you've touched the crux of the matter here indeed. As you  
certainly have guessed, the warning here does not come from the CSS  
specification itself (or at least, not as far as I know) but is  
present for accessibility reasons, to avoid cascading situations when  
the text color becomes the same, or too close to, the background  
color. But indeed, I'm leaning toward the side of people who find it  
annoying that the validator would throw warnings when I use  
background: transparent or no background-color with a color, *because  
I know what I'm doing*.

I suspect that our parser is not smart enough (I actually had a  
discussion with Yves telling me the other day that one of the things  
that would be good to re-write is the passing of context), but I  
would like to see:

* warnings when color and background-color within a specific context  
are too close (in luminance or chrominance)
right now the following does raise a warning:
p { color: #ffffff; background-color: #ffffff; }
but not the following
p { color: #ffffff; background-color: #fffffe; }

* much smarter cascading engine. See for instance the rather "simple"  
following case:

p { color: #ffffff; background-color: #000000; }
p.thatsok { color: #ae12FF }
p.thatsnot { color: #000000 }

The warnings issued are

     * Line : 2 (Level : 1) You have no background-color with your  
color : p.thatsok
	-> there should perhaps NOT be a warning
     * Line : 3 (Level : 1) You have no background-color with your  
color : p.thatsnot
	-> this is not necessary since we have the warning below
     * Line : 3 (Level : 1) Same colors for color and background- 
color in two contexts p and p.thatsnot
	-> THIS is good

So far our parser is fairly clever. That's good.

Now let's see the following:

it's the same problem, except that the stylesheet only defines colors  
for p, then for .thatsok and .thatsnot. A rather smart parser would  
recognize that <p class="thatsnot"> is problematic. I don't exactly  
know how feasible that would be, but that's the kind of behavior that  
would be much more useful than the current systematic warning on  
background: transparent.


olivier Thereaux - W3C -
W3C Open Source Software:

Received on Monday, 24 July 2006 05:42:22 UTC