Call to action: The demise of CSS hacks and broken pages


We’re starting to see the first round of sites and pages breaking due to the CSS fixes we have made. We would like to ask your help in cleaning up existing CSS hacks in your pages for IE7. It is has been our policy since IE6 that under quirks doctype we will not make any behavioral changes so that existing pages will continue to render unmodified, but under the strict doctype we want to change behavior to be as compliant as possible with the web standards. For IE7, we introduced new CSS functionality (see Chris blog post for the full list) and cleaned up our parser bugs. This leads now to several CSS hacks failing. If you are using IE7 (you are MSDN subscriber or received a copy at the PDC) you may notice major sites breaking due to the use of CSS hacks and the strict doctype.  

Example how easy it is to fall into the CSS hack trap

I was very happy to hear that Slashdot has their page rewritten using clean HTML 4.01 with a full complement of CSS. I immediately opened up IE7 to see how it would look like. It looked very good, but I noticed an odd behavior with their search box being moved into the footer of their page. I opened up the IE dev toolbar started to take a look, and found:

html > body #footer .search { margin: 0; }

#footer .search

{
            text-align: left;
            position: absolute;
            top: 0;
            left: 1em;
            margin: -1.6em 0 0 0;
            padding: 0;
}

It is targeting the following HTML:

            <div id=”footer”>
                        <div class=”search”>
                                    <form method=”get” action=”http://slashdot.org/search.pl”>
                                                <fieldset>
                                                            <legend></legend>
                                                            <input type=”text” name=”query” value=”” size=”20″>
                                                            <input type=”submit” value=”Search” class=”button”>
                                                </fieldset>
                                    </form>
                        </div>
            </div> 

As you can see the legend tag is empty. IE6 and IE7 reserve white space for the empty legend tag. The HTML 4.01 spec does not specify what should happen in this case. We just do it differently than Firefox and Opera, who do not reserve white space (since we were the first to implement this HTML 4 element back in the day there was no precedent to do it differently). The legend element is required according to the HTML validator, so Slashdot did the right thing to put an empty element in the page. The site authors wanted to work around the IE behavior by applying negative margins to IE only. Since we implemented the child selector (>) now for IE7 their CSS hack is failing. We contacted Slashdot and are trying to address this issue.

Call to action: Please check your pages

Here is a list of common CSS hacks to look out for (please also consider their variations):

We ask that you please update your pages to not use these CSS hacks. If you want to target IE or bypass IE, you can use conditional comments .

Here is a simple example how you would use it in the Slashdot scenario:

Using the existing style block:

#footer .search

{
            text-align: left;
            position: absolute;
            top: 0;
            left: 1em;
            margin: 0;
            padding: 0;
}

In a new style block underneath:

<!–[if IE]>

                    <style>

#footer .search

{
            margin-top: -1.6em;
}

                    </style>

<![endif]–>

I would prefer a CSS solution too but currently there isn’t one in the CSS standard.  Please help us spread the word so it is an easier decision for us in the future to make improvements to our standards implementation (even if it means breaking customers).  

Thanks,

 – Markus Mielke

