Oops, only sent this to one recipient earlier.<br><br><div class="gmail_quote">2009/10/11 David Workman <span dir="ltr"><<a href="mailto:workmad3@gmail.com">workmad3@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Peter,<br><br>From reading this discussion, I think you've slightly missed a salient point with regards to the current state of play with frames.<br><br>Frames aren't in HTML 4.01 Strict, they were moved into their own standard, HTML4.01 Frameset. With HTML5, they aren't being removed, they simply aren't being updated. With no updates, their version, standard and DTD are going to remain the same, namely HTML4.01 Frameset. <br>

<br>What you are actually arguing for therefore is the inclusion of all the elements of HTML4.01 Frameset into HTML5 Strict and HTML5 Transitional. As you seem to have no objection to how frames are handled in 4.01 it therefore seems odd that you are arguing for a radical change for them in HTML5.<br>

<br>As for people saying they are being 'removed' from HTML5, I see that as merely a colloquial use of the term and what they actually mean is 'With the HTML5 specification process, we aren't going to update the Frameset standard and as such this standard has been removed from our scope'. I think you can see why saying 'removed' is so much easier ;)<br>

<br>David Workman<br><br><div class="gmail_quote">2009/10/11 Peter Brawley <span dir="ltr"><<a href="mailto:pb@artfulsoftware.com" target="_blank">pb@artfulsoftware.com</a>></span><div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000">
Edouard,<div><br>
<pre>>Use case: displaying tree-based content (editable or not). (Note: I'm
>omitting the database aspect because it only matters on the server
>side: once on the client, the page doesn't care whether the data comes
>from/goes to a database, a collection of files, or anywhere else).
</pre></div>
I'm afraid that empties meaning from the use case, whose requirements
significant to this discussion arise from the database context: <br>
(i) the required page is a database maintenance webapp, <br>
(ii) the data it maintains is in the form of a tree, and <br>
(iii) the objects of database maintenance (rows in the database tables
which instantiate the tree) usually should not be bookmarkable for the
same reason other database webapps (eg phpMyAdmin) do not bookmark
database data---a bookmark belongs to a browser, but a row of database
table data belongs not to a browser but to users who may CRUD it, <i>and
access to such objects must not be shortcutted</i>. That is, database
maintenance in a webapp depends at least partly on protecting data from
some popular web mechanisms. If that offends HTML purists, or if this
use case conflicts with an "original" idea about the web, so be it. For
this context, HTML is just a device for getting useful things done on
the web while enforcing the rules of database maintenance.<div><br>
<pre>>First, let's look at what the currently existing solutions are: I may
>be missing some, but I hope the range is descriptive enough:
>A) <table>+<iframe>: This meets requirements 1, 2, and 5 out of the
>box. Requirement 3 could be achieved with some javascript.
>B) CSS position:fixed + overflow:auto: Again, this meets requirements
>1, 2, and 5. Requirement 3 would also be achievable with a bit of
>scripting.
>C) Insane <div>s + CSS + Scripting: This essentially meets all
>requirements (maybe excluding 4, depending on what the actual
>requirement is); although at a high development cost. (This would be
>the "MSDN style" approach.)
>D) HTML4 Frameset + HTML5 documents for frame contents: this meets
>requirements 1, 2, 3, and 5 out of the box, it's an almost trivial
>upgrade from any HTML4 web-app that takes a similar approach, and is
>relatively easy to implement.</pre></div>
Seems to me many developers would regard B & C as hacks. At they
very least they'd be more awkward than framesets. I think I've already
touched on why the MSDN approach is undesirable. You are not the first
to claim that A (tables & iframes) can meet this spec. I'm not an
HTML expert (which apparently frustrates you) but if A meets the spec,
I ought to have been able to find a working instance in the past six
years or so, don't you think? Or do you claim it's <i>entirely
fortuitous</i> that the only publicly well known solutions for this
spec use framesets? <br>
<br>
Re D), reasons for opposing removing framesets from HTML5 include: (i)
removal of a feature from a standard is often followed by further
degradation of support for it, which would undermine the functionality
I want HTML to support since framesets are commonly used, for good
reasons, to meet this use case, (ii) there could be HTML5 features one
would want to combine with framesets. <br>
<br>
Apropos the strange claims made here that removal of framesets should
make no difference to present or future frameset use: <i>if removal
makes no difference whatever, there is no rationale for removing them</i>.<br>
<br>
PB<br>
-----<br>
<br>
Eduard Pascual wrote:
<blockquote type="cite"><div><div></div><div>
  <pre>On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley <a href="mailto:pb@artfulsoftware.com" target="_blank"><pb@artfulsoftware.com></a> wrote:
  </pre>
  <blockquote type="cite">
    <pre>[lots...]
    </pre>
  </blockquote>
  <pre>Now, your last mail does describe the use-cases and their presumed
