[whatwg] framesets

Thu Oct 15 05:43:53 PDT 2009

 	<Pine.LNX.4.62.0910130924420.25383 at hixie.dreamhostps.com> 

 	<4AD4A1EB.8080102 at artfulsoftware.com>

 	<Pine.LNX.4.62.0910132224110.6803 at hixie.dreamhostps.com> 

 	<4AD5438D.3090407 at artfulsoftware.com>

 	<98038259-77F7-42FD-8A4A-097BB3E9EA3B at dartmouth.edu> 

 	<4AD57761.4060905 at artfulsoftware.com>

 	<5ccfb3340910140023s65dbb96bq988b96b55707aa1d at mail.gmail.com> 

 	<4AD5F4A5.2040204 at artfulsoftware.com>

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

Nelson wrote:

There is a specific use-case (that has nothing to do with databases
> or bookmarking) that framesets solve better out-of-the box right now
> in most browsers: that of a panel-based layout that allows resizing
> and maintains UI state without flickering whilst loading content in
> different panel

 As an aside, there is a reason why AJAX has become so popular over the
> past few years: it solves the specific UI-reset issue that is inherent
> in full-page refreshes. Maybe there is room for a better,
> standard-based approach to solving this issue, but framesets ain't it.

I totally agree.

I think the described case is the main flow in web applications.
I think most web applications have exactly this panel based layout, where navigation loads only a some of the panels.
I think they all use AJAX. Iframes are very unpopular, and as you say AJAX is the best current solution.

I think there should be a standard based solution because:

1.Even when using libraries like prototype, AJAX does take some coding. Why should I use so much code for such a simple, main flow use case?

2.By looking at browsers code I see there is a lot of clever stuff going on when loading/unloading a document.
In the AJAX based solution this happens only once in the application life cycle.
It seems to me that dedicating a special syntax to navigation would help browsers to test the application main flow.

Tali

