[whatwg] framesets
Peter Brawley
pb at artfulsoftware.com
Mon Oct 12 08:21:05 PDT 2009
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-0002.htm>
More information about the whatwg
mailing list