- From: Thomas Broyer <t.broyer@gmail.com>
- Date: Fri, 9 Oct 2009 18:23:10 +0200
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/
Received on Friday, 9 October 2009 09:23:10 UTC