Geius,

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.

Compare that to http://buzz.yahoo.com or http://games.yahoo.com or http://shine.yahoo.com or http://news.yahoo.com, to name a few. While http://www.yahoo.com gets more page views than any other single page on the internet, the majority of our traffic is on these more traditional "content" pages, not the portal.

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.

?!