IE7 Hacks

Microsoft has fixed much of the bugs that plagued IE6 and in the process removed the filters we used to target Internet Explorer in our CSS. As Lord God Martha would say, this is a good thing.

However, there will be a time when you need to send a rule to IE7 and not to IE6. Or perhaps you need to send a rule to IE7 and to IE6. I’ve put together a test page of IE6 hacks to see what IE7 doesn’t walk right past. I’m condensing the test page into the paragraph below.

Luckily, there is a loophole for us and we can use this for “offroad use only.” Why am I using this silly description? Because you and I need to move beyond hacks. Place browser specific (IE) in conditional comments or use a serverside script to place a class on the html or body (html class=”ie6″ ) to target these browsers in your main CSS file.

However, these hacks will let you develop your CSS on the fly and fix your issues before going the proper route.

Test Paragraph (condensed version of test page)

this is the test paragraph to see how IE7 will handle hacks

  • IE7 Beta2 understands #wrap>p.borderfun and applies correct color.
  • IE7 Beta2 ignores * html p.borderfun styles.
  • IE7 Beta2 recognizes the * hack.
  • IE7 Beta2 ignores the underscore hack.
  • In Firefox, Safari, and Opera, you should see a red border. In IE7, you should see a black border. In IE6, you should see a pink border.

How to use this

If you need to send something to IE6 and nothing else: use the underscore attribute hack (_border:1px solid pink;) If you want to send something to IE7 AND IE6, use the *attribute hack (*border:1px solid black;). If you want to send something to IE7 and NOT IE6, use a combination (*border:1px solid black; _border:1px solid pink;).

A call to arms

Get out there kids and begin removing your * html rules. Place those suckers in a conditional commented css file or at least begin replacing them with the underscore hack. When it comes time to tune for IE7, you’ll have less work to do.

4 thoughts on “IE7 Hacks”

  1. But isn’t the browser specific code exactly what we don’t want? Isn’t that the point of web standards? I won’t be using hacks, but I will be using valid CSS of any supported level. If the IE users get less of an experience, it’s the browsers fault…I’m just not convinced on the browser specific comments since it seems completely counter-intuitive to what the professional design community has been moving towards for many a year.

  2. Edward wrote:

    I won’t be using hacks, but I will be using valid CSS of any supported level. If the IE users get less of an experience, it’s the browsers fault…

    Actually, if the user gets a degraded experience, when workarounds exist. . . then it is not the browser’s fault, it is yours. Hiding behind the “I don’t do hacks” argument is great if you have 10 people viewing your site and all of them use FF or Safari. But hey, you keep up that great browser snob attitude. . . . It lets the rest of us who simply build better sites that work in all browsers get more work.

  3. Well, I’m not sure if I’m really explaining myself well. If by hacks we’re saying using large margins on tags to combat the the box model problem in IE 5 Win (which I don’t really believe is a hack), then sure I’ll do that. Actually, forget about hacks. I’m just very frustrated by how things are shaping up with IE 7. Yes, things aren’t done yet and I pray that we end up with a far better result than Beta 2. Here’s what I see:

    Using browser specific comments puts absolutely no further in the web standards world. What is one of the most important points of web standards? That we code one page/file/whatever and the result is the same in every browser and thereby improving accessiblity, cross-platform rendering, and everything in between. Browser specific code gets us nowhere. It’s the same path of logic as a hack. And that makes me bitter.

    Tantek nicely notes in his well-popularized WaSP post last November that “CSS2(.1) doesn’t say you can implement part of the spec. You’re supposed to implement the whole spec in the first place.” This is exactly what IE 7 must do. I have trust in the IE 7 team that things will get sorted out. The reason they’re doing this extensive beta testing and opening themselves up to the war-mongering Microsoft haters is to improve their browser. WaSP’s work with them hasn’t just been flushed…they’re trying. But as far as things have gone right now, I’m unhappy.

    None of the code we right should be considered hacks. Because when a browser is advanced or “modernized” like IE 7 should be, then the site should look just fine because it has properly implemented the level of CSS that it set out to do. I don’t really see anything I write as a hack. It’s proper code, well within the specifications, and all validates. As Tantek also noted, it’s harder for a new comer into the standards based market.

    To sum it up: “Don’t implement [an advanced] selector, until that browser is able to do so. IE5/Mac did so, so can IE7, more than five years later…”

Comments are closed.