<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thomas,<br>
<br>
>For example, compare:<br>
<a class="moz-txt-link-freetext"
href="http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx">>http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx</a><br>
>with<br>
<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><br>
>(and note that this URL cannot be find in <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>any<span class="moz-txt-tag">*</span></b>
link anywhere in the<br>
>JavaDoc, and requires JavaScript to display the "The Collections<br>
>Framework" page; while the MSDN page, even without JavaScript,<br>
>correctly displays the "main content" and can still be navigated,<br>
>though with highly degraded usability).<br>
>See also <a class="moz-txt-link-freetext"
href="http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html">>http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html</a><br>
>(frames, same issue as JavaDoc, with the added possibility to
control<br>
>the "classList" frame's content; only discoverable if you read the<br>
>JavaScript code in the frameset source)<br>
<br>
Indeed. I prefer the Java & Sun framesets to the MSDN page, even if
they pile up tree items in the url stack, but that's not the point. Nor
is the point that a Microsoft maven might prefer the MSDN solution. <br>
<br>
Quite apart from OS dependence issues, the points are (i) there are use
cases for which the Java & Sun framesets are simple, correct
solutions, and the MSDN solution is not, and (ii) revisions in
standards ought not to render existing use-case-correct solutions
unusable with other new features of the new standard.<br>
<br>
PB<br>
<br>
-----<br>
<br>
<br>
Thomas Broyer wrote:
<blockquote
cite="mid:a9699fd20910091521p5d4bdd19l118e9699cbf742f7@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, Oct 9, 2009 at 10:33 PM, Peter Brawley <a class="moz-txt-link-rfc2396E" href="mailto:pb@artfulsoftware.com"><pb@artfulsoftware.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Boris,
</pre>
<blockquote type="cite">
<pre wrap="">use cases that the W3C wants to discourage ...
</pre>
</blockquote>
<pre wrap="">That W3C mindset promotes no greater good; it just imposes an idea of what
use cases should and shouldn't specify. Might as wellwrite popuo removal
into HTML5.
</pre>
<blockquote type="cite">
<pre wrap="">The use cases can still be addressed with <iframe> and a bit of pain if
resizing is desired, as far as I can tell.
</pre>
</blockquote>
<pre wrap="">I quoted 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>),
"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."
</pre>
</blockquote>
<pre wrap=""><!---->
Usability of *HyperText* Markup Language involves being able to *link
to* the frameset as it is presented (which also means bookmarking).
Most users don't understand the concept of frames and don't understand
that when they bookmark a frameset (after having navigated within the
frames), what is bookmarked is not the "page" they were looking at
when they clicked the "bookmark this page" button.
While this can be made to work with JavaScript and (ab)using the #hash
part of the URL (à la AJAX applications' browser history
handling/management), it however is a usability issue with frames to
begin with.
</pre>
<blockquote type="cite">
<pre wrap="">I've not seen a counterexample. Have you?
</pre>
</blockquote>
<pre wrap=""><!---->
I find MSDN as it is now much more usable than when it used frames,
even if that means that the treeview state (which subtree is
opened/closed) isn't preserves when navigating (but trees are not
"first class citizen" of web pages, they always involve JavaScript,
and in this case, localStorage or sessionStorage (or cookies, etc.)
could preserve the treeview state between pages; for the record,
<datagrid> was an attempt to make data grids, and trees, become
first-class citizens, but it wasn't "stable" enough and has been
removed for Last Call).
For example, compare:
<a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx">http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx</a>
with
<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>
(and note that this URL cannot be find in *any* link anywhere in the
JavaDoc, and requires JavaScript to display the "The Collections
Framework" page; while the MSDN page, even without JavaScript,
correctly displays the "main content" and can still be navigated,
though with highly degraded usability).
See also <a class="moz-txt-link-freetext" href="http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html">http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html</a>
(frames, same issue as JavaDoc, with the added possibility to control
the "classList" frame's content; only discoverable if you read the
JavaScript code in the frameset source)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So this is all about assuming that the bit of pain will be enough of an
inconvenience
for authors that they will either address the use case in some way not
involving iframes
at all (and which presumably has a lower pain threshild; what is this way?)
</pre>
</blockquote>
<pre wrap="">As above, no-one seems able to point to a non-frameset solution.
</pre>
</blockquote>
<pre wrap=""><!---->
It depends if you consider the MSDN a non-frameset solution to your
"problem"; but I guess you're very attached to the "doesn't affect
treeview state and scroll position" thing (which isn't impossible to
solve; see above)
IMO, your mysqlquerytree example would be better solved using AJAX
(and innerHTML to inject the retrieved "web parts"): no need for
sessions on the server-side –at least for the treeview state storage–,
which means a more "RESTful" approach, with caching made possible
(even if it is only Vary:Cookie/Cache-Control:private, it's still
better than server state), scalability improvements (less data –state–
kept on the server, less requests to the server –caching *and* the
fact that it's a one-page thing: once you've loaded a subtree, even if
you collapse and re-open it, you don't have to reload it–)
... just like the Google Document Reader (here showing the GWT 1.5 doc):
<a class="moz-txt-link-freetext" href="http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5">http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5</a>
</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>