[whatwg] framesets

[Ian Hickson]

On Tue, 13 Oct 2009, Peter Brawley wrote:
> > 
> > Your requirements aren't met by framesets
> 
> Eh? Our solution meets the requirement and uses framesets.

As others have discussed, you explained that use wanted framesets because 
they prevented bookmarking, but they don't.


> > <iframe>s have been demonstrated to work as well as framesets
>
> No-one's been able to point to a working non-frameset solution that 
> meets this requirement.

I provided a sample myself:

   http://damowmow.com/playground/demos/framesets-with-iframes/001.html


> >, and, well, framesets suck.
> 
> Unargued, subjective.

Agreed. Here's a summary of the problems with framesets:

 * Poor accessibility. Frames are inherently a visual concept, and do not 
   map well to screen readers, speech browsers, or braille browsers.

 * Poor bookmarking story, which is difficult to work around even with
   pushState(). Users cannot reconstruct a frameset that they wish to 
   bookmark. Scripted support for this requires extensive server-side 
   effort to get right.

 * Poor searchability. Search engines cannot reconstruct the frameset that 
   represents the data that they have found. Working around this with one 
   frameset page per frame combination is a maintenance nightmare.

 * Poor printing story. There's really no good way to print a frameset 
   page. Browsers have tried various techniques, but they all 
   fundamentally lead to a poor experience.

 * Poor usability. Multiple scrollbars can lead to users being unclear as 
   to what to do when looking for content.

 * Slowness and high latency. Multiple HTML files means the total time 
   from going to a page to the page being loaded is automatically forced 
   to be greater than with ordinary pages, since there's more files to 
   fetch and thus a higher minimum round-trip time.

(Not all these problems are fixed by <iframe>s, and I wouldn't really 
recommend using <iframe>s instead of <frameset>s in general.)


> >I agree that there's lots of legacy content using framesets; that's why 
> >HTML5 defines how they should work (in more detail than any previous 
> >spec!).
> 
> ?! According to 
> http://www.html5code.com/index.php/html-5-tags/html-5-frameset-tag/, 
> "The frameset tag is not supported in HTML 5."

It's not allowed in HTML5 documents, but HTML5 does define how it works 
for the purpose of handling legacy (HTML4) documents.


> >The only thing that is easier with framesets than otherwise appears to 
> >be resizing, which I agree is not well-handled currently.
> 
> Unsubstantiated claim absent a working example of the spec implemented 
> without framesets.

I provided a sample showing frameset (without resizing) here:

   http://damowmow.com/playground/demos/framesets-with-iframes/001.html


> >As noted before, though, that's an issue for more than just frames; we 
> >need a good solution for this in general, whether we have framesets or 
> >not. Furthermore, that's a styling issue, not an HTML issue.
> 
> For those who have to write or generate HTML, that's a distinction 
> without a difference.

Possibly, but it's an important difference for spec design. :-)


On Wed, 14 Oct 2009, Peter Brawley wrote:
> 
> Of course the frameset /by itself /doesn't satisfy that requirement. It 
> permits us to meet the requirement with little code.

How does it help you do it better than <iframe>s?


> It's a nice, partial demo---side-by-side scrolling & no node bookmarking. But
> no borders

I've added borders for you.


> no resizing,

Granted. This needs fixing in general, though, not just for frames.


> no horizontal scrolling within frames,

I've added a wide page to demonstrate that this is also supported.


> it requires a separate html page for each node, &c.

It requires exactly as many HTML pages as framesets.


> If that blocks a use case, by all means don't use a frameset for it. For 
> this use, the above poses no problem at all. And if CSS were actually as 
> efficient for this spec as framesets, surely some developers would have 
> taken advantage of that by now.

If that mindset was used for everything, we'd never invent anything. :-)


On Wed, 14 Oct 2009, Peter Brawley wrote:
> 
> The full use case is treeview database maintenance. Tree logic has been 
> slow to mature in SQL, is non-trivial in HTML as we see, and is hard to 
> generate from PHP/Ruby/whatever.

