The iframe is back

[molendijk]

The iframe is back (HTML5). After all the trouble I had finding a proper replacement for it (HTML4 strict).
===
Arie Molendijk.

[jscheuer1]

Yeah, HTML 5 is pretty cool. I'm doing all my new work in it. A lot of things have been relaxed. If I didn't know better, well I don't know better. I'm not sure why let's say - In any case HTML 5 while preserving a lot of good stuff from HTML 4.01 and XHTML 1.0 has done a number of things to allow stuff browsers allow anyway. It even allows some things some browsers don't, at least not when scripting is combined with what used to be non-standard markup. But there are still some seemingly arbitrary 'no-no's for certain things, I think. But I can't think of anything off hand. Well stuff like width and height for elements that ordinarily can take them. Attributes are fairly limited - use css style instead. Sometimes though there is no workable alternative in style, though it could be argued to be "the browser's fault". I was never really all that happy with that explanation.

[molendijk]

Yeah, HTML 5 is pretty cool. I'm doing all my new work in it.
No problems with IE7?
===
Arie.

[jscheuer1]

I've not encountered any problems in HTML 5 as regards outdated IE versions that are not also problems in those browsers for other DOCTYPES that invoke standards.

Do you have something specific in mind?

[traq]

The only "real" issue I have in IE is the fact that you need to use javascript to trick IE into applying css to your html5 elements.

I view javascript as something that should have a fallback (or be "okay" without); not something that can be used as a fallback.

[jscheuer1]

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

[molendijk]

I've not encountered any problems in HTML 5 as regards outdated IE versions that are not also problems in those browsers for other DOCTYPES that invoke standards.
That's good news.

Do you have something specific in mind?
No, just a general question.

Thanks,
Arie.

[molendijk]

I've not encountered any problems in HTML 5 as regards outdated IE versions that are not also problems in those browsers for other DOCTYPES that invoke standards.
As far as I remember, IE7 accepts the frameborder attribute with a standard transitional doctype. It does not accept it with the HTML5 doctype. And there's no way to remove the frameborder. (But I hope I'm wrong).
===
Arie.

[jscheuer1]

Well, that's one thing (the one thing really, though there could be others) I was thinking about when I said:


Attributes are fairly limited - use css style instead. Sometimes though there is no workable alternative in style, though it could be argued to be "the browser's fault". I was never really all that happy with that explanation.

So, if you're saying you must have a valid document in HTML 5 and have it look as desired in outdated browsers, in the case of IE and a look of frameborder other than 1 (1 is the default) that will require clever use of IE conditional comments, yes. I'm not sure if that's even worked out in IE 9, let alone IE 8, which does work out a number of issues from 7, which worked out a number of issues from 6, etc. The versions seem to be coming hot and heavy from MS. Let's hope they soon "get it right" and folks adopt it.

Interestingly IE 6 support which was recently so important, is no longer considered so, at least not by many. That's because its use is plummeting. The same is beginning to happen with 7. And if 9 comes out, believe me - it's so much better, 8 will probably die a quick death as well.

The great thing about versions 7, 8, and 9 are that they all can run well on the same computer (not at the same time, but if a computer can run any of them, it can run any one of the others), they are really sub versions (MS gave up issuing sub versions at IE 6), except 9 is a bit more of a radical departure, at least as far as look and feel goes, but I suspect it is otherwise very similar to 7 and 8, just better css support and more features. I think they've sped it up (once it's loaded) a bit too. I'm no expert on 9 or its programmatical differences though yet.

Getting back to the issue of differences in these outdated browsers. Another area where this (standards compliance in a new DOCTYPE) often throws presentational junkies into a hissy fit is the appearance of form elements.

Suffice it to say that the precise rendering of your page should not depend upon nor be so important that these slight variations can cause you problems.

[molendijk]

Great John! Thanks a lot!
===
Arie.

[traq]

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:
<!DOCTYPE html>

[jscheuer1]

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]

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 (http://www.debeterevormgever.nl/html5-ie-without-javascript/) for html5 elements involves xml namespaces and intentionally serving it to IE wrong.

[jscheuer1]

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]

Not HTML 5's fault.

no, of course not :) still a stumbling block, though.

[jscheuer1]

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


<!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/side/html_5_tests/ie_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]

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

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

[jscheuer1]

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:


<article>Hola!</article>

as:


<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:


<!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]

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]

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.

[jscheuer1]

One other thing. In Chrome, probably all web kit, if the files are on the same domain, and scrolling="no", the iframe has no scrollbars. Using only overflow: hidden; as style for the iframe doesn't work. So something is perhaps wrong with all the browsers here. This worked with the scripted method as well as using the hard coded attribute.

[traq]

I think iframe is one of the newer elements in html5 - IIRC, it was originally excluded from the spec, but was returned because 1) it works in all browsers and 2) there's no good replacement for the functionality. It makes sense that support for the html5 attributes (like "seamless" and using css instead of the scrollbars attribute) would be dodgy.

[jscheuer1]

The iframe is back (HTML5). After all the trouble I had finding a proper replacement for it (HTML4 strict).


I think iframe is one of the newer elements in html5 - using css instead of the scrollbars attribute) would be dodgy.

Almost back then.

And perhaps the fox is the only one that got it right after all.

Why shouldn't you be able to control the scrollbars with style regardless of where the page in the iframe comes from? You cannot change its content or scroll it (well you can scroll it with a nested full page iframe), without server side code to capture the page and make it your own.

[traq]

Why shouldn't you be able to control the scrollbars with style regardless of where the page in the iframe comes from?

I would assume it was a bit of the "same-domain" logic on the part of the vendors; I guess the scrollbars would be considered part of the imported page. The inconsistency probably means that it's one of those things that wasn't very clear in the earlier specs.

HTML5 is fairly "solid" now, on paper. But most browser support for html5 is either carryover from html4.01 / xhtml1.1, or something that vendors developed themselves and has now been "rolled into" the spec.