The W3C CSS Validation Service Warnings

Just a general question

[CSS_Kidd]

Ok my CSS Validates, but why do I get strange warnings?

I went an validated some CSS I am currently working on and I got this Warning:

Same colors for color and background-color in two contexts #header and #footer

Now these are the rules it is referring to:

#header {
width : 790px;
height : 125px;
background : #630;
}
#footer {
background : url('../images/container-blur-bottom.png') no-repeat center top;
padding : 20px 0;
text-align : center;
font : 10px/1.3em Arial, sans-serif;
color : #630;
font-weight : bold;
}

Can someone explain to me, when bg color and font color are two different things, what is the deal with this warning?

I have gotten these warnings before when it was relating to the same things (height vs height, or width and so on), but never like this.

[buckworks]

It's just a warning, to alert you about a potential problem.

Considering their names it's unlikely that you'd apply both of these classes to the same element, but it can happen that someone ends up with hidden text because they apply classes where the text color and background color were the same.

As it stands it's not an error, but be very aware of where you're applying which classes.

[CSS_Kidd]

I guess it is just a curious question. I have been validating my css for a long time now and I have have never seen a warning like this before.

I even went back and validated some older stylesheets to see if I overlooked it in the common warnings that I always get... No luck... This is the first time I have seen it.

Maybe they updated the validator to call for this?

[swa66]

The validator does warn about color for a long time already, giving warnings about background ad foreground colors for as far back as I can remember.
It seems they did smarten up the validator over the iterations as I used to get somewhat similar warnings all the time.

As long as you're the only user of the CSS and/or have decent documentation to prevent others from applying both classes to something that's rendering in an overlapping fashion, you can safely ignore these.

[KenB]

I've been seeing some new and really irritating warnings in the past few months with the CSS validator. I think they did an update on it and ever since then there has been a lot of noisy warnings that aren't very helpful and could actually be obscuring important warnings.

For instance I used to use "inherit" for either color or background-color if I was defining the other just to make the warning about needing to define both go away. Now they've seen fit to throw the warning anyways. If I take the time to define both (even if I use "inherit"), I've probably got my bases covered on the issue of making sure color and background-color are different so don't throw a warning over it.

[rocknbil]

I've always ignored these, I perceived it, in a way, similar to S.E. indexing - the parser is reacting to what it can make sense of and can't extract context. It doesn't "know" that you have an image background there.

However, since you brought it up, imagine if the client doesn't render images. Then you do have same color text on a background.

Here would be an interesting experiment (going to try it next time I validate and get this warning!) I wonder if the following would make the warning go away:

background: #fff url('../images/container-blur-bottom.png') no-repeat center top;

Or, whatever might be a good alternate background color for that element, if there were no images. True, you may not actually need a BG color there, but if it doesn't wreck the layout, I see no harm . . . unless you need it transparent.

[KenB]

Yes I realize it is acting to context, however if you have used the following instruction you are providing enough context that the validator shouldn't throw a warning:

.bla{background-color#fff;color:inherit}

By adding "color:inherit" I'm acknowledging that when one assigns a background-color one should also assign a text color. As such, no warning should be thrown for the above example.

[Fotiman]

@CSS_Kid,
The warning is to make sure you understand that you have an element that has the same color as another element's background color. In a case like yours, this is not likely to be an issue, but if your HTML looked like this:

<div id="header">
  <div id="footer">
    This text may not be visible
  </div>
</div>

Then your inner text would have the same color as the parent background (depending on how big the background image is in #footer).

Again, not likely in your particular case, but if you were using ids or classes that were a bit more ambiguous, then it might be harder to tell. As mentioned above, if you give it a background color (different from the color) as well as background image, then you shouldn't see a warning.

@KenB,
No, if you use "inherit", that is not enough context for the validator not to throw a warning because it doesn't know what color is being inherited, and therefore you could have the same problem I described. By adding "color:inherit", you are in no way acknowledging that when one assigns a background-color one should also assign a text color. "inherit" does not provide any context to the validator to know whether or not your color will conflict. If you want to get rid of the warning, provide an actual value (other than "inherit").

.bla { 
  background-color: #fff;
  color: #000;
}

[KenB]

@Fotiman,

The CSS validator used to be happy with the "inherit" instruction and never threw an warning for it until recently.

The problem in my case is that the color oftentimes does need to be inherited from the parent object and the style rule in question can't anticipate what the exact color is because the color changes in different contexts. What is especially irritating about this is that this useless warning could cause me to miss a more critical warning that I do actually need to fix.

[Fotiman]

the style rule in question can't anticipate what the exact color is because the color changes in different contexts

And that is exactly the reason you will get a warning. If you can't anticipate what the exact color is, then there is a chance that you might inadvertently have a mix of color and background color that don't play well together. Therefore, you get a warning. The warning is there for your own benefit, to make you aware of a potential problem area. Why would this warning cause you to miss a more critical warning?

[KenB]

If you can't anticipate what the exact color is, then there is a chance that you might inadvertently have a mix of color and background color that don't play well together.

0% chance because you misread my statement. I said a specific style rule can't anticipate what color is needed, HOWEVER, I didn't say I couldn't anticipate what was needed.

I know what is needed based on the parent style rule, that applies the color. I use color rules in a cascading fashion and know very well at all layers what the possible range of colors are that could be applied higher up.

If I left off the color rule when I applied a background-color rule then yes a warning could be warranted because I might have had an oversight. HOWEVER, again I will state with absolute certainty, that IF I apply "color:inherit" I know for absolute certainty that there will be no conflict and thus a warning is not warranted. For years, yes years, no warning was triggered as long as both color and background-color rules were applied with one of them having the value "inherit". Why suddenly change this behavior now? It is senseless and annoying to the most extreme.

I do what I can to make warnings go away because I want to make sure I cover every base, however, in order to make this warning go away I'd have to use more style rules and use inefficient selectors at that, this ads CSS bloat and slows down page rendering. W3C needs to revert this warning behavior back to the way it had been for so long before the last update because it does more harm than good.

[Fotiman]

Well, I guess the point I'm trying to make is that you personally might know all possible color combinations with whatever CSS rules you've got in your cascade, but that doesn't mean that ALL developers will have this knowledge. And likewise, the validator has no way of knowing whether or not you are fully aware of all the combinations.

With all that said, I agree with you that this particular warning is not useful (I've just been playing devil's advocate). In practice, I think it's extremely rare that a developer would mistakenly use a color or background color that conflicted with another nested style, and even if it did, that would be a "logic" error, not a "validity" error.

[KenB]

With all that said, I agree with you that this particular warning is not useful (I've just been playing devil's advocate). In practice, I think it's extremely rare that a developer would mistakenly use a color or background color that conflicted with another nested style, and even if it did, that would be a "logic" error, not a "validity" error.

Exactly, it is a logic error and it is highly improbable that if someone is taking the time to define color:inherit that it is in error. The most likely cause of color conflict error is if one defined background-color or color but forgot to define the other entirely.

Warnings that are not useful are distractions that can cause one to miss important warnings.