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.
Oy, from the fact that users find web page links useful, it does not
follow that all identified content ought to be so linked.
A /design goal/ of this use case is to isolate individual framed items
from URL back/forward/history.external linking. Analagous to watching a
picture show where selecting N pictures does not commit you to hitting
the Back button N times to get back out. More significantly, each item
may have its own permission setting.
Linking is /one functionality/ that makes the web work. /It's not the
only one/. This use case /needs to isolate/ items within the page from
back/forward/history and external links.
PB
----
Thomas Broyer wrote:
On Fri, Oct 9, 2009 at 6:04 PM, Aryeh Gregor <[email protected]> wrote:
On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley <[email protected]> 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)
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00
