pb at artfulsoftware.com
Fri Oct 9 09:55:32 PDT 2009
> 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.
Thomas Broyer wrote:
> 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
> I'd add however that replacing a frameset with iframes doesn't solve
> the problem. MSDN (online) correctly (IMO) does *not* use either
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg