To Hack With It
Published 19 years, 1 month pastTo follow up on what I said recently, there’s another major reason to remain un-stressed about the impending release of IE7 and the use of CSS hacks. If you read over the list of things that have been fixed, they read like a who’s who of CSS hacks—and a who’s who of the reasons we use most CSS hacks in the first place.
How is that the ticket to a stress-free existence? I’ll give you an example. One IE bug I deal with a lot is the doubled-margin float bug. So I’ll write something like this:
#main {float: left; width: 30em; margin-left: 150px;}
* html #main {margin-left: 75px;}
I’ve halved the margin value in the “IE/Win only” line, which is the second one; that’s the CSS hack part of the duo. By taking this approach, the layout is consistent between IE/Win and every other modern browser out there.
Okay, so here comes IE7, which the team says has a fixed CSS parser so the Tan hack (which is what I used) isn’t recognized. That means IE7 completely skips the second line, the one with the hack. But IE7 has also fixed the double-margin bug on floats. So the hack rule is completely ignored by IE7, and it acts like other browsers when reading the first. It’s like it was Firefox or something. Meanwhile, any IE6 users out there get a consistent experience thanks to the Tan hack line, which it still recognizes.
So why aren’t I proclaiming that there’s absolutely nothing to worry about, as opposed to declaring my intent to stand pat? Because the promised fixes are just that: promises. I have no doubt as to the IE team’s deep desire to get these fixes shipped. They may, however, find themselves overruled by other factors on one or more fixes. Perhaps a given fix breaks the layout of eBay, or interacts badly with a particular version of Windows. Simply put, forces beyond their control might lead to a shipping browser that doesn’t fix everything they want to fix.
That’s a big part of why I said I wasn’t going to make any moves until we have a working release in hand. There’s absolutely no sense in rewriting all our style sheets to remove hacks—at least, there’s no sense right now. We’d be trying to author against a moving, distant, and phantom target. That’s a recipe for frustration.
In general, if the planned fixes do come through, then as far as site breakage, the advent of IE7 will be practically a non-event in the standards-oriented design community. Assuming those fixes are released, we’ll honestly have next to nothing to do. Yes, there will be examples here and there of sites doing funky stuff and experiencing problems, as with Slashdot. Those problem sites will be identified and fixed one way or another—maybe new hacks, maybe conditional comments, maybe reformulations of markup and CSS. The same basic thing happened when IE6 came out, and I suspect we’ll have less upheaval with IE7 than with IE6—and IE6 was pretty small stuff, site-breakage-wise.
Note that I suspect. I don’t know. Nobody can know until the IE team releases a version with the fixes included. When that happens, then we’ll start figuring out which way to jump. Or I will, at any rate. If anyone out there wants to do a little pointless panicking ahead of time, well, be my guest.
Comments (24)
I hope it works that way, because it should work that way.
We keep talking to our clients about forward compatibility, I hope Microsoft won’t disappoint us with this.
Thanks
If a site like eBay breaks in IE7 because of some new fix, then that’s eBay’s (or other site’s) problem and it’s very likely that the site will get fixed very quickly after IE7 is released.
Such results should not place any forces whatsoever on the IE team (particularly if any breakages are only minor design/layout issues that don’t affect accessibility), it’s the web site’s problem if the site relied on IE6 bugs. (If, however, it breaks because of new bug introduced in IE7, then the IE team should, of course, fix it.)
That’s a nice thought, Lachlan—very idealistic. That just isn’t how it works, though. If QA comes back and says “the new beta mangles eBay” (or some other major site) then the marketing folks are going to go ballistic, demanding the browser be ‘fixed’. Or events to that effect.
It happened a few times at Netscape when I worked there. We were very proactive, offering fixes to sites and working to do as you suggest, and had some internal support for that mission (heck, it was part of why they hired me). But when it came down to it, if a site wouldn’t change and it was big enough, the browser bent to accommodate the site. The same can very easily happen at Microsoft.
There will be forces operating on the IE team, and saying they shouldn’t won’t make it so. I hope that the team can avoid or sidestep such forces; I really do. Nevertheless, I’ll be completely unsurprised—disappointed, yes, but unsurprised—if they get caught by a situation like I described.
I was under the impression that they said they’d already fixed these problems. Are you saying you think it’s possible they’ll revert the changes before final release?
I’m not concerned about Internet Explorer 6 bug fixes not being exposed to Internet Explorer 7. I’m concerned about Internet Explorer 6 substitutes for display: table-cell not being exposed to Internet Explorer 7. They are being very quiet about display: table-cell, I don’t expect them to implement it.
Which is fine of course, they can’t do *everything*, but I think it’s a bit ignorant of people to say things like “Don’t worry! Internet Explorer 7 has all these improvements, so your code will automatically work!” Not that *you* are saying that of course, Eric, but a hell of a lot of people are.
The fact is, Internet Explorer 7 *will* force me to recode a lot of pages, and because they’ve taken away the * html hack, it means all our sites will now incur an additional request for an Internet Explorer stylesheet (an inline style element is a non-starter, and you can’t use conditional comments inside your main stylesheet).
PS: how about bumping up the font size in this comment box? I chose my font size for a good reason.
And to think I was feeling smug because all my recent projects have used conditional comments to add an additional style sheet to IE below version 7. Well for 5, 5.5 and 6 (5 for PC is still in my browser support profile).
But maybe I should not be so smug, now we are looking at exactly what IE7 will fix and what it will leave “broken” for backward compatability. And by broken I mean works the old IE way not the way everybody else reads the W3C specs.
And if IE7 causes major problems with a ebay, google, amazon, hotmail or yahoo site and the IE7 team can not convince to fix the problem. I am sure the final release of IE7 will have a work around so that any of the big sites ebay, google, amazon, hotmail and yahoo will look exactly the same in IE7 as IE6.
But hey all I have to do is add an extra conditional comment and new stylesheet for IE7 :-(
Hmm…and I had almost started patting mysel on the back for making my CSS layouts look identical both in IE and Mozilla :-).
I bleive the IE team have committed to fixing bugs in standards mode, but leaving the non-doctype bugs mode as it is.
If you don’t use standards, your site should stay as-is – if your site uses standards, but you are only using the MS broken version, then things may cahnge.
Those that have used hacks to pass standards css to good browsers and patched up css to IE6/5 should see no changes. The last statement is too idealistic and we probably will see cahnges, but hopefully they will be minor or easy to fix.
I hope that the situation when browser adapts to the site is allready a past … i hope …
Otherwise there wont be a lot of changes in the new IE, for me its clear, that to move on, IE will have to break a lot of things and we will have to accept it.
Since the past IE versions were “broken” – a lot of the sites are “broken”, and when IE will move on, the sites will be obliged to make the move as well. Since IE controls the market, we have no other option but to adapt to its changes, and as at the moment there is no “stable”(close to the release) version of the IE, i think we cant do much but to wait for a stable version(perhaps a RC) and then to adopt our sites to it.
See, this is exactly what I was talking about. Use hacks to pass display: table-cell to “good” browsers and patched up css to IE6/5 and see how far you get.
Pingback ::
write.myobie.com » Blog Archive » IE 7 will break your site
[…] s release or a release date is known. I am not going to waste my time with this. It seems Eric Meyer agrees with me.
[…]
Pingback ::
Podcast #12 | BrunoTorres.net
[…] olvedores para tirar os CSS Hacks já que eles (possivelmente) não vão funcionar no IE7 (comentário do Eric Meyer sobre o assunto); ainda teve a história do maluco que co […]
Jim, I misphrased my comment – you use the hacks to pass patched up CSS to crap browsers. A good browser will ignore the hack and apply the correct CSS code.
If IE7 fixes its rendering bugs then all the CSS hacks I’ve used (presumably fixed in IE7) will have no effect.
“It happened a few times at Netscape when I worked there. We were very proactive, offering fixes to sites and working to do as you suggest, and had some internal support for that mission (heck, it was part of why they hired me). But when it came down to it, if a site wouldn”t change and it was big enough, the browser bent to accommodate the site. The same can very easily happen at Microsoft.”
So you mean we may have actually found a situation here where we would cheer on Microsoft to use its monopoly and ignore the rest of the industry?
That’s ironic.
I noticed that IE7 was out long while before the bloggers wrote about it. I also knew the hacks were not working. While I was learning CSS, i continually went into the source of MSN.com and found that they use the hacks very often in their css file for all sorts of browsers (e.g. safari, ie/mac, ie/win, firefox).
Yet it was peculiar to notice they had a conditional comment for “IE7” all of a sudden up. (I went into the source continuously, so i noticed changes as well.) I knew then that even the MSN.com team were having trouble as well.
The only thing that the IE7 team has to keep in mind is this: follow the W3C standards, plus create an updated version of FrontPage that follows these standards.
Then:
a. amateurs will have the chance of building websites that are W3C compliant.
b. professional webdesigners, like me, will have a job, because “bigger” sites will have to follow these standards too and that’s not as obvious as it seems.
Pure economy!
Pingback ::
netgeek.com » IE7
[…] sing less. We’ll have to wait and see.. Eric Meyer offers us some hope in his post To Hack with it. And for those of you interested in testing, but don’t w […]
I’m finding some designers are mistaking the Tan Hack, along with the fix that is in IE7, for the global white space reset. Not a good thing when the amateur designers misunderstand what is being corrected and what isn’t.
Wow… I just came across this post, and after reading so much about IE7, conditional comments, etc., it was nice to find someone who put in words exactly what I’ve been thinking. You’re exactly right – keep up the good work.
It might be a naive question, but what’s wrong with using the !important hack for IE?
margin-left: 150px !important;
margin-left: 75px;
I use it all the time and wouldn’t like to find out it’s a mistake to use this syntax.
Just an oppinion, but, if Microsoft and it’s IE are making people such a problematic existance for such a long time and with no solid hope for a brighter future, shouldn’t it simply be banned from the market and the users be announced / warned (on MS’s expense, ofcourse) to switch to a BROWSER ? If it would be in my power, that’s what I’d do, with no regrets at all …
There is a css hack that works for all versions of internet explorer, including ie7. You can read about it here:
The IE7 CSS Hack
Pingback ::
Josh-Kerr.com » IE Sucks
[…] http://meyerweb.com/eric/thoughts/2005/10/18/to-hack-with-it/ […]
Pingback ::
graphiceyedea » Blog Archive » IE6? IE7? …to hack or not to hack?… the dreaded question…
[…] To Hack With It – Eric Meyer […]
This also triggered in IE7. I don’t understand how that could be.