[whatwg] framesets

Thu Oct 15 20:33:08 PDT 2009

Nelson,

1) Framesets have been deprecated for quite a long time. The reasons
for the deprecation have been repeated ad nauseam, and very solid.

Which solid objections did I not knock down?

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).

OK.

>3) There are HTML5-conformant solutions available right now that allow
>you to replicate the above scenario with a little more work.

Can't tell without a lotta work on it, I've solved the problem once, I'd 
rather spend development time on unsolved problems.

>6) For clarity sake, I'll repeat the point made several times:the
>bookmarking/navigation/security issue is *not* solved by framesets,

OK and for clarity's sake I'll again repeat framesets don't solve the 
navigation problem, they just make it easier to solve than any other 
available proved solution, and this wee problem is that browsers  own 
bookmarks, database users own database table rows, so usually you 
shouldn't bookmark database table rows, and much follows from that, 
therefore saying server issues don't bear on this issue is IMO 
astonishingly & quite wrongly blinkered.

>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.

Indeed, and as you also know in some contexts AJAX is not the most 
desirable refresh solution.

Thanks for the links to two alternative possibilities.

PB

-----

Nelson Menezes wrote:
> 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 <pb at artfulsoftware.com>
>   
>> 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 <dancinghampsters> 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 <dancinghampsters> 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
>>
>>     
> >
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.18/2437 - Release Date: 10/15/09 03:57:00
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091015/c3e0c510/attachment-0002.htm>