[whatwg] framesets

[Peter Brawley]

Edouard,

It seems you missed the start of this thread. One use case is 
coordinated browsing of a large database-driven tree in one scrollable 
subwindow and its nodes in another, under a header subwindow which 
(usually) has a tree search control which can direct the tree wubwindow 
to open & display down to the requested node. A frontend authentication 
page determines access to the page and optionally CRUD access to any 
combo of nodes. It must be possible to scroll either subwindow without 
affecting the other in any way. Tree & node subwindows to be editable 
and resizable. If a user does not have read access to a node, the node 
(and anything downstream from that node) is not visible to her. As in 
most standard database maintenance sites, data is not bookmarkable, so 
no tree node is bookmarkable, ie once the user comes in to read and/or 
manage the tree, the back button ignores all her tree moves & actions. 
In sum, the look and feel should resemble 
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html 
or 
http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.zos.doc/wps/dgn_navtree.html, 
plus (i) tree navigation should not add to the url stack and (ii) full 
CRUD must be supported for selected users.

A second use case is a questionnaire with a set of 600+ numbered yes-no 
answers in one xy-scrollable frame, an independently scrolling 
summary/stat info on that answer sheet, with the same rules as above, 
and optionally a third navigation/selection subwindow.

I searched the archives of this list for discussion of tree navigation & 
frames. I found Andrew Fedoniouk 
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html) 
saying "There are /use cases when frames are good/. As an example: 
online (and offline) help systems ...  In such cases /they provide level 
of usability higher than any other method of presenting content of such 
type./" That was what I too concluded from searching books & the web on 
the subject. Claims to the contrary made here are therefore surprising. 
I asked for examples of those claims, that the above specs can be met 
fully (i) with iframes (ii) without either frames or iframes. No-one 
pointed at an example that meets the spec fully. Closest is the MSDN 
site, which needs about ten times as much code as ours, and is tied to 
an OS. No thanks.

What's the justification? The above, plus data trees are increasingly 
important (eg see 
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html), the 
interface needed to maintain them is as described, and such interfaces 
can be developed more cheaply & quickly on a web page with PHP than with 
desktop-oriented tools. The most straightforward way to implement that 
interface on a web page is the frameset (which might have a little 
something to do with why IBM and Sun use framesets to meet similar specs).

Framesets are commonly used to present trees and some other 
master-detail data structures. Removing the frameset from HTML5 is a 
mistake.

PB

-----

Eduard Pascual wrote:
> I have been following this discussion for many hours and it's getting
> tiring. In addition, it doesn't seem to be leading anywhere; so please
> let me suggest some ideas that may, at least, help it advance:
>
> First: you have been asking for "counter-examples" (and you have been
> given the MSDN one), but you haven't provided any specific example to
> begin with. That would make a better starting point.
>
> Second: you reject sound arguments claiming that "the use case
> requires otherwise", but what's your use-case? Without clearly
> specifying the use case, your arguments based on it aren't going to be
> taken too seriously: they are basically based on nothing, until you
> properly define the case they are supposedly based on. To specify a
> use-case in a way that will be taken seriously by the editor and other
> contributors:
> - Clearly define the problem you are trying to solve. When doing so,
> describe the problem in a way that is independent to the solution you
> are proposing. For example, if you look on the archives, you'll see
> that the use case for RDFa was often defined as "including RDF triples
> on webpages": this didn't work because that's not the problem, RDF is
> the solution. The same way, if you describe the need as "allowing
> <frameset> on HTML5" you won't get anywhere: that's your own
> suggestion to address the need, but which is the need?
> Make sure that your use-case addresses real-world problems.
> - Clearly specify and justify the requirements. Keep in mind that
> "because the client wants it" is not enough justification; you'd need
> to get an answer to "why does the client want it?". For example, if
> someone hired me to build a web app that takes control of the users'
> computer, I might come to the lists and ask for a feature to implement
> that, based on the point that "the client wants it": that'd be
> pointless and would go nowhere.
>
> Third: once you have a well-defined use-case (or ideally, several
> use-cases), you have a chance to get your proposal being taken
> seriously. To do so, specify what you are proposing:
> - State why currently existing solutions don't meet the requirements.
> As far as this has gone, the only requirements that apparently aren't
> met by <iframe> and other alternatives are the "break deep-linking"
> and "break navigation" ones. Besides of the fact that you still need
> to justify such requirements, that's actually easy to achieve with a
> bit of ugly scripting.
> - Describe your solution. State clearly how/why it meets each of the
> requirements. Also, try to describe the specific changes required on
> the spec.
>
> If you manage to do that, your proposal will be definitely be taken
> much more seriously.
>
> Regards,
> Eduard Pascual
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091009/1be06ff1/attachment-0001.htm>