Broken pages discussions part 3
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).
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.
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 frantically 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.
