IE7 and IE7

Published 19 years, 2 months past

As noted on the WaSP site, the IE team is asking developers to clean up their CSS hacks because they’re causing sites to break in IE7 builds.

I have to admit that this call elicited an arid little chuckle from me, because it’s a case of chickens coming home to more than one roost.  There’s the fact that bugs in older versions of IE led us to use hacks, and so they’re making life harder for the IE team.  And then there’s the fact that the use of hacks is an inherently risky and fragile process, so the release of IE7 will make life harder for those who used them.  No smug self-superiority should be read into that second point, by the way: I quite firmly include myself in that crowd.

So—now what?  Personally, I’m not going to make a move until an IE7 beta with new CSS behavior is released.  Why change hacks just to have to hack more?  Put another way, if the ground is going to start shifting, there isn’t much sense in trying to guess how.  Wait until it does, and then adjust your footing.

Still, it might pay to consider ways to cope once the ground shifts.  This leads to something I’ve been pondering for a bit, and now’s a good time to bring it up.  When IE7 (the browser) comes out, it will make IE7 (the script) even more useful than it is now.

Here’s why: all the stuff that IE7 (the script) does, IE7 (the browser) is supposed to do as well.  That is to say, the script can bring IE6 up to par with IE7 the day IE7 is released.  See where I’m headed with this?  Instead of being chained to the fat tail of IE6 installs while being unable to use parser hacks in IE7, we can clear away the hacks and have IE6 and IE7 act basically the same.

They will of course not act exactly the same, and yes, there are drawbacks.  IE6 users will have to download the extra script, and those with JavaScript disabled will have problems.  Not every site will be able to accept those costs—but I’d wager the vast majority will.

In the main, it will be a lot less painful to clear out the hacks with IE7 (the script) available than without it.  A lot.

Oh, and before people start exhorting the use of conditional comments instead, it’s still too soon to know how good an idea that might be.  Doubtless they’ll come into play, but exactly how is completely unpredictable until we know what IE7 actually does.  Perhaps we’ll start using conditionals around the call to IE7 (the script).  Perhaps not.  Time will tell.

As I said before, it’s too soon to know which hacks to clear away or how to rework our code, but thanks to Dean Edwards’ efforts, I’m feeling a distinct lack of stress over the impending shifts.

