[Barry A. Warsaw]

...

...

...

...

...

"HM" == Harald Meland Harald.Meland@usit.uio.no writes:

HM> Like, in a separate frame, maybe?  That's what I've been
HM> thinking, anyway...

HM> However, the frame-full UI should be optional.  For a
HM> frame-less UI, I agree with Ken.

Harald, I hope you're not advocating using HTML <frame>s! I absolutely detest those things :). I think we can get all the benefits of frames without the headaches by using an arrangement similar to www.python.org and www.jpython.org (and not-coincidentally www.python.org/~bwarsaw :)

I suspect that I'm not understanding the issues involved clearly enough to be advocation one or the other construct. However, mere suspicion of lack of understanding have never stopped me from putting my foot in my mouth before :)

Here are some of possible uses I have been thinking about for HTML

<frame>s in Mailman:

• Implementing a admin-interface sidebar with links to the various admin pages

• Viewing list option documentation in the same browser window as the admin interface

• Keeping buttons like "submit changes" fixed in one window position while scrolling through all the settings in another frame (although this might very well be undoable due to the SUBMIT input being in another document than where the POST form is...)

The sidebar stuff could be done with an arrangement like Barry suggests, even though then the entire page would have to be re-rendered when a new page is loaded, and the sidebar would scroll along with the rest of the page.

Adding an option documentation row to the full-page table would only work properly if the entire page fits inside one windowful -- and would probably be messy even then. On the other hand, maybe the current approach of always showing option documentation in a separate window is the way to go.

Having fixed-position buttons is not really that important, I think :)

Harald