[whatwg] framesets

[David Workman]

Oops, only sent this to one recipient earlier.

2009/10/11 David Workman <workmad3 at gmail.com>

> Peter,
>
> From reading this discussion, I think you've slightly missed a salient
> point with regards to the current state of play with frames.
>
> 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.
>
> 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.
>
> 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 ;)
>
> David Workman
>
> 2009/10/11 Peter Brawley <pb at artfulsoftware.com>
>
>  Edouard,
>>
>> >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).
>>
>> I'm afraid that empties meaning from the use case, whose requirements
>> significant to this discussion arise from the database context:
>> (i) the required page is a database maintenance webapp,
>> (ii) the data it maintains is in the form of a tree, and
>> (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, *and access to
>> such objects must not be shortcutted*. 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.
>>
>> >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.
>>
>> 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 *entirely fortuitous* that the only publicly
>> well known solutions for this spec use framesets?
>>
>> 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.
>>
>> Apropos the strange claims made here that removal of framesets should make
>> no difference to present or future frameset use: *if removal makes no
>> difference whatever, there is no rationale for removing them*.
>>
>> PB
>> -----
>>
>> Eduard Pascual wrote:
>>
>> On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley <pb at artfulsoftware.com> <pb at artfulsoftware.com> wrote:
>>
>>
>>  [lots...]
>>
>>
>>  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
>>
>> ------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>>
>> Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 06:39:00
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091011/4ea1fe27/attachment-0001.htm>