[whatwg] framesets

Mon Oct 12 09:16:54 PDT 2009

Peter,

Thanks for the clarification, I think I have a little better understanding
now.

(Sorry I jumped into the mailing list in the middle of the conversation and
missed some of the earlier context) Are we currently discussing
implementation details around a proposed tree structure control?  I heard a
few people talk about framesets vs. frames vs. divs, but I thought the
proposal was that there would be a new <tree> tag?  I guess my confusion
lies in why frames & framesets are being discussed at all.

The "black box" part of the tree view has me a little confused as well.  I
would think that such a structure would benefit greatly by allowing
JavaScript access to its elements.  And if such access to its internal
elements were available, then why wouldn't a developer simply implement one
of the many ways to block data bookmarking that you and I are aware of?

I was envisioning a <tree> tag that would support expanding and collapsing
rows without forcing the developer to jump through fire-y JavaScript hoops
to get the implementation correct.  Then any modification to the tree would
be handled by the application developer via JavaScript or through a new page
view.  Am I way off base?

Mike Ressler

On Mon, Oct 12, 2009 at 12:01 PM, Peter Brawley <pb at artfulsoftware.com>wrote:

>  Mike,
>
> >Can you explain what you mean by "A DB row is a tree node and it must be
> possible
> >to block bookmarking of such rows." a little more?  From my understanding,
> a developer
> >could accomplish this with an onclick handler and some URI arguments, but
> it seems like
> >you're focused on the browser itself preventing the bookmarking of the
> link.
>
> There are good database reasons to block bookmarks to table rows, so that
> must be doable. That user requirement conflicts with the judgement, often
> voiced by HTML standards custodians, that frames are "bad" because they
> screw up bookmarking. The use case that mainly motivates my objection to
> this says that the datatree maintenance page must function as a black box
> with no internal HTML bookmarking at all---except for exit, navigation must
> be controlled entirely by database/tree logic. The argument is not,
> therefore, that HTML5 should support new methods of bookmark blocking. The
> argument is that for this use case, which is best served by framesets till
> proved otherwise (and no-one has yet), the bookmark objection to framesets
> is invalid.
>
> Yes I agree there are lots of ways to block data bookmarking.
>
> PB
>
> ------
>
>
> Mike Ressler wrote:
>
> Peter,
>
> Can you explain what you mean by "A DB row is a tree node and it must be
> possible to block bookmarking of such rows." a little more?  From my
> understanding, a developer could accomplish this with an onclick handler and
> some URI arguments, but it seems like you're focused on the browser itself
> preventing the bookmarking of the link.
>
> What would preventing bookmarking by the browser accomplish that an onclick
> handler that rewrites the URI of the link not accomplish?
>
> Mike Ressler
>
> On Mon, Oct 12, 2009 at 11:21 AM, Peter Brawley <pb at artfulsoftware.com>wrote:
>
>>  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
>>
>>
>>
>>
> ------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
>
> Version: 8.5.421 / Virus Database: 270.14.11/2430 - Release Date: 10/12/09 04:01:00
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091012/32449203/attachment-0001.htm>