[whatwg] framesets

Ian,
> > 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."
> >
> > I've not seen a counterexample. Have you?
 > I believe Andrew's statement to be incorrect.

If your belief is correct, there must be sites which accomplish this 
spec with tables + iframes (for example). No contributor has managed to 
point to them.

 > search engines can't index into them (search is a critical part of help
 > systems), pages in them can't easily be bookmarked

A DB row is a tree node and it must be possible to block bookmarking of 
such rows.
> Supposing that someone can produce examples, the argument for removing
> frames from HTML5 becomes: "frameset has been in HTML till now, /but is
> being removed because we do not like it/. If you insist on such use
> cases, re-architect them." That's a misuse of standards.
 >That's how we roll here. :-)

So I see. It's appalling.

PB

-----

Ian Hickson wrote:
> On Thu, 8 Oct 2009, Peter Brawley wrote:
>   
>> According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The 
>> following elements are not in HTML 5 because their usage affected 
>> usability and accessibility for the end user in a negative way:
>>
>>    * frame
>>    * frameset
>>    * noframes"
>>
>> As Andrew Fedoniouk said on this list in 2007
>> (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."
>>
>> I agree wholeheartedly, esp. when the topic list is long (thousands or 
>> millions of items) and itself editable, and the required interface is 
>> for flexible, independent scrolling of freely choosable bits of the 
>> topic tree in the left frame without affecting anything in the right 
>> detail frame. As Andrew said, frames are the only good way to do this.
>>
>> New standards ought not to remove required functionalities, ought not to 
>> break perfectly good & legal working code, and ought not to impose 
>> Hobson's choice of keeping functionality vs remaining 
>> standards-compliant. How do we get the unwise decision to remove 
>> framesets revisited?
>>     
>
> Except for resizing, anything you can do with framesets, you can do better 
> with <iframe>s and CSS. In addition, with pushState(), you can fix the 
> bookmarking problem in a better way than with framesets.
>
> Resizing is something that's harder to do, but that's a presentational 
> issue that we need to fix anyway, independent of frames.
>
> Framesets have a number of problems, chief amongst them that bookmarking 
> is dysfunctional, but also that the accessibility story for frames is 
> rather poor, and that there the presentation with frames is much less 
> pleasing than with other features (e.g. in Safari, this page:
>
>    http://www.artfulsoftware.com/infotree/mysqlquerytree.php
>
> ...has a vertical scrollbar for the top frame -- a problem you wouldn't 
> get if instead of four pages, you had three, with the main one containing 
> two iframes from the left and right frames).
>
> In addition to <iframe>s, other techniques exist to get similar results, 
> e.g. AJAX. The use case covered by <frameset> is definitely handled 
>
> (Getting rid of the frames altogether is probably best, since then tools 
> like search engines can actually return useful links. However, I 
> understand if some authors are unwilling to do the work to get to that 
> point. <iframes>, on the other hand, are very easy to migrate to.)
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>   
>> W3C's job is to enable, not function like a commissariat.
>>     
>
> This isn't the W3C.
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>   
>> I'm arguing that framesets have been part of HTML4, developers used them 
>> in good faith, and removing them from HTML5 unfairly & arbitrarily 
>> imposes a Hobson's choice of keeping existing functionality while 
>> foregoing new HTML5 functionality, or re-architecting existing 
>> functionality in order to use new HTML5 functionality.
>>     
>
> Actually, you only need to use frames in the frameset page, so if your 
> only concern is what validates, you could just use HTML4 Frameset for the 
> frameset page, and HTML5 for the content pages.
>
> But I would still strongly discourage using framesets.
>
>
> On Fri, 9 Oct 2009, Jonas Sicking wrote:
>   
>> The big difference is that <iframe>s can be used in good ways, framesets 
>> essentially can't.
>>
>> Another reason do deprecate <frameset> but not <iframe> is that we don't 
>> need *two* ways to make poorly behaving pages.
>>     
>
> Indeed.
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>   
>> Supposing that someone can produce examples, the argument for removing 
>> frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
>> being removed because we do not like it/. If you insist on such use 
>> cases, re-architect them." That's a misuse of standards.
>>     
>
> That's how we roll here. :-)
>
>
>   
>>> What'd be the point of keeping two sources of issues when one can be 
>>> enough to cover all use-cases?
>>>       
>> If your premiss is correct, backward compatibility.
>>     
>
> Backwards-compatibility is preserved: HTML5 defines how framesets are to 
> be implemented, so your pages won't stop working with HTML5 browsers. They 
> just won't be conforming HTML5, because we want to discourage the use of 
> framesets in favour of better solutions.
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>   
>> Why relegate a perfectly sound use case to a cul-de-sac?
>>     
>
> It would be a bad idea to relegate a perfectly sound use case to a 
> cul-de-sac. But that's not what we're doing. The use case is still 
> handled fine, in a number of ways (e.g. <iframe>s, Ajax-based navigation). 
> The feature we're relegating to a cul-de-sac is not perfectly sound.
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>   
>> It's not your brief to decide what's beneficial for a client.
>>     
>
> Actually, it sort of is.
>
>
>   
>>> It conflicts with expected behavior.
>>>       
>> It does not conflict with what these users expect.
>>     
>
> Framesets actually do conflict significantly with what most users expect; 
> that's one of their problems.
>
>
>   
>> Framesets are part of the current HTML standard and should remain.
>>     
>
> Actually framesets were deprecated in 1998. They've been on the chopping 
> block for over ten years now. Their use is _so_ discouraged in HTML4 that 
> they are not even included in the Transitional DTD, they are relagated to 
> their own third-tier DTD.
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>   
>> 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."
>>
>> I've not seen a counterexample. Have you?
>>     
>
> I believe Andrew's statement to be incorrect. I would argue that the 
> usability of help sites based on <frameset>s is horrible. For example, 
> search engines can't index into them (search is a critical part of help 
> systems), pages in them can't easily be bookmarked and URLs to them can't 
> be shared with other people (another critical part of help systems), and 
> using the "open in new tab" feature on index pages of help systems that 
> use framesets ends up breaking the frameset, making browsing multiple 
> aspects in parallel difficult.
>
>
> On Sat, 10 Oct 2009, tali garsiel wrote:
>   
>> 1. Tabs and tree menu navigation is very common in web applications. Do 
>> you agree with that assumption?
>>     
>
> Tabs are a media-specific presentation issue, and don't belong in HTML.
>
> Tree menu navigation is a use case we need to fix anyway, and will 
> probably do so in the next version of HTML. (We were going to do it in 
> HTML5, but had to punt because we couldn't get the detailed nailed down. 
> It's a hard thing to get right.) However, that's independant of frames. 
> The problem exists regardless of what the look is, one frame or many.
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.9/2428 - Release Date: 10/11/09 06:39:00
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091012/c726cbfe/attachment-0001.htm>

Received on Monday, 12 October 2009 08:21:05 UTC