David Hucklesby wrote: > So-called conditional comments seemed nice, until I wound up with > four additional style sheets just for IE. So I do wonder about the > utility of hiding CSS from the validator?
If hiding CSS from the validator is what conditional comments are used for - and that's too often the case, then it's a completely nonsensical exercise. It is "something" about those "holy cows and standards"... <http://www.gunlaug.no/contents/molly_1_08.html> OTOH, "hiding" _is_ an unavoidable side-effect of targeting IE through CCs though, so it may be excusable in some cases. > I mean, I can and do make mistakes in those hidden style sheets that > the validator could catch. Indeed. We can of course use the validator to our advantage anyway, by linking directly to the hidden stylesheet. In that respect my @import hacks for serving corrections to IE7 and older IE versions are a lot more problematic. I can only validate those stylesheets through direct input, as responses like this... <http://jigsaw.w3.org/css-validator/validator?uri=http://www.gunlaug.no/contents/styles/url(ag2c_con.css)%20all&warning=1&profile=css21> ...don't tell me much. > As for the non-validating code, well, my British English spell > checker tells me that "color" is spelled wrongly, but in the context > of an article about CSS I would simply ignore the "error". Holy smoke... <http://annevankesteren.nl/2009/02/www-style-thursday> :-) > What is so special about CSS that I need to trick the validator just > to get a passing grade? Getting a passing grade matters a lot to some, even if the code isn't up to it. Some just love those "valid" icons too much. ------ My position on the issue is that if/when we have to serve hacks, CSS hacks are to be preferred. The markup should be as meaningful, flawless and valid (in that order) as we can possibly make it, since the markup is the base everything else acts on. If the bar has to be lowered in order to make a browser behave, then let's lower it for CSS. That CSS hacks are "visible to the world" shouldn't bother anyone. Most can't see the difference between valid and non-valid code, and couldn't care less. Those who do, should know why both valid and non-valid hacks are sometimes the lesser of many evils. The problem with hacks is *not* that many of them are non-valid, but that those who put them in have too little knowledge about browsers and hacks to justify the hacks existence. Hacking is dangerous business - breaks far more browsers than browser bugs ever did, IMO, and hacks should *only* be introduced when "the hacker" knows perfectly well what s/he is doing. Leaving all hacks open to the public, and to the validator, is immensely useful when in the process of getting rid of totally unwarranted hacks. regards Georg -- http://www.gunlaug.no ______________________________________________________________________ css-discuss [[email protected]] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
