<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Nelson,<br>
<pre wrap="">1) Framesets have been deprecated for quite a long time. The reasons
for the deprecation have been repeated ad nauseam, and very solid.</pre>
Which solid objections did I not knock down?<br>
<pre wrap="">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).</pre>
OK.<br>
<pre wrap="">>3) There are HTML5-conformant solutions available right now that allow
>you to replicate the above scenario with a little more work.</pre>
Can't tell without a lotta work on it, I've solved the problem once,
I'd rather spend development time on unsolved problems.<br>
<pre wrap="">>6) For clarity sake, I'll repeat the point made several times:the
>bookmarking/navigation/security issue is *not* solved by framesets,
</pre>
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.<br>
<pre wrap="">>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.
</pre>
Indeed, and as you also know in some contexts AJAX is not the most
desirable refresh solution.<br>
<br>
Thanks for the links to two alternative possibilities.<br>
<br>
PB<br>
<br>
-----<br>
<br>
Nelson Menezes wrote:
<blockquote
cite="mid:a440ea080910150049t42482beav46a76a597ba2916c@mail.gmail.com"
type="cite">
<pre wrap="">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] <a class="moz-txt-link-freetext" href="http://methvin.com/splitter/4psplitter.html">http://methvin.com/splitter/4psplitter.html</a>
[2] <a class="moz-txt-link-freetext" href="http://developer.yahoo.com/yui/examples/layout/page_layout.html">http://developer.yahoo.com/yui/examples/layout/page_layout.html</a>
[3] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/html4/sgml/framesetdtd.html">http://www.w3.org/TR/html4/sgml/framesetdtd.html</a>
Nelson Menezes
<a class="moz-txt-link-freetext" href="http://fittopage.org">http://fittopage.org</a>
2009/10/14 Peter Brawley <a class="moz-txt-link-rfc2396E" href="mailto:pb@artfulsoftware.com"><pb@artfulsoftware.com></a>
</pre>
<blockquote type="cite">
<pre wrap="">Rimantas,
</pre>
<blockquote type="cite">
<pre wrap="">Maybe there are not many sites because nobody wants this type of sites?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">I hate this type of documentation sites personally.
</pre>
</blockquote>
<pre wrap="">Fine, you've no need for website maintenance of data-driven trees. That's not a rationale for excluding framesets from HTML5.
</pre>
<blockquote type="cite">
<pre wrap="">And to me this use case looks built around the chosen implementation,
</pre>
</blockquote>
<pre wrap="">Wrong. Frameset was chosen because it provides the most efficient available implementaiton.
</pre>
<blockquote type="cite">
<pre wrap="">while I prefers solutions built around solving the real need.
</pre>
</blockquote>
<pre wrap="">Which this is.
</pre>
<blockquote type="cite">
<pre wrap="">So you want HTML5 spec tailored for this particular case of yours?
Can I have <dancinghampsters> tag, please?
</pre>
</blockquote>
<pre wrap="">May I have rational responses please? This is not a request for a new feature. I want HTML5 to continue support for useful HTML.
</pre>
<blockquote type="cite">
<pre wrap="">Nobody forbids you from using previous versions of HTML.
</pre>
</blockquote>
<pre wrap="">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
--
<a class="moz-txt-link-freetext" href="http://rimantas.com/">http://rimantas.com/</a>
________________________________
No virus found in this incoming message.
Checked by AVG - <a class="moz-txt-link-abbreviated" href="http://www.avg.com">www.avg.com</a>
Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09 06:33:00
</pre>
</blockquote>
<pre wrap=""><!---->></pre>
<pre wrap="">
<hr size="4" width="90%">
No virus found in this incoming message.
Checked by AVG - <a class="moz-txt-link-abbreviated" href="http://www.avg.com">www.avg.com</a>
Version: 8.5.421 / Virus Database: 270.14.18/2437 - Release Date: 10/15/09 03:57:00
</pre>
</blockquote>
</body>
</html>