[whatwg] framesets

[Nelson Menezes]

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