- From: Peter Brawley <pb@artfulsoftware.com>
- Date: Thu, 08 Oct 2009 21:41:55 -0500
Aryeh, >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. 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. (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.) >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. 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. 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. 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 & a bit of javascript we can implement that interface with less than 10% of the code MSDN required. It seems to me that removing framesets from HTML5 mainly because search engines don't like them & developers have often mismanaged the Back button is a misuse of the standards process. PB ----- Aryeh Gregor wrote: > On Thu, Oct 8, 2009 at 7:52 PM, Peter Brawley <pb at artfulsoftware.com> wrote: > >> 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. >> > > 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. > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.421 / Virus Database: 270.14.7/2422 - Release Date: 10/08/09 06:39:00 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091008/39cae63e/attachment.htm>
Received on Thursday, 8 October 2009 19:41:55 UTC