Description

The <canvas> and <audio> elements (and probably other HTML5 element too) are unknown when they are in an HTML5 document loaded by an <iframe> which is hosted by a page with no <!doctype>.
<html><body>
<iframe src="ie9iFrameFrame.htm"></iframe>
</body></html>
<!DOCTYPE html><html><body>
<canvas id="x"></canvas>
<script>alert("canvas = "+document.getElementById('x'))</script>
</body></html>
test case: http://www.pixzzle.com/albums/random/ie9iFrameHost.htm
On IE9 the alert says: "canvas = [object htmlUnknownElement]"

Why does IE10 not have the fallback to IE9 or better to IE8? Have you changed your design oder is this a new bug;-)

Is there a way how I can change the documentmode of my IE9 iframe to IE9? Is there a hidden switch?

Posted by MathiasBynens on 5/27/2011 at 7:27 AM

http://css-tricks.com/ie-iframe-quirksmode/

Posted by James 2 on 3/20/2011 at 8:36 PM

Hello IE Team,

You mentioned that "If top is IE9, then everything under it is forced to IE9. If top is [other] then frames may be anything except IE9."

I have tried to set the top frame to IE8, but why the frames are still rendered as IE9? I wish to have the root frame to render in standards mode, while frames are rendered in quirks mode.

Do you have any working samples for a proof-of-concept to your statement above?

Thanks,James

Posted by Priyajeet Hora on 2/23/2011 at 3:31 PM

I find it rather ironic that IE teams goes an introduces yet another quirks mode. Why would a developer waste their time now to convert IE5 Quirks mode pages to IE9 quirks mode? The same effort can be used to convert it to standards mode but there is a pretty good reason why a developer wanted to leave a page rendered as IE5 quirks mode. With IE9 we cannot get child frames to render in IE5 quirks mode if we want some other child pages in IE9 standards mode. So either we give up all the new IE9 functionality or spend lot of money + time in converting pages.

And then one sees steve ballmer jumping on stage shouting DEVELOPERS DEVELOPERS...while his IE team makes lives of developers more miserable by introducing junk in an already bloated browser. And they wonder why developers prefer firefox or chrome.

Posted by Anders Retterås on 2/21/2011 at 3:22 PM

I don't know who published this workflow but it surely states that the IFRAME could render the document mode it was supposed to:http://ieblog.members.winisp.net/misc/How%20IE9%20Determines%20Document%20Mode.svg

You say it is by design?"It's not a bug, it's a feature"?As far as I have been able to test it, it seems like IE9 is the only major "modern" browser with this strange (and in my opinion faulty-) behaviour.

In many scenarios you cannot control the iframe-page or the container-page since it can be hosted/provided by an other site/server.

Posted by Microsoft on 10/29/2010 at 6:48 PM

Thank you for your feedback.

The issue you are reporting is by design.

This is by design.

If top is IE9, then everything under it is forced to IE9. If top is [other] then frames may be anything except IE9.

For this scenario, the marked-up IE9 page is rendered "as high as possible" which will be IE8 mode.

Best regards,

The Internet Explorer Team

Posted by agb5 on 10/7/2010 at 8:44 AM

Yea but, the point is I can't change to IE9 Standards mode because I don't own the host web site. I only own the content of the iframe.

Posted by Microsoft on 10/7/2010 at 8:28 AM

Thank you for your feedback.

We were able to reproduce the issue and are investigating it.

This page is loading in Quirks mode and if you chang to IE9 Standard mode, the right alert is fired.

Best regards,

The Internet Explorer Team

Posted by Alfonso ML on 9/19/2010 at 8:27 AM

This bugs breaks all installs of FCKeditor if the main page uses standards mode: http://dev.ckeditor.com/ticket/6324

Posted by Alfonso ML on 9/19/2010 at 7:59 AM

And besides the changed rendering, the extra penalty is that document.compatMode is lying reporting what should be applied to the frame instead of what's really being used. So any script that uses document.compatMode won't work properly in this situation.

Posted by Alfonso ML on 9/19/2010 at 7:52 AM

I was going to report the bug from the other side: the problem seems to be that the inner frame inherits the rendering mode from the host page, so if the host is in standards mode, then the contents will be rendered that way even if they use a different doctype.