Journal
CSS Validator Nonsense
30 September 2005 › 35 comments
Seeking Clarity
If you’ve been doing web design for awhile, you’ll remember the old days of table based layout. For me, the dawn of CSS and web standards was when I really started taking an interest in best practices. I liked the exactness that it called for – a certain level of precision as opposed to nesting tables within tables, and throwing down a font-tag to change an element’s color.
That being said, I fear that perhaps the W3C has gone a bit overboard recently, adding unnecessarily strict warning messages to every instance in which a background-color is not accompanied by a color and vice-versa. I find this very odd, because this is not something that native, unstyled HTML does by default anyways. It’s as if they’re saying “Hold on there cowboy – You can’t change the color of a blue link without also adding a background-color!”
Examples
For instance, on this site I change the color of h3 to make them stand out a little bit from the regular text, besides just having a change in font. This still passes validation as clean CSS, but as of late this has started throwing a ridiculous amount of warnings. Don’t believe me? Check out any of your favorite sites, and I guarantee that you’ll see something like this…
- (Level : 1) You have no
background-colorwith your color :h3
Oh the horror, I’ve been slapped with a Level 1 warning! Let me point out that this is not the same as having non-valid CSS. If you’re worried only about that, you can quit reading. This would be the equivalent to a cop stopping you at an intersection with nobody at it, and saying “Um, Mister – You didn’t come to a full and complete stop at that stop-sign.” You’d be thinking “So what? There’s nobody here, so there wasn’t any harm done.”
Here’s another example:
a { color: blue; }- (Level : 1) You have no
background-colorwith your color:a
The warning above is how default HTML works! Before you say it – I understand the accessibility reasoning behind this type of warning. You wouldn’t want white text on a white background, for instance, or too faint of a grey to be legible. To its credit, the validator can tell when a background color is the same as the foreground color, and gives you a warning for that too.
Suggestions
After a little Googling around, from what I can gather, the W3C added this pleasant bit of validation somewhere around the middle of September. To me though, it is so arbitrary that it really is not a very reliable warning. I think it would have been better if they had added some sort of native intelligence to the check, based on the nearest parent element.
For instance, if I have a div that has a white background, and have defined everything within it to have black text, then if you change something to a dark green, it should check how far in hex-color that is from the white background, and if it’s above X amount in variation, then it should give you a warning. That’s the type of validator I’d like to see, not something that just throws out random warnings In my opinion, it completely devalues more important ones.
Anyway, that’s just the way I see it. I’m sure that there will be people that disagree, but I think we need to have real warnings where they’re truely applicable, and quit sending knit-picky designers (like me) into a panic. Hopefully there are enough of us in agreement that the W3C will listen and do something about it.
Discussion + Dissension
Comments closed after 2 weeks.
#1 Joshua Kendall
I actually noticed this about a week ago. It concerned me, but I just went along and added a background color (I don’t generally use a background image for the page).
It’s stupid to have an id (#main) with a white background and then a paragraph (#main p) where you have you have to declare the background color again. I mean if it’s a class or element dealing with an id then it shouldn’t need to have a seperate background declaration.
#2 Nathan Smith
Exactly my point. I think the validator should have some sort of check so that if there’s no background defined, it will go on up the cascade until it finds one. Assuming there were none, it would simply match it against
body, and then perform some logical check on the color difference between the background and the text color. If it can’t be that robust, I think they should just get rid of that warning message altogether, as it’s not really telling us anything useful.#3 Yannick
I had the same problem on my site Nathan. I agree with you both. Sounds kind of odd for them to want us to add background colours to every element. Adding it to the body sounds about good enough to me or else leave that warning out all together.
As for the W3C’s website getting warnings and validation errors, that’s kind of funny. :)
#4 Andy Beeching
I saw this also! Very annoying, especially for complex CSS-based sites, where there is a lot of different typography and styling of elements, like lists with ids etc… Line after line of level 1 errors! I could understand it if it was a CSS on, images off situation, and you needed to make sure that the text was still legible, but as pointed out above, when you simply have header tags, and p tags within a div that already has the correct (in terms of contrast) backgound-colour set then it’s simply stupid.
I did, however pay attention to the level 2 errors I got, and now they’re sorted… anyone got a level 3 warning yet?
Another thing is that adding more colours to every single element will increase the file-size of the CSS, making mean and lean, cascading colours a little hard to achieve!
Finally, I noticed that my standard, and before valid filter to send stuff to Gecko-based browsers is now invalid, and had to go to dithered.com to find another one. The rule in question was the html:not([dummy]) selector which worked fine, before, and validated. You can now use body:last-child selector to the same effect. This is useful for serving Opera specific rules.
Filters available here (with explanations):
http://www.dithered.com/css_filters/css_only/index.php
#5 Will R
Well I had the same damn problem. I put the question to the guys @ oswd.org and this is what ‘Andreas’ recommened –
“all you need to do is add:
background-color:inherit;
...to the places where you have no background color, and the warnings disappear – most often with no visible change in the design (the element background inherits the background of the parent element, I believe).”
I think that works… Hope that helps. I agree the new W3C specifications are just so damn ridiculous.
#6 WD Milner
Does it only happen under the Strict DTD?
I hadn’t noticed as I commonly specify the background colour. Basically it’s a habit I got into a long time ago. Not everyone has their browser backgrouds set to default to white but unfortunately many site designers overlook setting a top level background colour as THEY have their browser backgrounds set to white and just overlook it. In such cases the background colour doesn’t get inherited as there is none to be inherited. I have seen this on small personal sites to huge corporate sites (Including a couple of the 9Rules folk :-) ).
For an intesting look at the web, set your browser background default to the old grey default or a blue or green and go surfing. Some of the site appearances may surprise you.
#7 Ara Pehlivanian
I think that the reason for this sort of scrutiny might be because of the fact that the web is being accessed more and more by non-conventional browsers. And if you think about it, a lot of our styling modifies the default rendering of the mainstream browsers. But who’s to say that just because IE or FF render an H1 in a certain size and an anchor in a certain color that a lesser known browser, a PDA, a cellphone or some other device won’t render things entirely different and so by setting only a foreground color you won’t be breaking something?
For example, say some web client displays a dark background by default with a lighter colored foreground color so that it’s easier on the eyes. And say that the color you want to set your links happens to be the same, or very close to the background color? And what if you didn’t bother to set the background color of the page because you assumed that it would be white. Then what?
If anything, it goes to show that the consortium is trying to prepare for the future of the web where not everyone will be using the same client to access your content.
#8 Robert
One of the nice aspects of separating design for content is to cut down on bloated sites. With this type of ‘warning’ it seems that they are asking for us to add bloat to our CSS, increased file size, and increased download time. Granted, it may not be much for some sites, but for other sites that already have considerable sized CSS, this extra declaration seems pointless other than to add bloat.
#9 Robert
Ara—Don’t you think that is more of a developer for browser concern than a designers concern? Browsers should all meet the same requirements, but instead focus is shifted on the designer, which really seems rather foolish to me.
It is like housing developers allowed to put in bad plumbing so all residents need to be certified in plumming, instead of making the housing developers all meet the same standard.
#10 Nathan Smith
While I see the point that Ara is making, that they’re trying to make things more accessible across the board, I agree with Robert. It’s up to the mobile browser developers to make their software condusive to surfing the web with familiarity. It shouldn’t be up to the W3C to coddle them with validation.
WD: Point taken, I’ve added
#fffalong with my body background image. And no, it's not just with Strict doctype, or even XHTML for that matter. It throws errors on HTML and XHTML Transitional / Strict, and XHTML 1.1. So, seems like this new validation is here to stay. Now, just like with IE, we need to figure out a hack or a work-around for abuggyverbose validator! ;)#11 Djublonskopf
Out of curiosity, and also having nothing more of value to contribute, this nevertheless seems like a rule aimed toward forcing good design-behavior rather than laying out what is disallowed as bad behavior.
Is this the only place where the only clear purpose of the CSS rule is to make sure something looks good, rather than just outlining what’s technically accurate markup so the standards-compliant software can universally render it? Or are there lots of other rules (you can’t have more than five uses of blinking styling on a page, perhaps) that I just don’t know about?
There are (a rare few) cases where it’s desirable to have text the exact same color as the background, for instance, and there’s no technical reason why a browser should not be able to render it as such. Granted a blog doesn’t usually need something like that, but I’ve built game pages before that made use of text hidden by color, and I’ve seen other puzzle pages that do it, too. And sometimes you’re just a silly high school student who wants to leave a hidden message for your friends that the teachers can’t see at a glance.
In any respect, I tend to see CSS rules as existing to give the CSS language enough structure and coherence that you can write software to understand it. And since text-color vs. background-color isn’t an issue of browser comprehension (the browser should still be able to understand instructions to render gray text even if it’s on a gray background), my personal feelings would be with Nathan et. almost al . . . that the cross-platform design beyond that should fall to whether the designer really cares about that. Warnings included.
#12 Paul D
Perhaps it’s good practice to put background-color: inherit in any element whose other colours are being modified. I haven’t really thought it through, though.
#13 Brown
Get over it. Sigh.
#14 Chris
I don’t think that we should have to do anything to work around – it defeats the purpose of “cascading” in Cascading Style Sheets.
#15 Roger Johansson
I believe the warning is there to reduce the risk of author stylesheets interfering with user stylesheets or system-wide colour settings.
Let’s say I’m using a theme for my OS that happens to make text input elements in forms black with white text.
Now imagine what would happen If an author stylesheet specifies that the text colour in text input fields should be dark grey, or black, and does not at the same time specify a background colour.
Dark grey or black text on a black background.
It’s just a warning to make sure you keep things like that in mind.
#16 Nathan Smith
Djublonskopf: Technically, one shouldn’t be using
blinkat all, because that’s been deprecated in XHTML. And the foreground/background color-check isn’t a rule per-say, as it is a strong suggestion. One’s website still gets the “congrats” from the validator as being good CSS, and then gets a slew of warnings that weren’t there last month.Paul D: I think that an inherited background would be bad, because if you have a background color defined, but also an image that overlaps it, then having it inherit the background color could put a funky, sharp contrasting box around the text. I’d rather settle for warnings.
Chris: I totally agree, having all these silly warnings thrown about makes me want to go back to doing video game mapping, where at least the game engine you’re working with isn’t in a constant state of flux.
Roger: I totally agree, that the point of these warnings is to get authors to take a look at how their stylesheets might break usability. But, I don’t think that the W3C should have implimented them until there was some way of checking whether or not the warning is actually viable for that situation.
Example: dark brown text on white background is still perfectly readable, so if text is defined as dark brown, but with no background-color, yet within a
divthat has a white background, I do not think the validator should have such a problem with it. That’s just my opinion, I realize you know a whole lot more about this than I do. ;)#17 Teevio
Yeah, I noticed the background-color warning yesterday when I was coding up a new site. I thought it was weird but didn’t think twice cause I thought I might be going crazy or forgetting that I had a bg color before.
That is definitely a dumb warning and will probably make a lot of sites invalid without anyone knowing about it.
#18 Nathan Smith
Teevio: I agree. While the sites won’t be “invalid,” they certainly don’t look quite as good as far as the validator is concerned. Seeing that “Congratulations” followed by a truckload of warnings is like winning the lottery only to find out they’re taking half out due to taxes! ;)
I find it very funny that having a background of #000 and a text color of #111 does not throw a warning. Technically, this is the type of color combo that the validator should be looking for, barely legible text. But, it only catches it if it's background of #000 with text color of #000. Seems completely pointless.
#19 Jim
Sigh. Roger is the only one who has the slightest idea of what he is talking about, and his point just flew over your heads. Example:
User stylesheet for tired eyes:
p {
background: blue;
color: white;
}
An author stylesheet:
#foo .bar p {
color: blue;
}
The W3C’s suggested fix for the author stylesheet:
#foo .bar p {
color: blue;
background: white; /* or whatever */
}
Now what does the author stylesheet result in? A completely unreadable document. And what does the fixed stylesheet result in? A readable document.
As for figuring out whether the colours are far enough away from each other to contrast enough to be readable, I suggest you actually give that one second’s thought. The validator can’t figure anything like that out unless a) you are talking about one particular document and one particular stylesheet (in other words, forget about validating a stylesheet alone, you have to validate every combination of that stylesheet and every page on your website), and b) the validator can magically predict what people have in their user stylesheets (which it can’t).
I have no patience for people like you. Did you post a message to the validator mailing list politely asking why it was giving you this warning? No, you just posted ignorance for the world to see and insinuated that other people were being unreasonable. Had you done the sensible thing, you might have actually learned something. If you don’t understand something then ask instead of flaming.
#20 Nathan Smith
Jim: Correct me if I’m wrong, but wouldn’t the user stylesheet trump the designer’s stylesheet unless the designer had prefixed his CSS with
!important? As far as I remember, the order of applied stylesheets goes from least to greatest as follows:browser default › designer › user › designer (!important) › user (!important)
So, in the scenario you’d given, the user’s preferences would win out over the designer’s anyways. Here’s an example in which it could be a problem: If for some reason, a user had a grey background (yet no text color) defined, and the designer had text color as grey (but no background), then the user would have grey on grey.
I do see what you mean, and I did understand Roger’s point as well, that it’s simply a suggestive warning, and not an error. I wasn’t saying that the validator is yet capable of color-matching, or that it should have to guestimate user-preference. Since user wins over designer, it wouldn’t have to.
I was simply saying that it would be incredibly useful if it could do hex-color matching, as this would give definite examples of possible conflicts. As it is now, it seems to add more clutter than anything. Perhaps a simple one-line warning would suffice, without pointing out every single instance.
So, while I do not consider my article a flame, I am truely sorry that I upset you. I realize I was a bit sarcastic, but I meant no offense. For the most part, I think the W3C has done an amazing job in helping turn around the web from being proprietary, and made it much more accessible.
Bear with me while I describe a hypothetical scenario:
Designer works hard making a company website front-end that is accessible. Goes to sleep that night knowing that it validates without a hitch. Wakes up the next morning, goes to work, and gets chewed out because of all the warning messages that are now appearing, on the day of the site debut.
^ While that is of course the absolute worst-case scenario, many designers were having quite a bit of confusion when the new warning messages started popping up. So, I wrote this article not because I don’t understand what’s going on with the warnings, but to point out how they could be more useful.
#21 Jim
> Correct me if I’m wrong, but wouldn’t the user stylesheet trump the designer’s stylesheet unless the designer had prefixed his CSS with !important ?
No, that is not the case.
http://www.w3.org/TR/CSS21/cascade.html#cascading-order
> So, while I do not consider my article a flame, I am truely sorry that I upset you. I realize I was a bit sarcastic, but I meant no offense.
Well perhaps I was a little harsh myself. I wasn’t so much offended as I was frustrated that yet another person had assumed the worst of the people working (usually without pay) on the validators. It seems that whenever people criticise the validator, it’s always because they’ve misunderstood something, and they never actually ask on the mailing list or report the bug they think they’ve found. As far as I’m concerned, if somebody is going to complain in public, the very least they could do is bring it up with the people responsible first.
#22 Nathan Smith
> No, that is not the case.
I stand corrected. Still, it is good to know that the final say is still in the hands of the user. You’re right, I probably should have brought it up with them first. After re-reading my article, I realized the link to the W3C non-validating page was in poor taste, so I’ve removed it.
To any W3C people that might be reading this, I apologize. I’m a bit hot-headed, and this isn’t the first time I’ve called things into question that would’ve been better dealt with via email. While my opinions still stand, I’m sorry if it’s caused any offense to you.
That being said, I do think it would rock to have some sort of hex-color check implimented in future versions of the validator. I’m sure for some of the coding geniuses out there, it wouldn’t be too difficult. I’m not opposed to warning messages, I just think they should be as informative as possible.
For instance, I love the generic
font-familywarning, because I often forget that not everyone has my favorite fonts, so it’s good to have a fall-back. Anyway, keep up the great work, and please don’t black-list me from possibly joining the W3C one day (after I learn to keep my big mouth shut).#23 Fransjo Leihitu
Yeah, I’ve noticed it to about 2 weeks ago. First I thought that I was going crazy, cus I knew the CSS was clean before. But after a while I saw the same warnings on all my CSS sites. I think the warning is over the top.
#24 Nathan Smith
Fransjo: You and me both. I thought I was seeing things at first, simply because of the sheer number of warnings that were being tossed about. While I see it’s purpose, there sure are alot of them being served up to various pages around the ‘net.
#25 Mike Montgomery
Perhaps it’s time to consider a discussion between Mike and Shaun. In a very long discussion titled “March to Your Own Standard”, Mike mentioned “One feature I wish the W3C validator had was the ability to ignore certain errors.” link text
Later, in an article titled “Amputate the W3C Validator,” on June 16, 2004, Shaun produced a script link text to “ignore certain errors introduced by legacy content management or ad serving software—a primary concern being unencoded ampersands.”
A customizable validator. Interesting idea, that.
#26 Nathan Smith
Mike M: that’s cool. I’ve read Mike Davidson’s article about his funky ampersand invalidating his site. I wasn’t aware of Shaun advocating a validator that would be customizable. I think that’d be cool, but I really think that some sort of color-checking needs to be implimented in future versions of the validator.
#27 Fransjo Leihitu
Yeah, that would be great. Maybe they can make the script, so you can choose between “show_warnings” of “show_no_warnings”
somthing like :
&show_warnings=1
or
&show_warnings=0
#28 Nathan Smith
Fransjo: That would be pretty cool, because then people using the validator could view warnings, decide if they’re applicable, and if not, turn them off by a slight modification in the url. Good idea!
#29 Stan Krute
I have lots of background-color:transparent in my CSS.
Totally legal. Not deprecated.
The validator now gives me a warning on that one.
Irritating behavior. Wrong behavior.
This is not a design validator. It’s a CSS validator.
Note to Jim: disagreement with your position does NOT
mean that one does not understand the issues involved.
Denigrating folks with other thoughts does not lead to
solutions.
—stan
#30 Nathan Smith
Stan: Thanks for that back-up. I’m glad that people are starting to realize that the new validator just clutters up the radar of potential problems by flagging way too many warnings, without offering real solutions. I really think that it would be most beneficial for it to do a color-closeness match up the cascade, and if it didn’t find anything, then not flag a warning, or offer one generic flag.
#31 Rajio
its pretty rediculous. the added warnings just polute the validator and dilute any legitimate warnings. makes designers not want to check the warnings at all since their discredited by bogus warnings like this. If I don’t want to assigns a background color, or even a text color for that matter, why should I? maybe, as the designer I have that taken care of ‘cascading’ from somewhere else, plus doesnt the nature of cascading style sheets imply inheretance? like if i set the text for my body to arial, then the text for all my site unless otherwise specified is arial. (hence, the style cascades!)
with the point about W3C’s stance on usability, that is not their department. I dont tell them how to create an efficient validation engine, they shouldnt tell me how to pick my colours. Plus, i might WANT it unreadable, did they even think about that one? Their just really out of line here and I’m glad to see I’m not alone in thinking so.
#32 Gary Robar
Okay. Wow, Quite the debate. Like the postings here, I have mixed feelings. I can see their (W3C) point in why they are requiring this (but I think we will see some refinement of this “rule” as time goes on.)
As for what I did, good ole search and replace, add in whats missing, which did’nt change my style, look, feel etc…W3C validator is happy, and I get no rediculous warnings.
Just a rediculous annoyance I guess.
In W3C defence – I think I was more mad b/c of the work i’d have to do to fix the warning errors, and not because of their implementation of the warnings.
#33 Nathan Smith
Gary: Yeah, it’s been awhile since I posted this article. I have learned to just live with the warnings, because I know whether or not a site is becoming inaccessible or unreadable because of color schemes, better than some automated process could tell me. So, I just let the warnings continue on. It’s not worth adding unnecessary bloat to my CSS files.
#34 Gary Robar
yes, the bloat factor is large here. I actually noticed these warnings as I have just spent a few hours ‘cleaning’ up my style sheets to cut down on their size and to make them more readable for editing. Once I finished the editing, I did a CSS validation check just incase I had typoed anything. I get line upon line of those warnings. Adding all of those useless tags seems crazy.
Thanks to those who are fed-up and ‘ignoring’ the warnings, however annoying they may be to see.
#35 Nathan Smith
Gary: I look at it this way, even the greats who have done high-profile site redesigns and written best-selling web development books have all sorts of CSS warnings on their sites. For instance, check out SimpleBits.com.