requirements. Your wording is maybe a bit messy, but you have at least
provided something worth discussing.
Just to make sure I (and others) are understanding your proposal as
intended, I'll try to paraphrase it in a more structured way (please,
if I got something wrong, just let me know):

Use case: displaying tree-based content (editable or not). (Note: I'm
omitting the database aspect because it only matters on the server
side: once on the client, the page doesn't care whether the data comes
from/goes to a database, a collection of files, or anywhere else).
Requirements:
1) The display will use multiple subwindows, such as "header",
"tree-view", and "content" (the names are arbitrary, hope they are
descriptive and concise).
2) The subwindows (or some of them) need to be independently scrollable.
3) The subwindows must be resizable.
4) The tree structure being displayed may be protected through some
permission mechanism, so each user only gets to see or interact with
the nodes such user has permissions for.
5) The "back button" and "bookmark" features shouldn't work.

So far, so good. Just if you had gone a bit further...
That's a use-case with a series of requirements. This is a good
beginning, but let's go to the next steps.
Requirement justification: you haven't provided any (it's the
requirements, not the use-case itself, what needs to be justified; a
use-case is inherently justified by the real-world needs it
addresses).
For requirements 1 to 3, I can assume as an implicit justification
something like "this is the behavior every user would expect" or
anything like that, so let's move forward.
For requirement 4, things are a bit weird: should authentication be
handled on the server or on the client side? It seems that it has to
be handled on the server side, so the nodes a user is not allowed to
see should never be sent to the client (otherwise, the user could look
at the source, hack through grease-monkey scripts, or override the
permission system in many ways). If it's handled by the server, then
it isn't relevant to HTML: HTML is a client-side language. If there is
some need to handle (part of) the authentication issue from the
client, you should provide more details and justify such need;
otherwise the requirement can just be omitted as it wouldn't be
relevant.
Requirement 5 does need some justification. In my opinion, there is no
need on your use case for these features (back button and bookmarks)
to work, but is there any real need for them to break? If there is,
please justify it; if there isn't, then that's not a requirement (it
would just be the absence of a requirement for these features to
work). Not needing them to work is *not* the same as needing them to
break.

Now, leaving aside the issues with the last two requirements, we can
move forward. The next step would be to see which requirements are met
by currently existing solutions, and which aren't. I will be ignoring
for now Requirement 4 because it's unclear what the actual requirement
would be.
First, let's look at what the currently existing solutions are: I may
be missing some, but I hope the range is descriptive enough:
A) <table>+<iframe>: This meets requirements 1, 2, and 5 out of the
box. Requirement 3 could be achieved with some javascript.
B) CSS position:fixed + overflow:auto: Again, this meets requirements
1, 2, and 5. Requirement 3 would also be achievable with a bit of
scripting.
C) Insane <div>s + CSS + Scripting: This essentially meets all
requirements (maybe excluding 4, depending on what the actual
requirement is); although at a high development cost. (This would be
the "MSDN style" approach.)
D) HTML4 Frameset + HTML5 documents for frame contents: this meets
requirements 1, 2, 3, and 5 out of the box, it's an almost trivial
upgrade from any HTML4 web-app that takes a similar approach, and is
relatively easy to implement.

Finally, once it is shown that currently existing solutions can't
handle the use-case (which hasn't been shown: C and D both can, and A
and B can as well if a bit of scripting is added to handle the
resizing requirement), it would only be left to verify that your
proposal actually meets the requirements. There is a problem here,
however: What is your proposal? I'm not sure why you haven't described
your proposal. If you want the editor to change the spec, it's quite a
good idea to describe the changes you want to be made on the spec.

In summary, what you need to do is:
1) Correct me if I made any mistakes when trying to synthesize your use-case.
2) Clarify and justify Requirement 4.
3) Justify Requirement 5.
4) Describe your proposal.
5) Show how does your proposal meet all of the requirements for the use-case.

As far as this has gone, my impression is that you want a HTML5
Frameset document type that is exactly identical to the HTML 4
version. It is pointless to "update" a version of a standard to a new
version that includes no changes at all.
Keep in mind that Frameset and content are two different document
types, with different content models (for example, a frameset page has
no <body>). HTML5 currently replaces/updates the Transitional/Strict
document types; it doesn't deal with Frameset because nothing is being
changed on it, so HTML4 Frameset stays valid as the "newest" (despite
its age) standard for frameset "master" pages.

Regards,
Eduard Pascual</pre>
  </div></div><pre><hr width="90%" size="4"><div>

No virus found in this incoming message.
Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a></div> 
Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 06:39:00

  </pre>
</blockquote>
</div>

</blockquote></div></div></div><br>
</blockquote></div><br>