[whatwg] framesets
tali garsiel
t_garsiel at hotmail.com
Mon Oct 12 03:07:12 PDT 2009
<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
More information about the whatwg
mailing list