- From: tali garsiel <t_garsiel@hotmail.com>
- Date: Thu, 15 Oct 2009 12:43:53 +0000
<Pine.LNX.4.62.0910130924420.25383 at hixie.dreamhostps.com> <4AD4A1EB.8080102 at artfulsoftware.com> <Pine.LNX.4.62.0910132224110.6803 at hixie.dreamhostps.com> <4AD5438D.3090407 at artfulsoftware.com> <98038259-77F7-42FD-8A4A-097BB3E9EA3B at dartmouth.edu> <4AD57761.4060905 at artfulsoftware.com> <5ccfb3340910140023s65dbb96bq988b96b55707aa1d at mail.gmail.com> <4AD5F4A5.2040204 at artfulsoftware.com> <a440ea080910150049t42482beav46a76a597ba2916c at mail.gmail.com> Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Nelson wrote: There is a specific use-case (that has nothing to do with databases > or bookmarking) that framesets solve better out-of-the box right now > in most browsers: that of a panel-based layout that allows resizing > and maintains UI state without flickering whilst loading content in > different panel As an aside, there is a reason why AJAX has become so popular over the > past few years: it solves the specific UI-reset issue that is inherent > in full-page refreshes. Maybe there is room for a better, > standard-based approach to solving this issue, but framesets ain't it. I totally agree. I think the described case is the main flow in web applications. I think most web applications have exactly this panel based layout, where navigation loads only a some of the panels. I think they all use AJAX. Iframes are very unpopular, and as you say AJAX is the best current solution. I think there should be a standard based solution because: 1.Even when using libraries like prototype, AJAX does take some coding. Why should I use so much code for such a simple, main flow use case? 2.By looking at browsers code I see there is a lot of clever stuff going on when loading/unloading a document. In the AJAX based solution this happens only once in the application life cycle. It seems to me that dedicating a special syntax to navigation would help browsers to test the application main flow. Tali ---------------------------------------- > From: flying.mushroom at gmail.com > Date: Thu, 15 Oct 2009 09:49:58 +0200 > To: pb at artfulsoftware.com > CC: whatwg at whatwg.org > Subject: Re: [whatwg] framesets > > Wow, what a tour de force; 78 messages and no progress. > > Peter, I believe the only reason the discussion has carried so far is > because you are, actually, on to something. You just don't seem very > aware that people are actually trying to pin down and solve the > "something" and keep banging on about framesets being the cure-all, > whilst ignoring other points. > > Here's (yet another) summary: > > 1) Framesets have been deprecated for quite a long time. The reasons > for the deprecation have been repeated ad nauseam, and very solid. > > 2) There is a specific use-case (that has nothing to do with databases > or bookmarking) that framesets solve better out-of-the box right now > in most browsers: that of a panel-based layout that allows resizing > and maintains UI state without flickering whilst loading content in > different panels (this is, I believe, the "something" you're getting > at). > > 3) There are HTML5-conformant solutions available right now that allow > you to replicate the above scenario with a little more work. The > iframes solution with a bit of JS [1] [2] for handling the resizing is > probably the easiest to implement, although an analogous solution with > AJAX is probably the best available (which allows for deep-linking > when this is desirable and doesn't automatically break bookmarking). > You can also (if you wish) break bookmarking/the back button with > these solutions, especially the AJAX one. There is also the CSS > position: fixed solution that will be adequate for a large number of > scenarios, or can complement the other two. > > 4) As repeated many times, you don't have to use HTML5. Keep using > HTML 4 Frameset [3] if you insist on using the frameset solution and > care about validation. The documents within each frame can be HTML5. > Or use HTML5 with framesets -- it won't validate but is guaranteed (by > the spec) to work. Do expect to run into the usability problems > inherent to frames, though. > > 5) There is a known need for CSS to handle the above panel resizing > use-case. That is a first-class CSS problem; don't expect the HTML > spec to address that, especially not with a mechanism (framesets) that > has many drawbacks and is deprecated for good reasons. For immediate > solutions, see 3) and 4) above. > > 6) For clarity sake, I'll repeat the point made several times:the > bookmarking/navigation/security issue is *not* solved by framesets, > and the slight hack to make this work (javascript's "replace") as you > suggest is neither exclusive to framesets nor (in the case of > security) acceptable. > > As an aside, there is a reason why AJAX has become so popular over the > past few years: it solves the specific UI-reset issue that is inherent > in full-page refreshes. Maybe there is room for a better, > standard-based approach to solving this issue, but framesets ain't it. > > [1] http://methvin.com/splitter/4psplitter.html > [2] http://developer.yahoo.com/yui/examples/layout/page_layout.html > [3] http://www.w3.org/TR/html4/sgml/framesetdtd.html > > Nelson Menezes > http://fittopage.org > > > 2009/10/14 Peter Brawley >> >> Rimantas, >> >>>Maybe there are not many sites because nobody wants this type of sites? >> >> You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years. >> >> The full use case is treeview database maintenance. Tree logic has been slow to mature in SQL, is non-trivial in HTML as we see, and is hard to generate from PHP/Ruby/whatever. >> >>>I hate this type of documentation sites personally. >> >> Fine, you've no need for website maintenance of data-driven trees. That's not a rationale for excluding framesets from HTML5. >> >>> And to me this use case looks built around the chosen implementation, >> >> Wrong. Frameset was chosen because it provides the most efficient available implementaiton. >> >>> while I prefers solutions built around solving the real need. >> >> Which this is. >> >>>So you want HTML5 spec tailored for this particular case of yours? >>>Can I have tag, please? >> >> May I have rational responses please? This is not a request for a new feature. I want HTML5 to continue support for useful HTML. >> >>>Nobody forbids you from using previous versions of HTML. >> >> Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. >> >> PB >> >> ----- >> >> Rimantas Liubertas wrote: >> >> So it does not answer the question: if framesets are as you claim not needed >> for the full spec, there should be lots of non-frameset sites which meet >> this spec as efficiently as ours does. >> >> >> Maybe there are not many sites because nobody wants this type of sites? >> I hate this type of documentation sites personally. >> And to me this use case looks built around the chosen implementation, >> while I prefers solutions built around solving the real need. >> >> >> >> If that blocks a use case, by all means don't use a frameset for it. For >> this use, the above poses no problem at all. And if CSS were actually as >> efficient for this spec as framesets, surely some developers would have >> taken advantage of that by now. >> >> >> Once again you assume that your spec is highly desired. Maybe it is not >> the case and so nobody bothered. >> >> <?> >> >> >> No need in this case. >> >> >> <?> >> >> >> Not an issue for this use. >> >> >> So you want HTML5 spec tailored for this particular case of yours? >> Can I have tag, please? >> >> >> >> Here's an application for framesets which is valid on previous versions of >> HTML, >> >> >> Nobody forbids you from using previous versions of HTML. >> >> >> >> meets a need, is more efficient than known implemented alternatives >> for this use case, >> >> >> You have framed (pardon the pun) this use case this way and reject all >> other options. Once again?you can use HTML4.01 frameset document >> with HTML5 documents loaded to frames. This was suggested more >> than once. >> >> >> >> and does not suffer from any of the frameset deficiencies >> you have listed. >> >> >> How so? >> >> >> >> Framesets remain useful, excluding them from HTML5 >> undermines support for those uses, and that weakens HTML5. >> >> >> I'd argue that it strengthens HTML5. >> >> Regards, >> Rimantas >> -- >> http://rimantas.com/ >> >> ________________________________ >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> >> Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09 06:33:00 >> >> _________________________________________________________________ Keep your friends updated?even when you?re not signed in. 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_5:092010
Received on Thursday, 15 October 2009 05:43:53 UTC