t_garsiel at hotmail.com
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"
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:
> 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).
> 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
> 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
> 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
> 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:
Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail®.
More information about the whatwg