Embedded CSS hacks vs separate cascading styles sheets

Question

I believe this is not the popular stance but I prefer embedded hacks such as * and _ in the style sheet rather than using separate IE specific style sheets. At first I tried separate style sheets but I found the scope of having the styles for the same elements span multiple files to be painful to maintain. It was not obvious while changing a style in the primary style sheet that I also had a corresponding style in one of the IE specific style sheets. Often time these style changes where so minor such as a minor adjustment of the padding that the extra time to test it in every browser seemed excessive and thus did not always happen.

If the hack was just included directly in the primary style sheet however, it would have been obvious that the style for IE 6 needed to be adjusted and tested as well. I can hear people saying you should test every style change in all of your supported browsers, but in the real world I find this stance unrealistic, and I do not see all of the developers on the team following through with it.

I understand that including the hacks makes your CSS not validate but I have found that I can quickly scan the validation results and ignore the errors regarding those hacks. In my opinion I would prefer to have a little more work interpreting the validation results than dealing with the site being rendered incorrectly in IE 6. I have also read elsewhere where people will not do hacks or separate style sheets but instead adjust/simplify the design so it will work for all browsers. Unfortunately the developer implementing the design does not always have this option when they are not in charge of the design. Plus the amount of hours I have struggled to get minor padding issues to work in all browsers just to avoid a hack nin hindsight seems pretty wasteful.

I am interested in others thoughts and justifications for their stances on this paradigm.

Answer 1

Well, I sort of fall into the same boat... if I can put in one * html #id instead of doing a whole conditional comment and specific ie6 stylesheet I'll do it. It may not be so elegant, but it saves a whole new CSS file to maintan.

However, If I end up having lots of * html and * prefixes, or the ultra long IE7 hack (which I can't recall right now), I'll prefer a conditional stylesheet.

I don't really see * html as a true hack... it's a valid selector (as far as I know), it just shouldn't work because there is no parent element to HTML (except for some reason in IE6). However, prefixing a property with an underscore or specific character does make the selector property invalid.

Another one I don't mind is using display: inline for IE6 to fix the double margin when an element is floated. I use this in my main CSS as it doesn't affect other browsers (only block level elements can be floated), and it's a hell of a lot easier to maintain. I generally leave a little note, something like

#my-div {
    diplay: inline; /* ie6 */
    float: left;
    margin-left: 20px;
}

So I'd say if it's a few hacks, I leave it in my main CSS. If it becomes unwieldy (and it often doesn't as I know the common ways that IE fail), I'll create an extra stylesheet and use conditional comments.

Answer 2

those are HACKS not CONDITIONALS.

don't get me wrong i do the same :\ sometimes its on a case based scenario. if your dealing with large scale websites use CONDITIONALS.

if your doing some crap u don't care about use hacks.

difference is the following:

HACKS - work for the time being, that is until someone fixes them, which they probally won't CONDITIONALS - GUARANTEED to work

Answer 3

I've used conditional comments to wrap the page in DIVs with ids, targeting the correct IE version, like described here.

This is much easier to maintain (like you said), keeps your css valid (no errors to overlook) and is more stable than hacks...

Answer 4

This might be offtopic, I'm not a guru of CSS... however, have you tried SASS?

http://haml.hamptoncatlin.com/docs/

I find CSS rather poor as an expressive language for styles. Lateral thinking, if you had a central protoCSS with your master style and it could translate them to the appropiate browser version, I think you would have it the best way possible: maintainable and simple to work with.

Sass is not exactly that, but it shouldn't be difficult to change it to that. If you aren't a developer I'm sure you will be able to convince Hampton or someone else to code it.

Answer 5

I've done some extensive work with CSS, crossing almost every browser under the sun, for small projects and large. While there is always asthetic appeal to any kind of code you may write, I think the greater concern is maintainability...and this goes for CSS as much as for any other kind of code.

While organizing your hacks and other css "fixes" into separate files that are loaded via conditional logic is nice from an asthetic perspective...it can actually create maintenance hassles down the road.

In my experience, its best to keep your hacks with the base CSS they are fixing for any given browser. This keeps CSS that styles some particular element of your UI together in a single place, which makes managing that CSS significantly easier, and also makes it clear where future fixes for possible (or probable) fiture browser css bugs should be placed.

In addition to placing your hacks just after the base css they relate to, you should also make sure its clear what a given hack fixes, along with the browsers the hack supports, with comments. I have worked on some large projects that used CSS extensively and in advanced ways, but we still had to support IE6. Long term, my team and I (which, btw, were all C# developers...at this particular job devs not only coded, but also did all UI implementation according to UI mockups created by our graphic designers) learned that you can actually use CSS to properly style pretty much any site without the need for hacks (it can be difficult, and requires some extensive knowledge of how CSS works...but it is possible to solve almost every bug in IE and Firefox without hacks...just clever/proper use of valid CSS).

Before my team learned enough about CSS to accomplish that, however, we had more hacks that we could count. Keeping our hacks grouped together with the base css they fixed along with tagging each hack with a reason and the browser or browsers that hack supported went a long way to keeping our monstrous CSS files maintainable. Not only will this help improve maintainability...but as you learn more about CSS and figure out ways to avoid hacks...you'll be able to remove them little by little as you fix up existing CSS to use your new tricks. Since your hacks are right next to the CSS your improving, its easy to get rid of hacks that are no longer needed.