[whatwg] framesets

[Peter Brawley]

Thomas,

 >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)

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.

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.

PB

-----


Thomas Broyer wrote:
> 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
>
>   
> ------------------------------------------------------------------------
>
>
> 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/d9e9ffc3/attachment.htm>