[whatwg] framesets

Sat Oct 10 15:15:35 PDT 2009

 	<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 gone, 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