[whatwg] framesets

On Fri, Oct 9, 2009 at 10:33 PM, Peter Brawley <pb at artfulsoftware.com> wrote:
> Boris,
>
>> use cases that the W3C wants to discourage ...
>
> 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.
>
>> The use cases can still be addressed with <iframe> and a bit of pain if
>> resizing is desired, as far as I can tell.
>
> I quoted Andrew Fedoniouk
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html),
> "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."

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.

> I've not seen a counterexample. Have you?

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:
http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
with
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
(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 http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html
(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)


>>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?)
>
> As above, no-one seems able to point to a non-frameset solution.

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):
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5

-- 
Thomas Broyer
/t?.ma.b?wa.je/

Received on Friday, 9 October 2009 15:21:57 UTC