[whatwg] framesets

On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel <t_garsiel at hotmail.com> 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
<frameset>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

Received on Saturday, 10 October 2009 15:51:53 UTC