- From: Mike Ressler <mressler@gmail.com>
- Date: Mon, 12 Oct 2009 12:16:54 -0400
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>
Received on Monday, 12 October 2009 09:16:54 UTC