I agree that we need to address the treeview control use case. However, 
with all due respect, there are many better ways to provide a tree view 
than framesets, even without an explicit tree-view control. An AJAX 
application can have a much better interface. Yes, it requires more 
scripting, but the cost to you translates into value for your customers.


> Correct, but excluding frameset from HTML5 increases the likelihood that 
> browsers will drop support for the feature.

This is incorrect. HTML5 requires that browsers supports framesets.


On Wed, 14 Oct 2009, Aryeh Gregor wrote:
>
> The *only* effect on you if you use frames is that your pages will not 
> validate as HTML5.  They will still work perfectly.  Their status as 
> "non-conforming but specified" is basically HTML5's analogue to HTML4's 
> "permitted but with their own DTD that we discourage authors from 
> using".  Nothing has changed between HTML4 and HTML5 for you, as an 
> author, except that validators will complain.  HTML5 will probably lead 
> to even more consistent frameset support across user agents, if 
> anything.

Indeed. This feature has been announced as deprecated for over a decade 
now, it should come as no surprise that it is being obsoleted.


On Thu, 15 Oct 2009, Markus Ernst wrote:
> 
> Just for being nitpickinig: This only applies to the frameset document, 
> which will validate as HTML4 Frameset. The pages contained will validate 
> as HTML5 (if properly coded, of course). I assume the validator does not 
> even recognize the fact that a document is part of a frameset.

Indeed.


On Thu, 15 Oct 2009, Nelson Menezes wrote:
> 
> There is a specific use-case (that has nothing to do with databases or 
> bookmarking) that framesets solve better out-of-the box right now in 
> most browsers: that of a panel-based layout that allows resizing and 
> maintains UI state without flickering whilst loading content in 
> different panels (this is, I believe, the "something" you're getting 
> at).
> 
> There are HTML5-conformant solutions available right now that allow you 
> to replicate the above scenario with a little more work. The iframes 
> solution with a bit of JS [1] [2] for handling the resizing is probably 
> the easiest to implement, although an analogous solution with AJAX is 
> probably the best available (which allows for deep-linking when this is 
> desirable and doesn't automatically break bookmarking). You can also (if 
> you wish) break bookmarking/the back button with these solutions, 
> especially the AJAX one. There is also the CSS position: fixed solution 
> that will be adequate for a large number of scenarios, or can complement 
> the other two.

Indeed.


On Thu, 15 Oct 2009, Peter Brawley wrote:
> > 
> > 3) There are HTML5-conformant solutions available right now that allow 
> > you to replicate the above scenario with a little more work.
> 
> Can't tell without a lotta work on it, I've solved the problem once, I'd 
> rather spend development time on unsolved problems.

Nobody is asking you to change your existing pages. Framesets will 
continue working. It's only for new pages that they are obsolete. (Other 
obsolete features are also obsolete for old pages that are being updated 
to use new technologies, but this doesn't even apply to framesets, since 
they always had their own DTD.)


On Thu, 15 Oct 2009, tali garsiel wrote:
> 
> I think the described case is the main flow in web applications.
>
> I think most web applications have exactly this panel based layout, 
> where navigation loads only a some of the panels.
>
> I think they all use AJAX. Iframes are very unpopular, and as you say 
> AJAX is the best current solution.

Indeed, there are lots of sites doing this kind of thing without 
framesets today.


> I think there should be a standard based solution because:
> 
> 1.Even when using libraries like prototype, AJAX does take some coding. 
> Why should I use so much code for such a simple, main flow use case?
> 
> 2.By looking at browsers code I see there is a lot of clever stuff going 
> on when loading/unloading a document.
>
> In the AJAX based solution this happens only once in the application 
> life cycle.
>
> It seems to me that dedicating a special syntax to navigation would help 
> browsers to test the application main flow.

This seems like a prime candidate for something to explore with a future 
version of HTML.

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