<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tali,<br>
<br>
Not sure whom you're asking, but my take is yes there's no good
solution but the frameset is the least worst I've found so far.<br>
<br>
PB<br>
<br>
-----<br>
<br>
tali garsiel wrote:
<blockquote cite="mid:BAY117-W41FE6CA39118577E6984BE83CA0@phx.gbl"
type="cite">
<pre wrap=""> <a class="moz-txt-link-rfc2396E" href="mailto:6ea53250910101207l3c190722he405b983fc7ba78e@mail.gmail.com"><6ea53250910101207l3c190722he405b983fc7ba78e@mail.gmail.com></a>
<a class="moz-txt-link-rfc2396E" href="mailto:BAY117-W2CC232231C30158F2FED583CA0@phx.gbl"><BAY117-W2CC232231C30158F2FED583CA0@phx.gbl></a>
<a class="moz-txt-link-rfc2396E" href="mailto:6ea53250910101551x5239027end5fc1b52cea81bdd@mail.gmail.com"><6ea53250910101551x5239027end5fc1b52cea81bdd@mail.gmail.com></a>
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
----------------------------------------
</pre>
<blockquote type="cite">
<pre wrap="">From: <a class="moz-txt-link-abbreviated" href="mailto:herenvardo@gmail.com">herenvardo@gmail.com</a>
Date: Sun, 11 Oct 2009 00:51:53 +0200
To: <a class="moz-txt-link-abbreviated" href="mailto:t_garsiel@hotmail.com">t_garsiel@hotmail.com</a>
CC: <a class="moz-txt-link-abbreviated" href="mailto:pb@artfulsoftware.com">pb@artfulsoftware.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:t.broyer@gmail.com">t.broyer@gmail.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:bzbarsky@mit.edu">bzbarsky@mit.edu</a>; <a class="moz-txt-link-abbreviated" href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a>
Subject: Re: [whatwg] framesets
On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
<blockquote type="cite">
<pre wrap="">I think its important that the W3C specification should provide a good solution for this common case.
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
<a class="moz-txt-link-freetext" href="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">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</a></pre>
<pre wrap="">
<hr size="4" width="90%">
No virus found in this incoming message.
Checked by AVG - <a class="moz-txt-link-abbreviated" href="http://www.avg.com">www.avg.com</a>
Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 06:39:00
</pre>
</blockquote>
</body>
</html>