- From: tali garsiel <t_garsiel@hotmail.com>
- Date: Sat, 10 Oct 2009 22:15:35 +0000
<7c2a12e20910091119j2e527fc7x3e50e668342a92a8 at mail.gmail.com> <4ACF873D.6000308 at artfulsoftware.com> <4ACF8B51.80507 at mit.edu> <4ACF9E08.1020606 at artfulsoftware.com> <a9699fd20910091521p5d4bdd19l118e9699cbf742f7 at mail.gmail.com> <4ACFCB99.1040306 at artfulsoftware.com> <6ea53250910091718md017d92xe32e244fca3343b6 at mail.gmail.com> <4AD009B2.9040904 at artfulsoftware.com> <6ea53250910101207l3c190722he405b983fc7ba78e at mail.gmail.com> Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 I agree with Peter that this type of document navigation is an extremely common use case. I think the use case includes navigation that loads only parts of the page, leaving the other parts static. Almost all web applications I know have tabs on top and a tree on the left. The idea is not repainting the tabs/tree etc on every click to keep a good user experience. On the old days frames were used, then a tables + iframes. Then iframes where considered bad design and I think most applications use divs + css + Ajax. In my experience this is not good either and causes serious performance issues. I think its called "single page design" where the browser is never told to unload a document and reload another but just to keep updating the DOM using Ajax with huge chunks of HTML. I think its important that the W3C specification should provide a good solution for this common case. Regards, Tali ---------------------------------------- > From: herenvardo at gmail.com > Date: Sat, 10 Oct 2009 21:07:42 +0200 > To: pb at artfulsoftware.com > CC: whatwg at whatwg.org; t.broyer at gmail.com; bzbarsky at mit.edu > Subject: Re: [whatwg] framesets > > On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley 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) +: This meets requirements 1, 2, and 5 out of the<br />> box. Requirement 3 could be achieved with some javascript.<br />> B) CSS position:fixed + overflow:auto: Again, this meets requirements<br />> 1, 2, and 5. Requirement 3 would also be achievable with a bit of<br />> scripting.<br />> C) Insane <div>s + CSS + Scripting: This essentially meets all<br />> requirements (maybe excluding 4, depending on what the actual<br />> requirement is); although at a high development cost. (This would be<br />> the "MSDN style" approach.)<br />> D) HTML4 Frameset + HTML5 documents for frame contents: this meets<br />> requirements 1, 2, 3, and 5 out of the box, it's an almost trivial<br />> upgrade from any HTML4 web-app that takes a similar approach, and is<br />> relatively easy to implement.<br />><br />> Finally, once it is shown that currently existing solutions can't<br />> handle the use-case (which hasn't been shown: C and D both can, and A<br />> and B can as well if a bit of scripting is added to handle the<br />> resizing requirement), it would only be left to verify that your<br />> proposal actually meets the requirements. There is a problem here,<br />> however: What is your proposal? I'm not sure why you haven't described<br />> your proposal. If you want the editor to change the spec, it's quite a<br />> good idea to describe the changes you want to be made on the spec.<br />><br />> In summary, what you need to do is:<br />> 1) Correct me if I made any mistakes when trying to synthesize your use-case.<br />> 2) Clarify and justify Requirement 4.<br />> 3) Justify Requirement 5.<br />> 4) Describe your proposal.<br />> 5) Show how does your proposal meet all of the requirements for the use-case.<br />><br />> As far as this has gne, my impression is that you want a HTML5<br />> Frameset document type that is exactly identical to the HTML 4<br />> version. It is pointless to "update" a version of a standard to a new<br />> version that includes no changes at all.<br />> Keep in mind that Frameset and content are two different document<br />> types, with different content models (for example, a frameset page has<br />> no <body>). HTML5 currently replaces/updates the Transitional/Strict<br />> document types; it doesn't deal with Frameset because nothing is being<br />> changed on it, so HTML4 Frameset stays valid as the "newest" (despite<br />> its age) standard for frameset "master" pages.<br />><br />> Regards,<br />> Eduard Pascual<br /> _________________________________________________________________ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009
Received on Saturday, 10 October 2009 15:15:35 UTC