- From: Peter Brawley <pb@artfulsoftware.com>
- Date: Mon, 12 Oct 2009 11:01:09 -0500
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 > <mailto: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 <http://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/0aa7cb6f/attachment-0001.htm>
Received on Monday, 12 October 2009 09:01:09 UTC