I don’t think there’s a solution to this one. Microsoft’s response is that it’s working as designed. I toss it out here more as a public service, to warn others of the trap that’s lurking out there. Maybe, with a lot of luck, someone else will figure out how to slay this particular beast.
View this simple page in FF, then try it in IE9: MSNBC Iframe
The page is garbled in IE9, right? The reason is that, apparently, IE9 forces the child page to the same DOCTYPE as the parent page. No matter what. So, this one is a mess because the MSNBC site has no DOCTYPE at all - it’s in quirks mode. It doesn’t render properly as anything else.
Now before someone beats me about the head and shoulders for using an iframe, let me tell you that it appears to do exactly the same thing with an embedded object.
If you happen to control both the parent and child pages, you can enforce some DOCTYPE discipline. But if you don’t, you’re basically screwed, as far as I can tell.
Can anyone shed any light on this, like maybe a workaround?
One workaround is available. It’s not a very satisfying long-term solution, but I think it will have to do for now. Plant this in the <head> section of the parent page:
Of course, this means that you’re not availing yourself of a lot of the other wonderfulness that IE9 promises. From what I’ve seen so far, I think I can live with that.
For my own stuff, I do my best to stick to XHTML 1.1 these days, though I still insist upon using iframes because the alternatives just seem to be no good. But this is a case in which I’m writing software that other people are using to create sites, so I have no control over what kinds of pages they might be calling up in their iframes.
I was astonished to discover, by the way, that a site like MSNBC would have no DOCTYPE at all. Wow. Just wow.
Lovely… thanks Microsoft. I’m actually in the middle of converting a site which has to use iframes, and I’m sure what we’re putting in the iframes is very not standards compliant, while my site is fully compliant.
Thanks a bunch for the heads up, though. I’m sure I would have spent hours trying to figure out what stupid thing I was doing. =p
Yes, I figured I could at least give some other folks some “steering” in the direction of the source of the problem.
Silly me, I had hoped that IE9 would finally put an end to all the browser-specific coding we’ve all been forced into. I should have known better. I swear, sometimes I’m tempted to put a browser-detection script in my pages, and if it detects IE, it would put up a big red warning box that says, “You’re using faulty software,” and gives the visitor a link to either FF or Chrome. I’ve had my fill of dealing with “compatability modes,” and things like the godawful “mark of the web.”
It always seems like IE is the browser that has issues with designs. We already have a customer who found something broken with TinyMCE in IE9. It was easy to fix, but just stating that it is always IE that is the problem.
True. You almost never see a post in which someone is asking, “Why doesn’t this work in Firefox?” (Unless they’ve made some truly horrendous coding error, of course.) But otherwise, things just work in FF and Chrome. No battles, no tears. But there’s always something screwy in IE. Every. Damned. Version.
For my site, I always click on the appropriate criteria for each browser to build. Many of the current version is always somewhat compatible, we only find a common ground in which to make our website are suitable for them.
Nah, everyone’s gotta be hip nowadays and Facebook is teh hip so everyone’s using iFrames for Facebook junk on their pages… iFrame won’t be leaving any time soon.
For my own stuff, I do my best to stick to XHTML 1.1 these days
Really? Now see, since 1.1 won’t render in any IE (except maybe 9, did 9 finally start working with application xhtml+xml?), that pretty much does what you want (ok no big red “Faulty Software” sign but their IE will ask them if they want to open the “document” in… Firefox, or something : )
I should rephrase that. I try to follow the strictness of XHMTL 1.1, though the pages aren’t actually being served up as the proper MIME type for them to be treated as application xhtml+xml. Murky subject, lots of disagreements out there about it. I prefer to steer clear of theological debates. At the end of the day, I just want the stuff to work.
MS says that iframes are being handled “as designed.” To them, this is not a bug. It’s a feature. I, on the other hand, would like to call in an air strike.
I try to follow the strictness of XHMTL 1.1, though the pages aren’t actually being served up as the proper MIME type for them to be treated as application xhtml+xml.
Oh, ok (I’m assuming you mean 1.0 actually where it doesn’t matter which MIME-type you use anyway). But still, it’s easy for you to give a big bird to IE whenever you want… just switch MIME-types. <evil grin/>
MS says that iframes are being handled “as designed.” To them, this is not a bug. It’s a feature.
Yeah, the usual. Lawlz. I think I want this phrase on a T-shirt.
Unfortunately, not everyone stay away from the tentacle-monster known as Facebook. They’ve deprecated that nasty fbml but in its place they’ve used… iFrames. Surely most of the other crappy social craplet scripts do similar.
Our business has iFrames on partner sites (so, our form with our backend sits on the partner sites), and there is certainly a doctype difference between the two (we use Strict, they use blah blah blah 3.2 tranny something), but we also furnish our own stylesheet in that document, so not sure if that affects anything?
What does affect us is that P3P thingie started in IE8. Bah.
Our company still hasn’t purchased Windows 7 so I can’t test anything about IE9 yet. : (
Is that an edit, because I didn’t see that entire sentence??? I wouldn’t have mentioned it otherwise. Probably my nasty case of TSDR in action – the opposite of what most people are afflicted with.
Though:
Then why are you using 1.1, which is a technological dead end AND shooting yourself in the foot on compatibility…
Does the XHTML vs. HTML argument have anything to do with the problem about which I started this thread? Can you fix the problem by changing the DOCTYPE? If so, please show me how that works.
No, but following the doctype might… and the WCAG… and the compatibility recommendations… Oh, and I’m not saying you can’t XHTML, I’m saying the most recent one you can trust is 1.0, NOT 1.1
or just a modicum of security mindedness which says you shouldn’t be trying to load another site inside the first one, and doing so opens the door to cross-site exploits…
But hey, I’m running a user.js that blocks iframes and objects from working in the first place in Opera until I allow them, so what do I know?
Was kind of my point – oh noes something that probably should never have been allowed in the first place doesn’t work… whatever will we do?
This is a simplified example. In the real application, the “other page” is being opened in a Highslide JS expander window, which uses an iframe mechanism. I only stumbled on the problem in the first place because I happened to be using a site as an example that was in quirks mode. Highslide JS itself can’t be run in quirks mode, so there’s a mis-match. No problem in any other browser. It’s just IE9 that chokes on it.
