Welcome to MSDN Blogs Sign in | Join | Help

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

Published Wednesday, October 12, 2005 1:07 PM by ieblog

Comments

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

Wednesday, October 12, 2005 4:21 PM by Phil Scott
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.



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

Wednesday, October 12, 2005 4:31 PM by Kevin Lawver
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.

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

Wednesday, October 12, 2005 4:36 PM by Duncan Lock
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.

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

Wednesday, October 12, 2005 4:45 PM by Joel Bruick
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.

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

Wednesday, October 12, 2005 5:11 PM by Lionel
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?

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

Wednesday, October 12, 2005 5:20 PM by Ben
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.

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

Wednesday, October 12, 2005 6:21 PM by Analgesia
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

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

Wednesday, October 12, 2005 6:26 PM by Joel Bruick
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.

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

Wednesday, October 12, 2005 6:41 PM by PatriotB
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?

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

Wednesday, October 12, 2005 7:49 PM by Jim
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?

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

Wednesday, October 12, 2005 7:49 PM by Carey Evans
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?

# I for one welcome our new CSS overlords ;)

Wednesday, October 12, 2005 7:51 PM by kL
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...

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

Wednesday, October 12, 2005 7:51 PM by John Serris
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.

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

Wednesday, October 12, 2005 7:53 PM by Juan Carlos
Would like to know when IE 7 Beta 2 will be out, please, so we can make such changes AND test them.

Thanks.

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

Wednesday, October 12, 2005 7:54 PM by kL
@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.

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

Wednesday, October 12, 2005 7:58 PM by Thomas Tallyce
> 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?

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

Wednesday, October 12, 2005 8:33 PM by Brady J. Frey
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.

# A suggestion

Wednesday, October 12, 2005 10:34 PM by Aziz Köksal
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.

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

Wednesday, October 12, 2005 11:43 PM by Lachlan Hunt
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.

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

Thursday, October 13, 2005 12:11 AM by Alan Trick
==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'.

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

Thursday, October 13, 2005 12:41 AM by C Montoya
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?

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

Thursday, October 13, 2005 12:53 AM by Ryan Blunden
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.

# Congratulations

Thursday, October 13, 2005 1:30 AM by Craig Ringer
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.

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

Thursday, October 13, 2005 1:36 AM by Lordmike
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/

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

Thursday, October 13, 2005 1:50 AM by John A. Bilicki III
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?

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

Thursday, October 13, 2005 2:45 AM by Thomas Vavra
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.

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

Thursday, October 13, 2005 4:28 AM by Robin
Thomas - yes, they have done on both attribute selectors and alpha PNG.

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

Thursday, October 13, 2005 5:11 AM by Jens Meiert
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.

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

Thursday, October 13, 2005 5:29 AM 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.

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.

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

Thursday, October 13, 2005 5:36 AM by Rijk
@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.

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

Thursday, October 13, 2005 5:57 AM by wondering
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.

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

Thursday, October 13, 2005 5:59 AM by 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.

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

Thursday, October 13, 2005 6:06 AM by Paul S
Can't you wait till you release at least the public beta before requesting this....I have no access to IE7 through Microsoft.

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

Thursday, October 13, 2005 6:19 AM by a webdeveloper
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...

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

Thursday, October 13, 2005 6:30 AM by jeffrey
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.

# Yes, I know it's blasphemy

Thursday, October 13, 2005 6:34 AM by Ben
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.

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

Thursday, October 13, 2005 6:40 AM by Shred
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.

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

Thursday, October 13, 2005 6:44 AM by DP
*LOL*
Microsoft - you made my day.

# Sloppy, amateurish

Thursday, October 13, 2005 6:47 AM by Brett Merkey
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

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

Thursday, October 13, 2005 6:53 AM by hardcoder
where to send all these additional bills for this additional work? to you billiboy?

# You're kidding right?

Thursday, October 13, 2005 6:55 AM by Cüneyt Yilmaz
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...

# IE 7 Beta

Thursday, October 13, 2005 7:14 AM by Klaus Hartl
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!

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

