Internet Explorer 7 and * html

When Internet Explorer 7 is released, probably later this year, it looks like one long-standing CSS selector bug in IE will be fixed: the Star html Selector Bug, also known as the Tan hack. Since the bug has been used by many web developers to target specific CSS rules at Internet Explorer as a way of working around various CSS bugs in the browser, some are worried that Microsoft fixing the bug in IE 7 may cause developers a lot of extra work.

If the CSS problems that authors have used the Tan hack to provide workarounds for still remain, there will indeed be trouble. But since Microsoft are also saying they will fix a lot of rendering problems related to CSS in IE 7 there is a reasonable chance that the problems that caused developers to use the * html hack have also been fixed. In that case all should be fine.

But we don’t quite know yet, and there are those who, like John Gallant of Position Is Everything, are opposed to the Star html selector bug being fixed. Microsoft’s Internet Explorer team, on the other hand, advise developers to completely stop using CSS hacks and instead use conditional comments when Internet Explorer needs different CSS.

Molly E. Holzschlag has written a summary of the Star html discussion in Star HTML and Microsoft IE7 and points to John Gallant’s article that explains why he believes that the star HTML bug should not be fixed in IE 7: Wither the Star-HTML hack?. Accompanying the article is a poll where developers can vote for how they believe the removal of the star-HTML hack will affect them. Comments on the poll can be made at Molly.com in star html poll comments.

Phew. That’s a whole lot of noise for a CSS hack, but it’s good if we can get everything fully sorted out before IE 7 is released.

Personally, I prefer using CSS hacks as little as possible, and only as a last resort. I see many developers sprinkle CSS hacks all over their CSS files without first attempting to find a hack-free way of solving the problem, which is often possible. When I do need to use CSS rules targeted at IE/Win, I also tend to use conditional comments instead of CSS hacks.

Posted on January 5, 2006 in Browsers, CSS, Quicklinks

