[whatwg] framesets

[Thomas Broyer]

On Fri, Oct 9, 2009 at 6:04 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley <pb at artfulsoftware.com> wrote:
>
>> 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.
[...]
>  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.

That's because it uses parent.frames["details"].location.replace(...)
and parent.frames["tree"].location.replace(...)

(in this case, I'd talk about a "developer [who has] mismanaged the
Back button")

> Removing a feature that's
> intrinsically broken is absolutely the correct use of the standards
> process.

I'd add however that replacing a frameset with iframes doesn't solve
the problem. MSDN (online) correctly (IMO) does *not* use either
frames or iframes, and still works great (using JavaScript, but
Peter's example requires JavaScript too). i'd even say it works better
than Peter's example because the tree state is maintained on the
client-side, which means requests to the server can be cached
efficiently (and additionally are lighter-weight and don't even
require server-side processing)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/