The W3C HTML Working Group has posted the second working draft of XFrames. Accopprding to the introduction,
Frames were introduced into HTML at version 4.0 [HTML4]. They introduced a manner of composing several HTML documents into a single view to create an application-like interface.
However, Frames introduced several usability problem that caused several commentators to advise Web site builders to avoid them at all costs. Examples of such usability problems are:
- The [back] button works unintuitively in many cases.
- You cannot bookmark a collection of documents in a frameset, or send someone a reference to the collection.
- If you do a [reload], the result may be different to what you had.
- [page up] and [page down] are often hard to do.
- You can get trapped in a frameset.
- Searching finds HTML pages, not Framed pages, so search results usually give you pages without the navigation context that they were intended to be in.
- Since you can't content negotiate,
noframesmarkup is necessary for user agents that don't support frames. However, almost no one producesnoframescontent, and so it ruins Web searches, since search engines are examples of user agents that do not support frames.- There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.
This document defines a separate XML application, not a part of XHTML per se, that allows similar functionality to HTML Frames, with fewer usability problems, principally by making the content of the frameset visible in its URI.
In itself, this seems fine. However, it really feels like there's a lot of overlap with XLink, XInclude, XSL, and CSS. I think those technologies together could accomplish everything that's suggested here. If they can't, I'd really like to hear why they can't, and then ask whether it might be simpler to make a few small additions to those specs rather than inventing something completely new.