[whatwg] framesets

 	<BAY117-W3028B5E214EDAE8AB9A8EB83C90 at phx.gbl>
 

 <Pine.LNX.4.62.0910120719160.25383 at hixie.dreamhostps.com>
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


Does "pushState" apply to bookmarking ?From reading section 6.10 of the spec it seems to apply only to back/forward navigation.If it does, it seems a good solution for iframe bookmarking problem.
> Date: Mon, 12 Oct 2009 09:12:34 +0000
> From: ian at hixie.ch
> To: whatwg at whatwg.org
> Subject: Re: [whatwg] framesets
> 
> 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.
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
 		 	   		  
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you?re up to on Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009

Received on Monday, 12 October 2009 03:07:12 UTC