----------------------------------------
> From: flying.mushroom at gmail.com
> Date: Thu, 15 Oct 2009 09:49:58 +0200
> To: pb at artfulsoftware.com
> CC: whatwg at whatwg.org
> Subject: Re: [whatwg] framesets
>
> Wow, what a tour de force; 78 messages and no progress.
>
> Peter, I believe the only reason the discussion has carried so far is
> because you are, actually, on to something. You just don't seem very
> aware that people are actually trying to pin down and solve the
> "something" and keep banging on about framesets being the cure-all,
> whilst ignoring other points.
>
> Here's (yet another) summary:
>
> 1) Framesets have been deprecated for quite a long time. The reasons
> for the deprecation have been repeated ad nauseam, and very solid.
>
> 2) There is a specific use-case (that has nothing to do with databases
> or bookmarking) that framesets solve better out-of-the box right now
> in most browsers: that of a panel-based layout that allows resizing
> and maintains UI state without flickering whilst loading content in
> different panels (this is, I believe, the "something" you're getting
> at).
>
> 3) There are HTML5-conformant solutions available right now that allow
> you to replicate the above scenario with a little more work. The
> iframes solution with a bit of JS [1] [2] for handling the resizing is
> probably the easiest to implement, although an analogous solution with
> AJAX is probably the best available (which allows for deep-linking
> when this is desirable and doesn't automatically break bookmarking).
> You can also (if you wish) break bookmarking/the back button with
> these solutions, especially the AJAX one. There is also the CSS
> position: fixed solution that will be adequate for a large number of
> scenarios, or can complement the other two.
>
> 4) As repeated many times, you don't have to use HTML5. Keep using
> HTML 4 Frameset [3] if you insist on using the frameset solution and
> care about validation. The documents within each frame can be HTML5.
> Or use HTML5 with framesets -- it won't validate but is guaranteed (by
> the spec) to work. Do expect to run into the usability problems
> inherent to frames, though.
>
> 5) There is a known need for CSS to handle the above panel resizing
> use-case. That is a first-class CSS problem; don't expect the HTML
> spec to address that, especially not with a mechanism (framesets) that
> has many drawbacks and is deprecated for good reasons. For immediate
> solutions, see 3) and 4) above.
>
> 6) For clarity sake, I'll repeat the point made several times:the
> bookmarking/navigation/security issue is *not* solved by framesets,
> and the slight hack to make this work (javascript's "replace") as you
> suggest is neither exclusive to framesets nor (in the case of
> security) acceptable.
>
> As an aside, there is a reason why AJAX has become so popular over the
> past few years: it solves the specific UI-reset issue that is inherent
> in full-page refreshes. Maybe there is room for a better,
> standard-based approach to solving this issue, but framesets ain't it.
>
> [1] http://methvin.com/splitter/4psplitter.html
> [2] http://developer.yahoo.com/yui/examples/layout/page_layout.html
> [3] http://www.w3.org/TR/html4/sgml/framesetdtd.html
>
> Nelson Menezes
> http://fittopage.org
>
>
> 2009/10/14 Peter Brawley 
>>
>> Rimantas,
>>
>>>Maybe there are not many sites because nobody wants this type of sites?
>>
>> You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years.
>>
>> The full use case is treeview database maintenance. Tree logic has been slow to mature in SQL, is non-trivial in HTML as we see, and is hard to generate from PHP/Ruby/whatever.
>>
>>>I hate this type of documentation sites personally.
>>
>> Fine, you've no need for website maintenance of data-driven trees. That's not a rationale for excluding framesets from HTML5.
>>
>>> And to me this use case looks built around the chosen implementation,
>>
>> Wrong. Frameset was chosen because it provides the most efficient available implementaiton.
>>
>>> while I prefers solutions built around solving the real need.
>>
>> Which this is.
>>
>>>So you want HTML5 spec tailored for this particular case of yours?
>>>Can I have  tag, please?
>>
>> May I have rational responses please? This is not a request for a new feature. I want HTML5 to continue support for useful HTML.
>>
>>>Nobody forbids you from using previous versions of HTML.
>>
>> Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature.
>>
>> PB
>>
>> -----
>>
>> Rimantas Liubertas wrote:
>>
>> So it does not answer the question: if framesets are as you claim not needed
>> for the full spec, there should be lots of non-frameset sites which meet
>> this spec as efficiently as ours does.
>>
>>
>> Maybe there are not many sites because nobody wants this type of sites?
>> I hate this type of documentation sites personally.
>> And to me this use case looks built around the chosen implementation,
>> while I prefers solutions built around solving the real need.
>>
>>
>>
>> If that blocks a use case, by all means don't use a frameset for it. For
>> this use, the above poses no problem at all. And if CSS were actually as
>> efficient for this spec as framesets, surely some developers would have
>> taken advantage of that by now.
>>
>>
>> Once again you assume that your spec is highly desired. Maybe it is not
>> the case and so nobody bothered.
>>
>> <…>
>>
>>
>> No need in this case.
>>
>>
>> <…>
>>
>>
>> Not an issue for this use.
>>
>>
>> So you want HTML5 spec tailored for this particular case of yours?
>> Can I have  tag, please?
>>
>>
>>
>> Here's an application for framesets which is valid on previous versions of
>> HTML,
>>
>>
>> Nobody forbids you from using previous versions of HTML.
>>
>>
>>
>> meets a need, is more efficient than known implemented alternatives
>> for this use case,
>>
>>
>> You have framed (pardon the pun) this use case this way and reject all
>> other options. Once again—you can use HTML4.01 frameset document
>> with HTML5 documents loaded to frames. This was suggested more
>> than once.
>>
>>
>>
>> and does not suffer from any of the frameset deficiencies
>> you have listed.
>>
>>
>> How so?
>>
>>
>>
>> Framesets remain useful, excluding them from HTML5
>> undermines support for those uses, and that weakens HTML5.
>>
>>
>> I'd argue that it strengthens HTML5.
>>
>> Regards,
>> Rimantas
>> --
>> http://rimantas.com/
>>
>> ________________________________
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>>
>> Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09 06:33:00
>>
>>

_________________________________________________________________
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