[whatwg] framesets

 	<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


Here is my suggestion - adding a "type" and "navigation-state" attributes to frameset in order for bookmarking , deep linking and back button to work.

Something like:

<frameset type="navigation" navigation-state="1">? //here I put my tabs
<frameset type="navigation" navigation-state="1">? //here I put the menu
?? <frame type="content">? //the content
</frameset>
</frameset>

The browser will keep a match between the navigation-state of the navigation frames and the URL of the content frame.

use case:
The user clicks a tab - the "navigation-state" will change using JavaScript? from "1" to "2, the "content" frame is reloaded.
The user clicks the "bookmark" button.
The browser puts in the bookmark storage the new content URL + the new state.

When the bookmark is invoked the browser loads tabs and menu frames and exposes the navigation state to them.It also loads the content with the new URL.
The tabs frame uses the state information to display the correct tab using JavaScript.
Something like history.navigationState.

The tab and menu frames might be in different navigation states.
There can be a combination of tabs in state "1" , tree in state "2" , content URL is x.
The browser will remember the combination when bookmarking.

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

Received on Saturday, 10 October 2009 18:00:48 UTC