Comments (36)

  1. Eric, you are so on the money! I always saw a difference between IE6 and “standards compliant” browsers. The IE7 script is an attempt to elminate those differences. I said to Molly a while back that the IE7 script would become realy useful when Microsoft sorted out the real IE7.

    Microsoft have been using my script themselves:

    http://beta.asp.net/

  2. Since you’re the “Godfather” of CSS (reference to the WE’05 podcasts) I appreciate that you spoke up and sort of calmed the worried masses (myself included). I’m not really sure what IE7 will bring, and like you, want to wait until some sort of stable build before I fret about how to deal with its various idiosyncrasies.

  3. I must say that although IE7’s fixes are a welcome break, I really am not going to change my ideology: make it standards-compliant, then complain about the browsers which aren’t standards-compliant.

    You can see why people don’t often ask me to build them websites. :(

  4. While we can’t know for sure how IE 7 (the browser) will handle web standards and CSS rendering, my personal opinion on this is more of a wonder why CSS hacks were used to begin with (as opposed to conditional comments or scripts).

    The way I see it, we have had (and still have) a choice to either litter our CSS files with hacks, or we could implement it with a solution like Dean’s with using cover-up scripts or having scripts include style sheets for IE only to handle bugs/quirks.

    From my humble point of view, having CSS hacks in the file/-s that gets served to all and every visiting web browser seems like the least attractive idea, relying on behavior that can break in the most horrible ways.

  5. I still see the biggest problem with conditional comments simply that you have to modify the HTML to use them. In other words, you can’t simply include one CSS file which then has various sub-includes or sub-sections or single conditional rules/properties for a specific browser. Instead your HTML suddenly looks like this:

    And God help you if you have a style switcher.

  6. I agree. As I mentioned on the IE blog, I believe that the conditional comments are an unnecessary additional bloat. The comments will be wasted on those browsers that a) are not IE, and b) don’t have javascript enabled. So, the conditional comments only apply for IE with JavaScript enabled. In that case, why not just include an external JavaScript as normal, and within the script, do your own browser testing – if it’s IE, then include Dean’s script as an additional requirement.
    Of course, that means that there are numerous external scripts being applied, but then – this /is/ to fix older browsers, and downloading a new browser that does not require the fix is free.

  7. OK, forgot to encode entities above …
    That was a normal link element, followed by three link elements in conditional comments, one for browsers < 6, one for = 6 and one for 7.

  8. A good browser hack exploits the browser in the following way: a standards based browser will ignore this code, a crappy one like IE6 will not ignore the code.

    So, the broken parser feeds modified code to workaround a broken renderer. If IE7 fixes its parsing and rendering bugs, then IE7 will treat the hacks like any other standards compliant browser – it will ignore them.

    Where’s the problem?

  9. The problem is they are Microsoft, and as the Goliath of the software world the meaning of “we’ve fixed all the bugs in…” doesn’t mean they actually REALLY fixed them like they should be so that IE could become a truly standards compliant browser. Rather, I think it means we’ve found a way to make it support “a,b,c” without scrapping the whole browser and starting from scratch.

    I personally doubt that IE will ever truly be a standards compliant browser in the sense that Firefox, Opera, and Safari are. There will always be things you have to do to your web pages because it’s IE… These conditional statements are just the first step of that…

  10. Michael: the problem is that the IE 7 development team can’t guarantee that every rendering bug will be fixed. There are too many, and they’ve got deadlines.

    So, the parsing bugs will be fixed, but some rendering bugs won’t be. Thus some sites with parsing bug-based hacks will break in IE7.

  11. Michael, this is my thinking as well. They seem to be touting it as a great advancement in standards compliance in various ways so if that’s the case, ideally it shouldn’t have any problems with the present-day hacks.

    Paul, I think in this day in age, not fixing a few bugs that can cause thousands of sites to break is fairly unacceptable, deadlines regardless. I’d rather they take a little longer to fix the bugs than tell the developers of the world to fix all the sites they’ve done because they can’t fix a few bugs. Mind you, I’m not one of them so I’m sure it’s much harder than I can imagine but if it means that IE7 becomes a fantastic improvement over IE6 in all the right areas, I’d rather wait for it.

    I like the idea of keeping everything contained in one CSS file with a few hacks necessary at the top to import other CSS files instead of loading up the markup with conditional statements that shouldn’t be needed in the first place. I wouldn’t mind working with Dean Edward’s script to help IE6 play nice with newer sites but I’ve noticed it seems to break printing styles somehow. I could be way off base about that though as I haven’t tested it thoroughly.

    Just my two cents.

  12. I think IE team did right when asking to start cleaning CSS hacks,
    this is the only way of doing “their best” to avoid the developer problems. The problem itself is in older IE, in its implementation of the web standards.
    Just imagine, what would happend, if they would anounce it just 1-2 weeks before the release, or even a few weeks after =O) – a lot of bashing from everywhere, that noone has ever thought, that any such thing could happend … =O)
    It makes sense to anticipate the new changes in some of the future sites, but one cannot implement a functionality from Microsoft which is not present and not available (a promise is a nice marketing word).
    As for me, I am not going to make any changes until i see some IE version, which is going to be somewhat closer to the final release. There is no need ( and no time =O) ) to make changes for each of the IEs alphas and betas.
    I dont have any doubt that a lot of sites are going to look hmmm … strange when IE 7 will appear, and i am happy, cause its going to prove the reliability of the IE (actually its non-existance), going to give more space for better browsers and more work for us, developers.

  13. If a company builds a site for IE that looks horrible in a standards compliant browser, the argument is: “those browsers are a minority, we need to focus on the main market share.” When IE7 is released IT will be the minority. I’d bet those few problems IE7 users see due to incompatibility with existing hacks will be far less invasive than the horrors that compliant browsers’ users have been seeing on IE-centric pages for years. … just a thought.

  14. I agree that, if the parser and renderer bugs are fixed together, there won’t be a problem – or more accurately, those who have the problem have not applied hacks correctly.

    While it’s understandable that people are still very cynical about Microsoft because of its attitude over the years since IE6 came out, I feel this is unfair to the development team working on IE now. Through their blog they have consistently shown their willingness to listen to the developer community, and their serious intent is demonstrated by Microsoft’s involvement with the WaSP. I really think that, rather than flaming them with the Slashdotters’ “Micro$loth are the suxors!” kind of attitude, we should accept their statements of intent in good faith.

    We should remember that there are still plenty of things we have to do to our pages “just because” it’s Firefox, Opera or Safari, as well as IE – there is no such animal as a completely bug- or quirk-free browser. Given that the specs/recommendations themselves contain ambiguities, and don’t always specify what should be done in some weird corner-case, there never will be (unless the mathematical provability of software comes along a good bit, and the standards are redrafted in the Predicate Calculus).

    Conditional comments have been an invaluable tool for working around the deficiencies of IE and, even if the IE team fail to deliver on their good intentions, will allow us to continue to work around whatever problems remain (or arise). Really, once conditional comments were implemented (and they’ve been around since 1998), using parser bugs to feed special code to IE was a complete waste of time: the mechanism was already in place, without the need for relying on undocumented behaviour which could disappear at any time. The Tan hack would never have been identified (or at least never used)if it had been easier to find stuff in the MSDN library…

  15. I’m not sure that the IE7 team understands the way that this is supposed to work. If they’re going to actually fix the problems that caused us to need the hacks, they should fix the hacks.

    Meaning that the reason that we have hacks is that they’re browser is broken in at least two ways: it doesn’t handle some display issue properly, necessitating the hack, and it doesn’t handle whatever the hack exploits in the CSS itself (precedence, comments, whatever).

    Their job isn’t just to fix what’s wrong with padding or whatever, but also to fix things like * html. Then the hacks won’t matter.

  16. If there are new/unfixed rendering bugs in IE7 (almost inevitable?) then we’ll have to find new CSS parsing bugs that target IE7.

    Some or most of the rendering bugs from IE6 will be fixed in IE7, so MS had to fix the CSS parsing bugs else we would have had a problem – we would have been serving CSS code to fix bugs that don’t exist in IE7, we would then have been faced with the dilemma of choosing support for IE7 or IE6, or finding another workaround.

    Hopefully the majority of rendering bugs will be fixed and our current sites will work fine. Why we need to drop the hacks is beyond me – IE7 should ignore them and take the valid css code. If there are then any problems then it is the IE7 renderer at fault, and not the CSS hacks.

  17. Pingback ::

    Podcast #12 | BrunoTorres.net

    […] e a história da microsoft pedir aos desenvolvedores para tirar os CSS Hacks já que eles (possivelmente) não vão funcionar no IE7 (comentário do Eric Meyer sobre o assunto); […]

  18. I’ve been reading all the blogging going on about this issue and, granted I haven’t read every single post, I haven’t seen any mention of the ie specific “hack” that I use all the time (pretty much the only one, besides specifying height:1% whenever anything involving floats goes screwy in ie), and that is use of the !important declaration.

    I love this “hack” because it validates and uses regular old css. It goes like this – if ie has moved something over 3px to the right when all other browsers seem to get it right, I simply say:

    #something {margin-left:0 !important;}
    #something {margin-left:-3px;}

    Since ie ignores the !important declaration it applies the rules in the second line, while all other browsers apply the rules in the first line.

    Now, if IE7 decides to start following the !important declaration but fails to resolve all the problems that call for me to use it then I’m in big trouble! ;o)

  19. Pingback ::

    torresburriel.com » Lecturas sobre hojas de estilo y est

    […] appened about 8 days ago. For those that missed it: And then the blogs began talking: meyerweb.com/eric/thoughts/2005/10/17/ie7-and-ie7 webstandards.org/buzz/archive/2005_1 […]

  20. Pingback ::

    Martin Bekkelund » IE7: Har du skutt deg i beinet?

    […]

    IE7: Har du skutt deg i beinet?

    Via Eric Meyer og WaSP leser jeg at utviklingsteamet bak Internet Explorer 7 n

  21. MS is quite annoying for me : they claim to do their best to make IE7 to be standards compliant (what is goooood! specially if they want to stay on the run), they ask everybody to throw away hacks for IE6 and IE5 (that everybody uses in the best way they can to correct IE’s problems), BUT, at the same time, they give us a proprietary solution to the hacks (which, IMHO is nothing more than a disguised “offical” hack), what is not the way to do in a standard world (worst if we’re heading to a more “accessible” world). It is amazing how they make things so we have to depend on them … It is frustrating

  22. Does anybody else know of any sites that have successfully used the IE7 script? I’ve tried it on multiple sites of mine and at work with no difference. Maybe I’m using it wrong, but I do want to see it out in the open.

  23. I think IE7 is doing the right thing by eliminating hacks, such as ‘tan’, and trusting us as developers to step forwards and get sites compliant. After all, we did hack IE in the first place, which we knew someday would change.

    My question is, why can’t we just take our IE 5 and 6 hacks and throw them in a conditional statement that links to an ie56.css stylesheet. It seems like this would be the best way to isolate problems with IE5 and 6 and let us develop hack-free (we hope) in IE7.

  24. Once scenario might see ie7 breaking all the sites that use hacks. Users won’t think “oh there using hacks” they will just think ie7 sux because with ie6 their favourite site looked fine. I’m sure this something the ie team have thought about.

  25. Pingback ::

    Tableless » Blog Archive » Podcast Tableless #12

    […] s CSS Hacks de suas páginas por causa do IE7, porque tem uma possibilidade nada remota de o site não funcionar nele. O grande Eric Meyer deu sua opinião sobre o assunto; Sempr […]

  26. Pingback ::

    Max Design - standards based web design, development and training » Blog Archive » Some links for light reading (20/10/05)

    […] John Allsopp has been busy doing Podcast remixes of WE05 Internet Explorer and hacks Response to IE and hacks 1 Response to IE and hacks 2 Response to IE and hacks 3 Res […]

  27. Now, if IE7 decides to start following the !important declaration but fails to resolve all the problems that call for me to use it then I”m in big trouble! ;o)

    Looks like they are (I’m running IE 7.0.5730.11), another workaround (untested, found on another site) is to use IE7’s “conditional comments”. For example:

    ‘[if lt IE 7]’ apparently continues for IE versions

  28. Pingback ::

    PNG Transparenz im IE 5 & IE 6 | bueltge.de [by:ltge.de]

    […] der IE standardkonform! Was und wie alles unterstützt wird, dazu eine Demoseite mit Hinweisen. Eric Mayer hat schon früher ausführlich berichtet, aktuell steht nun Version 2Beta bereit. Diese […]

  29. I cannot thank you enough for this script!!!!
    I’m sort of a beginner at web design – still have so very much to learn – and having to recode everything for IE was just so frustrating.
    I’ve got a bunch of different things on some of my pages for this site – FusionCharts, a javascript nav bar, and transparent pngs. I tried a few of the recommended .png fixes, but they either didn’t work for me or they caused more problems than they solved. This *fixes* the problem!!!! and it doesn’t mess up my other JS-driven business. Thank you! Thank you! Thank you! (now I can move on to the other stuff…)

  30. Pingback ::

    Let Internet Explorer 6 Behave Like Internet Explorer 7 » DivitoDesign

    […] Eric Meyer’s thoughts […]

  31. Pingback ::

    Let Internet Explorer 6 Behave Like Internet Explorer 7 | SulVision

    […] Eric Meyer’s thoughts […]

  32. Pingback ::

    BlogLESS : The IE7 Library

    […] apparently been updated fairly recently. If it works, to quote Eric Meyer: In the main, it will be a lot less painful to clear out the hacks with IE7 (the script) available […]

  33. Pingback ::

    IE7.js a universal solution to IE6 craptastic-ness? | ChrisRenner.com

    […] library, which causes IE to behave like a standards-compliant browser. Eric Meyer has some great thoughts about IE7.js as well. | | | | | […]

  34. I’m confused about IE8.js. I’ve implemented it and it’s working fine in IE6 and IE7. However it seems to be making these two browsers perform better than IE8. Is this possible?

    Specifically the nth-child selector which doesn’t seem to be supported by IE8 (http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx) is working fine in the two previous versions with IE8.js support?!?

    How can that be? I thought IE8.js makes previous versions perform like IE8.

  35. Ok after a lot of searching and sifting through conflicting information I found this:

    “ie8.js adds support for last-child in IE7 and IE6.
    No known solution for ie8.” http://www.webmasterworld.com/css/3939889.htm

    So it seems you, Eric, have improved IE6 and IE7 beyond IE8. Is it not possible to improve IE8 to this standard as well?

    Many of the improvements from IE8.js seem unusable if IE8 doesn’t support them. Strange situation: all browsers support except IE8!?

  36. Hi Eric,

    As this was recommended by you, I had to try it & I did.

    But the results we re not what I had expected. Although, this script has a support for everything every little shortcoming of IE 6, it lacks in some aspects.

    Aspects like unnecessary spacing, margin, padding & really weird problems that wouldn’t appear if the script ain’t used.

    Is it just me or someone else has also run into such problems?

    Regards,
    vinod
    I don’t Hate IE6, it’s just old now.
    Give it a rest

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview