Forum Moderators: not2easy
Conditional Comments [msdn.microsoft.com] are now, for the most part, accepted as being the way to segregate the IE Hacks. They are HTML comments which mean the CSS can't take care of the job, but with IE8 we are to get a meta tag (also a non-css method) to take care of version targeting (though for the record, I'm out with the jury on which way the default will roll out on X-UA-Compatible=?)
anyway whichever way doesn't matter what it means is if you want to version target you will take care of it the <head> of the document.. so I thought if we're gonna have to do it going forward, why not do it backwards too. Rather than have multiple stylesheets being called per IE version number how about using the comments to set an ID or class name instead, then we could use specificity rather than parse hacks (the speed freaks alternative option to conditional comments) to version target.
Use the underused HTML element
add an ID to the HTML element based on the version number, we've not been able to use it properly for anything else because of IE's quirks so lets use it for this..
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<![if false]><html><![endif]>
<!--[if IE 7]><html id="ie7"><![endif]-->
<!--[if IE 6]><html id="ie6"><![endif]-->
<!--[if IE 5]><html id="ie5"><![endif]-->
<head>
<title> CSS Comments </title>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<style type="text/css" media="screen">
p {background: #ff0;}
#ie7 p {background: #cfc;}
#ie6 p {background: #fcf;}
#ie5 p {background: #dad;}
</style>
</head>
<body>
<p>In IE7 the background on this paragraph is green, in IE6 it's pink, in IE5 it's purple, in all others it's yellow</p>
</body>
</html>
the extra bytes in the HTML are minimal in comparison to the extra http requests that would need to made for separate stylesheets? - I'm sure someone could come up with a more elegant (& validating) way I didn't check the validation I'm leaning more to the what works side here ;)
the CSS with the ID attached would be transparent as to which version it's targeting, without the need to remember which parse hack targets what?
viable or rubbish?
Invalid html might yield surprising results in compliant browsers (e.g. the validator at w3c.org doesn't recognize the html element declaration anymore ...
The "normal" conditional comments are not a problem as they are comments (i.e. valid html).
This is probably more a problem for a strict doctype and shoudl be a no-no for a xhtml doctype.
It's not going to be as powerful as giving the html a variable ID, but an extra div in IE that get the version as ID would work for a lot (not for what we need different on the body e.g., but then that div could probably take the role ...)
What I was thinkign of (untested), but this does validate.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title> CSS Comments </title>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<style type="text/css" media="screen">
p {background: #ff0;}
#ie7 p {background: #cfc;}
#ie6 p {background: #fcf;}
#ie5 p {background: #dad;}
</style>
</head>
<body>
<!--[if IE 7]><div id="ie7"><![endif]-->
<!--[if IE 6]><div id="ie6"><![endif]-->
<!--[if IE 5]><div id="ie5"><![endif]-->
<p>In IE7 the background on this paragraph is green, in
IE6 it's pink, in IE5 it's purple, in all others it's
yellow</p>
<!--[if IE]></div><![endif]-->
</body>
</html>
And it makes it easier for IE fixes to sneak into the standards browsers, causing testing to be harder than it needs.
One problem: the <!if ... > and <![endif]> are invalid html.
I know, I said that in op ;), was just throwing a theory to see what the thoughts were, try this variation instead for the "downlevel" browsers
<!--[if !IE]>--><html><!--<![endif]-->
Thinking of this: why don't we add an extra div around the typical wrapper with the appropriate ID to select all the legacy MSFT browsers ?
Yes, that's another way to do the same thing, possibly cleaner as you don't need the "else" condition. btw it would be just as powerful, as the ID on the HTML element
Regardless of it all it still means there's superfluous CSS to download for the complaint browsers, slowing them down due to MSFT not doing their homework.
that I'm not sure is a valid disadvantage, what is there likely to be?, most IE stylesheets just have a few extra lines in them. Also CSS's are full of 'superfluous' code at any one time, comments, rules that don't apply to the specific page one would be looking at, what's a couple extra?
And it makes it easier for IE fixes to sneak into the standards browsers, causing testing to be harder than it needs.
p {width: 480px; padding: 10px;}
#ie5 p {width: 500px;}It's not making anything easier for IE fixes to sneak into standards browsers
as I was reading, especially the threads where TEAMS are responsible for maintaining CSS files, it's not always easy for them to remember, or even know if they're new to a team, that if they change a width in the main stylesheet they should also be opening, checking and possibly amending the segregated IE stylesheets too. That could possibly be double work for some, it is the biggest argument I see against using Conditional Comments, this way is still using them just differently in a more CSS friendly way?
It is suggested as a best practice that you should always place comments in the main stylesheet to notify yourself or others that there is a corresponding/extra rule in the separate IE sheet(s).. and while I agree with that (it's not always easy to remember even your own css after a few years!) it is extra bytes in the stylesheet the same as the IE specific rule, only the IE rule is right next to its partner with this method and much easier to change at the same time
why is this done on the html tag and not the body tag?
IN most sites now there is already an ID on the body element, i was simply trying to avoid a bit of conflict.. as you see from swa's post it can be applied just as well to an extra div, I used the HTML element as it exists and is relatively clutter free in most cases.
Is the <![if false]><html><![endif]> part really necessary?
I'm also seeing more and more that the validator is not the be all and end all, this is one instance.. just because it doesn't like the Microsoft syntax, doesn't mean it won't work, the browsers have their own minds and I'm sure it's in everyone's best interests to let MS have these comments, others starting to misinterpret them now would be shooting themselves in the foot don't you think?
the extra bytes in the HTML are minimal in comparison to the extra http requests that would need to made for separate stylesheets?
Can't see the argument on that one, if we used the standard way of conditional comments and put them in the head of the HTML then it's the same. The extra bytes are downloaded by all browsers.
Shirley the better way is..
Say we are using the standard method for conditional comments and each IE browser has a style sheet as well as the default, and the rest of the browsers just the default.
then (omitting comments for brevity)
default.css
IE5.css
IE6.css
IE7.css
All non IE browsers just one http request for the default.
Each IE browser two http requests (default + its own).
This way the extra bytes are the conditional comments in the HTML file (<link rel tag.)
HTTP requests are expensive (speed wise) and should be kept to a minimum, but if you have a large site then putting your 'Conditional comments + CSS' in the head is worse? And doing what you suggest here is even worsererer? CSS file should be cached in the browser?
It's interesting though. ;)
In my case any extra bytes would be minimal, in fact they would likely not be extra at all now that I think about it because yes as you say my comment simply replaces another, possibly longer one
<!--[if IE 7]><html id="ie7"><![endif]--> would replace
<!--[if IE 7]><link rel="stylesheet" type="text/css" media="screen" href="ie7.css"><![endif]--> BUT it would save the extra HTTP request, I wasn't suggesting the CSS had to be in the head of the document, it would go in the main stylesheet alongside all the others, one call for all browsers.. sorry it was embedded in the head of that demo for demo
basically there are lots that still prefer to use hacks to target so that they only have to maintain a single stylesheet, whether this is becasue it's a team thing and they want it to stay together or whether it's a speed saving http request, this I though might be a way to do that without using the dodgy parse hacks, which I never recommend as they may fall foul of the next IE release, and/or not everyone understands when they see them. See Yahoo.com's stylesheet for an example (the example that prompted me to do this actually, I can't believe the number of hacks in there, though I know why they are there)
and when you see something like this,
div{
background: #00f; /* all browsers including Mac IE */
*background: #f00; /* IE 7 and below */
_background/**/: #0f0; /* IE 5.0 */
_background:/**/ #f62; /* IE 5.5 only */
_background/**/:/**/ #f61; /* IE 6 only */
}
which would be clearer to most people, the above or:
div {background: #00f;}
#ie7 div{ background: #f00;}
#ie5 div {background: #0f0;}
#ie55 div {background: #f62;}
#ie6 div {background: #f61;}
I know I wouldn't have known what that first one was doing (and I know it's an extreme, as it's all in one rule.. but image these peppered through a stylesheet :o) unless I'd looked up the web, bit's of it yes, but not combined.. so I include myself in that I find the second one much easier to understand and I would do even if I came across it years later!
and technically the stylesheet could still have less bytes
because the ID's replace the comments,
so in all there could be less bytes and less HTTP requests theoretically, in some cases anyway?
aye, interesting
Hmm, brains just thrown in another question, specificity ?
Shouldn't be a problem though as the hacks are at the root so over-rule all.
Only other thing I can think of is things like html parsers may choke on the <![if false]><html><![endif]>. Again that's the brain talking and not me. ;)
The one I posted above (e.g. adding an extra div) would be something I'd seriously consider using if I wanted to be more friendly to IE users.
Since I only write xhtml, I cannot afford to write invalid xhtml (that's the argument the "don't write xhtml" side uses that I agree with, but I chose a different solution than they do)
[The thing is that when we start to deliver xhtml not anymore as text/html, the browsers should *not* render invalid xhtml, hence we have to refuse invalid xhtml]
But I'm still scared about all the unneeded markup that will end up in the normal sections instead of the #IEx parts where they belong IMHO. But then again, the hacks, etc. still can do that too, perhaps more.
It's a bit harder to test than with separate stylesheets and it's a bit more unneeded stuff to load and parse for the standards compliant browsers.
