- From: Eduard Pascual <herenvardo@gmail.com>
- Date: Sat, 10 Oct 2009 21:07:42 +0200
On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley <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
Received on Saturday, 10 October 2009 12:07:42 UTC