W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] framesets

From: Peter Brawley <pb@artfulsoftware.com>
Date: Thu, 08 Oct 2009 21:41:55 -0500
Message-ID: <4ACEA2F3.4090905@artfulsoftware.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:17 UTC