Personally I hope some organization (perhaps the WaSP) is going to release some public documents and e-mails the Internet Explorer team. Although they could fix a lot of annoying behavior with their current rendering bugs they could also break a lot of stuff if they are not careful. In this post I will outline some possible examples of what could break when the Internet Explorer team tries to support something better. This is especially relates to their CSS rendering, since those rendering and parsing bugs are exposed by web authors to make things work.
Let’s start with the underscore hack. What if they are going to have support for both
height, but still parse
height? Oops. Currently, when you are using
height in Internet Explorer it acts as
min-height. If this behavior will continue there is no problem. If they fix
height to work correct and still parse
_height there is. The Internet Explorer team thinks they can support such things using
DOCTYPE switching. That works now, so why would it not work in the feature. To exactly quote Dave Massy:
I've seen this idea before. However I'm struggling to see how this is really very different to the
DOCTYPEswitching we support today. This is a technique we've used before to free ourselves from compatibility constratints and as I've said several times here we expect to use that technique again in the future.
I guess I just gave an obvious example that would break perfectly standard compliant sites using a proper
DOCTYPE with some little hacks to make it work in Internet Explorer. Of course, they could fix all their bugs and keep the
DOCTYPE switching. That would mean that
* html would be ignored in at least
text/html documents and in
application/xhtml+xml documents as well, but I doubt if they are going to support that. (The MIME type implies the root element.) If they are going to support XHTML they would need QA people. And not just some random person. They would need people who know a lot about browser quirks and what could go wrong. Who know the specifications and can write proper test cases.
Perhaps some organization could help them with that as suggested in the first paragraph, but maybe it is better if they finally get their act together themselves and hire some people that actually know things about this.
Another thing that could go wrong is
DOCTYPE switching. They might think a comment before it (or an XML declaration) is irrelevant and it should still trigger standards mode. (It should, but probably not in Internet Explorer.) As you can see all thing have dependencies. If they fix one they should definitely fix the other otherwise they break existing rendering. (And by better supporting
width, whatever has your preference) they might already break things because some sites are simply not tested cross browser.)
O well, I’ll test this summer.
I don't think the IE team should spend that much effort ensuring that pages don't break due to hacks. Authors that use them should be well aware that browser updates may make the hacks fail and it's their responsibility to remove the hacks when that time comes. However, I do agree that IE shouldn't just fix the bugs that allow the hacks without fixing the bugs that require the hacks in the first place. Ideally, if they made IE conform 100% (or at least as good as Moz/Opera/Safari) to the CSS spec, then theoretically, none of the hacks should apply anyway, so there should be very few breakages.
Exactly because of this I don't think IE7 will have an updated rendering engine.
Agreed with Lachlan - hacks are used knowing that they're exactly that. Incidentally, after I questioned Dave it looks like the IE team will be switching on 'strict'
I'm saying that when we address issues in standards support and the changes have an effect on compatibility then those changes will only be enabled under the strict doctype.
But I doubt that IE7 will introduce much (if anything) in the way of extra standards compliance.
Lachlan, you're partiall right. But what if there's no way of exluding your hacks from the new browser? Although supposedly this could be done via conditional comments, who knows.
Basically, we want them to fix everything or nothing. I avoid using CSS hacks in case they cause problems in the future. CSS hacks have always made me feel uncomfortable, and I've only really ever used the
> selector hack.
I'm pretty convinced IE7 won't have a new rendering engine.
But if it does, and it breaks my hacks, I won't be bothered by it. Any CSS coder that has used hacks should have done so with the knowledge that they are workarounds and may break in the future.
It'd be great if the IE7 team took the time to evaluate ways to sidestep the most common hacks, but in the end, web developers should have expected this to be an issue. Like Simon said, if they don't fix EVERYTHING, they may as well fix NOTHING.
Just use Tasman for application/xhtml+xml, text/xml, application/xml and application/*+xml and keep Trident for text/html.
I like Erik's suggestion :). On the CSS3 selector support chart at MacEdition at least, Tasman looks great ^_^. Though they now don't have Tantek anymore, of course.
Anyways, what I wanted to say is, I think there are a number of things they could fix without breaking existing web pages. PNG alpha channel support comes to mind, or the floats three-pixel jog, stuff like that. If they would only update those issues, I would already be quite happy :). Of course not as happy as when they would fix everything, of course ^_^.
What do you care about IE 7..? You can't even code this site right for IE 6. Every mouseovered link inside one of your P tags causes text to be spewed everywhere.. Oh, that's right...I keep forgetting it's cool to ignore 80% of any given market. My bad.
Perhaps because he prefers to comply with established standards instead of hacking for a broken browser than decides to reflow text just because the background colour is changed? :)
I suspect "IE7" will just be IE6 SP3, stopping a few of the more blatant vulnerabilities. Probably (if their track record is anything to go by) by changing the default settings so that existing installations suddenly break.
Let's just say I'm not planning to uninstall Mozilla quite yet.
You can't even code this site right for IE 6.
Laruens, it is in fact the IE team that have not coded properly. Anne has simply allowed the site to degrade gracefully in less standards compliant user agents – a decision which I fully support. If you don't like the way a document renders for you, you have the option to write a user style sheet, use an alternative non-broken browser or simply accept the slight degredation.
I don't understand, when are people going to start blaming IE for their rendering problems instead of the author of a standards compliant site?!
Personally I go with the "If you've used hacks, you will know how to fix them"
And personally i just feed IE a second stylesheet using conditional comments to overide anything i need to, so when IE7 comes along, all I need to do at most is create another stylesheet
BUT - thats work I'd rather not do... How do i explain to a client - sorry you need to pay me to make your site work in IE7, when i probably sold them standards etc, with one of the reasons being cross browser compatibilty and not needing to adjust for new browsers....
James, naturally I agree with Tommy and Lachlan. But let me warn you, if you don't like Anne's site, you should definitely not go to mine. :-)
james, there is a difference between personal sites and public sites. However, if you can give me the necessary CSS hacks to make this work in Internet Explorer, please do! (Note that I said CSS hacks. For now, I am not going to change my markup.)
There is a perfect solution for that problem - conditional comments. Your HEAD part of the document will look ugly, but the CSS will stay valid.
Simply put everything under "if lte IE 6" comment and it will work forever. If something is changed in IE 7, hopefully there will be "if IE 7" cond. comment.
Remember, a big thing for the IE team is "compatibility," making sure the browser wont suddenly start screwing up pages after an upgrade. So those weird standards glitches are going to be around for a while. There isn't an easy way to keep the buggy rendering along with new standards-compliant rendering.
I'm looking at this as more of an Internet Explorer Service Pack 3, not a new browser.
What do you care about IE 7..? You can't even code this site right for IE 6. Every mouseovered link inside one of your P tags causes text to be spewed everywhere.
Exaggerate much? I've viewed this site in IE 6 for WinXP SP2 plenty of times, and when links within p tags are hovered the text only nudges to the left a tiny amount. This is not an issue with Anne's markup, but rather just another of IE's countless stupid little bugs. Plus, it's hardly even noticeable.
The only other obvious difference I notice in IE 6 is the decreased quality of the .PNG images, but that is to be expected. Hardly anything worth bitching about.
I agree. Do not use hacks of any kind. It is unprofessional and can lead to unpredictable results in the future. Think long term instead of short term.
Also, if you are worried about rendering issues such as this IE bug with the background color changing, considering not changing the background color. Then you don't have to worry about that issue with IE users.
Ask yourself if the feature is really worth all the hassle. In most cases, it's not.