The iframe is back

**traq** · 01-26-2011, 04:47 PM

Originally Posted by jscheuer1

Which HTML 5 elements are you talking about? Something non-standard in other DOCTYPES?

semantic stuff, like <header>,<article>, etc.

As a side note, even though the doctype is supposed to be case insensitive, I've found it doesn't always trigger standards mode in IE unless the "doctype" part is capitalized:

Code:

<!DOCTYPE html>

**jscheuer1** · 01-27-2011, 05:42 AM

Aren't those (header, article) from XHTML? And for use for syndication ala XLM-ish use of the page? If I've got that right, I don't think earlier IE ever supported any of that, regardless of the DOCTYPE. What's been your experience?

Anyways, the issue here is something that the browser supports in other standards compliant DTD's that it doesn't support in HTML 5, even though it is technically valid in HTML 5 - right?

**traq** · 01-27-2011, 03:35 PM

they're regular elements is html5, replacing <div id="header">, <div class="article"> and the like. Because they have xml parsers, most modern browsers will apply css to them now, without any trouble. IE ignores them (treats them as meaningless, nonsense tags) unless you use createElement to make an example of the new element (then IE magically recognizes all of them).

No, IE never (still doesn't) support xml. Ironically, the non-js solution for html5 elements involves xml namespaces and intentionally serving it to IE wrong.

**jscheuer1** · 01-27-2011, 06:38 PM

So before HTML 5 they didn't work in IE without a fudge, now with HTML 5 they still require a fudge, right? If so, nothing odd there. Not HTML 5's fault.

**traq** · 01-27-2011, 08:48 PM

Originally Posted by jscheuer1

Not HTML 5's fault.

no, of course not

still a stumbling block, though.

**jscheuer1** · 01-28-2011, 04:59 AM

So what's right? Here's my test page - validates as HTML 5 and it's css validates too:

HTML Code:

<!DOCTYPE html>
<html>
<head>
<title>IE - Iframe &amp; &lt;article&gt; Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">
iframe {
	overflow: hidden;
	border-width: 0;
	width: 300px;
	height: 250px;
}
article {
	font: bold 90% sans-serif;
}
</style>
</head>
<body>
<iframe src="http://www.google.com/"></iframe><br>
<article>Hola!</article>
</body>
</html>

Here's the demo:

http://home.comcast.net/~jscheuer1/s...iframe_art.htm

It's different here in Firefox, doing all of what I would want it to, but not necessarily according to standards. The iframe has no border or scrollbars even though its content overflows. The article tag's content is rendered according to the font set in the style section.

IE 8 and less render the iframe with a border and scrollbars and render the article content without the style. Safari (which balked at loading it at all at times, redirecting to some Asian site), Opera and Chrome showed no border but did show scrollbars. All three of those got the article tag 'right'. IE 9 was like them as well.

**traq** · 01-28-2011, 06:10 AM

that lack of styling on the article element is what I'm talking about. add this to your head and try again in IE

Code:

<script>document.createElement('article');</script>

**jscheuer1** · 01-28-2011, 03:18 PM

Yes, I caught that already. It should be noted though that without the <br>, article style needs to be set display: block; for IE < 9. And should be anyway, just in case anything added later depends upon article's native display property, which is block in supporting browsers, inline in IE < 9 when using the fudge.

However, I was simply referring to a page without fudge, and how even the supposedly standards compliant browsers varied.

Does Firefox have it right, or those others?

In IE < 9 without fudge it sees:

Code:

<article>Hola!</article>

as:

Code:

<ARTICLE></ARTICLE>Hola!<ARTICLE></ARTICLE>

The iframe is a little more difficult to crack. This 'works' in Firefox, Opera, IE 7+, but still fails to remove scrollbars in Safari and Chrome:

Code:

<!DOCTYPE html>
<html>
<head>
<title>IE - Iframe &amp; &lt;article&gt; Test II</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">
iframe {
	overflow: hidden;
	border-width: 0;
	width: 300px;
	height: 250px;
}
article {
	font: bold 90% sans-serif;
	display: block;
}
</style>
<script>
(function(){
	var a = document.createElement('article');
	a = null;
})();
</script>
<script defer>
(function(run){
	var f1 = document.getElementsByTagName('iframe')[0];
	if(!f1 && window.addEventListener && !run){
		document.addEventListener('DOMContentLoaded', arguments.callee, false);
		return;
	}
	if(!f1){setTimeout(arguments.callee, 300); return;}
	f2 = f1.cloneNode(false);
	f1.src = 'about:blank';
	f2.frameBorder = '0';
	f2.scrolling = 'no';
	f1.parentNode.replaceChild(f2, f1);
})();
</script>
</head>
<body>
<iframe src="http://www.google.com/"></iframe>
<article>Hola!</article>
</body>
</html>

I guess web kit browsers do not support the attribute scrolling in this context (they do assign it, it's in their DOM view, and if you hard code it they still ignore it), and see it as either cross domain to (essentially) set Google's HTML and/or BODY elements to overflow hidden, and/or they don't respect that property/value pair for iframe.

Demo II:

file://localhost/C:/webwork3/test/html_5_tests/ie_iframe_art_2.htm

**traq** · 01-28-2011, 03:31 PM

I think, in that example, Opera and Chrome got the iframe "right." And you're right that that is another issue --cross-browser consistency-- that will be some time in resolving. There are javascript "fix" scripts that add all the new elements, and set their display properties appropriately.

**jscheuer1** · 01-28-2011, 04:26 PM

I don't see any way to get rid of the scrollbars for the iframe in web kit without setting the HTML (if the page in the iframe is standards compliant, the BODY if not) element of the page in the iframe to overflow hidden. This can only be cross scripted in javascript alone only if the pages are on the same domain (browser security restrictions, at that rate you can set it hard coded or (perhaps preferred, depending upon the reason) javascript scripted on the page in the iframe). With server side code it can be extended, but at that point the remote host might block it, and it requires the host of the top page to have certain permissions set. And it's complicated, subject to failure for other reasons in some cases.

Thread: The iframe is back

Thread Tools

Search Thread

Bookmarks

Bookmarks

Posting Permissions