<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Edouard,<br>
<br>
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
<a class="moz-txt-link-freetext" href="http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html">http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html</a>
or
<a class="moz-txt-link-freetext" href="http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.zos.doc/wps/dgn_navtree.html">http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.zos.doc/wps/dgn_navtree.html</a>,
plus (i) tree navigation should not add to the url stack and (ii) full
CRUD must be supported for selected users.<br>
<br>
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.<br>
<br>
I searched the archives of this list for discussion of tree navigation
& frames. I found Andrew Fedoniouk (<a class="moz-txt-link-freetext"
href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html</a>)
saying
"There are <i>use cases when frames are good</i>. As an example:
online (and
offline) help systems ... In such cases <i>they provide level of
usability higher than any other method of presenting content of such
type.</i>"
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.<br>
<br>
What's the justification? The above, plus data trees are increasingly
important (eg see
<a class="moz-txt-link-freetext" href="http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html">http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html</a>), 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). <br>
<br>
Framesets are commonly used to present trees and some other
master-detail data structures. Removing the frameset from HTML5 is a
mistake.<br>
<br>
PB<br>
<br>
-----<br>
<br>
Eduard Pascual wrote:
<blockquote
cite="mid:6ea53250910091718md017d92xe32e244fca3343b6@mail.gmail.com"
type="cite">
<pre wrap="">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</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.8/2425 - Release Date: 10/09/09 08:10:00
</pre>
</blockquote>
</body>
</html>