[whatwg] framesets

[tali garsiel]

 	<6ea53250910101207l3c190722he405b983fc7ba78e at mail.gmail.com> 

 	<BAY117-W2CC232231C30158F2FED583CA0 at phx.gbl>
 

 <6ea53250910101551x5239027end5fc1b52cea81bdd at mail.gmail.com>
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0



What I'm saying is based on my experience. I'v been involved in developement of large and complex web application for the last 9 years.

I know this discussion is getting too long but I believe it's because it touches a real problem.

Lets try to see where we disagree.

1. Tabs and tree menu navigation is very common in web applications.
Do you agree with that assumption?

Possible solutions for creating such navigation are:

1. Using one page + server side includes to repaint the navigation every time.
Not good.From my experience it burdens the server (it's not just images - its reading the XML that describes the tabs , calculating tree permissions , getting the whole tree data from the database etc) and causes a noticeable flicker.

2. Using frames - not good from the reasons you pointed out

3. Using iframes - not good from the same reasons

4. Using ajax - not good.From my experience browsers know how to load documents and don't react well in a situation where there is one document and every screen is built by updating the DOM of this document.I think the tests browser do do not include such cases and its not how they are meant to act.

So - for an extremely common use case there is no solution at all.

Again , please specify where you disagree.

Solution - I don't have a detailed solution but I think that the applications outer structure should be described by special tags which will behave well with bookmarking and the back button.
In outer structure I mean the part of the layout that consistently appears in each screen.


Tali
 



----------------------------------------
> From: herenvardo at gmail.com
> Date: Sun, 11 Oct 2009 00:51:53 +0200
> To: t_garsiel at hotmail.com
> CC: pb at artfulsoftware.com; t.broyer at gmail.com; bzbarsky at mit.edu; whatwg at whatwg.org
> Subject: Re: [whatwg] framesets
>
> On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel  wrote:
>> 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.
> Peter's case is quite legitimate; I just asked for him to properly
> detail it so it can be properly discussed.
>
> Your reference to the "old days", however, scares me a bit: on the
> "old days" there weren't many web applications, only web pages. If you
> are trying to argue for sites (made of pages or documents) that use
> s to keep the menus and headers static, I must stronly
> oppose that: while neglecting the "back button", "bookmarking" and
> "deep-linking" features inherent to the web may be acceptable for some
> specific applications, this is absolutely a bad idea for "classic"
> pages: these elements do not take that much to load (and, if they use
> images, the browser will have them cached anyway), and all other
> advantages of using frames in this scenario (such as maintaining a
> single instance of the menu) are far better handled through
> server-side solutions such as "includes". Being unable to deep-link to
> (or bookmark) a specific page on a site is a serious drawback; hence
> any site that considers breaking such capabilities must accurately
> weight the cost of the drawback against the value of the benefits it
> expects to achieve from it.
> If you have specific use-cases for Peter's proposal, you're welcome to
> bring them forward... oh, wait... what's Peter's proposal?
>
>> I think its important that the W3C specification should provide a good solution for this common case.
> You know, solutions don't come out of thin air: they are proposed by
> contributors to the lists like you, or me, or anyone else here. If you
> know the cases you want to have addressed, then I strongly encourage
> you to suggest a solution. The same advise I gave Peter applies: make
> sure to describe the use-cases you are addressing, detailing the
> requirements (and justifying them when they aren't 100% obvious),
> showing where current solutions fail, and showing that your proposal
> meets all the requirements.
>
> Honestly, I don't think that this process is ideal, but it's the way
> things are normally done here, and I can't think of a better process
> (otherwise I'd bring it forward). Some discussion on the abstract can
> be useful, but at the end of the day, only solutions that address
> use-cases and meet requirements make it into the spec.
>
> Finally, let me insist on a small detail that seems to go unnoticed
> regardless of how many times it has been repeated in the last hours:
> HTML5 updates/replaces the Transitional and Strict doctypes of HTML4.
> HTML4 Frameset isn't being updated as of now, and it stays valid,
> legitimate, and current. Using a HTML4 Frameset master page that shows
> HTML5 documents on its frames is valid and conformant. In addition,
> this seems to address all the use-cases that have been put forward (at
> least, it addresses all the ones HTML4 Frameset + HTML4 inside frames
> could address).
> What is being asked for? What do you (and/or Peter) want to be changed
> on the spec, and why? If nobody answers this, there is very little
> hope this discussion will go anywhere.
>
> Regards,
> Eduard Pascual
 		 	   		  
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
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_5:092010