<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-html" lang="x-unicode">
<pre wrap="">&gt; Try bookmarking a specific page, giving someone a link to a specific
<span class="moz-txt-citetags">&gt; </span>page . . . you can't.  There's one URL for the whole thing, no matter
<span class="moz-txt-citetags">&gt; </span>what page you have open.  It seems you can't even use the back and
<span class="moz-txt-citetags">&gt; </span>forward buttons -- navigating doesn't create a new history entry.
<span class="moz-txt-citetags">&gt; </span>(This appears to be true at least in Firefox and Chrome.)  Linking is
<span class="moz-txt-citetags">&gt; </span>what makes the World Wide Web work, and frames completely break it.</pre>
Oy, from the fact that users find web page links useful, it does not
follow that all identified content ought to be so linked.<br>
<br>
A <i>design goal</i> 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.<br>
<br>
Linking is <i>one functionality</i> that makes the web work. <i>It's
not the only one</i>. This use case <i>needs to isolate</i> items
within the page from back/forward/history and external links. <br>
<br>
PB<br>
<br>
----<br>
<br>
Thomas Broyer wrote:
<blockquote
 cite="mid:a9699fd20910090923w1576480dt844fea27d9890a9a@mail.gmail.com"
 type="cite">
  <pre wrap="">On Fri, Oct 9, 2009 at 6:04 PM, Aryeh Gregor <a
 class="moz-txt-link-rfc2396E" href="mailto:Simetrical+w3c@gmail.com">&lt;Simetrical+w3c@gmail.com&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley <a
 class="moz-txt-link-rfc2396E" href="mailto:pb@artfulsoftware.com">&lt;pb@artfulsoftware.com&gt;</a> wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">A small example is at
<a class="moz-txt-link-freetext"
 href="http://www.artfulsoftware.com/infotree/mysqlquerytree.php">http://www.artfulsoftware.com/infotree/mysqlquerytree.php</a>. All the content
is from a MySQL db. It's a small part of the tree &amp; 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.
      </pre>
    </blockquote>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->[...]
  </pre>
  <blockquote type="cite">
    <pre wrap=""> 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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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")

  </pre>
  <blockquote type="cite">
    <pre wrap=""> Removing a feature that's
intrinsically broken is absolutely the correct use of the standards
process.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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)

  </pre>
  <pre wrap=""><hr size="4" width="90%">

No virus found in this incoming message.
Checked by AVG - <a class="moz-txt-link-abbreviated"
 href="http://www.avg.com">www.avg.com</a> 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00

  </pre>
</blockquote>
</div>
</body>
</html>