Thursday, February 12th, 2009

Frames are back

Category: HTML

Remember the days of frames and framesets? Not the iframe, but when you had sites with fixed headers and you cursed at not being able to bookmark correctly.

Anne Van Kesteren has blogged about HTML5 frames and how the world is different:

Personally I’m quite fond of the way HTML frames are handled in HTML5. In case you missed it, HTML5 now defines rendering of HTML in non-normative fashion. All gory rendering details of all HTML elements that affect rendering in contemporary Web browsers defined, including blink and marquee. Yay! For implementors this is really useful. I can recall several instances offhand where Opera QA was trying to figure out what the default styling was in other browsers for certain elements because pages did not look quite the same. (E.g. margin of form elements in quirks mode or various elements that need to have text-indent:initial applied to them for unknown reasons.)

Frames and framesets is designed as a simple grid algorithm that ignores CSS for that particular document. For an obsolete feature, it’s quite neat. I almost started writing evil test cases against it (e.g. inserting a body element before the frameset, removing the head element, etc.), but then decided that ensuring that extremely old and obsolete features work correctly is probably not the best use of my time. (Admittedly I’m still tempted.)

He links to Mark Pilgrims latest HTML5 update that includes:

The big news this week is more major work on the non-normative section on rendering HTML documents, including a lot of reverse-engineered documentation of legacy (invalid) attributes that users expect browsers to support.

Posted by Dion Almaer at 6:33 am

2.3 rating from 41 votes


Comments feed TrackBack URI

Return of frames, font, b and i tag, introduction of the new m tag…
The more I hear of HTML5 the more it seems like the biggest web disaster since IE6. Is there anything worth (except canvas) in this spec ?

Comment by ywg — February 12, 2009

Note that frame, frameset, and font cannot be used by authors! They are non-conforming (as I hoped was clear from my post). User agents are just expected to keep support for them.

Comment by annevk — February 12, 2009

@ywg, XHTML DTD also supports b and i tags, these where never deprecated (b != strong and i != em). You need a seperate DTD for frames, but yet again, frames where never deprecated. The only tag that’s deprecated and is basically redundant is the font tagl. In the next generation XHTML DTD, it’s planned to combine both existing DTD’s back into 1, so the “return” of framesets isn’t being ushered in by HTML 5 to begin with.

Comment by BenGerrissen — February 12, 2009

Personnally, I can’t see why I would like to use frame. I hated it then and still Hate it now. I woudn’t care it would go away….

Comment by karnius — February 12, 2009

Back to the 90’s ??
This evil evil thing called frames should be long banished.
shame people are even thinking about it again.
makes me sick.

Comment by vsync — February 12, 2009

@Anne, Ben : You’re right, I’ve always thought thoses tags we’re deprecated in xhtml…

Comment by ywg — February 12, 2009

I’m under the impression this post is about the standardization of how these tags are handled – rather than how awesome they are. HTML5 has to be a working document, and browsers are not going to just drop support for such a widely (if wrongly) used feature — having it standardized is the best that could happen for it.

Comment by el3ment — February 12, 2009

@karnius, just because the option is there, doesn’t mean you must use it ;) It’s still considered bad practise to use framesets 90% of the time. It’s just too harsh to completely remove framesets because there are fringe cases where framesets are actually the best possible tool to use. If you don’t dabble around in those fringe cases, just ignore framesets and go by best practises.

Complaining about this, is just as silly as moaning vegetarians. Just because you don’t like meat, doesn’t mean others should stop eating meat…

Comment by BenGerrissen — February 13, 2009

So I’m writing a mashup site, where I pull information from multiple places. For the most part I use div tags, and AJAX to pull the content in, however there are some applications, that depend on specific css (with common names), or specific javascript, which requires the page to be rendered within a specific location.href. I don’t have control on those applications, but want to incorporate their content into mine. This isn’t a cross domain issue, but a cross application issue, within the same organization.

IFRAME is the only way I can pull in the content from the other application, without breaking that content’s intended look and feel. You take iFrame away and you will break many very functional applications. People need to get their head out of their “need to code to new standards @$$es” and understand that there is a very good need for frames, and you should not make them go away.

Comment by PuckPuck — February 13, 2009

Leave a comment

You must be logged in to post a comment.