[whatwg] framesets

 	<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.


> 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&lt;br /&gt;&gt; box. Requirement 3 could be achieved with some javascript.&lt;br /&gt;&gt; B) CSS position:fixed + overflow:auto: Again, this meets requirements&lt;br /&gt;&gt; 1, 2, and 5. Requirement 3 would also be achievable with a bit of&lt;br /&gt;&gt; scripting.&lt;br /&gt;&gt; C) Insane &lt;div&gt;s + CSS + Scripting: This essentially meets all&lt;br /&gt;&gt; requirements (maybe excluding 4, depending on what the actual&lt;br /&gt;&gt; requirement is); although at a high development cost. (This would be&lt;br /&gt;&gt; the "MSDN style" approach.)&lt;br /&gt;&gt; D) HTML4 Frameset + HTML5 documents for frame contents: this meets&lt;br /&gt;&gt; requirements 1, 2, 3, and 5 out of the box, it's an almost trivial&lt;br /&gt;&gt; upgrade from any HTML4 web-app that takes a similar approach, and is&lt;br /&gt;&gt; relatively easy to implement.&lt;br /&gt;&gt;&lt;br /&gt;&gt; Finally, once it is shown that currently existing solutions can't&lt;br /&gt&gt; handle the use-case (which hasn't been shown: C and D both can, and A&lt;br /&gt;&gt; and B can as well if a bit of scripting is added to handle the&lt;br /&gt;&gt; resizing requirement), it would only be left to verify that your&lt;br /&gt;&gt; proposal actually meets the requirements. There is a problem here,&lt;br /&gt;&gt; however: What is your proposal? I'm not sure why you haven't described&lt;br /&gt;&gt; your proposal. If you want the editor to change the spec, it's quite a&lt;br /&gt;&gt; good idea to describe the changes you want to be made on the spec.&lt;br /&gt;&gt;&lt;br /&gt;&gt; In summary, what you need to do is:&lt;br /&gt;&gt; 1) Correct me if I made any mistakes when trying to synthesize your use-case.&lt;br /&gt;&gt; 2) Clarify and justify Requirement 4.&lt;br /&gt;&gt; 3) Justify Requirement 5.&lt;br /&gt;&gt; 4) Describe your proposal.&lt;br /&gt;&gt; 5) Show how does your proposal meet all of the requirements for the use-case.&lt;br /&gt;&gt;&lt;br /&gt;&gt; As far as this has gne, my impression is that you want a HTML5&lt;br /&gt;&gt; Frameset document type that is exactly identical to the HTML 4&lt;br /&gt;&gt; version. It is pointless to "update" a version of a standard to a new&lt;br /&gt;&gt; version that includes no changes at all.&lt;br /&gt;&gt; Keep in mind that Frameset and content are two different document&lt;br /&gt;&gt; types, with different content models (for example, a frameset page has&lt;br /&gt;&gt; no &lt;body&gt;). HTML5 currently replaces/updates the Transitional/Strict&lt;br /&gt;&gt; document types; it doesn't deal with Frameset because nothing is being&lt;br /&gt;&gt; changed on it, so HTML4 Frameset stays valid as the "newest" (despite&lt;br /&gt;&gt; its age) standard for frameset "master" pages.&lt;br /&gt;&gt;&lt;br /&gt;&gt; Regards,&lt;br /&gt;&gt; Eduard Pascual&lt;br /&gt; 		 	   		  
Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?.

Received on Saturday, 10 October 2009 15:15:35 UTC