These are all very good tips. I don't recommend using CSS hacks for per-IE-versioning. You can just as easily use(and should!) conditional stylesheets. You can specify versions for different versions of IE if you need to. Non-IE browsers will ignore them, and you can tailor them to the versions of IE you care to support.
I don't want to start a holy war. Of course, there are some arguments in favor of conditional comments. However, it's not an obvious win. As a web developer at Yahoo, I've seen this argument many times over the last 3 years. Here's the cliff notes:
Hacks Proponent With star-property and _property, you can serve a single css file, reducing the number of requests.
CC So, serve ie.css and standards.css. IE doesn't get standards.css.
Hacks But, then you have to maintain two copies of the css. That sucks.
CC Nuh uh! You have a script that concatenates them. You still write ie-hacks.css separately, but your build process tacks it onto the end of ie-production.css.
Hacks With the IE-targeting star-property and _property hacks, you can keep the hacked code close to the "real" code. Even if you concatenate in production, you still have to have two separate files. If something changes, you have to remember to change it in two places.
CC So, have your build script pull out the star-property and _property rules from your single CSS file, and only serve them to IE with conditional comments.
Hacks But, then you're doing exactly the same thing as having these hacks, but also maintaining a script to do what the browser gives you for free. More complexity in your build process = more room for bugs.
And that, generally, is the end of the discussion. Occasionally, you get this:
CC But those hacks can't target a specific version!
Hacks But IE<6 is not supported anyhow. How specific do you really need to be in your CSS? Have you ever actually targeted a browser version other than "ie lte 6" or "ie lte 7"?
CC That's not the point!
These are the reasons that, as a matter of corporate policy, Yahoo generally prefers _property and star-property to conditional comments.
thanks for the above two posts. You guys made my day. I'm in the the final throws of trying to make a good site look "acceptable" on IE6. Your experience helps my isolated decision process. I hope this threads runs further.
Particularly, I am wrestling with this: My site is mostly text. Typography is king here. Its easy to make it look nice on OS X. But both Firefox and IE6 on WinXP look like hell. This is mostly a WinXP core fonts problem. But the same font between Firefox and IE6 on WinXP looks different and I can't find an acceptable balance. Let me add to that: I can't find any "readable" core font on WinXP. What do you do?
I'm a Mac guy too, but have also spent years developing sites on Windows. One of the biggest giveaways that tell me a site has been developed exclusively on a Mac and probably not tested much on Windows is the fonts.
From personal experience, stay away from Lucida. One of the most common fonts across all platforms is Arial. I usually recommend using this for your general copy font. The attempt to render Lucida looks really crappy on Windows if its missing, and you can never tell which computers have it and which ones don't. That being said, Lucida is a nice looking font when its available. If you are you looking to use Lucida, read below.
This is a solution that's been promoted for a couple years, font-family: "Lucida Sans Unicode", "Lucida Grande", Verdana, Arial, Helvetica, sans-serif;
Its definitely a good idea to do some cross-platform testing. Another idea is to use the SIFR technique, although it relies on Flash(not my favorite recommendation).
I definitely respect a fellow frontend developer, but your points don't really support using css hacks.
1) You shouldn't have duplicate copies of your stylesheet in multiple files. You have your core stylesheet(s) that have rules for all browsers. The only rules that should exist in your ie.css are the ones that specifically need to be over-ridden for IE to fix specific bugs. This obviates the need to have server-side scripts doing concat-magic, beyond minification on all stylesheets.
2) In general, I normally only have my style.css(served to all browsers) and one ie.css(served via conditional comments to any version of IE <= 7. 95% of the time, if something is broken in IE7, its also broken in IE6 and is fixed there. Very rare is the time that something that breaks in IE6 but not IE7 can't be fixed by stepping back and redesigning the structure slightly to obviate the perceived rendering bug completely. In the rare 5% of the time that IE6 and IE7 are both broken, but in different ways, and I can't conceive of a different way to eliminate the bug all together, then I will simply add another conditional stylesheet only for IE6. I think in the last 3 years, I've probably only had to do this 2-3 times. Its such an edge case, its simply not a problem in my day-to-day work.
3) The browser share at my last company(3-4 million visitors monthly) was 25% Firefox, 70% IE(24% IE6, 75% IE7, 1% IE8 beta), and 5% all others(Safari, Chrome, Opera). 30% of all our visitors would receive 1 stylesheet. Slightly less than 70% would get 2 stylesheets. However, while the general style.css could be any size depending on a site's needs, the IE-specific stylesheet was never larger than a few dozen css rules at most. aka, it was a tiny, tiny file usually less than 1k-3k. This is a minimum load for even an older browser like IE6 to handle.
4) In looking through http://yahoo.com, there are no stylesheet <link>'s in the page structure. There is a ton of inline javascript and css though. By examining via Firebug, I see one <link> tag for a stylesheet. I'm concluding that it is being loaded into the DOM via js instead of being hardcoded. What I am also seeing is that since the css is being loaded inline, even though I'm on Firefox I am still getting the CSS hacks like underline, star, and alphaimageloader filters. Yes, these are ignored by my browser but I shouldn't being receiving them in the first place. Additionally, since the CSS is not being located in its own file(s), additional weight is being added to the page on every single page view. If the styles were being loaded, then they would be cached by my browser and I would not need to re-load that data again on subsequent pageviews.
There is always a valid point about extra objects in a page and the Yahoo homepage makes very few external requests(4 js files and 12 css background images). Its a highly-performant page. But in the interest of optimizing a site for everyone instead of the majority, putting stylesheets into separate files and using conditional comments does not put enormous extra load onto browsers. Even better, it gives me the page performance I want in my browser while giving the best performance possible for the users who(for whatever reason) are still using IE6.
I'm going to make some assumptions about your environment, please correct me if they're not true (as it will mean that my conclusions might not make sense.)
So, it sounds like you're talking about having two separate css files in your code tree. One file that has all the CSS for all browsers, and another one that's just for IE.
Also, I don't know what kinds of sites you build, if they're more like web applications, or modular things that product managers control through a back-office style application, or static content sites, or what. I don't know how often they change, or the likelihood of using parts of one inside another. Not every website is the same, and the problems of one are not necessarily the problems of another.
Yahoo's problems and priorities are possibly not yours. In particular, the Yahoo home page is very unusual. It probably doesn't make sense for you to do anything at all like www.yahoo.com, because I'm guessing unless your company is google or microsoft or aol, you don't have any sites with that kind of requirement.
Subsequent page views? That page doesn't get subsequent page views. It loads up when they click the blue "e" or the compass or the red fox, and they click a link, and they're gone. For about a billion people, that's what "internet" means. Milliseconds matter. The demographic is insanely broad.
On these kinds of media sites, especially when you're talking about a company with several thousand engineers, it's important to build for modularity and reusability. What that means in practice is that we almost never have a single "style.css" in the code tree for a site. On every property where I've worked (games, food, brand universe, buzz, and yap), we split up the css files per-module.
Then, there's a build script that concatenates the CSS, minifies it, and puts it on an edge-cache origin server for our content delivery network. (Actually, when I was on games, we had no such script, did it manually. This sucked like you would not believe!) Besides being physically close to the user, the CDN edge caches also force far future expires headers and gzip the content. (In development, we serve the CSS files locally, so you see a dozen local CSS files in dev mode, but only one in production. This way, we still get the tweak/save/switch/reload we webdevs love.)
6 months later, some part of some module has to change. It's important to be able to quickly find the relevant code to change, and be able to make that change with the confidence that you won't break the rest of the page in the process. There's a good chance that the person making the change isn't the person who wrote the module in the first place.
Modularity. Reusability. Consistent conventions. These are so crucial.
If the ie hack css is far from the module's "normal" css, then that adds an additional burden of discoverability for the coder who comes along later to fix or alter something. It seems like a little thing, but those little annoyances add up fast.
Also, it puts additional complexity in the CSS build script. If I can just tell my build script to pull in `find htdocs/css/ -name *.css`, that's very simple, and almost impossible to mess up. Deployment bugs are the most costly in terms of PR, effort, and morale. They are to be avoided, even if it means sullying up your CSS with a few underscores and asterisks. (Having been highly involved in the build and deployment processes on several projects, I can tell you first hand, hiccups at the last minute SUCK.)
The _property and star-property hacks are safe, they work, and they're very well known. They keep the "hack" rule close to the "regular" rule it modifies. They allow the build and deployment processes to be stupider, which reduces bugs.
What's more, they're not actually illegal CSS! The CSS spec explicitly tells browsers what to do with unknown CSS properties, and _height is just another unknown property. It doesn't break the parsing, and is only a few extra bytes to download. Compared with the HTTP connection overhead of making a second request, those bytes are a rounding error.
Seriously, try it. curl -I your css files, and check out how many bytes are returned. Then gzip both the files, and do the math, for what's sent to the user if they're concatenated vs separate. Add in the fact that only 2-8 HTTP requests will actually go in parallel, so that second file is blocking an image that could be downloading. The Yahoo exceptional performance team has measured hundreds of different sorts of web pages across our network, and the #1 way to improve performance is to reduce HTTP requests.
Like I said, Yahoo's problems and priorities may not be the same as yours. And that's great. You probably don't have a jillion users, or a few thousand engineers. You probably don't have people changing projects regularly.
Still, even in the situation you've described, I fail to see the pragmatic up-side of using multiple css files instead of _property and star-property hacks. If you have two CSS files to manage, wouldn't one be at least a little easier? While you say that you don't want to "burden" non-IE users with the extra rules, isn't it worth the unmeasurably small hit for them in order to significantly improve performance for the other 70%?
You're still using a hack. You're just using one that requires you to alter your markup, keep the hacked rules far from their canonical siblings, and serve multiple files instead of one.
And before jumping either to CSS hacks or CC remember that often there are ways to avoid hacks altogether. As Andy Budd once told at his talk at @media conference in London it is so sad that too many webdevs think that CSS hacks is the normal way to do things. They are not. Instead of thinking "what hack shoul I use to fix it?" one should first think "how can I rework it to fix it in IE without hacks?".
When there are no hacks there is no problem of "where do I put my hacks in?" to solve.
I think I have used only one hack: _width to solve broken box model in IE5 (which is no longer relevant. And I don't count setting display: inline on float to avoid double margin bug in IE6 as a hack.)
And I like the smush.it linked in the presentation that 'minifies' your images.