<!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">
Aryeh,<br>
<br>
&gt;How is this better for you than making the sidebar position: fixed<br>
&gt;(and maybe even in an iframe if you specifically want that)? I can<br>
&gt;think of a few ways, e.g., if it's essential that the state of each<br>
&gt;frame remain unchanged when you navigate the other frame. <br>
<br>
Thanks for responding. Perhaps you can show me otherwise, but
containing a browsable tree insided a fixed sidebar does not give us
independently scrolling subwindows side by side on one page, with the
possibility of editing in either subwindow without the slightest effect
n the other. That is the requirement, framesets let us meet it, and
nothing else we know of does.<br>
<br>
(Of course even if it is possible to do it without frames, new
standards ought not to require that perfectly functional, legal,
working code be rewritten on pain of standards non-compliance.)<br>
<br>
&gt;What's a<br>
&gt;concrete example where this is necessary, though? Maybe there are<br>
&gt;other ways to approach the problem that don't completely break<br>
&gt;bookmarking/URL copying/the browser back button/etc.<br>
<br>
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.<br>
<br>
A variation on this design isĀ  a frameset where the right frame is an
instance of an answer set to a questionnaire with up to 700 yes-no
questions, a left frame shows answer set statistics dynamically, and
the set of answersheets are browsed in the top frame.<br>
<br>
MSDN Help used to implement a similar, frame-like interface in ASP. It
was slow, it required a huge amount of code, and of course it was
OS-dependent. With frames &amp; a bit of javascript we can implement
that interface with less than 10% of the code MSDN required.<br>
<br>
It seems to me that removing framesets from HTML5 mainly because search
engines don't like them &amp; developers have often mismanaged the Back
button is a misuse of the standards process.<br>
<br>
PB<br>
<br>
-----<br>
<br>
Aryeh Gregor wrote:
<blockquote
 cite="mid:7c2a12e20910081821y2f0c2b6cn86116bfaf360f94c@mail.gmail.com"
 type="cite">
  <pre wrap="">On Thu, Oct 8, 2009 at 7:52 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="">I agree wholeheartedly, esp. when the topic list is long (thousands or
millions of items) and itself editable, and the required interface is for
flexible, independent scrolling of freely choosable bits of the topic tree
in the left frame without affecting anything in the right detail frame. As
Andrew said, frames are the only good way to do this.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
How is this better for you than making the sidebar position: fixed
(and maybe even in an iframe if you specifically want that)?  I can
think of a few ways, e.g., if it's essential that the state of each
frame remain unchanged when you navigate the other frame.  What's a
concrete example where this is necessary, though?  Maybe there are
other ways to approach the problem that don't completely break
bookmarking/URL copying/the browser back button/etc.</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.7/2422 - Release Date: 10/08/09 06:39:00

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