Comments (302)

  1. Anonymous says:

    This is interesting. Now I’ve used some of the parser bugs to get around some problems with IE in the past. For example, to fake min-height I’d do something like this:

    .content{ height: 500px}

    #container>content { height: auto; min-height:500px}

    Assuming I’m using CSS hacks to work around bugs in IE 6, things should be fine, right? Ideally IE 6 keeps getting the height wrong and ignoring the child selector. But IE7 understands the child selector, and properly overrides the height and applies the min-height.

  2. Anonymous says:

    Since it looks like that legend is always empty, shouldn’t it be:

    #footer .search form>fieldset>legend {

    display:none;

    }

    IE6 will ignore the style because it doesn’t understand the child selector, and it won’t affect any of the other browsers who apparently have the equivalent behavior.

    Actually, the best fix would be to remove the empty legend tag since it’s not serving any purpose, or put content in it.

  3. Anonymous says:

    Changing your last code block to something like this:

    <!–[if lt IE 7]>

    <style>

    #footer .search

    {

    margin-top: -1.6em;

    }

    </style>

    <![endif]–>

    would make it apply only to versions of IE prior to IE7. Something I’ve taken to doing more often is something like this:

    <!–[if lt IE 7]>

    <link rel="stylesheet" href="ie.css" type="text/css" />

    <![endif]–>

    which supplies an extra stylesheet to older versions of IE if placed last in the cascade.

  4. Anonymous says:

    The Slashdot example doesn’t make sense to me. If the CSS bug they’re trying to work around has been fixed in IE7 then they can use the * html hack, since IE7 will no longer recognize it. If the bug still exists, please fix that instead of forcing us to workaround it in a different manner.

  5. Anonymous says:

    I don’t understand why you would want to use browser-specific code in this case. Since the problem is that the standard doesn’t specify a standard behavior in the case, it seems natural to explicitly request a behavior for all browsers. So, wouldn’t it work to use something like

    #footer .search legend { display: none; }

    ? Even IE6 should have no trouble with it, and, according to your description, I think it would fix the problem.

    Is there some problem with this?

  6. Anonymous says:

    Joel,

    Slashdot isn’t trying to work around a bug in IE, they are trying to work around a rendering difference between IE and the rest of the world. The spec doesn’t define how an empty legend should be rendered, and IE chose a different path than other browsers. Since the spec doesn’t define it, different rendering is not a bug.

    Slashdot is using an IE6 CSS bug to work around the IE rendering difference, but the CSS bug is fixed so in IE7 Slashdot’s code doesn’t know to apply the rendering adjustment.

    This is exactly the place for conditional comments. Duncan recommends "[if lt IE 7]" but of course that would have the same problem as using the IE6 CSS bug hack… The rendering adjustment is still necessary in IE 7 since it isn’t considered a bug. The recommended "[if IE]" makes more sense.

    Or if Kevin’s suggestion of a targeted "display: none" really works and makes IE 7 render exactly the same way as the other browsers, then it would be a good clear approach. I don’t see a good reason to hide it from IE 6, so it could even be made simpler.

  7. Anonymous says:

    This is a nice request in a perfect world, but we don’t live there.

    We don’t know which redering bugs will still exist in IE7

    We don’t know (exactly) which parsing bug will still exist in IE7

    We know we should use parsing bugs that are no longer in IE7 to apply hack that fix redering bugs that are no longer in IE7.

    And also we should use parsing bugs that are still in IE7 to apply hack that fix redering bugs that are still in IE7.

    We just don’t know which redering and css-parsing bug there will be in IE7.

    Conditional comments are a nice fix for just half of the problem. With cond. comments we no longer need to rely on parsing bugs, but we still don’t know which hacks are still required bij IE7 (in an ideal world none).

    So all we can do is wait for IE7b2

  8. Anonymous says:

    Ah, I see I missed the explanatory paragraph between the CSS before/after examples. Still, it would be nice if IE7 (in strict mode, at least) would follow the implementation of other browsers in cases where something is unspecified and the other browsers have come to an apparent consensus. Such cases aren’t technically bugs, but that doesn’t really matter if we have to write a hack for it anyway.

  9. PatriotB says:

    Interestingly if you try to run the W3C Validator against anything from slashdot.org, slashdot returns 403 Forbidden. Whats the matter, do they not want people to see the validation errors for their new design?

  10. Anonymous says:

    I concur with everybody else, display: none is the obvious answer here.

    > The spec doesn’t define how an empty legend should be rendered, and IE chose a different path than other browsers.

    No, if Internet Explorer is generating a block box for the legend element without any display: block in a stylesheet, then that’s incorrect behaviour. The HTML 4.01 specification clearly states that the legend element type is inline, and as such, it should not be generating a block box by default.

    http://www.w3.org/TR/REC-html40/interact/forms.html#edef-LEGEND

    Is Internet Explorer 7 going to understand display: table?

  11. Anonymous says:

    IE6 and other browsers don’t reserve vertical space for other empty elements like paragraphs, so it seems like a bit of a special case to do so for legends, but I guess we have to live with it.

    A CSS hack I’ve used a bit is writing _height to mean min-height in IE, but I haven’t seen anything mentioned about the underscore hack or the implementation of height and min-height. Is there anywhere to find out about these, apart from watching this blog?

  12. Anonymous says:

    If you’re changing behavior – why not unify that with other browsers? They’ve adjusted tons of stuff to work like in IE, so you could bend on that one.

    About Slashcode – empty <legend /> tag doesn’t serve it’s purpose, so it’s just stupid hack to please validator. They should have used <legend>Search</legend> + display:none…

  13. Anonymous says:

    So Markus, how do the rest of us get our hands on this newer build of IE7? I can see myself spending quite a bit of time fixing sites I’ve used these hacks on. Not looking forward to it.

  14. Anonymous says:

    Would like to know when IE 7 Beta 2 will be out, please, so we can make such changes AND test them.

    Thanks.

  15. Anonymous says:

    @Jim: Spec doesn’t say that legend is inline (bit you’re referring to says its _content_ is inline). Besides HTML inline is technically completely different thing than CSS inline.

  16. Anonymous says:

    > If the CSS bug they’re trying to work around has been fixed in IE7 then they can use the * html hack, since IE7 will no longer recognize it.

    I agree. Can someone explain why * html can’t continue to be used here?

  17. Anonymous says:

    So… you’re only going to fix some CSS bugs, and I have to then go around and fix the hacks on my site now? No deal. I’d rather let them break, and wonder what’s wrong with IE.

    Make your CSS full compliant, and then we’ll talk. Last post I checked, you weren’t going to be anywhere near Gecko or Safari. This isn’t productive, having to mop up your mess only half way.

  18. Anonymous says:

    Has the IE-Team ever considered implementing the conditional comments feature for CSS documents, too?

    As for instance:

    /*[if eq IE7 ]>

    ul { margin: 1em; }

    p { margin: 1em 0em; }

    <![endif]*/

    I understand that you can achieve the same if you just embed the aforementioned piece of code in your (X)HTML document. But the point is that this may not be an option for every project out there and having all your CSS Code in one place can be very advantageous at times or simply be convenient.

    At any rate, it’s certainly more preferable using a reliable feature than using those ridiculous and awful CSS hacks, no?

    I mean, just come to think about it. With every new version of the Internet Explorer, there will also appear a series of new bugs, which will then keep annoying us webdelopers for the next 5 years (, provided that IE won’t implement a Live Update feature which would fix security bugs and rendering bugs as well). I just see it coming that people will be busy with searching for yet another CSS hack, not for <IE6 but for IE7.

    If the IE programmers introduced this feature in IE7, then future versions of the Internet Explorer wouldn’t require webdevelopers to modify their stylesheets, or maybe only in very seldom cases.

    A comment from a member of the IE-Team would be highly appreciated. Thanks.

    Regards.

  19. Anonymous says:

    CSS Hacks written by competent authors should be designed so that fully conformant CSS parsers use the correct style rules, and any hacks applied for non-conformant browsers should address the cause of the problem, not the symptoms.

    This slashdot example is clearly a case where they’ve addressed the symptoms, not the cause. i.e. It appeared that the search box was misaligned, so they used whatever they could to push it back into place. However, as you mentioned, the cause is the legend element which can be addressed, as suggested in previous comments, using legend{display:none;}.

    Whether or not a browser contains a conforming rendering engine, as opposed to the parser, is another issue entirely; but therein lies the fundamental problem with CSS hacks: most rely on parsing errors to feed different CSS to non-conforming rendering engines.

    Thus, fixes for one don’t necessarily mean fixes for the other and hacks that depend on a parsing bug being fixed in the same release as a rendering bug it was used to address are inherently unsafe for that reason.

    The exception to this rule is the combination of bugs that are already known to be fixed in an upcoming release. For example, both * html{} (parsing bug) and ‘min-/max-width/height’, ‘height’ and ‘width’ (rendering bugs) have been fixed, so hacks involving combinations of those are now safe to use.

  20. Anonymous says:

    ==CSS hackers Anonymous==

    Hi, my name is Alan Trick and I’m a CSS hacker

    Oh the irony, on the IE blog. Anyways, I *love* the interest that you guys have shown in standards over past couple of months and I can only hope that your standards support is as good as this blog.

    Unfortunatly, I’ll probably be CSS hacking for a couple more years. The main reasons are:

    1. It’s easier. Quite offen you can fixes problems a lot quicker with a well written hack.

    2. For non IE/Win. IE Mac (which is a very interesting beast) and unfortunate thing called Netscape (ealy versions). Neither of these support conditional comments. Both have annoying CSS bugs.

    3. Forwards compatibility. While you mentioned this as being a reason not to use hacks, it usually works for them. When a browser updates they often fix the display bugs with the parser bugs, which makes for only a small number of updates needed instead of writting a whole new CSS file.

    Hopefully in a couple years hacks will be as common as the &lt;marquee&gt; tag.

    Also you guys mentioned the lengend element and forms. This is one place were browsers are really mucked up. Every single rendering engine is as far away from all the others as possible. It would be nice if you guys could work together so that web developers could have some standards to work off of. This is up to you guys though and not the w3 because CSS not meant to imply what something looks like, not enforce it.

    @Aziz Köksal: I don’t see how that would really be all that advantageous. It’s against the CSS specs as well as the philosophy behind CSS. I don’t think IE needs any more non-standard ‘features’.

  21. Anonymous says:

    If the legend whitespace is not specified in the HTML spec, and therefore it’s up to the browser to decide how to handle it, shouldn’t we be asking the W3C to set a standard? I know MS is heavily involved with web standards, and in the WASP, why not just ask them to decide on something?

  22. Anonymous says:

    Hats off to you IE developers I say…

    I wish I could say I’m surprised by some of the negative feedback and people still wanting to use IE hacks in their stylesheets but I’m not.

    This is all relatively simple, which is also the message I took out of this post.

    1. IE conditional comments provide a neat way of organising ALL your IE hacks so if you need to hack IE, use conditional comments. Why do it any other way?

    2. Lets just accept the differences between IE and the other browsers and get over it! IE 7 is a significant step forward towards a more standards compliant rendering experience and as Joel pointed out, this is not an example of an IE bug, simply a rendering issue between IE 7 and other browsers.

    Haven’t we got more important things to worry about like usability and accessibility? IE conditional comments provide an IE specific solution (if needed), problem solved.

  23. Anonymous says:

    This is good to see. Not only are you folks fixing many of the long-standing issues with MSIE, but you’re communicating with developers so they know what’s changing.

    It looks like you’re going to considerable lengths to make the upgrade as painless as is possible for something that breaks compatibility in some ways. I personally don’t see what more you folks could do, except freeze MSIE’s renderer at the IE 6 level.

    Personally this has been very helpful, as I’m currently faced with some rendering issues with IE in an in-house web app I’m working on, and this gives me some very handy information on how best to tackle the problem.

    Given that this only applies to the strict renderer anyway, I must admit I don’t see what the problem is. Congratulations, folks.

  24. Anonymous says:

    Paul Thurrots site has this date on Internet Explorer 7 Beta 2, Dec 7.

    I’m not sure if its 100% correct, but he has been 80-90% correct before.

    http://www.winsupersite.com/

  25. Anonymous says:

    Good stuff, one remaining question though at this point. Will we be able to throw IE in to quirks mode by having a comments tag before the XML declaration or doctype?

  26. Anonymous says:

    I have an additional question: If you implemented the > child selektor, did you also implement attributes?

    I mean like:

    #foobar[id] or .foobar[class] ?

    If you really implement png-24 it will not be a problem for me, but it would be good to know.

  27. Anonymous says:

    Thomas – yes, they have done on both attribute selectors and alpha PNG.

  28. Anonymous says:

    Well, regarding the Slashdot phenomenon – it seems more appropriate to me to (recommend to) use the "legend" element with text and then hide it via "display: none;". Far better, and working without any problems.

    And hey, IE guys, what do you mean with "[…] not to use these CSS hacks"? Child selectors, for example, are per se no "hack". And next, though there is a chance that IE will one day support these selectors, while it does not address the issues which forced authors to use the "hack", IE hopefully addresses most of the other issues so that the transition is smooth and people won’t get any trouble using child selectors.

    And finally, please do not encourage "conditional comments". Comments are not meant to include any "queries", that’s a), and b) does it require internal stylesheets. That’s total OMG.

  29. Anonymous says:

    regarding the recommendation of using conditional comments: I would recommend instead that people apply their browser-specific CSS fixes using JavaScript. This would reduce the amount of clutter that needs to be downloaded every time a page is refreshed.

    Some people may complain and say "what about people that don’t have JavaScript installed/enabled"? I imagine that the only browsers that are in that demographic are:

    a) speech browsers

    b) search engines

    c) customised by paranoid techies

    In the case of ‘a’ and ‘b’, CSS fixes wouldn’t matter anyway. In the case of ‘c’ – a paranoid techie might have CSS turned off as well anyway, and anyway – screw ’em – they knew there’d be trouble when they turned of JavaScript anyway.

    Actually, a better solution might be to recommend Dean Edwards’ ie7 script (ie7.sf.net), and forget about CSS hacks altogether.

  30. Anonymous says:

    @John A. Bilicki III: It was mentioned earlier in this blog that in IE7 the Doctype switch has been fixed, so that an XML prolog doesn’t cause Quirks mode anymore for XHTML documents.

    @Jens:

    What’s wrong with conditional comments? You can put a LINK element in it as well.

    Separating the hacks from the ‘good’ css seems like good practice to me.

  31. Anonymous says:

    i am really wondering about microsoft as a whole company.

    in the past, its not so long ago, microsoft did everything to invent their own "standards" to copyright, protect and patent all their stuff and to make life hard for everybody else on this planet.

    there are hundreds of examples especially in the html/webstandards area, and internetexplorer was one of the worst apps ever to see the daylight and messing up things amongst webdevelopers.

    and now, all of a sudden, microsoft asks exactly the people and the community that it has despised so very much so far for helping out and disabling hacks?

    this is totally nuts. microsoft becoming and doing good for this planet after all?

    i bet not. your company is still evil, greedy, selfish and just capitalistic, with no sense of fairness, justice and humanness at all.

    for the technical side of the problem: why not including an emulation mode in ie7, which could be activated to make it behave like old ie6 versions. like a compatibility mode or something.

    but for the people that work at microsoft: you guys are the company, and you ppl could do much more good for your own sake and the sake of your company and this planet as whole.

  32. Anonymous says:

    Regarding the legend tag:

    The HTML 4.01 spec does not specify what should happen with an empty legend tag. Right. But why do you reserve a white space for an empty legend tag? If a tag is empty your browser should not print anything.

  33. Anonymous says:

    Can’t you wait till you release at least the public beta before requesting this….I have no access to IE7 through Microsoft.

  34. Anonymous says:

    until ms don’t ensure the users < winxp and mac could get ie7 i will NOT take out any hacks. ms cloned, copied etc. everything before – so go and clone firefox or anything else and don’t let us make your work for you. many years qualified people work out hacks for your contempt of standards and now we should do your bidding? no thanks…

  35. Anonymous says:

    build a crappy browser thatdestroy pages, then complain that people use its bugs to try to make pages work properly.

    this is not the case with legend, but I could find 200 examples where IE forces me to use hacks if I want him to work.

  36. Anonymous says:

    Yes, the following suggestion might be blasphemy for Microsoft, but I had to try.

    Why not use the Firefox rendering engine, called gecko? It is Open Source, so Microsoft is allowed to use it (and don’t even have to pay for it, as it is available for free (as in free bear)).

    Every Webdesigner would be happy if the IE 7 renders pages the same way Firefox does it.

    Ok, Microsoft would have to open source IE 7 but as it is included in WinXP / Vista Microsoft doesn’t make any money directly with IE. I don’t think many uses will upgrade vom Windows 2000 (or whatever) only to get a new version of the Internet Explorer. So no earnings will be lost and I don’t think that the business competitors won’t have much advantages of an open sourced IE.

    Also the developers of IE can concentrate on other features like improved phising protection or something like that.

    In the end it sounds (well, at least to me) like a good solution. Less work for Microsoft, less work for Webdesigners.

  37. Anonymous says:

    I have wasted a lot of time finding workarounds for your standard-ignorant browser. I had to make a lot of design tradeoffs because your unability to e.g. render PNG properly.

    Honestly, I do not care about the issues you got now. I won’t remove a single workaround for your buggy stuff again. You messed it up, now it’s also your turn to find a solution for it.

  38. Anonymous says:

    *LOL*

    Microsoft – you made my day.

  39. Anonymous says:

    The ill-conceived article and the reaction to it show that neither the original poster nor the organization he represents have a clue regarding the vast experience Web workers have built up in constructing IE hacks.

    Remember: IE6 already has a "standards" mode. It is the source of these hacks.

    Advice is futile when no one has shown that IE7’s "standards" mode will be less buggy than IE6’s.

    My solution to this point is to make certain that IE stays out of this extremely weird mode. As it stands, "quirks" mode is predictable and quite compatible with Moz/Firefox standards behavior.

    Brett Merkey

  40. Anonymous says:

    where to send all these additional bills for this additional work? to you billiboy?

  41. Anonymous says:

    First you’re building cars with triangular tires, and people had to build roads with holes on it, and now you’re complaining your new car with round tires can not drive on these roads.

    You’re realizing that there are some trivial things called standards now? You’re joking right? I hope, for the amount of time your buggy browsers cost us to write and debug hacks, you’ll pay someday!

    When Microsoft is talking about standards and Microsofts commitment to them, I’ll trust them so much like I’ll do Mephistopheles when he’s talking about world peace…

  42. Anonymous says:

    If you are asking web developers to clean up their style sheets because of IE 7, you should at least make IE 7 Beta available for them!

  43. Anonymous says:

    Sorry for my broken English. It isn’t my native language.

    Now to the question about deleting all the hacks that needed to be written for IE6 and before. I really appreciate the thought that IE7 will be more standard conform this question is the best proof that there is no intention to go the whole way. If there are no exact display specs are written why don’t do it the way that is standard? That IE introduced something in some Version long ago doesn’t mean that it should be stay the way it is. I understand that it isn’t easy to get this thing we call browser up to date with standards, or at least try it. But what happens if now the hacks are going to be replaced? Everyone with IE6 will look at crappy sites and think it is the fault of the web developers. Our fault. But instead it is your fault.

    Qoute by Kae Verens:

    "regarding the recommendation of using conditional comments: I would recommend instead that people apply their browser-specific CSS fixes using JavaScript. This would reduce the amount of clutter that needs to be downloaded every time a page is refreshed. "

    1. JS has a great amount of incompatibilities itself so this isn’t an option.

    2. Not only nerds or people with disabilities have JS deactivated. Look at the download counter of "No-Script" for FireFox which blocks all JS as long as you don’t add the site to your whiteliste. This is very helpful because many sites just do a lot of the ugliest stuff with JS or just disturbing things. JS isn’t HTML and shouldn’t be needed for displaying something. Forcing not only css hacks, written in css, but instead css hacks written in JS. This is not only the same stuff we dealing with right now, it is much worse.

    Comment Querys? That would be exactly the same problem. Not near any standard and would require an additional skill from those who don’t know JS or other program languages. This would undermine the goal to be standard conform from the beginning. Doing this only IE can do isn’t the way to go. Everyone who designed a website should know this.

    (X)HTML and CSS are different things. (X)HTML to order information and CSS to edit display information, nice formatting and all this neat stuff we love in standard conform browsers. JS is a script languages which CAN be used to do neat stuff to but shouldn’t, under absolutely no circumstances be required for a website to be displayed the way it should on its own.

    Now come on everybody. The goal for standard compatibilities is not only because it sounds nice. It is because this helps web developers greatly with their work, it helps people without JS or SQL skills to do a site that works. Without having to read through the half of the web searching why one browser decides to display something completely different just for the sake of being the first who introduced it. With that point taken IE would have to do a whole lot of stuff different. JS hacks or additional non standard object are exactly the opposite way.

  44. Anonymous says:

    Sorry, but I’m just crying because I laugh so much. Not about you, no way! But about all the web designers who were Pro-IE all the time and now see what they did…

    Good luck with IE7, make it a good program 🙂

  45. Anonymous says:

    The story with IE7 is some kind of ironic.

    If i were not a webdeveloper myself, i would laugh.

    Learn to stick to the standards from the beginning on, and you save us all a lot of trouble!

    Altough i welcome that IE7 will try to follow the standards now. Just took you 7 versions to get there…

    *sigh*

    regards

    smilingrasta

  46. Anonymous says:

    I think it is very good, that you are working on making the IE7 more standards compliant. I don’t think oit is a big deal, because the issue about hacks possibly not working in the future are obvious and have been referred to in countless tutorials. For my part I’ve handled it the other way around and refused to implement hacks. My motto was nice design for those that can do it, but only content for the browsers that can’t. That means that future IE7 users maybe won’t have to wonder anymore, why the design is a bit quirky. And that’s a good thing 🙂

  47. Anonymous says:

    All these IE hacks had to be implemented because Microsoft didn’t come up with a decent web browser. Now where their share on the browser market starts to shrink a tiny little bit they want us to remove to exactly these hacks they have caused themselves. Who’s gonna pay for all this? – As you might have guessed, webdevelopers and their customers.

    Microsoft – shame on you!

  48. Anonymous says:

    All these IE hacks had to be implemented because Microsoft didn’t come up with a decent web browser. Now where their share on the browser market starts to shrink a tiny little bit they want us to remove to exactly these hacks they have caused themselves. Who’s gonna pay for all this? – As you might have guessed, webdevelopers and their customers.

    Microsoft – shame on you!

  49. Anonymous says:

    I hope this is just a joke! I can’t even cout up all the hours I’ve spent in the past ‘fixing’ perfectly good code so that IE can render it somewhat. Now you’re asking me to recode? Let’s put it this way: For the past 1.5 years I’ve told my developers to code corretly. The browsers that understand the code (Firefox) render it correctly. All others don’t to some degree. We also attach a link to http://www.getfirefox.com.

    This time it’s up to YOU to get your act together. We don’t code for a browser anymore. I don’t see the reason to.

  50. Anonymous says:

    Guys, you really annoy me.

    I’m using PNG hacks to allow IE 5.5 + 6 to display PNGs with full alpha channel transparency. Yeah, allright, IE7 can now display alpha channels out of the box. Not only comes this feature WAY too late, but also am I NOT going to remove the hack, no matter how f*cked up PNGs will be displayed in IE7, I don’t even care if it crashes. IE 5+6 visitors are far more important to me than those few IE7 beta crackheads.

    I really hope IE7 does not become the common browser.

    You can’t just demand that I do the same amount of webdesign work, that I already had to do because you f*cked up all previous IE versions concerning CSS, AGAIN.

    Sorry Microsofties, too sad you’ll probably never learn it.

  51. Anonymous says:

    Microsoft is doing the right thing in breaking all those sites. Web-developers start looking at WPF, that’s the future, not anything from w3c.

  52. Anonymous says:

    You don’t seem to know what CSS hacks are about.

    They are the most ingenious, cleanest and most of the time ONLY way to cope with well-known CSS bugs in IE 5 and 6 like the box model bug, the three pixel jog, the double margin bug, the guillotine bug etc.

    The Slashdot <legend> example is about something not specified in the HTML spec and someone decided to target this with a CSS hack. There might be better solutions but to conclude that CSS hacks are evil, is just a sign of utmost ignorance.

  53. Anonymous says:

    Hi,

    I’m sure, that IE7 would have not fixed all bugs. Conditional comments are helpfull, but I prefere to provide a special CSS file for all IEs and use CSS hacks inside to separate the versions. It’s not performant, to use multiple CSS files instead and other authors may use only one CSS file (at media screen). Therefore, and because Microsoft fixes only security bugs in a major version of IE, CSS hacks are quite necessary.

    Of course the child-selector cannot be used as a CSS hack any more, but what about * html? I see no reason to fix this bug, because it’s only used as CSS hack. Leave this bug and we have the choice, to change our CSS for IE 7 using the child selector for bugs already fixed in IE 7 and the star-html hack for bugs still remained.

    Otherwise we have to find out a new bug for a new CSS hack – but why? We should change our CSS now. You should see the advantage of using a well known CSS hack instead of creatng a new hack when IE7 will be published.

    By the way, Please have a look at http://de.selfhtml.org/css/layouts/browserweichen.htm

    We’re going to update this well known german documentation and it would be helpful for german visitors to find here a CSS hack, which still works in IE7.

  54. Anonymous says:

    Well, I do appreciate that you work on the IE standard issues and I do also appreciate that you try to inform web designers that this will break some and which hacks.

    I would strongly suggest to create a document describing the best practice for web designers to deal with these issues.

    AFAIC it would be best for us to isolate all the IE hacks of a site into an additional CSS, which is only loaded with a comment conditional in IE < 7.

    It would be helpful to write down the exact syntax for such a comment if you would like to make an impact. I certainly don’t intend to dig myself through a lot of material to find out how to assign every IE 5 & 6 with that kind of proprietary MS comment hacking.

    A final word – regarding if something is not specified: Do it as the others do.

    Noone gives a ship if you were first or if it’s a bug or not. All we and our employers/customers want is an operational site. Browser differences have literally cost billions of dollars/euros/whatever and slowed down economy quite a bit by wasting a lot of time of a lot of bright people. I know a couple of bigger projects which have ruled out IE as a browser for inhouse apps for just this reason.

    So, your intentions are good and will be honoured. Keep up the good work and bury the old.

    Klaus

    BTW: V7 runs just fine with a major site I operate, which has about a handful CSS hacks applied.

  55. Anonymous says:

    This won’t make me popular at MS but it seems this is our chance as designers to stop IE’s monopoly.

    Let’s not fix our sites for IE7. IE7 won’t be used by a lot of people in the beginning. Those few people using IE7 will see a lot of sites break and will be very disappointed in IE7 and switch back to IE6 or Firefox.

    This way IE7 will never be a succes and IE will lose it’s monopoly.

    This will probably never happen, but it’s a funny though that IE7’s standardsupport could become it’s demise.

  56. Anonymous says:

    This won’t make you popular but it makes you look stupid…

    It looks quite like a designer’s hybris to assume that non-support of a major browser would change anything on market share. Web design is about serving customers, not about changing markets.

    If your site, or the one of your employer/customer breaks, it’s you who’s getting blamed and asked to fix it. If you blame it on IE, then this doesn’t change a thing. Just fix it or get lost. Contrary to your belief web designers are not the center of the universe.

    IE7 already works very well with most sites *because* it is more standard compliant, and due to security reasons and MS marketing it’s share will be relevant pretty soon after release.

    Klaus

  57. Anonymous says:

    Aside from the fact that it’s very funny to see MS people ask the community to please remove all the hacks they had to put in to get their pages to render on previous IE versions (really, I laughed out loud) I would like to point out that THE REASON we have all these hacks is the giant marketshare of IE 5 and 6.

    Given Joe Public’s upgrade path (many are STILL using 5.5, or even 5.0 by the looks of my logs) I don’t expect IE7 to become mainstream for a long long time to come, and with Firefox reaching maturity and Opera becoming free as in beer it might never happen.

    To expect people to fix their pages because you’re creating what is destined to become another niche browser (yes, I’m talking ’bout IE7)…well, you don’t get out much, do you?

    If I were you I’d go the MS way and code in CSS-hack-hacks, because hell will freeze over before the community will work with you on this one.

  58. Anonymous says:

    As others have pointed out, it’s a little odd to make this request now when most web developers don’t even have the ability to test their code on IE7. Release the IE7 public beta and I’m sure many of us will jump on this request.

  59. Anonymous says:

    I’ve read and re-read this entry and it’s still not making sense to me. What exactly is happening to break these pages? If IE7 is being fed code behind a hack that is required for IE5 and/or IE6 to work properly, but these hacked values screw up in IE7 because it sticks more closely to the standard and doesn’t need to be hacked, how is that ANY different from putting the hacked values behind a conditional comment that IE7 will also still see? If IE7 applies the style rules properly but doesn’t fix the selector bugs, then I can see how this can be a problem. But why not just fix the selector bugs too, at least when not in quirks mode, so that IE7 not only doesn’t need the hacks, it ignores them? Then we as designers could code for IE7 the same way we code for Safari, Firefox, Mozilla, Netscape, Opera, and the possibly upcoming Google browser and THEN hack as needed for previous versions of IE.

    The only way I can see such hacks causing problems is if IE7 is only half fixed so that either it doesn’t see the hacks but still needs them do to shoddy style rules handling or so that it gets the rules right so that it doesn’t need the hacks, but still reads the hacks anyway due to improper selector rule handling. If both the style rules and the selector rules handling are fixed, there’s no problem, right?

  60. Anonymous says:

    I suppose it’s therapeutic to give everybody an outlet to complain about Microsoft as a corporation. Unfortunately there’s the whacko calling them "capitalistic" as if that’s a bad thing. I thought the problem was when companies *abuse* the system. Oh well.

    I wish the signal-to-noise ratio was a bit higher, but between the noise there’s been plenty of good discussion about better ways to handle this problem in CSS.

    I think a lot of us agree that display: none would be a more universal way to address the quirky treatment of legend. Since IE’s handling doesn’t technically violate the specification, we should fix it for ALL browsers who handle it IE’s way, not just for IE as a conditional comment would do.

    With all due respect to the IE team (and I’m obviously addressing the developers here — not Bill Gates himself), I think we either need more testcases (like the legend element on Slashdot) or a copy of IE7 in our hands. Hacking CSS is a practical consideration, not some sort of science.

  61. Anonymous says:

    I often use the child selector to avoid ‘real’ rendering bugs in IE5/6. Rendering differences are a reality and are something designers and developers needs to advise their clients about.

    I’ll be continuing to use the child selector to get around IE5-6 bugs that have been fixed in IE7. And so far it looks like that I’ve dodged a bullet by implementing it in the past for bugs that IE7 seems to have fixed.

    So the advice should sound more like; “Only write workarounds for bugs and not for rendering differences.” And make sure your fix is CSS compliant. Remember, your pages will look differently from browser to browser to expect otherwise is folley.

  62. Anonymous says:

    How about you just make IE 7 ignore these hacks like other ‘standards compliant’ browser? IE 7 sounds like a job creator… conditional CSS is a total PITA.

  63. Dave says:

    Play with the sample code that is posted above by adding some background colors to each element. I think you will agree that IE6 (and IE7?) handling of the legend tag is ugly. If you specify a legend in IE, the background color of the fieldset "escapes" the grouping frame and looks very ugly. In Firefox it stays inside the frame. IE’s interpretation may be within the spec but it does not yield nice looking web pages.

  64. Anonymous says:

    make IE7 opensource – btw – jumping to the bottom of this Page after clicking "Post a comment" – only possible with IE7 ??? LMAO

  65. Anonymous says:

    See a small css1, css2 and css3 sample test website which works with Geckos and Operas and others. See http://www.aadmm.de/en/index.htm for a comprehensive test website for css, dom, graphics formats (gif-, png-, jpg- and jpg2000, incl. png alpha channel test) javascript, plug ins inquiry (also works with ie), xhtml, xml and xslt. Take a look on the Topic Screenshots and see how MS IE 7.0b (Windows Vista Beta 1) display a XHTML 1.1 and CSS 2.1 website.

  66. Anonymous says:

    The webstandards for accessibility and usability said that we have to build websites backward compatible.

    <a href="http://www.w3.org/WAI/&quot; title="WAI">WAI</a>

    do you really mean that all people at XY day at XY clock are using your new product?!

    Where do you live?

    It is your job to realize webstandards.

    if MS will pay me, ok I’ll give you my knowledge about css hacks for your unprossional work named IE (5. or 6. or 7)

    take a look to Mozilla, they are programmer 😉

    you made my day

    thanks a lot 🙂

    Monika

  67. Anonymous says:

    No problem, I’ll fix my hacks, just as soon as I can test it.

    1.) Uh oh… can’t do… IE7(Alpha/Beta/?) not publicly available!

    2.) Uh oh… can’t do… my default dev box is Win2k, or Fedora Core.

    Now, I suppose I could install it, on an XP box, but #1.) is holding me back.

    I find it hilarious personally, that you are asking developers to clear out hacks, put in, because of buggy software you released.

    There is a very simple solution to all of this… Fix the bugs > release the browser to the general public > let us fix our code (remove hacks), as applicable.

    I for one, have no intention of changing a single character of my code, until I can test it out.

    @Kartoffelknülch

    Yeah, the lack of a "jump" to the form when posting on this Blog, is a perfect example of how Microsoft *just doesn’t get it*. This is a 2 second fix… yet we have been waiting months for this.

    I’m gonna pull a "Ray Nagin" here <http://en.wikipedia.org/wiki/Ray_Nagin#Criticism_of_relief_efforts&gt; … We want a boycot on Blog posts, until this is fixed.

    WE DONT WANT TO SEE ANY MORE POSTS TO THIS BLOG, UNTIL THIS IS FIXED. Come on Microsoft, this is NOT hard to do… show some effort.

  68. Anonymous says:

    First off, good work trying to move to a fully standards compliant browser.

    For everyone asking who is going to pay for the ‘additional work’ IE 7 is going to create, well, go talk to who pays your bills now — your customers! Are you honestly suggesting that you want all future versions of IE to be as badly broken as IE 6? As painful as it may be, the answer is to get everyone using a standards compliant browser as quickly as possible.

    Is Microsoft responsible for this whole mess? Sure, it has a big share of the blame. But remember this whole thing started before ANYONE was compliant with ANY standards. Remember the browser war? It wasn’t as though everyone’s favorite (Netscape) was standards compliant either. It was a battle and all browsers were trying to figure out what customers really wanted; everyone was looking for an advantage.

    If MS had a little more forsight it would probably have realized there isn’t any money in the browser anyway and since it dominates the OS market it would end up being the dominant browser regardless of the competition. It could have saved the world a lot of money, but Microsoft didn’t have the foresight to see that and instead, we have a mess. It may have been the only company that could have prevented the mess but it surely wasn’t the only one that caused it.

    We also need to differentiate between the ‘bugs’ and the ‘differences’. Bugs need to be fixed. The "differences" need "alignment". If the spec isn’t specific enough, we’re going to have problems. Everyone’s favorite suggestion here is to have Microsoft change their decision and make it comply with Firefox’s behavior. I wouldn’t mind seeing that happen. But from the other perspective, IE is still far and away the dominant browser; maybe the other browsers should change the way they handle it? Or maybe someone should figure out which way is better and create a standard!

    Some hacks are going to be problematic and there is nothing anyone can do about it. Software changes…we hope it improves and in this case, we hope it becomes standards compliant. The process of doing so will cause us all a lot of pain — this fact of life was ensured way back when MS didn’t commit to a standards compliant browser back from day one. When nobody else did either.

    Go ahead, beat them up about not being any smarter than their competition on that issue. I’m going back to work.

  69. Anonymous says:

    Can you not ask your programmers to change IE7, i.e. not to bother the empty legend tags. Isn’t that an easy thing to do?

  70. Anonymous says:

    Maybe I need a second cup of coffee…. But I fail to see why we would need to avoid using the star-html hack. In strict mode, IE7 will ignore these rules, right? Am I missing something? Is it going to ignore it in quirks mode, too — is that the problem?

  71. Anonymous says:

    This blog has certainly got me excited about the forthcoming release of IE7, but your call to action is premature, as others have pointed out. As a CSS developer I’m well aware of which hacks I’ve used where and why, and as far as I can tell nothing will break with the arrival of IE7. But I can’t know for sure until I have Beta 2 on my desktop.

    I presume this post is a preemptive strike so that IE’s critics won’t be able to say "IE 7 Launched; Internet Breaks". But if you’ve done what you say you’ve done this won’t happen. I’m very pleased that the ‘* html’ hack has been removed ‘casue all my pages would go bad without it. What you seem to be saying here, though, is: "we haven’t quite fixed the layout, so you need to check out other ways of hacking IE". Before we’ve even seen it.

    If Paul Thurrott’s timeline is right, I think you ought to consider bringing forward the release of Beta 2 – even if it’s only Beta 1 with the CSS changes (and slate a Beta 3 relase for December with the other stuff). I can’t be the only one who wants to check my sites in IE7, but none of us are going to rewrite a single line of CSS til we’ve seen it.

    Chris

  72. Anonymous says:

    @ Aziz Köksal

    "Has the IE-Team ever considered implementing the conditional comments feature for CSS documents, too?"

    This is a very good idea. I think this should come out of the CSS working group though, not Microsoft alone. If the community feels we need a non-breakable forwardlooking solution the working group is the right place.

    Breaking hacks with new versions is not just an IE problem, since hacks exist for a variety of browsers: http://css-discuss.incutio.com/?page=CssHack

  73. Anonymous says:

    I don’t have the IE7 beta to test but I’m dying to know if the float clearing method located here http://positioniseverything.net/easyclearing.html

    will be in any way affected by ie 7.

    I know it’s not an ‘ie-hack’ but it’s a bit of a hack anyway and it standards compliant browsers it relies greatly or proper parsing and implementation of css’ :after and the IE hack side of it relies on IE’s incorrect box model always expanding to enclose floated contents.

  74. cwilso says:

    I think a number of you are missing the point. The problem, as I see it, is that many web designers have gone and used particular hacks to hide or show rules for IE, when the hack is a totally separate symptom unrelated to the issue they’re trying to work around.

    It’s fine to work around bugs in a specific version of IE – but you’re not versioning that or allowing us to not break your content while moving our standards compliance forward.

    In the specific example Markus described, a CSS bug (the * html selector) was being used to work around a difference in rendering that is not specified by the relevant standard (and certainly wasn’t specified when we implemented legend). In order to not break this page’s desired rendering, we either have to not fix our CSS bugs, or we would have to arbitrarily change rendering of the legend element when its content is empty (which I guarantee would break some other site somewhere) – and that’s just one non-standards-compliance issue that’s being worked around.

    If you use CSS hacks to work around standards compliance bugs, then the only thing I’ll say is that isn’t a good versioning strategy – but when you use them to work around issues that AREN’T related standards compliance issues (like, would you think it’s a good idea to use the * html selector to work around IE’s lack of support for display:table? How about lack of support for CSS3 features?) then you are asking for that to break.

    As for the other calls to "action", well, perhaps I’ll respond to those on my own blog.

    -Chris Wilson (MS)

  75. Anonymous says:

    @Markus:

    >This is a very good idea. I think this should

    >come out of the CSS working group though, not

    >Microsoft alone. If the community feels we

    >need a non-breakable forwardlooking solution

    >the working group is the right place.

    I did some google-ing on this some time ago. It appears that the idea has been suggested several times on CSS mailing lists, and systematically rejected (mainly on the ground that it would encourage browser-specific code).

    I feel that practical considerations are more important than this concern (some people *have* deadlines to meet, and many CSS hacks are worse than a clean browser-specific extension), but I also feel that adding such a feature on your own would be very ill-perceived by many web developpers. Maybe you could propose some kind of public web-based survey on this subject?

    I agree that aligning your standard-mode implementation on the consensus of other browsers would be a good idea. On the short term, it’ll avoid some problems for web developpers. On the longer term, it’ll allow a future standard to resolve the issue.

    However, I’d like to point out that web page that rely on undefined behaviors are intrinsically broken. Maybe you can get IE to behave like Firefox or Opera, but it doesn’t mean that any standard compliant will behave in the same way. Designing Firefox-only websites is no better than IE-only. Moreover, in some other gray areas, there may not be a consensus between other web browsers.

    I take it that this post was about unmaintainable CSS hacks. Sadly, it appears that a lot of web developpers have not yet understood what "graceful degradation" is. If IE7 breaks your web pages, it may be because your hacks were *broken* and *unreliable*. You encourage the IE team to recognize past errors, to fix them and to make a better browser for the future. Please apply the same to your own work: if your CSS hacks do not degrade gracefully, learn from past errors and learn to write CSS that do not break so easily. (Isn’t it in the spirit of web standards?)

  76. Anonymous says:

    @Chris Wilson:

    >In the specific example Markus described, a

    >CSS bug (the * html selector) was being used

    Wrong hack. 🙂 It looks more like child selectors to me.

    >or we would have to arbitrarily change

    >rendering of the legend element when its

    >content is empty (which I guarantee would

    >break some other site somewhere)

    True, and I understand that it can’t be an easy decision. However, if it reduce the total number of sites broken by upgrading to IE7, it’d surely be better to change it.

    >As for the other calls to "action", well,

    >perhaps I’ll respond to those on my own blog.

    Ohoo… This seems interesting! Maybe some fresh news on the CSS front are coming?

  77. Anonymous says:

    > But I fail to see why we would need to avoid using the star-html hack. In strict mode, IE7 will ignore these rules, right? Am I missing something?

    I still don’t understand this either.

    @chris wilson:

    > I think a number of you are missing the point. The problem, as I see it, is that many web designers have gone and used particular hacks to hide or show rules for IE, when the hack is a totally separate symptom unrelated to the issue they’re trying to work around.

    That is indeed a different issue. As others here have pointed out, presumably the correct solution with the <legend> issue is explicitly to define what should be done, which ought to satisfy all browsers.

    But Chris, I disagree that we are "missing the point". The blog post does not seem to be about avoiding using hacks for things that are about browser inconsistencies due to spec vagary. The post says:

    * html

    ..

    We ask that you please update your pages to not use these CSS hacks.

    Why is it harmful to use * html ? As others have pointed out above, this should only be seen by IE5/6, whereas 7 will behave correctly. So surely we should be *encouraged* to use that as a means to move towards compliance.

    Or am I missing something here?

    The IE team are *absolutely right* to try to move to standards now rather leave buggy behaviour in than allow us to have to continue to fight buggy rendering. But the blog post is either unclear or misleading, and I suggest a new post urgently be posted if IE7’s reputation is not to be dented by hearsay and misunderstanding, as seems to be the case given the comments on this post.

  78. Anonymous says:

    A simple question:

    Do you have any statistics about how many web-pages use different css-hacks and how many pages use features that will be rendered/parsed differently with IE 7?

    If not, have you considered using a web-crawler (e.g. reusing your own msn search) to gather such stats?

    If you have such stats, do you use it to find which features are needed the most?

  79. cwilso says:

    Lionel: you are correct, I was referring to the wrong hack. Same message though.

    If you are intelligently using the "* html" hack, for example, knowing it will work for IE5 and IE6 but not IE7, then good on ya – but my point was that when you say "this should only be seen by IE5/6, whereas 7 will behave correctly" – IE7 will behave correctly and never apply these rules; you don’t really know if whatever difference in behavior you were trying to work around is "fixed" in IE7 or not.

  80. cwilso says:

    Thomas Tallyce:

    It is harmful to use "* html" because you don’t know whether the issues – real bugs or simple differences in behavior – you are working around will be removed when "* html" goes away. If you DO know this for the particular issue you’re working around, then it is not harmful. If you do NOT know this, then you should use a versioning-capable system like conditional comments, and be prepared that you will have to update your workarounds when the issues are fixed.

    Hans: Yes, yes we do, and not really – because I think customer feedback (e.g. the blog comments posted on past CSS posts on this list) is more direct and useful.

  81. Anonymous says:

    >In the specific example Markus described, a CSS bug (the * html

    >selector) was being used to work around a difference in rendering that

    >is not specified by the relevant standard (and certainly wasn’t specified

    >when we implemented legend). In order to not break this page’s

    >desired rendering, we either have to not fix our CSS bugs, or we would

    >have to arbitrarily change rendering of the legend element when its

    >content is empty (which I guarantee would break some other site

    >somewhere) – and that’s just one non-standards-compliance issue

    >that’s being worked around.

    So what you saying is:

    "We break some sites the one way or the other.

    However, we rather prefer to break sites that support other browsers than the ones that rely on IE6, even if this means that the behaviour in question will still differ between browsers."

    You simply don’t get it. If you would like me to actively support your browser, then do your part to make our life easier.

    To me it doesn’t matter much if it’s a bug, or a "difference" – it just requires a different solution no matter how you call it.

    Klaus

  82. Anonymous says:

    For all the years I’ve made websites, I never used a hack, and all my sites looks the same in any browser!!

    I am amazed that you guys don’t simplify your code to work on anything, it’s just HTML and CSS.

    Good luck

    P.S. I’ve been designing websites for over 10 years

  83. Anonymous says:

    Sorry if someone already mentioned it (or if it is said in the article), but why don’t you make IE7 ignore the hacks, just like every other browser does?

  84. Anonymous says:

    @: Alexander Hoff

    "Regarding the legend tag:

    The HTML 4.01 spec does not specify what should happen with an empty legend tag. Right. But why do you reserve a white space for an empty legend tag? If a tag is empty your browser should not print anything."

    IE /always/ preserves a line-box even if there is no inline content, and not just for ‘legend’. The simplest thing to do is set the font-size to 0 (legend {font-size: 0;}. It causes no harm and fixes the intrinsic height issue.

    It would certainly be better were an empty element actually empty, but that’s not the way IE works. If that were the largest IE problem, life would be sweet.

    cheers,

    gary

  85. Anonymous says:

    Markus, maybe it shouldn’t be stated as a call to "action", but a call to "review". Because IE 6 has been out for so long, I think a lot of developers have started using hacks as a standard instead of what they should be: a short-term fix to a browser incompatibility. As the usage of CSS has increased, better and better hacks have come along. It’s probably time for everyone in the industry who maintains a site that uses CSS to go look at their stylesheets and review what hacks they’re using to get around problem X in browser Y. If you’re using one on Markus’s list, maybe look for a better one.

    If you don’t have IE 7 yet, then just catalogue the hacks you’re using so at least you know where they are when you do get IE 7 to play with.

    IE 6 is not going away anytime soon (it took more than 3 years for IE 6 to knock IE 5.5 below 50%), so we’re still going to need hacks. We just need to be smart about managing them. If we’re not, well, we, and the businesses we build sites for, will be very sad.

    Oh, and the blustering about not supporting IE 7? That’s funny. I don’t think you have a choice if you want to remain in the industry. I for one hope that IE 7’s adoption rate is 10X faster than IE 6’s so I can stop supporting it (because browser’s don’t return from the dead, you know).

    Good luck, IE team. Our sanity depends on you guys getting it right!

  86. Maurits says:

    It will be a lot easier for me to fix my sites for IE 7 if you give me IE 7.

  87. Anonymous says:

    Wait wait wait…wait! You’re asking thousands of web developers to go back and change all their style sheets because you don’t like the way they’ve had to get around IE’s bugs? How about you, instead, fix IE so that 1) The CSS works properly, and 2) the hacks no longer work. This would solve everyone’s problem. You could even distribute it as a part of those nifty Windows update things. Just a thought…

  88. Anonymous says:

    My Proposal: Make your web-browsing software fully CSS compliant before releasing it. Then ask again 😉

  89. Anonymous says:

    Hey,

    and what is about all the other user, which are unable to use IE7 or unable to upgrade to IE7?

    Should they use Opera or Firefox instead of IE6?

    There are many user, like Windows 2000 owners, which are unable to upgrade to IE7, because MS don’t release an updated IE for that os.

    So what about these users?!

    If all webdesigners/coders remove there CSS hacks, etc..

    regards,

    iNsuRRecTiON

  90. Anonymous says:

    It’s a good thing that IE is moving towards better standards-compliance, but, as others have stated, asking us to rewrite our code while IE 7 is still unaccessible to must of us is ridiculous. As responsible software engineers, you could do thousands of sites a big favor (as a compensation for all the rendering bugs IE 6 and its predecessors had brought onto us), and refrain from releasing this browser until _all_ previously hack-worthy bugs have been fixed.

    Chris, if the suddenly "standards-compliant" IE 7 would ignore our hacks that exploit bugs of IE 6, then should it not render everything correctly? A half-fix is not a fix. It’s much the same as it was with "application/xhtml+xml". You opted out because you could not support it reliably, and while many (including me) were disappointed, it was the right thing to do. Please either fix every bug where the hacks’ ignorance by IE 7 would cause errors, or don’t expect web developers to franctically start looking for techniques that might break an immature closed-source proprietary browser that is currently used only by a few hundred people.

    Yes, it’s a step in the right direction, but you’re still wearing the right shoe on the left foot. Until you correct the shoes, your steps will remain crooked.

    UED77

  91. Anonymous says:

    Seems to me that, if the new browser IS in fact standards compliant, then the hacks will just pass them by, as they do Safari, Firefox and the other compliant browsers.

    I don’t think I’m going to ‘de-hack’ anything until Microsoft lets us know that, say, 90% of their users have migrated to the new browser. After all, the whole point behind the hacks was to make the CSS work for the 90% of the audience who were using a non-compliant browser.

    Why not just fix it Microsoft? You don’t have to have EVERYTHING your way.

  92. Anonymous says:

    I do not understand why everyone still insists on calling it a bug and why everyone keeps saying "bug is fixed". To me, I think my life is become more troublesome now that there are no longer any techniques to treat each browser differently.

    It is understood among the majority that the way pages are rendered depends on the browser. I see in firefox I must specify a height in a div tag that has another (set of) div tag(s) with content in it or else the div tag border shrinks to the smallest height possible (which is not encompassing all that lies inside). In IE that is not the case, thankfully. So in firefox i have a whole other conditions I implement.

    To me, the hacks were not exactly hacks and the bugs were not bugs. It was part of the way browsers worked. If rendering of every browser is not the same, then each browser should have a unique code to it.

    I think I will just have to insert another css stylesheet only for IE 7.

  93. Anonymous says:

    To guy, who’s been developing websites for 10 years and doesn’t need CSS hacks: I’m guessing you’ve never moved from table-based layouts to CSS-based layouts.

    You should look into going all-CSS (in spite of the occasional need to hack it). The web community has made a lot of advances in the past 10 years. It’s great that Microsoft is going to help us out again. They were an early adopter of CSS. Unfortunately IE fell off the priorities list after Netscape was crushed. Happily, IE seems to be a priority again, and we’ll be able to do even more cool stuff with CSS.

  94. Anonymous says:

    Alright, I’ll remove my hack… Well, I never used any. Yes, IE has bugs. But except if you do the last fashion CSS trick, it is very possible to create a Design that work both for IE and other browsers without any hack. Of course it’s a little more work, but you don’t have any trouble after when things change. That what standard are for, isn’t it?

    <legend> has a semantic signification. So we should put some word (like search) and do a display:hidden, has it has been stated million time from people that were not crying at Microsoft because they will have some more work to do.

  95. Anonymous says:

    This "Call to action" is a joke. For years, MSIE6 forced us to use all sorts of hacks and now we are supposed to remove them to accommodate a web browser that is not even out yet. Even worse, MS blithely announced that MSIE7 would not even try to pass the ACID2-Test (read http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx).

    Show me a browser with good all-around standards support and we’ll talk.

  96. Anonymous says:

    I think a lot of people are still missing the point.

    1. The issue here is the way IE renders an empty legend tag, which according to MS is not a bug but a difference in the way IE handles empty legend tags vs. the way Firefox et al renders the same occurrence.

    2. According the the W3C standards there is no defined way an ’empty’ legend tag should be rendered, however it is interesting that the IE teams feel it needs to display and empty character when it encounters an empty legend tag instead of doing the logical thing, printing nothing.

    3. Furthermore, the standards on the rendering of a legend tag states the content is inline, and since MS has decided to print an empty character instead of nothing when encountering an empty legend tag it should follow that standard and use inline not block.

    4. It is in this case that the proposal from the IE team seems ridiculous since creating a hack to work around this rendering inconsistency will require developers to pour through many line of code and layouts to find where the newly used standards in IE7 develop long standing inconsistent rendering issues.

    I’d also like to point out that if MS wants web developers to work with them on IE7 bugs, fixes and inconsistencies they will need to release a public beta ASAP. Any beta released should be able to run on top of the current XP install and not interrupt or overwrite previous installations in order to allow developers to easily access their IE 6 copies for testing current projects. (Not all of us can or want to run out and buy a beige box just for IE7 testing).

    Overall I’m glad to see MS and the IE team moving towards a more standards compliant browser (the web needs this), but please be respectful of the hard work developers have poured into their sites and the hacks they have to implement because it took years for MS to deliver a decent web product.

  97. Anonymous says:

    MSFT guys… Are you against bug trackers? Have you guys ever considered giving us that much transparency? Doing so would let us PLAN AHEAD so we can do our hacks before we aren’t surprised in the final release through trial and error.

    I’m not proposing open-source, we wouldn’t be able to fix the bugs ourselves, but if we could AT LEAST track what is being fixed and what is being purposely ignored, you can do a lot of good for the web…

    I’D LIKE ALL THE COMMENTERS ON THIS BLOG TO STATE THEIR OPINION ON THIS POST BECAUSE THE POSTS SUCH AS THIS ARE DELETED WITHOUT REASON.

  98. Anonymous says:

    I’d also like to point out that if MS wants web developers to work with them on IE7 bugs, fixes and inconsistencies they will need to release a public beta ASAP. Any beta released should be able to run on top of the current XP install and not interrupt or overwrite previous installations in order to allow developers to easily access their IE 6 copies for testing current projects. (Not all of us can or want to run out and buy a beige box just for IE7 testing).

    A quick google search will show you how to have both versions installed… MS doesn’t want you to know this. Well too bad MS, I don’t see any harm in having 2 versions installed simulataneously.

  99. Anonymous says:

    MSFT guys… Are you against bug trackers? Have you guys ever considered giving us that much transparency? Doing so would let us PLAN AHEAD so we can do our hacks before we aren’t surprised in the final release through trial and error.

    I’m not proposing open-source, we wouldn’t be able to fix the bugs ourselves, but if we could AT LEAST track what is being fixed and what is being purposely ignored, you can do a lot of good for the web…

    I’D LIKE ALL THE COMMENTERS ON THIS BLOG TO STATE THEIR OPINION ON THIS POST BECAUSE THE POSTS SUCH AS THIS ARE DELETED WITHOUT REASON.

  100. Anonymous says:

    I think MS is afraid of that if pages will break in IE7, users will blame it on the browser (and not on some CSS hacks they never even heard of) and switch to another browser. Maybe that’s what it’s all about.

    Neverthless do I appreciate the efforts to make IE7 more standards compliant.

    One little thing: everybody should have used conditional comments instead of polluting their style sheets with some harmful hacks. Even two years ago, it could have been clear that there will be an IE7 some time in the future. One should *never* use hacks that are not future proof!

  101. Anonymous says:

    <!–[if IE]>

    <style>

    #footer .search

    {

    margin-top: -1.6em;

    }

    </style>

    <![endif]–>

    Conditional comments like the above are still going to break IE in the future. The risk is that eventually, a version of IE down the road will include the bugfix that caused the need for the special margin-top rule for IE6. Yet, the rule will still be applied and the search-box above will be positioned 1.6 em higher than it should be.

    Likewise, writing a conditional comment specifically for IE6 won’t work either because we don’t know if the bug will carry through to IE7 because *cough* it hasn’t been released yet *cough*

    No, Microsoft, the solution to this mess is for you to fix your CSS parser bugs *and* match your CSS rendering to that of the other browsers.

  102. Anonymous says:

    I’m using the child-selector to filter out IE’s inability to get the "background-position: fixed" style correct. Does IE7 actually get CSS1 right, now? If it does, then the child-selector filter is appropriate.

  103. Anonymous says:

    "I would prefer a CSS solution too but currently there isn’t one in the CSS standard."

    You could add an "@-ie7-only" rule to CSS that only gets interpreted by IE7. In fact it’s specifically allowed by the CSS 2 standard as long as it’s named correctly with a – or _ in front.

  104. Anonymous says:

    @Jonny fairplay

    Total agreement. Fix this BLOG before telling developers to compensate for bad MS code.

    I noticed on your post, the one above, and a bunch of posts on this Blog, that there is another bug.

    The auto-linking of URL’s (cough URI’s) is messed up. Standard links don’t terminate correctly when a double-quote, or > (&gt;) symbol is encountered.

    E.g. These links will not work, but they should.

    1.) Visit Google: <http://www.Google.com/&gt;

    2.) Visit: <a href="http://www.Google.com/">Google</a&gt;

    When MS gets around to fixing this Blog’s comment form, fix this while you are at it.

  105. Anonymous says:

    Thank you for your response.

    If what Lionel says is true, then I guess we have either to stick to CSS hacks that don’t affect IE7 or we have to use conditional comments in our HTML files in order to address rendering issues of older IE versions in a separate stylesheet.

    I’m quite reluctant to use conditional comments in my source files because it unnecessarily complicates the maintainability of my (multilingual) project (which I’m still working on). The dilemma is that every additional stylesheet is required to be localized to the languages that my website is going to support. Now you may wonder what on earth there is to localize in a stylesheet that only accommodates browser-specific CSS hacks. Well, guess what, multilinguality isn’t always all about translating messages/resources, there’s also the issue with the directionality of a writing system. Not all scripts are written from left to right, there are also some that are written from right to left (e.g. Arabic, Hebrew et al), or from top to bottom (Chines, Korean, Japanese) or even bottom to top (Mongolian). Anyway, before I digress: the directionality of a script (atm. I only care about LTR and RTL scripts) determines whether my content column has to float left or right, and whether my sidebar must have a margin-left or margin-right property set. So if I want to correct, for instance, the box model issue of IE 5.5 in a separate CSS document, then I’m required to provide the same stylesheet adjusted to RTL layouts.

    You say: "Breaking hacks with new versions is not just an IE problem, since hacks exist for a variety of browsers: http://css-discuss.incutio.com/?page=CssHack&quot;

    I utterly concur with you on this. But to be honest, I absolutely don’t care about what rendering issues Opera 5/6/7 or Mozilla 1.0 had, because their respective users should update their browser on a regular basis. If the most current version of the said browsers still haven’t rectified a specific rendering bug, then I’m willing to employ some CSS hacks as long as it doesn’t get fixed.

  106. Anonymous says:

    IE should not offer any standard-mode(s) if it actually doesn’t understand the standard.

    Calling for help promoting an incomplete product by replacing one set of work-arounds (css hacks) with another set (conditional comments)?

    That’s freaking funny.

    I would prefer another approach:

    Software-built-in workaround… Simply show a replacement page linking the download pages of the (at least almost) complicant browsers whenever IE finds something in a doc/stylesheet that it cannot handle.

  107. Anonymous says:

    Can’t you guys institute a proprietary prefix for all CSS declarations that would have the highest specificity? If all the browsers did this it would be easy to address differences.

    Example:

    div {position: fixed; -ie-position: absolute; width: 100px; -ie-width: 120px; padding: 10px;} /* Yes I know the box model is fixed, it’s just an example */

  108. Anonymous says:

    I don’t mean to be obvious… but why not just put in a selector that makes IE6/IE7 behave like the other 2 major browsers?

    #footer .search legend {

    display: none;

    }

    it solves the problem immediately, and you don’t need to worry about a browser specific hack. Both Opera and FF seem to exhibit this behaviour now, so this small change seems like the easiest option.

  109. Anonymous says:

    Concerning css-hacks for IE6 and IE5, IE7 should behave exactly like other browsers do.

    This can’t be such a big problem.

    You can’t ask us to change our sites, just because your new browser behaves in a strange way.

    You/Microsoft will get real hate, if you don’t make IE7 a „real“ browser.

    You shouldn’t insist in going your own way by doing things different.

    Do things right.

    Others do it, so you can do it, too.

  110. Anonymous says:

    ps: In my eyes it’s crap to scroll back up the page and click on „Post a comment“.

    Why do you hide the form at the end of the page?

    That’s annoying …

  111. Anonymous says:

    "Make your CSS full compliant, and then we’ll talk. Last post I checked, you weren’t going to be anywhere near Gecko or Safari. This isn’t productive, having to mop up your mess only half way. "

    Good point. In the spirit of your comment, lets all petition the leaders of our countries to declare war on their allies. I mean, if we can’t have total world peace, what’s the point of doing it "half way"?

    Come on. Lets get serious. If you went to the doctor with 2 broken legs and he told you he could only fix the right one, would you say "if you’re only going to do a half job, don’t bother"? Just because YOU CHOOSE to be stubborn doesn’t make Microsoft’s effort any less important.

  112. Anonymous says:

    "Come on. Lets get serious. If you went to the doctor with 2 broken legs and he told you he could only fix the right one, would you say "if you’re only going to do a half job, don’t bother"?"

    Actually, I’d go to a different doctor…

    More important than the empty legend tag thing for me (and I agree with the others, here… displaying an empty tag makes no sense), I hope IE7’s fieldsets display correctly when a background color is present. If that’s intentional behavior, that also doesn’t make sense.

  113. Anonymous says:

    Lots of effort to conform pages to buggy w3c standards.

  114. LarryOsterman says:

    [ MY OWN OPINION ]

    "Gil", Microsoft doesn’t own the blog software, it’s community server by Telligent.

    YWDRYP: Why don’t all the other browsers change to be like IE? After all, w.r.t. the legend tag, IE is just as compliant as the others are (since the spec doesn’t say what to do with an empty legend tag). And IE has more than 90% of the market share, so clearly the other browsers should be following IE’s lead here.

    Since this isn’t a spec compliance issue (the spec is silent in this matter), they should follow the behavior of the dominant browser, and not be different for the sake of being different.

  115. Anonymous says:

    @LarryOsterman

    Microsoft should follow examples by other browser makers because they’re already more developed in standards than IE. It would also be easier for IE to change then for all the other browsers makers to make that one change.

    I doubt Opera, Netscape and Mozilla etc, would all agree to make a change just to support microsoft’s whacky ideas.

    IE is also in new development stages, so Microsoft might as well change the ‘legend’ tag’s behaviour while they’re at it – As well as everything else.

  116. Anonymous says:

    I say release a version of IE that addresses the CSS hacks of today, and let the currently hacked implementations break. Sure, there will be a small hiccup while thousands of jobs are created to fix web sites, but the end game sounds sweeter and worth the troubles.

    I see a couple of issues in this request of MS that require further study:

    1) How many sites will break if the comments are not used? My guess is the sites affected is a minority. It might be the loudest group, but a minority still.

    2) I see this all the time with software companies, not wanting to break a few eggs. YOU HAVE TO BREAK EGGS WHEN YOU’RE MAKING AN OMLETTE. Sure, some people will get upset if you release a version of the software that disrupts the current process, but we’re moving to where the grass is greener. This sounds like an education issue – not an implementation issue.

    3) And finally, shouldn’t the new IE ignore the IE 6 hacks anyways? Isn’t that why they’re called IE 6 hacks?

    Thanks for the opportunity to chime in.

  117. Anonymous says:

    "The HTML 4.01 spec does not specify what should happen in this case. We just do it differently than Firefox and Opera, who do not reserve white space (since we were the first to implement this HTML 4 element back in the day there was no precedent to do it differently)."

    If the specification does not specify what to render for an empty legend element, why are you rendering *ANYTHING* for it? Although it seems odd both that useless elements are sometimes included simply to pass validation and that the specification even requires legend elements for fieldsets (instead of allowing them to be optional, since fieldset elements themselves add meaning to markup with or without associated labels), how to handle an empty container element seems obvious: ignore it. Am I missing something?

  118. Anonymous says:

    DAM IT PEOPLE! If you don’t know WTF you’re talking about, don’t post!

    Stop trashing IE conditional comments! Go to the dam page and READ IT before you post…well if ie will break bug fixes…DUH! You can detect VERSIONS of IE for goodness sakes. Research before you post or for that matter work as a designer/developer.

    IE team – while I’m not happy it took competition to get you folks working on IE again, I am happy with how you’re going about it — so keep up the good work (and i mean that long and short term ;-)).

  119. Anonymous says:

    I’ve been using conditional comments on a project recently, and think they rock (stylesheet has only one hack left now).

    <a href="http://www.brucelawson.co.uk/index.php/2005/future-proof-your-css-with-conditional-comments/">A tutorial: Future-proof your CSS with Conditional Comments</a>

  120. Anonymous says:

    @chris wilson:

    > It is harmful to use "* html" because you don’t know whether the issues – real bugs or simple differences in behavior – you are working around will be removed when "* html" goes away. If you DO know this for the particular issue you’re working around, then it is not harmful. If you do NOT know this, then you should use a versioning-capable system like conditional comments, and be prepared that you will have to update your workarounds when the issues are fixed.

    That seems entirely sensible. I do think the original posting is highly unclear in this regard. And I do think the vast majority of sites using the * html hack, for instance, know why they are doing so.

    Chris, I think the point is many web developers posting to this blog expressing confusion at this article, are actually expressing *trust* that the other bugs you’ve fixed, have indeed been fixed. If, as per your excellent previous postings, this there should be no need for sane web developers to start moving to conditional comments, as you yourself note.

    I would suggest following up this main posting with another for clarification. What you’ve written about seems rather different to the posting itself.

    It also seems a little premature, when a public Beta2 containing all the fixes that * html is intended to work around, hasn’t been released. Perhaps a suggestion, at Beta2 release time, IF people are finding their pages break BECAUSE they have used * html etc to work around things that are not strictly IE6 bugs (but, like <legend> are undefined behaviour), that people move to conditional comments, would be sensible.

    At present, polluting one’s HTML with conditional comments, when perfectly usable CSS hacks exist, just in case your fixes aren’t actually fixed is probably not the best strategy.

  121. Anonymous says:

    in the interest of full disclosure, i’m a firefox tester. and having tested ie7b1 and firefox 1.6a1, ie doesnt even come close to firefox. i hate the way the toolbars are arranged. they are just out of order. a few suggesions:

    -i definitely like a previous posters idea of open sourcing ie. perhaps they could run dual versions. standardIE and openIE, a community run project. similar to the regular SUSE versus openSUSE. i think this would make ie a lot better. and it wouldnt take 4 years to come out with a new version. (it was only 1 year between firefox releases)

    -i also like mozilla’s nightly builds, a new testing build every day. many previous posts on this blog talk about bug fixes, but since there’s no build for us to test, theres only the very limited ie dev staff to test it. i enjoy using the firefox auto-update to download a small 500k update everyday that includes bug fixes and new features. it allows for quicker bug filing and fixing. (most major firefox bugs get fixed in a few hours/minutes).

    i think with these 2 suggestiongs, testing and development would be better. who knows, maybe ie7 will manage to keep firefox from taking market share away faster than it already is.

  122. Anonymous says:

    How will the new IE7 hover behavior coincide with the hover.htc file that was written to get around IE6’s current lack of the hover behaviour?

    For example if IE7 is used to view a page with the hover.htc file attached would IE7’s hover behaviour work correctly?

    This page explains the particular file I’m concerned about: http://www.xs4all.nl/~peterned/csshover.html

  123. Anonymous says:

    I don’t see anything intrinsicly better in

    <!–[if IE lt 7]>

    <style>

    .foobar { foo: bar; }

    </style>

    <![endif]–>

    over

    * html .foobar { foo:bar; }

    Except that it seems like less work to change the hacks in one CSS file when a new version of IE comes out than to change the comments in all of them. I don’t suppose it matters much if new versions only come out once every five years or so.

    We don’t yet know which bugs are going to be fixed in IE7, which are going to be left, and which are going to be introduced. All browsers have bugs, and inconsistencies in behaviour like the handling of <legend>s. Personally, I’m gonna wait till a stable version of IE7 comes out, see what (if anything) doesn’t work, and fix it then. I’m not following any "calls to action" now.

  124. Anonymous says:

    As for me, this is hack too. I don’t understand why MS not accept standards W3S and complicate our lives. MS want unification but this is diversification. It’s step back.

  125. TJSynkral says:

    It is peculiar that the W3C standard talks about FIELDSET as though it might be used without a LEGEND, in the manner that /. does. However the DTD says that LEGEND is required, although having an empty LEGEND makes no sense.

    I think the problem is that the W3C authors did not reach a good consensus on this one, and put

    <!ELEMENT FIELDSET – – (#PCDATA,LEGEND,(%flow;)*) — form control group –>

    when they really meant to put

    <!ELEMENT FIELDSET – – (#PCDATA,LEGEND?,(%flow;)*) — form control group –>

    As little use as there is for FIELDSET/LEGEND, it’s no biggie, but I think IE should treat no legend the same as empty legend given this irregularity in the standard.

  126. Anonymous says:

    I don’t see me un hacking my css any time soon. I doubt very seriously that nobody will be able to find hacks that target IE7 for one thing. And if IE7 is as CSS savvy as you’d have us believe it’ll respond to the current set of hacks in the same way as Firefox and Safari currently do and IE6 will still be affected by the previous generation of hacks for another thing.

    I’ll tell you what, I’ll begin unhacking my css when you guys make a version of IE7 beta publically available.

  127. Anonymous says:

    Hi, I cant claim to understand everything you talk about here. But I am just starting to learn how to use internet related software better. For years I have just been pointing and clicking, and thats about all.

    Thanks, and keep it up!

    <a href="http://r2000.blogspot.com">R2000</a&gt;

  128. Anonymous says:

    Finally, something I like to hear from Microsoft. "We’re starting to see the first round of sites and pages breaking due to the CSS fixes we have made." Translated from web browser developer, it says "we’re making web developers’ lives easier." 🙂

  129. Anonymous says:

    Firefox sucks period. You idiots who think MS is the evil are a joke. MS makes the right decisions when standards are wrong and does it the right way. It’ll be here when FF is dead and gone. IE thanks for the innerHTML property!! Thanks for .parentElement, thanks for .Children. Anyone mention how every browser copied innerHTML? Anyone mention XLST support from the go that was once again copied by others? The list goes on..AJAX IE had it back in the day man where was FF and Opera? IE7 rules so far and when they are done FF and Opera will be coping them and implementing every feature IE came out with. Nickel and Dime software here today gone tomorrow.

  130. Anonymous says:

    Peaceout, that seems a little harsh. Certainly, IE has had excellent features in the past (IE 4 beat everything on the market hands-down at the time). If they were the first with XSLT support (I don’t have time to check, but I wouldn’t be surprised) first, good for them. It was also a brilliant move to create XmlHttpRequest.

    But it’s not about what IE has gotten in the past; it’s about what IE needs to get now.

    Currently IE’s CSS support is effectively crap. Workarounds have to be written for just about anything; they have a broken implementation of CSS 1 and part of a broken implementation of CSS 2, as well as the tremendous number of security problems brought about by ActiveX.

    Firefox has excellent CSS 1 and CSS 2 support (as does Opera), as well as a significant portion of the unfinished CSS 3 standard, and ActiveX just isn’t in there, providing truly top-notch security. Firefox is also implementing SVG.

    IE7 looks to fix a lot of the CSS bugs; it also looks like the Vista version will solve all the security problems in one fell swoop. I’m very pleased by this; I’m a little concerned that IE 7 doesn’t have *enough* CSS fixes (I would appreciate some CSS3 features), but some is better than none, and the fixes they *have* made seem to go a long way toward getting IE 7 up to the same level as Firefox and Opera.

    However, IE7 is missing SVG support, and I’m skeptical as to the security enhancements on XP. I also note that Firefox is extremely extensible (I don’t know about Opera; I don’t use it), which is something the IE seems to lack. I look forward to any improvements MS makes on extensibility.

    To say that FF will be gone tomorrow seems a little naive, if you ask me. Gecko-based products have been around since before Internet Explorer (anybody remember Netscape 0.9, from 1994?), and it doesn’t seem like it has any intention of ever stopping production.

    Right now Firefox also has a rendering speed lead on IE; especially the 1.5 betas. If IE can steal away the performance crown, excellent. That’s what a free market is all about; competition. That is most likely why Microsoft is taking the time to advance IE at all; note the period between IE 5 and IE 7 during which it had a huge market share and effectively stagnated feature-wise.

  131. Anonymous says:

    Most of the problems faced by the broken web sites are due to:

    1. Lack of implementation of standards by IE or by the website author.

    2. Incompatibilities between the various implementations of the same satandard by the different browsers.

    Problem 1 will hopefully be solve as Microsoft implements new standards and as sites are fixed by their authors. Nothing to do here, except careful decisions while designing IE.

    Problem 2 however can be solved by the establishment of an alliance between the browser designers. You might say that such an organization already exists. However, let’s be honest: There are not many browser in the world only 3-4. Why can’t they colaborate on their implementations instead of fighting with one another who will be the most standards compliant. An alliance can be formed which will analyse colaboratively and decide how unclear or confusing standards can be implemented the same across the 3 browsers. And if a browser vendor wants to be more or less standards compliant because of time, money or backward compatibility issues then this will be allowed, however it will be openly discussed amongst the browser vendors and general targets can be reached.

    You are only 3-4 players in the browser field. For the sake of your customers, please at least stop having incompatibilities in the implementations of the same standards. People want their sites to be easy to build but also not having to build more than one version for every browser. Even if browsers become fully standards compliant, the problems will continue to exist if you three do not decide to come to an agreement and colaporate instead of fighting!

  132. Anonymous says:

    Okay, do I get this right: I have always done standards-conform website design, and my pages looked absolutely perfect in FF, Opera, Konqueror etc., but I always had to add those ugly hacks only to make IE also display the site as I want it, which honestly got me really pissed off sometimes, and now you want me to remove all those IE-hacks, only because it took you years to find out that there’s a standard for such things as HTML and CSS and because you realized that your strategy to take open standards and change them to your liking to bound users to your products will fall back on you sometimes in the future? Come on, I always had twice the work to make my pages work with your browser, and now I again have to work to make it work in your old browser AND in your upcoming browser? I’d rather redirect IE-users to http://www.mozilla.org, thats much easier!

    Tom

  133. Anonymous says:

    Sorry couldn’t be @rsed reading all comments so don’t know if someone’s already posted this, but isn’t the point of standards to move away from conditional coding for specific browsers like IE(7)?

    Yes I understand we as developers currently use hacks to make our pages look similar in most browsers.

    However, to go backwards to the days of multiple stylesheets for different browsers, this is just idiocy at a completely new level imho.

    Am I missing something here? Even the webstandards project (www.webstandars.org) is in support of this, yet they seem to be contradicting their whole ethos and basis of their site. Big loss of respect there.

    This whole concept is totally flawed and anyone praising it should get their head checked because come IE7’s release developers will all be cursing having to support yet another browser with a separate stylesheet.

    Just like the days of…

    if ( navigator.appName.indexOf( "netscape" ) ) document.write( … );

    else if ( ad infinitum )

    I’m happy to be proven wrong here, but you just can’t talk about standards compliance, when you’re trying to introduce it by adding conditional coding to your web pages.

    Chris.

  134. Anonymous says:

    Sorry couldn’t be @rsed reading all comments so don’t know if someone’s already posted this, but isn’t the point of standards to move away from conditional coding for specific browsers like IE(7)?

    Yes I understand we as developers currently use hacks to make our pages look similar in most browsers.

    However, to go backwards to the days of multiple stylesheets for different browsers, this is just idiocy at a completely new level imho.

    Am I missing something here? Even the webstandards project (www.webstandars.org) is in support of this, yet they seem to be contradicting their whole ethos and basis of their site. Big loss of respect there.

    This whole concept is totally flawed and anyone praising it should get their head checked because come IE7’s release developers will all be cursing having to support yet another browser with a separate stylesheet.

    Just like the days of…

    if ( navigator.appName.indexOf( "netscape" ) ) document.write( … );

    else if ( ad infinitum )

    I’m happy to be proven wrong here, but you just can’t talk about standards compliance, when you’re trying to introduce it by adding conditional coding to your web pages.

    Chris.

  135. Anonymous says:

    Let’s not kill IE7, Microsoft are gonna do that by saying it won’t run on Windows2000, therefore a users upgrade path will be to naturally move away from IE or buy a new PC. If we can educate people to what a web browser is, that will be a moment to note in history as many people simply can’t use the Web if there is no blue e to click on.

    Let’s move forward, dispense or vast knowledge of their browser and work together to help them, help us, in the spirit of the common good.

    Everyone join in: "there are people coding, if you care enough for the websites, spread a little fox for you and for me" …..

  136. Anonymous says:

    I personally think that conditional comments within CSS should be discussed more so, than simply pushed aside just because the W3C and others don’t agree, as I feel people in support of such a feature have valid points.

    However, I don’t feel this post’s comments section is the place, so perhaps the IE team (or those over at WASP) could start a new post entry, with the aim of ironing out the pro’s and con’s in one place?

    The reason being, I feel that an IE BETA is the perfect place to trial it. If it works out, it should be included in the main build, if not, it can be removed before the final product is released.

    I am in complete support of W3C recommendations, but I do feel that just because they reject the idea of CSS CC, that the idea shouldn’t be put to bed.

    As far as I know, the W3C have no active role in syndication XML mark-up, RSS, ATOM, etc (please correct me if I am wrong here) but look where that has gone.

    While it would be great if all browsers supported the recommendations to the full, I think history has shown this isn’t the case, nor will it be for a long time coming, be it via lack of support, or just bugs (known and unknown).

  137. Anonymous says:

    Ops, forgot about the main point of this entry.

    I feel that the comments which state ‘display: none;’ should be used in this case are correct.

  138. Anonymous says:

    Conditional comments in the CSS is one thing, we already have pseudo-conditional comments in the form of a Mac IE5 ignore hack, etc. This post is referring to conditional comments in your HTML page, which means you lose your extensibility because you’re adding conditional comments. You missed the whole point, and if you think that conditional comments in your code is a decent enough thing go back to 1998 and code, coz that’s where you belong. There is no valid point to making my job and every other decent front end developers’ job out there more difficult, and reducing ROI by making re-designs more complicated, etc.

    There are no pro’s and cons here imo, if they can’t support standards, which the good people at mozilla and opera obviously can, then why are they creating a new browser? Just ad tabbed browsing to IE6 and save us all the hassle till you can pull your finger out of your @rse and do something productive.

    But yes the idea should be put to bed, the w3c make standards not conditions for people to do whatevet they want, otherwise there would be no point having a recommendation, or an advisory board, it would be a free for all.

    Let’s learn from history rather making an effort to keep repeating it. Mozilla is moving the whole thing forward, MS should catch up and help make surfing the net all it can be.

  139. Anonymous says:

    Why does IE 7 don’t support all CSS 2 specification?

  140. Anonymous says:

    Oh my gosh, you arent kidding…after a quick run around the internet with IE7 in Vista 5231 it looks well…..very broken…you really need to get a public beta of IE7 to developers pronto. Even download.com looks aweful.

    It’s ashame old versions of IE have ruined the internet for a long time to come.

  141. Anonymous says:

    It’s fantastic to hear IE7 will finally correct the CSS problems that held back the Internet for so long.

    However, in the time it has taken for Internet Explorer to finally do this we have obviously all poured an insane amount of time into pushing forward with CSS and as such having to develop work-arounds for Internet Explorer – as such we obviously all have a lot of work to do in undoing a lot of this work so that IE7 will work.

    That said, it boggles me how MS employees could possibly ask us to do this without even having a copy of IE7 to test with. Are we meant to simply remove all these work-arounds and just blindly assume IE7 will work? We don’t even know what has and hasn’t worked and, sorry to be harsh, but we have no reason to assume your new fixes will actually be standards compliant… it MAY be possible we still have to implement work-arounds to make IE render/work properly.

    Surely MS should be distributing copies of IE7 NOW so that we can use it to prepare – otherwise, frankly, none of us are going to do anything until we physically have a copy of IE7 in our hands. If that’s December as has been suggested then I’m guessing February may be the earliest any of us even begin to look into this.

    I feel the need to point out that simply removing these hacks is no solution – IE6 is unfortunately used by a lot of people, generally what 80% (for my customers I’m happy to say only 40%), so what really needs to happen is all the hacks be reworked to only kick in for IE6. In my case every page is dynamically generated, even the CSS itself, so I spit out completely custom code when I detect IE… again, without a copy of IE7, I don’t even know how it is I will be detecting IE7 so that I can spit out a standards compliant version for all browsers, a tweaked version for IE:Mac, a hacked up version for IE5/6, and then no doubt a tweaked version for IE7 (I’m assuming there will still be differences).

    Not to repeat myself again, but without an actual copy of IE7 nothing can happen.

    Must say, after all the insane amount of time I poured into making IE work properly with a pure XHTML/CSS site, I am not looking forward to the thought of having to go through that process again… I honestly sincerely desperately do hope that IE7 works purely with my raw code, no custom tweaks necessary…

  142. Anonymous says:

    In response to "Wojteq", no browser fully supports the spec yet. For example, I have not been able to get auto-generated numbering working and have so far not seen an example of it either, which is a damn shame considering how much help it would be to so many different types of web sites. I also haven’t seen that great a support for paged media either, though mozilla has definately stepped this up a few notches.

    Since MS is already familiar with it’s former browser’s inconsitencies with the spec and various other tribulations, why doesn’t it build IE7 with these in mind. This is, why does it not just ignore the hacks we put in for former IE versions?

    Or why doesn’t it do something similar to what IE6 already does by switching to a lower version of IE’s rendering engine when different doctypes are present or if there is a xml declaration or comment preceeding the pages’ doc type?

    The best solution though would be to simply use the gecko rendering engine, I mean it is an open source project after all. Though I imagine human pride, which is something we all posses and are made falliable by – we’re not gods, remember that MS – is hindering this solution.

  143. Anonymous says:

    The biggest gripe usually is the difference in box models right?

    W3C has provided the "box-sizing" property. (CSS3 I think)

    Gecko supports this up to some point. (with values "-moz-content-box" and "-moz-border-box")

    Make sure IE7 understands this property. Then developers will have the solution in hand.

  144. Anonymous says:

    "Sorry, we wouldn’t have these problems if Microsoft would have done this job correctly from the beginning. So you learned that it’s not a good way to ignore exsiting standards.

    Hope Ms learned its lesson."

    NEVER!

    <a href="http://r2000.blogspot.com">R2000</a&gt;

    <a href="http://nybathrooms.com">Bathroom Review</a>

  145. Anonymous says:

    Can someone explain what this means please?

    IE6 security (?) alert:

    "Entering a non-secure Web site from a secure Web site

    The Web site you were viewing was a secure site. A secure Web site provides secure communication and has a valid certificate. Secure communication means that information that you provide, such as your name or credit-card number, is encrypted so that it can’t be read or intercepted by other people. The certificate is a statement verifying the security of the site. A certificate contains information that a specific Web site is authentic. This ensures that no other site can assume the identity of the original site.

    However, the Web site you are going to does not use a security protocol, so information you send and receive will not be protected. And since the site does not have a certificate, you cannot be sure that the site is who it says it is.

    Given what you know about this Web site and your computer, you must decide whether to view this site.

    If you do not feel confident about viewing this site, click No."

    It says the site used to be secure, but then goes on to explain what a secure site is. After you’ve read what a secure site is, it tells you that this site is NOT secure.

    Why does it explain what a secure site is if the warning is for an insecure website?

    This confused me so much I didn’t know what to decide, considering I HADN’T BEEN VIEWING ANY SITES BEFORE I GOT THE WARNING. "The Web site you WERE viewing WAS a secure site."

    This was for a Microsoft website too – hotmail.

    Please do something about your warning messages, they are useless.

  146. Anonymous says:

    You made your bed …

    Why don’t you lie in it ?

    😉

  147. Anonymous says:

    In response to Herbie, if you read what I have already posted and what Ben Buchanan wrote you’ll realise that what you’re saying is absurd to say the least.

    We want to go forward not backwards, please read the other posts as to the reasons we wish to not have conditional comments in our web pages, so we do not have to keep repeating ourselves.

    Chris.

  148. Anonymous says:

    Many of these comments are nonsense!!!

    Here’s my two cents. IE6 did have a lot of oddities and require hacks, and I really think Microsoft is right in fixing the bugs even if it means some hacking sites will break.

    I know everyone likes backwards compatability, but every once in a while, something has to be overhauled. If IE7 can be repaired to the point where IE7 code will work essentially the same on FireFox, and vice verca, than fantastic. This is a long term solution.

    I’m with Microsoft on breaking some compatability. I’d rather have a platform where I don’t have to hack in the future than have IE continue to be so very odd.

    Also, something that’s a bit off topic, about spyware.

    Will it be possible for system administrators to set a stricter policy on browser pluginaddon installation? Currently at my office I put FireFox on the systems, and because FireFox downloads plugins from a closed network, users don’t stumble on websites that automatically install malicious-but-obnoxiously-legal spyware "addons" and "toolbars" and "plugins". The vast majority of users don’t understand these things, and the warning message IE pops up is just gibberish. They ignore it and agree to install. If I could put a restriction on that, nontrivial to override, I’d be happy as a clam.

    That’s the main reason I run FireFox… Most Windows computers get infected fast if non techies use it. FireFox is much more idiot proof in that regard. I don’t let other people use IE on my computer for that reason… One time my brother visited from out of state, and used my computer some over the time, and after spending a week and a half with IE, actually completely 100% broke the computer o_O baffling.

  149. Anonymous says:

    I’m not much of a webdesigner, even though I have been trying to come up with something usefull during the last 10 years. No imagination *sighs*.

    Anyway, my question to you IE and other webdesigners is, wont all your pages that works in FireFox/Opera/Safari etc also work in IE7 if IE7 will use the same web standards?

    Or did you make sites specifically for IE6 that doesn’t really work in any other browser (I have seen a lot of these)?

    To me it looks like this, if it works in FF and IE7 will use web standards, then it will just work as normal.

    Am I right or wrong? IE team, developers?! =)

    I’m happy when my stuff work in lynx. 😉

  150. Anonymous says:

    Lordmike,

    That’s kinda my view on it. If a web designer truly has a "standards compliant" mode and a set of IE hacks, it ought to continue to work, all that’s required is a little few lines of code to check if the user is running IE7 and, if that’s the case, use the standards code.

    Of course, that’s kinda fantasy land.

    There are some behaviours – as this Slashdot issue demonstrates – that aren’t quite defined in the spec.

    Furthermore, all browsers do have quirks. FireFox inclusive. I work on FireFox all the time, and I’m using it right now… I develop all my sites for both FireFox and IE (I used Linux but IE6 runs with Wine) and there ARE some incompatabilities which turn out to be a bug in FireFox, or simply some undefined behaviour that happens to be different in the browsers.

    This is rare, but you only need to find one such oddity to have to fork your code per-browser.

  151. Anonymous says:

    hey,

    something that has always bothered me is how differently ie & firefox (dunno about others) handle paddings.

    if i have a table cell with a fixed size of 200×200 and padding of 10, IE will add the padding to the size so the total size will be 220×220, and firefox won’t.

    I hope in the future all browsers will handle this the same way, it’s a pain in the ass.

  152. Anonymous says:

    I don’t honestly see the point – at current Firefox growth rates, it will have a higher market share than IE by the time Vista comes out

  153. Anonymous says:

    Backwards compatibility is your problem and obviously in your own interests to have older pages render properly. IE6 isn’t going away anytime soon.

  154. Anonymous says:

    I’d personally like to request developers NOT TO FIX their so called hacks. Why should we? Let the pages break and users can be forced to download conforming user agents, e.g. firefox.

    It took long enough to work around IE’s problems, if MSIE team has to suffer a bit to make things work .. well, they deserve every bit of it

  155. Anonymous says:

    quote:

    hey,

    something that has always bothered me is how differently ie & firefox (dunno about others) handle paddings.

    if i have a table cell with a fixed size of 200×200 and padding of 10, IE will add the padding to the size so the total size will be 220×220, and firefox won’t.

    I hope in the future all browsers will handle this the same way, it’s a pain in the ass.

    end quote

    Actually, as of IE6, they all DO handle it the same way.

    CSS states that width and height should not include padding, border and margins; so a box with a width of 200px and a padding of 10px SHOULD have a width of 220px.

    IE5 didn’t do this, mostly because the old way was the standard way done before the spec was written. IE6 does it the same as the other browsers, but only in standard mode (in quirks mode, IE6 will use the old box model, like IE5).

  156. Anonymous says:

    Really? That’s good.

    One other thing I’d like to see fixed is IE’s rendering of dotted/dashed borders – all broken, when you for example scroll them outside the current window and back

  157. Anonymous says:

    I still need to know if IE 7 is going to stop allowing poorly formed code. If it is I have to approach my analysis differently than if it isn’t. I am hoping for the isn’t.. thank you !

  158. Anonymous says:

    It’s all well and good for Microsoft to fix all the problems that we’ve worked hard to correct for, using CSS hacks. It’s what we’ve been asking for, for years. (Too bad all the browsers can’t just use the Mozilla/Gecko engine…)

    However, it is silly for Microsoft to expect us to fix these problems, in advance of getting copies of IE7 — suggesting, naturally, that we all pay through the nose and subscribe to MSDN.

    This problem is largely of Microsoft’s own making, and then they want us to pay THEM to get copies of IE7 in advance, and fix all the sites that we worked hard to create? I don’t think so. They need to make IE7 available in advance of general release, to web developers who can substantiate the need for it.

  159. Anonymous says:

    One more thing…

    Without having a working copy of IE7 beta, there’s no way for us to know how to modify our code in advance. Simply saying, "We’ve fixed the rendering bugs" and "don’t use hacks" isn’t going to cut it. There are still going to be differences in how Gecko, Opera, Safari, Konqueror, etc. render pages, even if IE didn’t exist. Therefore, hacks are not going to go away, as long as rendering engines interpret the same (X)HTML and CSS differently. I have my doubts about how conditional comments are going to work in non-Microsoft browsers, for another thing.

    The ultimate proof is going to be to see how a page that renders fine in other browsers looks in IE7, and how to correct those differences. It will just lead to another IE7 hack.

    Microsoft can do us all (including themselves) a favor and purposely build in a CSS hack for IE7. Otherwise we’ll have to find one, and if that fails, then IE7 users will have to live with broken web sites, making Microsoft’s project a dismal failure.

  160. Maurits says:

    > purposely build in a CSS hack for IE7

    For example:

    @-ms-ie7

    {

    /* This block will apply only to Microsoft IE 7 */

    }

  161. schachin says:

    Though I have read most of the comments, I know this may be a duplicate post and if it is I apologize (so much to get thru 🙂 ), but I have a question about properly formed HTML.

    I know and understand how IE 7 will implement standards related to CSS, but I have yet to read about how they will handle standards around poorly formed HTML.

    For years, IE has taken code that is written with unclosed tags, improper nesting and deprecated HTML. In IE 7, will sites that are written with poorly formed HTML be rendered more like they are in Firefox or will they still render in IE as they do now?

    This is important because I work for a company that does not see the need to make our code correct (let alone compliant) because most of our users are IE, so I need to know if our poorly formed code will break in IE7. thanks!!

  162. Anonymous says:

    You are suggesting to use condition comments to work around problems with IE. Unfortunately the downlevel-revealed conditional comments as described on MSDN do not validate (if someone should ever feel the need to use them instead of uplevel-revealed).

    I found a work-around for this problem using a quite unusual syntax:

    <!–[if IE]><![if !IE]><![endif]–>



    <!–[if IE]><![endif]><![endif]–>

    (more details on http://www.odahoda.de/blog/2005/04/06/valid-downlevel-revealed-conditional-comment/).

    Can we expect that this behaviour will continue to work in future IE versions? (I haven’t tried it in IE7beta, but it will apply to IE8+ too anyway).

  163. Anonymous says:

    With regards to your legend rendering I cannot understand why you are doing it differently than the other 2 browsers mentioned.

    If there isnt a set standard by the w3c, then don’t create it your own way.

    Creating different ways of doing things is what caused all the issues in 5/6/etc.

    Standard is 1 way unform amongst all things, not "doing it a different way" beceause it isnt specified.

  164. Anonymous says:

    To Philip J Fry :

    Difficult to educate the public, in fact.

    We are company A. Yesteray the phone rang. A Mrs Roe lady started to tell me we are company B. As I protested we are not company B, but company A, she claimed even more vehemently we are comany B. I decided to turn around the problem and kindly ask here why she knows we are company B. She told me she entered company B name in her brwoser and was directed to our site.

    For her, since entering company B name in her browser bring her to our site, then we are company B, even if our site is clearly stating, from logo to bottom contact address, that we are company A. very clever.

    But that’s not all. As you certainly understood, Mrs Roe did not enter company B name in the adress bar of her browser. Actually, she did enter it in the search engine bar. Since there is, on a remote page of our site – not even in thye front page -, a note about company B, Mrs Roe was offered a search result page with our site on front rank, and clicked on it being sure it was Company B she reached.

    The conclusion is clear :

    – apart some geek, people do not understand what is a web site.

    – they do not make any difference between an adress bar and a search bar.

    – they even don’t understand the difference between "this site is company B site" and "this site contains the sentence ‘company B’".

    Which brings me to the point :

    IE lack of support for standards so far is unforgivable.

    But spending hours to develop hacks for so trivail things as a space in a legend box is not cleverer. Both IE and hacks developpers deserve what they now reap.

    Rally, what is the mater if the legend box in IE display a blank and not in Firefox ? What does it change to the real navigation experience of Mrs Roe, which, I guess does not even know how to close the browser window ?

    So here is my proposals :

    – to Markus : don’t care about hacks. Don’t be afraid to break site that rellies on hacks. The only think you must be afraid of is breaking site that are standard compliants.

    – to web developers : develop for the most standard compliants browser. Then test in using any browser having at elast a 5 % market pentration. Then remove anything that breaks so as to render navigation difficult. Simplify your lay-out if needed. In most case, ergonomy will improve just by renouncing to use that superb layouts that just breaks in the other browser. Most of all, do never relly on hacks just for the pleasure of the eye. It is not worth the risk.

  165. Anonymous says:

    "For IE7, we introduced new CSS functionality and cleaned up our parser bugs. This leads now to several CSS hacks failing."

    I’m not normally one to defend MS on ANYTHING, but there is a grave misunderstanding in many of the responses I’ve read here. Marcus did not ask us to REMOVE our hacks.

    The problem in the example given by Marcus is a combination of the IE rendering of the LEGEND tag, the (nonsense) requirement of the tag to be valid and the negative margin fix ("hack"). IE7 still renders the legend tag the same (which is legitimate if not wise), but now recognizes the html > body #footer .search { margin: 0; } override used for other browsers that don’t render the empty legend tag. However, this is only ONE example.

    Marcus suggests that we use conditional comments to specify which browser a particular hack is for. This is good practice if you’re going to use hacks anyway. Versioning systems are quite familiar to programmers, but apparently hasn’t been grasped by many web developers. I agree, such comments shouldn’t be necessary (esp. in our HTML), but neither should hacks in our CSS. As IE moves into full standards compliance (as we all want it to do) We can expect there to be bumps along the way.

    Yes, in this particular example it would be better for all if IE simply stopped rendering empty tags, but that’s only ONE fix for ONE problem and is not necessarily true for ALL cases. It seems from a lot of these responses that many of you want IE to be FF, but it isn’t and never will be.

    When ALL browsers are fully compliant, then we can get rid of all these senseless hacks, but in the meantime, we as developers should properly version the hacks we use so compliant browsers don’t even have the opportuniy to get confused.

    It’s really little different than commenting your work which you should do anyway for maintenance.

    I agree it would be better if these conditional statements were available in external CSS, but as far as I know we’re stuck on this point.

    As for MS… it’s about damn time. :o)%

  166. Anonymous says:

    I haven’t had time to read every single comment, treat repetition as a vote for the idea:

    If you’re going to create new, official hacks then please create them in the external CSS so we don’t have to add code to every single document.

    …yes, I do think conditional comments are a hack, not a solution or feature. The conditional comments serve no purpose for any product other than yours, which goes against the idea of ‘build once, display anywhere’.

    Your way means we have to add a line to every document (sure, we have nothing better to do) AND run an extra CSS file. The CSS way would mean we just update our existing stylesheets.

  167. Anonymous says:

    Sorry, we wouldn’t have these problems if Microsoft would have done this job correctly from the beginning. So you learned that it’s not a good way to ignore exsiting standards.

    Hope Ms learned its lesson.

  168. Anonymous says:

    I give an input button a 1-pixel-solid-border, yet it displays what appears to be a 2-pixel-solid-border. I give the same input button padding and margin of zero, yet there appears to be 20 pixels of empty space on either side.

    Tell me this has been fixed already.

  169. Anonymous says:

    Thomas mentioned, "real bugs" vs. "simple differences in behavior" here: http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx#481630

    Does anyone know of any kind of list of behavioral differences that excludes bugs?

  170. Anonymous says:

    There was a time, many moons ago, when IE was king and all other browsers were playing catch-up, modifying their browsers to behave similarly to IE in all areas which were out-of-scope of the W3C standards.

    Times have changed. It is now IE’s turn to play catch-up, and modify IE to behave like the current bleeding-edge set: Opera, Mozilla, Firefox, Safari…

    In version 9, Opera has finally modified their unordered list default styling to match Firefox, rather than IE. They know where page design is going, eg. one design for all. Apparently, the IE7 development team has not been allowed to learn this lesson.

    These conditional comment solutions just give further proof that the IE7 team has no plans to relinquish their quirks in favour of a higher unifying purpose.

    Sure, they will fix the CSS bugs, the rendering bugs and all the misbehaviours that contradict the spec, and for this I am truly pleased! But what of those things outside the spec? Things for which the newer browsers have settled upon a solution, while IE languishes behind undecided.

    Must we, as developers, always have to deal with the two different methods by which lists are styled? Must we always have to deal with two different ways the <legend> element is handled? Must we always be required, in some way, to single out the IE family using conditional comments because IE *just* *acts* *differently*?

    It seems to me that MS is depending on its market-share to drive other browsers back to designing for *its* differences rather than none at all. The developers of other browsers, and many of their users who also design websites, will not be fooled by this veiled indifference.

    For years, Opera and Mozilla have been making concessions to IE. Is there no hope that IE will make some in return?

  171. Anonymous says:

    As most people agree on css design will follow the w3c standard. If a brouwser doesn’t follow these rules hacks will be needed.

    I will never consider polluting my html output with conditional comments.

    regards,

    Bastiaan

  172. Anonymous says:

    > There are still going to be differences in how Gecko,

    > Opera, Safari, Konqueror, etc. render pages, even if

    > IE didn’t exist.

    Are there? If you look through web pages and design forums, you never see:

    /* Hack for Firefox because it doesn’t render

    such-and-such properly */

    … or:

    /* Konqueror doesn’t do this properly, so we

    have to hide it */

    Why is it always IE? Because it’s the worst browser known to humankind. If Netscape had beaten IE (read: if Microsoft hadn’t managed to wrangle IE into being distributed with its OS) the web would be far ahead of where it is today.

  173. Anonymous says:

    Really? You’re asking web designers to change their coding habits to work with your new browser?

    I contest this absurd request, and ask you to fix your broken browser to comply with web standards. Then no hacks will be required, whether CSS-based or conditional statements. The latter is still a hack to accommodate a browser that is developed to serve the needs of Microsoft rather than the needs of web visitors.

    It is you, Microsoft, that needs to change its habits. Not web designers. This is my call to action for you.

  174. Anonymous says:

    I just hit an IE display bug I hadn’t encountered before, and its solution:

    http://www.satzansatz.de/cssd/pseudocss.html

    I’m guessing that since you’re implementing all the CSS 2.0 pseudo-classes in IE7 this will now have been fixed, but thought I’d toss it your way just to be sure.

    Chris

  175. Anonymous says:

    I’m reading the MSDN description of conditional comments (http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/ccomment_ovw.asp).

    There seems to be an error in the article, or I’m just not understanding it.

    There is a "Show me" sample to demonstrate the [if IE 5] conditional statement, and when I view the demo using IE 6.0, it displays the message box telling me that I’m using ‘IE 5 or later.’ But the article then says, "Clearly, Internet Explorer 6 will not display the message box or the text content because the major version number is different."

    So why is it displaying for me when I’m using IE 6? Did the article just get it wrong?

  176. Anonymous says:

    Twey seems to have forgotton about Netscape 4. That was truly the worst in common usage, and thank God it can pretty much be ignored these days. If Netscape had beaten IE, some derivative of NN4 is what we’d be left with, instead of the much better Mozilla based browsers that were a direct result of losing the browser war.

    Anyway, an HTML conditional is not too useful when you have to apply it to hundreds of pages, including some that might be on other people’s servers. If MS doesn’t want us to try to find some sort of CSS hack that they didn’t account for, it would be much better if they provided us with a straightforward condtitional that could be used _within_ our CSS files. Something like this perhaps:

    /*[if IE gte 7]/

    #footer .search { margin-top: -1.6em; }

    /[endif]*/

    This would no more break standards than the HTML version, since other browsers and validators would read all that as a comment.

  177. Anonymous says:

    Internet Explorer, CSS Hacks

  178. Recently, Microsoft has published the Second Public Beta of the forthcomig and long awaiting &lt;a href=&quot;http://www.microsoft.com/windows/ie/ie7/default.mspx&quot;&gt;Internet Explorer 7&lt;/a&gt;, addressed to developers and web developers to test

  179. At the end of January, Microsoft released a public beta of the next version of Internet Explorer [download | readme | tour]. IE 7b2 offers more stringent security measures and other improvements including tabbed-browsing, updated CSS, RSS support and

  180. CSS Hacks sind fr den Webdesigner lebensnotwendig, wenn er anspruchsvolle Crossbrowser-Webseiten entwickeln will. Hier mal ein paar sehr interessante Seiten, die ich ber CSS Hacks gefunden habe. CSS-Hacks am Box- Modell (Thestyleworks) Eine Aus

  181. One good thing about the redesign of this site that I released back in June, I used IE conditional comments to separate the IE CSS hacks needed to render the site properly. That seemed like a good idea then, and now the IE team working on IE7 is saying

  182. Avoiding CSS Hacks and Future Proofing Your CSS

  183. It’s always nice to see software lining up to work around standards. But when you throw out the accountability issues for not doing this right the first time, its just likely to end up biting end users. And such a…

  184. At the end of January, Microsoft released a public beta of the next version of Internet Explorer [download | readme | tour]. IE 7b2 offers more stringent security measures and other improvements including tabbed-browsing, updated CSS, RSS support and