5 Reasons to Avoid CSS Hacks and Conditional Stylesheets

CSS hacks and conditional stylesheetsCSS is more of an art than a science. You can know about every combination of selector and be an expert in every styling property, yet still be unable to lay out and style your website as you want.

There are several reasons why developers from traditional programming backgrounds dislike CSS:

  1. Learning the rules is only half the game – you need experience to really understand CSS.
  2. CSS can be illogical and require too much trial and error.
  3. Even if Browser X renders your page perfectly, Browser Y could fail dramatically.

Many web sites and applications are considered complete only to find that it breaks in a certain browser. Web developers therefore resort to hacks and conditional CSS to fix the issues as quickly as possible.

Unfortunately, quick-fix development can cause more problems in the long run…

1. CSS validation may not be possible
There are many tools, such as the Firefox console and the W3C validation service, that help developers find errors within CSS code. Unfortunately, hacks and conditional stylesheets often rely on invalid CSS to exploit a known browser bug or apply vendor-specific properties. If your CSS is already throwing errors, you may miss the real problems.

2. Your CSS becomes more complex
Quick fixes generally apply further rules to your existing rule set. In the case of conditional CSS, those rules will also be in a separate file and only apply under certain conditions. Whilst tools such as Firebug can help locate and analyse the code, they are not available in every browser. The increased complexity makes debugging and maintenance more difficult.

3. Your CSS may not be future-proofed
Hacks rely on browser bugs. Unfortunately, the next version of that browser may fix the very bug you depended on. This was certainly one of the causes of IE6-compatible sites breaking in IE7, e.g. the * html selector was was incorrectly applied by IE6 but fixed in IE7.

If your website already relies on IE6 and IE7 conditional stylesheets, it is extremely likely you will require one for IE8.

4. It is browser detection
Webpages should be device-independent. Whilst we do not live in an ideal world, browser detection always feels a little dirty. It is certainly avoided in JavaScript and server-side code, so why use it for CSS?

5. There is rarely a need for them
It is unusual to find a design that could not be created by an experienced coder using standard CSS that works in all the popular browsers (and, yes, that includes IE6). Minor rendering differences are always inevitable, but the CSS code can remain clean and valid for all browsers.

Ultimately, hacks and conditional CSS can lead to poor development practices and a failure to diagnose or understand the real problem. The key is to test early and test often: find the issues at the start of the project and you will not need to resort to quick fixes at the end.

Don’t believe me? See 10 Fixes That Solve IE6 problems

