[whatwg] framesets

> 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 <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)
>
>   
> ------------------------------------------------------------------------
>
>
> 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...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091009/249f1263/attachment.htm>

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