[whatwg] framesets

On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley <pb at artfulsoftware.com> wrote:
> Thanks for responding. Perhaps you can show me otherwise, but containing a
> browsable tree insided a fixed sidebar does not give us independently
> scrolling subwindows side by side on one page, with the possibility of
> editing in either subwindow without the slightest effect n the other.

It works to a considerable degree.  Look at this example:

http://www.w3.org/Style/Examples/007/menus

You can see how the box in the upper right could be moved to the left,
and a margin could be left on the main content.  The navigation box
can be independently scrollable by using overflow-y: auto or scroll.

One major practical drawback is that this doesn't work in IE6, but
that should be irrelevant in a few years.  Also, position: absolute is
probably acceptable fallback in many cases for those users.

Another significant drawback is that while you can interact with the
frames independently, any navigation will navigate all frames at once.
 But that's really a feature, not a bug.  All the problems with frames
stem from the fact that the frames are independently navigable.  You
can pretty easily preserve the state of the navigation menu using
JavaScript, since you have to change it using JavaScript anyway.

> (Of course even if it is possible to do it without frames, new standards
> ought not to require that perfectly functional, legal, working code be
> rewritten on pain of standards non-compliance.)

Of course they should, if part of a previous standard was found to
cause problems.  Otherwise we'd never be able to fix historical
mistakes.  There are enough mistakes we can't fix even if we wanted
to, without refusing to get rid of mistakes when we can.

> A small example is at
> http://www.artfulsoftware.com/infotree/mysqlquerytree.php. All the content
> is from a MySQL db. It's a small part of the tree & read-only. Our networks
> (and some clients) run edit-enabled versions of that frameset. The tree can
> be any size. Some client implementations have an extra frame on the right.

Try bookmarking a specific page, giving someone a link to a specific
page . . . you can't.  There's one URL for the whole thing, no matter
what page you have open.  It seems you can't even use the back and
forward buttons -- navigating doesn't create a new history entry.
(This appears to be true at least in Firefox and Chrome.)  Linking is
what makes the World Wide Web work, and frames completely break it.

See also: http://en.wikipedia.org/wiki/Framing_(World_Wide_Web)#Criticism

> It seems to me that removing framesets from HTML5 mainly because search
> engines don't like them & developers have often mismanaged the Back button
> is a misuse of the standards process.

Search engines are indifferent to frames, as far as I know.  It has
nothing to do with developers (of what?) mismanaging anything --
frames inherently break linking/bookmarking/etc.  URLs no longer work.
 I don't know why back and forward don't work in the browsers I tried
it in, but they don't do that either.  Removing a feature that's
intrinsically broken is absolutely the correct use of the standards
process.

Received on Friday, 9 October 2009 09:04:55 UTC