Have you successfully avoided hacks and conditional CSS or have they been essential within every project?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • rb3m

    Oh, I believe you. When coding in strict mode I rarely need any fixes for IE7 and usually can fix whatever minor stuff IE6 throws out with less than 10 lines in a conditional style sheet, sometimes just a couple of lines are enough. It’s all in the planning.

  • Phil Nash

    Whilst I will be interested to see tomorrow’s “10 fixes that solve IE6 problems” I take a few issues with this current article.

    I add my IE6 (and occasionally IE7) fixes using a separate stylesheet fed by conditional comments. This allows me to validate my main stylesheet and apply any hacks (like behaviour files for transparent pngs) in the IE only stylesheets.

    Reliance on conditionally applied stylesheets for the buggy IE6 and 7 does not imply you will need another one for IE8 if you are writing standards based, best practice code for Firefox and Safari, as IE8 (apparently) fully and correctly implements CSS 2.1. If your site works in browsers that already obey the standards then it should have no problem in IE8. Perhaps not all progressive enhancements will be included, but that’s a different story.

    Browser detection using safe methods (I consider conditional comments safe, no-one else uses them, but for IE where the problems lie) is necessary because of the multiple platforms that must be dealt with and the fact that the biggest one is the worst. JavaScript doesn’t need to detect browsers because it can detect objects, server side code need not detect browsers as it doesn’t run in the browser, however I bet parts of server side code are written differently for different OSes.

    As I wrote at the start, I also look forward to the 10 fixes that don’t require hacks. But to say you’ll never need a hack is ridiculous, unless you do have a valid method of enforcing IE6 to display transparent pngs correctly. I await your next article with baited breath.

  • Anonymous

    Agreed! So much time can be spent making the hacks work in all the browsers. Test early & often on all your A-grade browsers (esp IE6) to avoid problems during QA.

  • Azizur Rahman

    Its very well you saying all this, bow now can you afford to not to put in hacks when you know that 95% of your users uses IE6 because other major systems in the organisation would not work with latest version of the browsers?

  • http://www.lovezapp.com lovezapp

    Well written. I agree that CSS code can–and should–be standards compliant, spartan, and work in all browsers. I admit I still write conditional stylesheets, but after reading this article I’m going to try honing my CSS skills to minimize their usage. Thanks, guys.

  • James Beattie

    >> Unfortunately, hacks and conditional stylesheets often rely on invalid CSS
    This is not really correct. The point of using conditional stylesheets is that you can use standard css and only show it to the relevant browser. This is the whole point of using the conditionals instead of the hacks!

  • Alicia

    I generally try to avoid hacks and conditionals. I rarely have to resort to them and will if it’s highly important that one little rendering bug bungles a whole page in one browser or another.

  • Gabi Agu

    CSS hacks are not used for the fun of it, but rather to fix browser rendering issues. The problem is not CSS, but the browsers. As long as people will be using browsers that are 10+ yrs old (our dearly beloved IE6), you cannot expect things to work flawlessly just because you, as a front-end developer, respect the standards. That browser doesn’t.
    When it comes to the need for hacks and conditional styles, I believe it’s more of an issue of project complexity/size. For small projects, yes, you shouldn’t be using them. For large scale, complex layouts, they may become necessary.

  • Richard J Keys

    Good article.

    However, in practice (and I’m thinking more of the devil that is IE6) it’s possible to keep most of the nasty CSS hacks etc inside and IE6 stylesheet. Global CSS will usually then validate fine.

    From what I’ve seen of IE8, it tends to behave itself much better so the need for IE8 stylesheets ought to be reduced somewhat.

  • curtismchale

    I write my conditional stylesheets to a specific browser only as needed after trying to make a single sheet work in all browsers. Many of my sites only have a single line to make something work in IE and then only for a specific version. In theory this would allow new versions to serve the normal sheet which future proofs the design/layout.

  • the dooode

    Great post, looking forward to the follow post tomorrow! I’ve always avoided using hacks and conditional stylesheets by nesting elements to get round the IE box issue. I much prefer this as i know the code is valid and will not break with newer browser versions… hacks and conditional stylesheets means 2 sets of code – yuk!

  • developer

    unfortunately, conditional CSS is required in the real world, especially with sites that use advanced javascript to display overlay DIVs and other things of the sort. the main condition is IE6. luckily IE has specific conditional statements, which are valid HTML comments, that other browsers ignore. as long as IE6 is being used, conditional CSS will be a necessity.
    .
    on the other hand, CSS hacks should be avoided if possible.

  • n0other

    I disagree. There are some problems that are unsolvable or hard to solve. These problems are always incompatibilities in rendering between IE and the rest.

    Separate stylesheets served with conditional html comments are the way to go because you:

    * save time by not searching endlessly for an optimal solution which may not be there
    * can target specific IE versions – absolute control
    * do not have to rely on invalid CSS as you would have to if you’d wanted your hacks served from a single file.

    Some problem examples off the top of my head: float double margin bug in IE6, when you don’t want display: inline. Dropdown elements ignoring any element stacking and staying on top, IE6.

    And sometimes, weird rendering incompatibilities which you can’t tolerate if you want a pixel perfect layout, for example, a top padding of 3px for IE instead of 5 for the rest etc. etc.

    About the complexity argument: inexperienced should not mess with stylesheets any way and proper naming conventions and not having to rely on invalid css when serving separate CSS files are pretty easy to grasp even for novices.

    For example: iestyles.css for all ie versions, ie7minus.css for anything below 7 (naming convention used by Magento shopping cart).

    The future proof argument: since you can target specific versions of IE with conditional html comments, any untargeted / future versions with improved rendering would get the normal CSS file and not the targeted ones.

    Please note that I speak about HAVING to solve issues, not wanting something different. From my experience, the only time you HAVE to solve something such way is for IE. Period.

    If, however, you WANT to solve something in a non-standard way, like use -moz-border-radius for round corners, than I completely agree with your presented arguments, such things should be avoided.

    I remember being amazed at wordpress.org navigation – round corners for Gecko users, shadowed text for Opera fans (no round corners), and none for IE. Very very bad.

  • Florent V.

    > 1. CSS validation may not be possible

    True enough. But if you don’t use parsing bugs as hacks, limit yourself to a valid CSS properties and maybe a zoom:1 for hasLayout, the only fix-related errors you will get are “zoom is not recognized”. Not that hard to manage.

    > 2. Your CSS becomes more complex

    Yes and no. Not using hacks mean that you may have hidden complexity in your CSS code: you bumped into a rendering problem, tried several solutions that apply to all browsers until you find something that works for all. Very well. Now you have code that you can’t change as you would expect for other CSS code because it will break something in some browser if you do. Undocumented, transparent fixes may lead to quite a few maintenance issues. ;)
    Or you document your changes (like: “/* We have to use padding and not margins here because the top margin disappears in IE 6-7 if the parent has the layout */”), which is better, but not very different from rules applied to IE lte 7 only. ;)

    > In the case of conditional CSS, those rules
    > will also be in a separate file

    Big maintenance issue. Solution (not perfect, but interesting): use a conditional DIV in your HTML, that wraps all the content, with a class name such as “ISIE67″ (if the conditional comment targets version 7 and lower), “ISIE6″ or “ISIE7″.

    > 3. Your CSS may not be future-proofed

    True for hacks. Not the case for carefully used conditional comments. (So you know what to use…)

    > If your website already relies on IE6 and IE7
    > conditional stylesheets, it is extremely likely
    > you will require one for IE8.

    I have found that to be false. In my experience, if you developed your website with HTML 4.01 and CSS 2.1, you will get very few issues in Firefox, Safari, Opera, Chrome… and IE8. Most websites I worked on before I started testing systematically in IE8, websites which use conditional stylesheets or classes for some IE6 and IE7 fixes, are displayed perfectly in IE8. I was quite impressed with the quality of the CSS 2.1 rendering in IE8.
    (Things may be different for JavaScript, but we’re talking CSS here. ;))

    > 4. It is browser detection

    True. And what’s the problem with that? Three things come to mind:
    1. If you use browser detection to limit access or features to some browsers only, that’s notoriously bad.
    2. Browser detection may or may not be reliable. Most techniques are not. Reliable techniques are a) object detection in JavaScript and b) conditional comments in HTML. Both methods are reliable, but may be used in inefficient or wrong ways, so that requires a bit of experience to get it right.
    3. It takes more time, and maintenance is harder.

    So if you don’t do #1, and avoid bad uses in #2, the only thing that’s left is: takes more time, and maintenance is harder. But the alternatives won’t be really quicker, and may not improve anything regarding maintenance.

    > 5. There is rarely a need for them

    I strongly disagree. It is true that there is less need for them that inexperienced coders think. But you still need them for IE6 and IE7 for a lot of precision work. Which mostly boils down to hammering things into place with hasLayout, or preventing them to be hammered out of place by removing hasLayout (yup, it works both ways, that’s why is a nightmare and I’m so glad there’s no hasLayout anymore in IE8).

  • http://www.cemerson.co.uk Stormrider

    I don’t ever use conditional comments, I hate them. I like my HTML to be pristine, and it shouldn’t be littered with stuff to do with styles like that. I don’t serve different stylesheets to different browsers either, everything gets the same styles.

    However, I do use some hacks within stylesheets – mainly ‘* html ‘ to target IE <= 6. I don’t really see a problem with it either. With regards to IE7 fixing that – yes, it did. That was perfect. It means the fixes I used for IE6 were limited to IE6 and not carried over to IE7, which is a much more compliant browser. Why would I WANT my fixes to carry on to a new browser? The fact that IE7 didn’t understand * html was the perfect situation, in my eyes.

    When IE6 usage drops to a low level, those hacks can easily be taken out without affecting anything else at all.

    Seems like an ideal solution to me!

  • http://www.cemerson.co.uk Stormrider

    I look forward to the 10 fixes article though.

    Surely a property added to the css, that shouldn’t need to be there, but fixes a bug (ie, apply hasLayout in IE, or position: relative, width: 1%, zoom: 1, all those different IE fixes for various situations) are just hacks with a different name? They validate, yes, but that doesn’t mean they aren’t a hack.

  • WebDev Den

    I have to agree with n0other. Although I would much prefer to not have to resort to hacks or conditional stylesheets, making my pages display properly in IE6 makes this necessary. Same goes for Safari to a lesser degree. I look forward to the next article. I’m fairly well experienced with CSS, but I don’t consider myself a “guru” or anything. Anything that helps me keep clean markup and code is most welcome!

  • JdL

    This is bull crap.

    Point 1: CSS validation != practical application. I have not heard of a browser yet that checks to see whether CSS is valid before trying to render it.

    Point 2: Smart people use hacks to simplify their code. Code becomes more complex when you have to bend over backwards to work around non-standards-compliant browsers.

    Point 3: NO CODE is future-proofed. Once it’s written, it’s in the past. As new rendering engines, new devices, etc. are created, you have to re-test your “future-proof” code in them. If I were a CSS coder, I would personally love to tell my managers that the code I write for them is all they will ever need. “It will just work. Trust me.” Guess who would be first in line for the pink slips?

    Point 4: JavaScript actually WORKS in all browsers. CSS does not.

    Point 5: “Rarely the need” depends on who your client is, what your site is, and what code you’re allowed to touch. If you completely control and plan your own code, it’s all good — but in the other 90% of cases, you’re going to have to hack around other people’s code.

    Was this guy seriously paid to write this?

  • Chiseler

    I disagree with this article, primarily because it takes a stance more related to an ivory tower than practical web design.

    Ultimately, what the client (and more importantly the user) really cares about is, does my site work when people try to access it? I think one has to be reasonable about what one targets: how much effort is worth to get your site working in IE4, when barely anyone uses it? Not much. Still, the behemoth in the room, IE6, is still out there, breaking the china, and it cannot be ignored. As web designers, we have a responsibility to address this problem in a standards-oriented way.

    I agree that hacks are not ideal. It’s a blunt instrument whose purpose is to target a specific browser version, but it’s all too easy to mess up. As much as I am not a fan of Microsoft’s bad browser behavior in the past, conditional comments are a much better tool than hacks. They allow one to efficiently and accurately target CSS corrections to a particular browser version without having the potential to harm another browser.

    Quite frankly, it is far more difficult to fix a bug in Safari, Firefox, or Opera, since they lack conditional comments. Yes, those are generally better than Microsoft, but they each use a different rendering engine, and they have disagreements, too, even if they are more minor… they can still cause a problem. The only way to fix these is through hacks, and they are quite ugly. Subsequently, I simply don’t fix some rendering errors in these browsers unless they are critical.

    There are some problems that are genuine browser bugs: why should I go out of my way to change my semantic HTML in order to aid in fixing a browser problem, when that problem could be soled easier through a CSS correction? If I need to use HTML changes to help, I will, but conditional comments help to avoid that.

    Yes, this makes CSS more complex. Yes, it is tougher to validate. But it does allow problems to be solved.

    Part of the problem with this article is the conflation of hacks with conditional comments. They are not the same thing. The issues with future proofing are much easier to solve with conditional comments.

    As for this being browser detection. Yes, it is. Because certain browser versions have bugs that need to be fixed in order for the site to work.

    If you can fix a problem without using conditional comments or hacks, by all means do so. Why wouldn’t you? Knowing the ins and outs of CSS helps make that happen. But sometimes, those fixes are inevitable and necessary. To say otherwise is irresponsible towards the client and the user.

  • StevenHu

    CSS is more of an art than a science. You can know about every combination of selector and be an expert in every styling property, yet still be unable to lay out and style your website as you want.

    Whew! And I thought it was just me!

  • Hugo

    It’s funny how the sitepoint website itself uses 3 conditional hacks for different versions of IE:

    Give us a break! LOL

  • http://designmovesme.com Roy Vergara

    can’t wait for the follow up article tomorrow! March 5th? err today?

  • http://www.studio-gecko.com/ XLCowBoy

    Riiiiiiight.

    I’ve seen one-too-many people saying “I can do any site without hacks”, and always, their sites look like every other site on the web.

    How about this simple (but unfixable) IE6 problem?

    Create a drop down [select] box with options.
    Create a drop-down menu, and make sure the drop-down box appears over the [select] element whenever you hover.
    Oh, what do I see? The [select] box still appears above the drop-down?
    Oh, what if I try to give the drop-down menu a z-index of 9999999? Why doesn’t that work?

    *rolls eyes*

    Sorry, only way to fix that is with a conditional hack. Pew Pew.

    The simple truth is this:

    1) A client wants their site to look unique
    2) Sometimes, making it unique requires a fancy approach
    3) Usually, that fancy approach doesn’t work as it should in IE
    4) Normally, you would need to use IE-specific targeting (such as conditionals or hacks)
    5) Finally, There is no such thing as “future proofing” for all browsers. How can you guess what each vendor is going to produce? Microsoft’s track record speaks for itself: Does IE7 follow IE6? No. Did they follow standards? No. So why would you expect IE8 Follow IE7 or the standards?

    If IE8 renders like it should: e.g. like a Gecko or WebKit browser, then we would no longer need to create another set. However, knowing MS, that isn’t going to be the case.

  • Florent V.

    I mostly agree with n0other and Chiseler.

    I would just like to add that fixing an issue by modifying the styles served to all browsers might cause problems too.

    First, you have to test every supported browser once you make such a change in response to a problem is one browser, because the changes you made may have messed up things in another browser (rare, but still happens).

    But the biggest problem is that you end up with invisible fixes. If every fix is made of valid and discrete CSS styles served to all browsers, then there’s something missing from your code: your knowledge of what problems you encountered and how you fixed them. Which means that someone (even you) modifying that code might trigger a bug even though that bug had already been identified and fixed.

    A way to fix this? Document your fixes with CSS comments. Consequence? Your code looks like it’s complex again. The truth? It was complex all along, you just hid the complexity by not documenting it in the first place. :)

  • http://www.lunadesign.org awasson

    I have to agree with XLCowBoy,
    Once you’ve been playing with CSS for eight to ten years you get a pretty good feel for what you can do and what some browsers (I’m talking to you IE6) won’t do.

    Hacks no…. Conditional Comments yes. Conditional Comments will never (that’s right, I said never) hang CSS or HTML validation because they are buried in comments and ignored by all but IE browsers. They are future proofed as well because they only target the browser you aim for (mostly IE6 but sometimes IE7). IE8 is standards compliant so… No need for a fix.

    These days I rarely have to rely on IE specific stylesheets linked via conditional comments but for complex layouts, I doubt there is any other way to achieve the end results without them and provide pixel for pixel consistency for old IE browsers.

  • kumarei

    I agree with most of this article, but disagree with the part about conditional style sheets. While I don’t think they should be used for most browsers, IE 6 and 7 (to a lesser degree) often NEED their own styles in order to be usable, much less stylish. Fortunately, Microsoft gave us an easy way to target these browsers without touching any other (more standards compliant) browser.

    I strongly disagree with JdL. While I use hacks occasionally, there should be a very good reason to use a hack before you do. Otherwise you end up with one time use code, because it becomes almost impossible to remember what all of the different hacks were meant to do. Add to that the fact that they’re probably going to muck with other things that you don’t intend them to, and you have a nice recipe for code mush. Again, that’s fine if it’s one time use code, if you’re not on the hook to upkeep it, and your client doesn’t mind getting something unmaintainable. But if you want something that will last, that you can reuse parts of, and that you’ll be able to update rather than having to rewrite, I would strongly consider alternatives before using a hack. Remember, time saved now might be time spent later.

  • Conditionally Conditional

    I prefer not to use conditional CSS to target IE if I can help it. However, one of the sites I work on uses some very fancy CSS to reformat tables in a very pleasing way for modern browsers. It completely explodes in IE. Rather than turn a good sized chunck of CSS to using ugly hacks to hide it from IE, it’s just nicer to hide it all together from IE using conditional comments.

    I do not use CSS hacks. Ever. There is nearly always a way to code something that works in IE *and* still validates (and if not, I can always shove it into the IE only conditional CSS file).

  • http://www.yellowshoe.com.au/ markbrown4

    I mostly agree with this article. If you want to create some more complex layouts and support IE6 hacks are a neccessity – the browser just doesn’t support what you are needing. I find myself using * html { height: 1% } to give layout to IE6 and or position: relative to fix bugs.
    min-height: 0; for IE7.
    They’re really the only things that I consistently use to fix bugs. And when functions aren’t supported by browsers like fixed positioning.

    The need to use hacks is becoming less and less so the main points in the article are good ones.

  • http://www.magain.com/ mattymcg

    Great post, Craig. I love suspense… can’t wait to read tomorrow’s follow-up!

  • http://www.optimalworks.net/ Craig Buckler

    Great comments.

    But my main point still stands: you should avoid both hacks and conditional CSS. Once you start using them, there’s a danger you will become reliant on them. It is better to understand the core problem so you can avoid it in future.

    There are some extreme edge cases, but they are the exception rather than the rule. Several situations, such as 24-bit PNG support, are often handled better using JavaScript than invalid CSS.

    As for specific cases, I would say that ‘* html’ is a hack because it’s invalid CSS. However, something like ‘display:inline’ to fix the IE margin bug is not – it’s valid code and it will be in the same place as your main element styling rather than in a separate CSS file.

    Finally, if you stick to web standards, there is no reason why the code you write today will not work in the browsers of tomorrow. However, that becomes increasingly unlikely if you are specifically targeting today’s browsers.

  • krues8dr

    I waited on commenting until after the so-called follow-up article, and it’s all a bait-n-switch. Your 5 reasons and 10 “fixes” don’t take into account any real-world IE6 scenarios. Ever heard of the Box Model bug? Or any of the hundreds of other documented issues? Get your head out of the sand – this is just another fluff piece full of info that doesn’t apply for real developers.

    What is with the poor quality of SitePoint authors these days?

  • http://www.cemerson.co.uk Stormrider

    Who said the * html stuff has to go in a separate css file? And how likely is it that a browser in the future will incorrectly interpret that again? About as likely as a browser breaking some valid css I reckon.

    Just because code is valid, doesn’t make it ‘not a hack’.

  • http://www.lunadesign.org awasson

    Craig,
    I’m interested in having a look at your next article and hope to take some time today to do so. As far as this article goes, I’m not sure it really hits the mark. I think the topic is relevant and I do know what it’s like to submit articles so kudos for getting your material out but I have to take issue with a number of areas that I think misinform your readers.

    The art vs science argument in the intro IMO is misleading because CSS is science as applied to a variety of browsers… It’s more like the experience of how that science will apply in the slightly different environments provided by each browser. Furthermore, It’s not that CSS is illogical; I have found that the reason some traditional programmers may dislike CSS is exactly due to the inconsistency of various browser implementations of W3 standards.

    Hacks and workarounds don’t make stylesheets complex… Stylesheets that control complex web page layouts are complex because they are the rules that control the visual structure of the page. To state that hacks and conditional comments are the reason for this complexity is an oversimplification.

    Yes *html is a hack and we haven’t used it for many years only because it won’t validate. If it would validate, I would still be using it because only one browser would pay attention to it (I’m talking to you IE6). As a result I’ll swear by conditional comments as part of my best practices. Being inside comment tags and the nature of the browser to ignore comment tags, they validate and are future proof. How else are you going to add one or two pixels of left padding to IE6 or change the width of a float:left div so that it looks just like IE7, or FF, or Safari, etc…

    Yes, let’s stick with standards compliant HTML/CSS but when that fails to keep those pesky non-compliant browsers in check, you have to rely on something to do the trick. That the client who still uses (and swears by) IE6 doesn’t care that 75% of the web has moved on to better behaved browsers. They want it to look right in their browser.

    Anyway, I’m sure the debate will rage on so I’m off to do some work and then I’ll have a read of your latest article.

  • MauiMan2

    Personally I use zero hacks but I do put conditional comments to use, albeit very minimally, and the style rules in those conditional comments ARE valid CSS.

  • http://www.lunadesign.org awasson

    That’s a very good point MauiMan2 has made and I should have mentioned that in my earlier post… The CSS that I include in my conditional comments is perfectly valid CSS. It’s only there to override the rules for a certain browser.

  • http://www.optimalworks.net/ Craig Buckler

    @krues8dr…

    Your 5 reasons and 10 “fixes” don’t take into account any real-world IE6 scenarios.

    Which real-world is that then?! ;-)

    Ever heard of the Box Model bug?

    Of course (although it’s not really a bug, rather than a different interpretation of the standards which were incomplete when IE was being developed). In IE6, use a strict DOCTYPE (as stated). You can even get around it in IE5 and IE5.5 by avoiding padding and using margins on inner elements.

    Or any of the hundreds of other documented issues?

    Name a few that have stumped you and I’m sure we can come up with some solutions.

  • Chiseler

    “You can even get around it in IE5 and IE5.5 by avoiding padding and using margins on inner elements.”

    While yes, this can work, it is just as much of a hack as the use of conditional comments. If you’re avoiding margins and padding on inner elements for the IE5s, then that means you’re nesting an extra element inside so that you can define widths and heights on one element while doing margins and paddings on another. Adding extra HTML purely for IE? Yeah, that’s a hack, even if it validates.

  • Stevie D

    XLCowboy:

    Finally, There is no such thing as “future proofing” for all browsers. How can you guess what each vendor is going to produce? Microsoft’s track record speaks for itself: Does IE7 follow IE6? No. Did they follow standards? No. So why would you expect IE8 Follow IE7 or the standards?

    The direction of travel is towards standards compliance. IE7 fixed a lot of the problems of IE6, but MS didn’t really have a handle on how important standards compliance was to the web community even then. The backlash against dodgy browsers and even IE7 has sunk in with the browser builders. It is a pretty safe bet now that each iteration of a browser will be at least as compliant as the previous one, and will not introduce any significant rendering bugs. Any all-new browser that doesn’t meet the standards will be laughed out of town.

    So yes, code that is written to the standards and works in all current major browsers is as future-proofed as it is possible to be. Code that is full of hacks is pretty much guaranteed to go wrong in some browser or other in the future.

  • http://www.optimalworks.net/ Craig Buckler

    Adding extra HTML purely for IE? Yeah, that’s a hack, even if it validates.

    Why do you necessarily need extra HTML? If you have a P inside a DIV, you simply apply margins to the P rather than padding to the DIV.

    You should keep your HTML as simple and clean as possible. Yes, IE5 and IE5.5′s box model differences can throw up problems, but I doubt many developers are coding for them now. Even so, it’s possible to support those browsers if you are aware of the issues.

  • Kim

    (probably already mentioned, but…)

    Amusing – you say “don’t use CSS hacks” then link to a page containing mostly IE6 CSS hacks! :)

    Conditional comments are worth using for IE6/7 when you can keep your main stylesheet clean of crud like this:

    ————————

    #element {
    min-height: 20em;
    height: auto !important; /* understood by all browsers */
    height: 20em; /* IE6 incorrectly uses this value /*
    }

    ————————
    (what a waste of bandwidth for the ~80-90% of people not using IE6!)

    The following method works well for me:

    1. Get the main layout/styles working 100% in a decent browser (Firefox/Safari/Opera) with no hacks and using clean & tidy HTML
    2. Use conditional comments to load an external style sheet for IE6 and IE7 if required (a separate CSS file for each version tends to work well for larger sites).
    3. Do what it takes to get the job done in each broken version of IE

    Also, who cares about valid CSS for IE6 when the browser is so broken in the first place?

    Hope that helps someone anyway :)

  • Chiseler

    “Why do you necessarily need extra HTML? If you have a P inside a DIV, you simply apply margins to the P rather than padding to the DIV.”

    Dude. You do web development, right? You have done layout with CSS, right? You are aware that complex layouts involve positioning or floating divs, and that many of those divs require both widths and padding, eh? And so that means putting a div inside of a div if you want to do width of one element and padding on another.

    Even the P example is bad. If you’re putting margins on a P rather than putting padding on a DIV, that means you would then need to put those same margins on every other text, element, such as UL, OL, DL, BLOCKQUOTE, FORM, TABLE, and more. It’s way too easy to miss something there. Far better to just adjust the width to accommodate the IE5s in a stylesheet served through conditional comments.

  • Nacho

    This article is naive.

    If IE would respect web standards, conditional comments or hacks wouldn’t exist or be necessary. We as developers use them because we really don’t have another choise.

    So until IE reaches the lower porcent of the market, which is highly difficult due to the issue that most people use windows and have that crappy browser as a default one (and most times they don’t even know that there are other posibilities), we are screwed.

    We are all aware about this facts, this article is not ‘enlightning’.
    We use this stuff because is the only way for know.

    Ignacio

  • http://www.optimalworks.net/ Craig Buckler

    that means putting a div inside of a div if you want to do width of one element and padding on another

    There are cases when that may be a solution, but you can certainly minimize it. And this is all assuming that IE5/5.5 is one of your targeted browsers? I thought you wanted to drop IE6 support?!

    that means you would then need to put those same margins on every other text, element

    Why? If it’s sidebar containing a menu, you might only have a single internal UL to style? If it’s your main content block, then perhaps an additional DIV is the lesser of all evils. But if you really cannot face the horror of that DIV, why not apply #content * { margin-left: ...; margin-right: ...; } to start with?

  • Tom

    +1 for disagreeing with ‘Avoid Conditional Stylesheets’ – for the time being, anyway.

  • pooka

    I think this article is more about grabbing attention than anything else. I was going post more but I’m not sure it’s worth it.

    Come on SitePoint bit more substance in future please.

  • http://f3v.ru/ StydayOdode

    Спасибо крупное за предоставленную сообщение. Существо рад разместить ее у себя на дневнике. Если Вы не против, то я так и совершу.Если находимся какие-то проблеммы со копирайтом, постучитесь на мой дневник,я целое исправлю. Так же прибавил Ваш должность на соцзакладки. Вообщем если что обращайтесь, – завсегда выслушаю и осмыслить. Со, почтением, Firestarter.

  • http://blog.afterlight.net.au AussieJohn

    I’m not sure how I missed this article in my feed, but alas, I read the title, I read the 5 points (and then I wanted to stop reading).
    I’m sorry Craig, but if you want me to read your articles, you should post things that are a bit more geared towards real life development, not “airy-fairy ideal-world-without-shitty-browsers” type scenarios.

    The facts are that we DO have to contend with the likes of IE6 (and IE7) and things like conditional stylesheets might be browser detection, not quite best-practice, and take a few minutes longer to code up, but ultimately it’s about getting these sites to display and work well in these browser, if that means sacrificing a bit of standards, then unfortunately so be it.

    Please don’t take this the wrong way, I love standards, I’m a big fan of them. I hate IE6 and the fact that I still have to write code for it. However, a utopian perspective on these issues will not help me when I need to fix something for IE6 only, a conditional stylesheet with some specific CSS will though.