Thursday, October 13, 2005 7:16 AM by P. Ahlers
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.

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

Thursday, October 13, 2005 7:35 AM by Hannes
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 :)

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

Thursday, October 13, 2005 7:40 AM by smilingrasta
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

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

Thursday, October 13, 2005 7:48 AM by Alex
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 :-)

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

Thursday, October 13, 2005 7:49 AM by Don Vliet
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!

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

Thursday, October 13, 2005 7:50 AM by Don Vliet
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!

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

Thursday, October 13, 2005 7:53 AM by Matt
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 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.

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

Thursday, October 13, 2005 8:06 AM by The Pro Guy
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.

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

Thursday, October 13, 2005 8:22 AM by zzz
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.

# CSS hacks

Thursday, October 13, 2005 8:23 AM by Nick
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.

# CSS hacks for IE7 will be necessary

Thursday, October 13, 2005 8:40 AM by Ingo Turski
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.

# IE 7 and standard support

Thursday, October 13, 2005 8:47 AM by Klaus Busse
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.

# Call to action: Let's kill IE :-)

Thursday, October 13, 2005 8:57 AM by Analgesia
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.

# re: Call to action: Let's kill IE :-)

Thursday, October 13, 2005 9:17 AM by Klaus Busse
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

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

Thursday, October 13, 2005 9:30 AM by Michiel
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.

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

Thursday, October 13, 2005 9:40 AM by Jeff Schiller
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.

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

Thursday, October 13, 2005 10:02 AM by Derek Pennycuff
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?

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

Thursday, October 13, 2005 10:28 AM by iEdML
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.

# CSS valid selectors should only work a round actual IE bugs

Thursday, October 13, 2005 10:33 AM by Egor Kloos
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.

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

Thursday, October 13, 2005 11:07 AM by Jesse
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.

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

Thursday, October 13, 2005 11:27 AM by Dave
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.

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

Thursday, October 13, 2005 11:36 AM by Kartoffelknülch
make IE7 opensource - btw - jumping to the bottom of this Page after clicking "Post a comment" - only possible with IE7 ??? LMAO

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

Thursday, October 13, 2005 11:45 AM by Matthias
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.

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

Thursday, October 13, 2005 12:07 PM by Monika
The webstandards for accessibility and usability said that we have to build websites backward compatible.

<a href="http://www.w3.org/WAI/" 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

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

Thursday, October 13, 2005 12:08 PM by Johnny Fairplay
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> ... 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.

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

Thursday, October 13, 2005 12:09 PM by Joe FItzGerald
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.

# Please respect others time and do what other browsers are doing.

Thursday, October 13, 2005 12:21 PM by brag
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?

# Why not starhtml?

Thursday, October 13, 2005 12:40 PM by Dougal Campbell
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?

# We Need Beta 2 Now!

Thursday, October 13, 2005 12:42 PM by Chris Ovenden
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

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

Thursday, October 13, 2005 12:48 PM by Markus [MSFT]
@ 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

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

Thursday, October 13, 2005 1:03 PM by thinsoldier
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.

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

Thursday, October 13, 2005 2:05 PM by cwilso
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)

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

Thursday, October 13, 2005 2:09 PM by Lionel
@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?)

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

Thursday, October 13, 2005 2:20 PM by Lionel
@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?

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

Thursday, October 13, 2005 3:00 PM by Thomas Tallyce
> 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.

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

Thursday, October 13, 2005 4:14 PM by Hans
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?

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

Thursday, October 13, 2005 4:40 PM by cwilso
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.

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

Thursday, October 13, 2005 4:48 PM by cwilso
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.

# Gosh, were is the problem?

Thursday, October 13, 2005 4:54 PM by Klaus Busse
>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

# Never needed a hack

Thursday, October 13, 2005 5:16 PM by guy
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

# Helping IE7 by removing hacks?

Thursday, October 13, 2005 5:32 PM by ywdryp
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?

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

Thursday, October 13, 2005 5:43 PM by Gary Turner
@: 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

# Maybe It's Not A Call To Action?