Comments

  1. Cmon, it`s our turn now. Conditional comments are here for a long time and they work. No need to use hacks.

  2. With conditional comments you rely on another hack. A bug in the HTML parser. Personally I use the “underscore hack” and sometimes “zoom:1” and “position:relative” to get IE’s attention. The rest mostly works in one go.

  3. I’m very worried.

    From what I’ve seen in the latest build of Vista the “* html” hack has been removed, but the reason for using the hack has not. I use this hack mainly to compensate for the box-model, guilotine and peekaboo-bugs.

    If these things aren’t addressed in the next couple of beta’s a lot of maintainance will have to be planned for our complete back-log of sites.

  4. January 5, 2006 by DutchKid

    I don’t like conditional comments because they’re inside the (x)html-document, instead of in the css. Besides, I don’t like to have Microsoft telling me what code to use.

  5. Personally, I prefer using CSS hacks as little as possible, and only as a last resort.

    Hacking should indeed be the last resort. Hard to avoid them completely when dealing with IE/win though. It’s anyone’s guess at the moment what IE7 will be needing.

    I want as many bugs and bug-related problems gone in IE7 as those behind it can possibly manage to solve before the final release. That includes getting rid of the present hacks, since chances are they will backfire more often than help. Too many weak and hack-overloaded sites around.

    I use conditional comments here and there, but that’s as much of a hack as anything else. Proprietary CSS do have the advantage of being easy to spot when sent through the validator, thus the validator can be really useful at times.

  6. January 5, 2006 by Tommy Olsson

    I don’t see the problem.

    If Microsoft has indeed fixed the rendering bugs, they must fix the star-HTML parsing bug, too. Otherwise we’ll be sending bad rules to a compliant browser.

    If they don’t fix some rendering bugs, we can still target IE5/6/7 with conditional comments and keep sending workarounds without affecting compliant user agents. And we can keep our old style sheets which use the Tan hack to fix problems in IE5/6 that will never be corrected.

  7. I prefer using conditional comments since hacks don’t make your css-document more readable. Come on, it is much easier to create an extra-css-file for IE and to include it via conditional comments than hacking around everytime you need to apply a padding or something else!

  8. January 5, 2006 by Freewheelin' Franklin

    There will always be browser bugs, so why not introduce browser id in css?
    Maybe something like this:

    Rule applying to IE 7 only:
    #ie7 html p {color:blue}

    Rule applying to Firefox 1.5 only:
    #ff1.5 html p {color:blue}

  9. Browser id in the CSS, that’s probably not a very good idea anyway there is already UA CSS and pseudo-class selector names start at hyphen.

  10. I must confess that I recently realized that I left WIN/IE5 totally. I have no way to test CSS for WIN/IE5 on my desk today. For that reason or not, I hardly use those CSS patches. I wolud like to know if quirks mode in WIN/IE6 renders exactly the same as WIN/IE5 does. Can anybody here tell me?

  11. I’ve always thought the use of hacks within CSS is stupid. I have used the child selector to feed compliant browsers with prettier things like PNGs, but very sparingly. I always knew that the day would come when hacks might get fixed when rendering bugs might not.

    I also agree with Anne with respect to conditional comments; however, Microsoft plan to support them for the forseeable future so it would seem that they may be the way to go.

    My personal feeling is that CSS should be layered in such a way that IE-specific styles should be in a separate external sheet that can be added at the last possible moment, either by conditional comments or by server-side intervention.

  12. Again, Conditional Comments considered harmful: a) They do not belong to any (open) standard and have not been discussed publicly; b) HTML comments should not be parsed, so they actually violate existing specifications; c) they force developers to use more than one style sheet, which might be seen as a strong disadvantage in CSS usage.

  13. It would be absolutely pathetic for IE team to remove * hack without fixing its main CSS errors.

  14. There will always be browser bugs, so why not introduce browser id in css?

    Yes, thats a good idea!

    But hey! IE7 may be the browser which renders things most correct for now on? Who knows?

  15. Here’s what I’m hearing: “I want Microsoft to fix all the bugs except the ones that make my life easier.”

    “I don’t want Microsoft to tell me how to code. Only the W3C can do that.” C’mon, SOMEBODY has to tell you how to code.

    And conditional comments considered harmful? Invalid CSS is okay but invalid HTML is bad? (never mind that both are technically “valid”, it’s just you’re relying on the behaviour of a browser to misinterpret one over the other) Yes, Jens, I can see your CSS hacks!

    Yeah, imagine the hell of keeping the * html hack and discovering that your pages still need to be fixed in IE because the bugs they did fix are now rendering incorrectly.

    Let’s face it people. It’s a new browser, if you used a hack, you’re going to have to change “something” to make your pages work correctly. Deal with it. If you don’t like it, take up knitting. I could use a new sweater.

  16. Is it true that IE7 will only be supported on XP and above platforms? If so then I think you will need to be considering both browser versions for some considerable time after the release of IE7.

  17. @Franklin, what Robert is referring to are W3C specified vendor-specific extensions, which accomplish what you’re suggesting and are already in use (by Mozilla for example).

    @Quinn, you can grab an unsupported standalone version of IE 5 from evolt.org

    @John, yes it’s true. The standalone version of IE7 will only be available for XP.

  18. What is the projected marketshare of IE7? What will be the residual marketshare of IE6? Has the Microsoft Team ever stated that IE6 will be corrected? Or, IE5/5.5?

    Whatever happened to those “Be nice to Opera” hacks? after Opera fixed themselves.

    I don’t see any problem. IE5/5.5/6 will continue to require hacks; IE7 may require a new set of hacks. It seems to be a tempest in a kaffecup, all of this IE7 fixes versus stytle sheets.

    I’ll wait.

  19. January 5, 2006 by Eli Simpson

    How is using conditional comments exploiting a bug in the HTML parser? Conditional comments is an IE feature, documented extensively and will never be “fixed”. Not sure what Anne means here…

  20. January 5, 2006 by Roger Johansson (Author comment)

    Anne: Maybe I’m missing something, but I thought Conditional Comments were something that Microsoft implemented in IE. In what way are they a bug in the HTML parser?

    Woolly: Compensating for the box model is only necessary for IE 5.x (unless you force IE 6 to use quirks mode).

    Tommy: Problems may occur if the * html parsing bug is fixed but the CSS rendering bugs are not. And if you read John Gallant’s article, that may actually be the case.

    Anyway, I’m not doing anything until IE 7 is available.

  21. January 5, 2006 by Matt G

    I honestly don’t understand the hate towards conditional comments. The main arguments against them that I see include a) that they are proprietary html and not part of any spec, b) that information inside comments should not be parsed and c) it means creating another stylesheet.

    So what?

    a) Why do they have to be part of any open spec when they are IE specific? It isn’t something that all browsers should implement, so of course it isn’t going to exist in any spec except Microsoft’s.

    b) True, but conditional comments move outside the strict definition of a “comment” anyway. They are easily visually identified in the markup due to the [if IE] part of the tag, and the comment aspect keeps it from being parsed by any other browser. It’s incorrect from a traditional programming point of view, but it isn’t as if IE is parsing all comments in this way. The conditional comment is syntactically removed enough from standard comments that it should be considered an IE feature rather than a breed of IE commenting.

    c) Don’t be lazy. Seperating hacks out of a valid stylesheet is the ideal way of working. Sprinkling IE specific * hacks, voice family hacks, underscore hacks, zoom hacks, band-pass filters etc throughout a stylesheet that gets sent to every browser is sloppy and inefficient. Don’t want to link these files on every page? Learn to use server side includes.

    MS have given us a method of targeting each individual version of IE/Win that works all the way back to version 4. Widespread use of vendor-specific CSS selectors is still a way off. IE7 will present a whole new bag of problems when we find out what has and hasn’t been fixed - with the added disadvantage of losing one of the easiest and most widely used hacks - but conditional comments can still be used to target it and send an IE7 specific stylesheet.

    Long criticism short: why is this still even being debated?

  22. …since Microsoft are also saying they will fix a lot of rendering problems related to CSS in IE 7 there is a reasonable chance that the problems that caused developers to use the * html hack have also been fixed.

    Wow, that’s a pretty extreme level of faith to put in the company that gave us IE6.

    I use the Tan hack to feed a few rules to IE6 when all else fails. I do not accept the idea that using the hack makes me a bad developer, nor do I accept that using MS’s preferred hack is any better. Nor for that matter do I accept being told what to do by the company that created the problem in the first place.

    If MS wanted to make up a new system (again) then they could at least have made it a CSS comment hack so it could be retrofitted on existing sites without editing every single damn file (which you’d still have to do to use SSIs, so people can quit acting like SSIs magically appear without any work).

    Besides any of that….. why is anyone acting like the IE team really care what we want? They’ve made a decision and we can wail and gnash our teeth all day and they’re not going to change their minds.

  23. Considering the Tan hack was about as unhackish as a CSS hack goes I though it was a shame they removed it.

  24. Don’t be lazy. Seperating hacks out of a valid stylesheet is the ideal way of working. Sprinkling IE specific * hacks, voice family hacks, underscore hacks, zoom hacks, band-pass filters etc throughout a stylesheet that gets sent to every browser is sloppy and inefficient.

    Don’t be lazy? Sloppy and inefficient? Putting everything in one stylesheet is more efficient than separating out the CSS into browser-specific stylesheets. Not only because there’s one less HTTP request to make, but because if you compress multiple stylesheets individually, you get a lower compression ratio than if you compress a single large stylesheet. Furthermore, caches will know of one very popular resource rather than multiple, less-popular resources, making cache hits more frequent.

    Separating things out in the name of clean code with no regard as to the consequences is something I’d class as lazy, sloppy and inefficient.

  25. Jonathan, what you see are empty comments and child selectors. Okay, and probably Tantek’s classical box model hack. Both first are per se no “hacks”. And the latter is almost “safe”.

    Personally, I think we need to keep in sight the development with IE 7, but I don’t feel very worried about it. There is a certain chance that several issues forcing us to use “hacks” will be fixed as at the same time the “hacks” are supported (for example, child selectors).

    Nonetheless, I hope for an as large as possible common ground in CSS support in future user-agents so that the need for certain “hacks” is minimized. So I’m rather concerned with what the IE team will do after the release of IE 7 - will they fall into hibernation again for another four, five years, or will they jump on us with the next release just two weeks after their first stroke.

  26. January 6, 2006 by Christian

    Wow, that’s a pretty extreme level of faith to put in the company that gave us IE6.

    When IE6 was released a couple of years ago (2001?), which was then the most standardcompliant browser? I don’t know. Mozilla was founded in 2003, so there was no Mozilla-based browsers around. Netscape … nah, don’t think so. Opera 5 for Windows desktop reaches a record five million downloads on October 4 according to their website. I havn’t used Opera much to say I know anything about standards support in early versions. Considering the competition, I would say that IE6 was the top browser of it’s time.

    With IE7, Microsoft takes a step forward towards a compliant broswer. It should be a good thing right? But why do people moan about it so much? Is the hate towards MS so strong? I don’t get it. They say they will fix the * bug/hack. Some people like it, some people say that they should leave it. Please tell me how MS should develop the new browser. The way I see it, it doesn’t matter if they develop a 100% compliant browser, there will always be some people not happy about it anyway (I don’t mean the functionality of the browser).

  27. When IE6 was released a couple of years ago (2001?), which was then the most standardcompliant browser?

    Most web-design standardistas would likely say that, at that point in time, it was IE5/Mac, which had been released a year earlier.

  28. If MS would just make a browser that was as compliant or better than (say) Firefox, then there wouldn’t be an issue at all because it would render pages just like Firefox renders them. Since most developers are creating FF compatible pages (standards-compliant pages,) everything would just be swell.

    The problem is that many people (me included) don’t trust MS to release a browser that is standards-compliant (up to at least the level of Firefox.) This means that while them may eliminate some useful bugs that developers use to fix things, they WON’T get rid of other annoying bugs like the float margin bugs, the position relative background bugs, etc.

    If they would just release a decently standards-compliant browser, then we’d have nothing to fear. It can’t be that hard, the Firefox people are working for free!

  29. You people take something as simple as laying out boxes on a page and change it into a war

    Tables, css, divs, flash, whatever way you choose that works…

  30. IE7 is bad joke. Mozilla is future :-)

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.