[whatwg] framesets

[Ian Hickson]

On Thu, 8 Oct 2009, Peter Brawley wrote:
>
> According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The 
> following elements are not in HTML 5 because their usage affected 
> usability and accessibility for the end user in a negative way:
>
>    * frame
>    * frameset
>    * noframes"
> 
> As Andrew Fedoniouk said on this list in 2007
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html),
> "There are use cases when frames are good. As an example: online (and offline)
> help systems ...  In such cases they provide level of usability higher than
> any other method of presenting content of such type."
> 
> I agree wholeheartedly, esp. when the topic list is long (thousands or 
> millions of items) and itself editable, and the required interface is 
> for flexible, independent scrolling of freely choosable bits of the 
> topic tree in the left frame without affecting anything in the right 
> detail frame. As Andrew said, frames are the only good way to do this.
> 
> New standards ought not to remove required functionalities, ought not to 
> break perfectly good & legal working code, and ought not to impose 
> Hobson's choice of keeping functionality vs remaining 
> standards-compliant. How do we get the unwise decision to remove 
> framesets revisited?

Except for resizing, anything you can do with framesets, you can do better 
with <iframe>s and CSS. In addition, with pushState(), you can fix the 
bookmarking problem in a better way than with framesets.

Resizing is something that's harder to do, but that's a presentational 
issue that we need to fix anyway, independent of frames.

Framesets have a number of problems, chief amongst them that bookmarking 
is dysfunctional, but also that the accessibility story for frames is 
rather poor, and that there the presentation with frames is much less 
pleasing than with other features (e.g. in Safari, this page:

   http://www.artfulsoftware.com/infotree/mysqlquerytree.php

...has a vertical scrollbar for the top frame -- a problem you wouldn't 
get if instead of four pages, you had three, with the main one containing 
two iframes from the left and right frames).

In addition to <iframe>s, other techniques exist to get similar results, 
e.g. AJAX. The use case covered by <frameset> is definitely handled 

(Getting rid of the frames altogether is probably best, since then tools 
like search engines can actually return useful links. However, I 
understand if some authors are unwilling to do the work to get to that 
point. <iframes>, on the other hand, are very easy to migrate to.)


On Fri, 9 Oct 2009, Peter Brawley wrote:
>
> W3C's job is to enable, not function like a commissariat.

This isn't the W3C.


On Fri, 9 Oct 2009, Peter Brawley wrote:
> 
> I'm arguing that framesets have been part of HTML4, developers used them 
> in good faith, and removing them from HTML5 unfairly & arbitrarily 
> imposes a Hobson's choice of keeping existing functionality while 
> foregoing new HTML5 functionality, or re-architecting existing 
> functionality in order to use new HTML5 functionality.

Actually, you only need to use frames in the frameset page, so if your 
only concern is what validates, you could just use HTML4 Frameset for the 
frameset page, and HTML5 for the content pages.

But I would still strongly discourage using framesets.


On Fri, 9 Oct 2009, Jonas Sicking wrote:
> 
> The big difference is that <iframe>s can be used in good ways, framesets 
> essentially can't.
> 
> Another reason do deprecate <frameset> but not <iframe> is that we don't 
> need *two* ways to make poorly behaving pages.

Indeed.


On Fri, 9 Oct 2009, Peter Brawley wrote:
> 
> Supposing that someone can produce examples, the argument for removing 
> frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
> being removed because we do not like it/. If you insist on such use 
> cases, re-architect them." That's a misuse of standards.

That's how we roll here. :-)


> >What'd be the point of keeping two sources of issues when one can be 
> >enough to cover all use-cases?
> 
> If your premiss is correct, backward compatibility.

Backwards-compatibility is preserved: HTML5 defines how framesets are to 
be implemented, so your pages won't stop working with HTML5 browsers. They 
just won't be conforming HTML5, because we want to discourage the use of 
framesets in favour of better solutions.


On Fri, 9 Oct 2009, Peter Brawley wrote:
> 
> Why relegate a perfectly sound use case to a cul-de-sac?

It would be a bad idea to relegate a perfectly sound use case to a 
cul-de-sac. But that's not what we're doing. The use case is still 
handled fine, in a number of ways (e.g. <iframe>s, Ajax-based navigation). 
The feature we're relegating to a cul-de-sac is not perfectly sound.


On Fri, 9 Oct 2009, Peter Brawley wrote:
>
> It's not your brief to decide what's beneficial for a client.

Actually, it sort of is.


> >It conflicts with expected behavior.
> 
> It does not conflict with what these users expect.

Framesets actually do conflict significantly with what most users expect; 
that's one of their problems.


> Framesets are part of the current HTML standard and should remain.

Actually framesets were deprecated in 1998. They've been on the chopping 
block for over ten years now. Their use is _so_ discouraged in HTML4 that 
they are not even included in the Transitional DTD, they are relagated to 
their own third-tier DTD.


On Fri, 9 Oct 2009, Peter Brawley wrote:
>
> I quoted Andrew Fedoniouk 
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html), 
> "There are use cases when frames are good. As an example: online (and 
> offline) help systems ...  In such cases they provide level of usability 
> higher than any other method of presenting content of such type."
> 
> I've not seen a counterexample. Have you?

I believe Andrew's statement to be incorrect. I would argue that the 
usability of help sites based on <frameset>s is horrible. For example, 
search engines can't index into them (search is a critical part of help 
systems), pages in them can't easily be bookmarked and URLs to them can't 
be shared with other people (another critical part of help systems), and 
using the "open in new tab" feature on index pages of help systems that 
use framesets ends up breaking the frameset, making browsing multiple 
aspects in parallel difficult.


On Sat, 10 Oct 2009, tali garsiel wrote:
> 
> 1. Tabs and tree menu navigation is very common in web applications. Do 
> you agree with that assumption?

Tabs are a media-specific presentation issue, and don't belong in HTML.

Tree menu navigation is a use case we need to fix anyway, and will 
probably do so in the next version of HTML. (We were going to do it in 
HTML5, but had to punt because we couldn't get the detailed nailed down. 
It's a hard thing to get right.) However, that's independant of frames. 
The problem exists regardless of what the look is, one frame or many.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'