Framesets/Frames

[JAB Creations]

A site with music shouldn't be forced to have it's music be played in a separate tab or window. That's personal preference and horridly bad design just as pop-ups are. Not even considerable reasons to drop frames.

[lyosha]

A site with music shouldn't be forced to have it's music be played in a separate tab or window. That's personal preference and horridly bad design just as pop-ups are. Not even considerable reasons to drop frames.

HTTP was designed with each request being completely independent and stateless, so that design does make sense from that point of view.

Frames are essentially different pages, just like tabs, but the trade-offs of frames is more than that of another tab or window.

If you must have it play continuously when a person is navigating in one window, then you can implement AJAX navigation like Gmail and then the it will essentially be just one page and achieve the same effect, but that solution will suffer from the same problems as frames except for slightly better navigation being possible.

All in all, I don't see this is a valid use case: music on a page should be optional and so should having it play continually; which means if a person so chooses, he/she can do what's necessary for that (open a new tab). Navigation should be stateless, and frames is a horrible workaround for trying to make it otherwise.

That said, browsers will continue supporting frames for a long time to come, so there's no need to worry. If you wish to make framed websites that play music continually while people are navigating, you still can. Just don't expect it to be liked by your visitors.

[pzbrawl]

> Well, background music, just like frames, is bad, IMHO

Oy. What sane adult would willingly give over to W3C the power to determine what's "good" and "bad" on a web page!?

Evidently frames are inconvenient for certain business activities, like searches paid for and driven by advertising. That is not a reason to deprecate frames. The internet is about more than business.

Frames are terrific for browsing and editing trees and their details. The tree in one frame, editable detail in another, all controlled by a header frame. We use such pages for many purposes. Even if we wanted to host from Windows (which we don't), to accomplish the same effect in ASP takes about ten times as much code.

If frames do not solve your design problem, don't use them. But don't cripple HTML5!

[zcorpan]

If you want HTML5 to allow framesets, then you'll probably have to provide use cases for which using <iframe> or other means are not sufficient.

[pzbrawl]

> If you want HTML5 to allow framesets, then you'll probably have to provide use cases for which using <iframe> or other means are not sufficient.

Here are two.

Use case #1:

We use a frameset in a web browser for maintenance of trees in (MySQL) databases. For an example of what it looks like, look at online MSDN documentation. We do NOT wish to have to host this on a Windows server.

The trees typically have thousands of items. Top frame has a header and a search control. Below it, the left frame scrolls the tree autonomously, cannot be closed, can be widened. Within it, user may open up or close the whole tree or part of it, may select/create/edit/delete,cut/paste nodes. Right frame shows detail content for the tree node currently selected in the left frame, and offers editing of that content.

So far I have not seen a way for iframes to provide this functionality.

Use case #2:

A questionnaire with hundreds of items, live header info, summary stats and ancillary info (including help) in one frame, independently scrolling question/answer controls in the other.

This might be somewhat doable with <iframes> but it appeared to us we would lose some desirable aspects of our interface.

A general comment: Willingness to declare certain web interfaces "bad" strongly suggests that a weird nanny/religious mentality has taken hold--inappropriately--in the W3C community. It echoes previous codiong "religions" (eg dynamic typing used to be "bad"; so did non-OO coding). There are no "bad" interfaces. Interfaces do and don't meet their requirements, is all.

[JAB Creations]

If you want HTML5 to allow framesets, then you'll probably have to provide use cases for which using <iframe> or other means are not sufficient.

Browsing pages without the music being interrupted, like I said before.

Before and after comparison of pages, revisions, etc.

I'm sure with enough time I could come up with an lengthy list.

[pzbrawl]

A poster wrote:

A site with music shouldn't be forced to have it's music be played in a separate tab or window. That's personal preference and horridly bad design just as pop-ups are. Not even considerable reasons to drop frames.

and Lyosha replied:

HTTP was designed with each request being completely independent and stateless, so that design does make sense from that point of view.

Good grief. HTML statelessness is just historical accident. Database-driven web pages must be stateful.

[lyosha]

While it is fully possible to create those interfaces (in a better way, IMO) with iframes, css (overflow:auto), ajax, etc., if you really want frameset so bad, what's preventing you from embedding html 5 documents in a frames page?

<html>

<frameset cols="25%,*">
<frame src="/nav" />
<frame src="/content/can/be/in/html/5/and/still/valid" />
</frameset>

</html>

BTW, I'm not the W3C, I'm just one guy.

[pzbrawl]

While it is fully possible to create those interfaces (in a better way, IMO) with iframes, css (overflow:auto), ajax, etc.,

Got a few working sites to show me?

if you really want frameset so bad,

Why would I bother to make the case for them if I didn't "really" want to use them?

what's preventing you from embedding html 5 documents in a frames page?

There's too much to do to waste time re-architecting something that has been working just fine for years, just because some W3C people got religion about frames.

[lyosha]

what's preventing you from embedding html 5 documents in a frames page?

There's too much to do to waste time re-architecting something that has been working just fine for years, just because some W3C people got religion about frames.

Uh... if you don't want to bother with HTML 5 at all, why complain about it in the first place? Nobody is forcing you to rework anything.

I've said this before, but I'll repeat it for those who don't read but come only to rant:
Browsers will still support frames pages when HTML 5 becomes the standard. Frames pages will just not be valid HTML 5, but they will still render.

You just won't be able to stick a |valid html 5 frameset page| badge on it, but that shouldn't bother you since you can't put anything on a frames page anyways.

[JAB Creations]

lyosha, we're removing anchors from HTML5; you can still use them on your site, but it won't be valid.

[pzbrawl]

Uh... if you don't want to bother with HTML 5 at all, why complain about it in the first place? Nobody is forcing you to rework anything.

Eh? Obviously the objection is not to the whole of HTML5. A feature we depend on is being removed. If you're going to respond, read more carefully.

Declaring background music or frames "bad" is idiotic. Removing working features from HRML5 is idiotic.

You asked for use cases. Three have been outlined here. I asked you to cite a website which implements what I'm talking about without frames or tens times as much ASP code. Evidently you cannot.

What would be helpful is info on how to convey this to those who are making these decisions.

[lyosha]

You can make a valid HTML 4 frameset page that embeds valid HTML 5 documents in the frames. There's nothing to rework if you choose not to. The only thing you would need to change in an existing HTML 4 application is the pages inside the frames and leave the frameset page alone. "What's wrong with that?" is what my question was. You then said it would require to rework everything. Obviously we weren't on the same page.

I can show you some websites, but I didn't want to throw just anything out there, that's why I didn't post any websites yet. I personally don't find the need to use frames, but I have used two types of frame-like behavior in a few web applications. Only one is public so far, and it's an AJAX navigation example I made back in 2004: http://chudosok.detyabozhye.com This approach would allow for continual background music while navigating. With a little CSS, you can emulate frames style scrolling as well.

I also gather you're not very proficient with server-side technology. There are ways to do this without any server-side scripting, but server-side scripting is very helpful in this, as well many other things. Plus, there are far more technologies than ASP, many of which are arguably simpler to use to do many things including help emulate frames.

You can contact "those who are making these decisions" on the mailing list. To be honest though, I doubt you will make anyone change their mind. While you won't be persecuted for using frames, it is highly discouraged because the drawbacks outweigh the benefits, and including frames in the spec would achieve the opposite effect.

[lyosha]

lyosha, we're removing anchors from HTML5; you can still use them on your site, but it won't be valid.

No, anchors aren't going anywhere, just the name attribute for the a element is going. Instead of writing:

Code: Select all

<h1><a name="foo">Foo</a></h1>

You can write:

Code: Select all

<h1 id="foo">Foo</h1>

If you want to use the a element however you still can:

Code: Select all

<h1><a id="foo">Foo</a></h1>

All fully valid and currently working with no problems.

[zcorpan]

Here are two.

Use case #1:

We use a frameset in a web browser for maintenance of trees in (MySQL) databases. For an example of what it looks like, look at online MSDN documentation. We do NOT wish to have to host this on a Windows server.

The trees typically have thousands of items. Top frame has a header and a search control. Below it, the left frame scrolls the tree autonomously, cannot be closed, can be widened. Within it, user may open up or close the whole tree or part of it, may select/create/edit/delete,cut/paste nodes. Right frame shows detail content for the tree node currently selected in the left frame, and offers editing of that content.

Is the "can be widened" essential to your use case? If not, it seems it should be possible to have the header be part of the page, the left frame be an <iframe> and the right frame be an <iframe>, too, with CSS to give them the right size and position.

Use case #2:

A questionnaire with hundreds of items, live header info, summary stats and ancillary info (including help) in one frame, independently scrolling question/answer controls in the other.

This might be somewhat doable with <iframes> but it appeared to us we would lose some desirable aspects of our interface.

What aspects?

A general comment: Willingness to declare certain web interfaces "bad" strongly suggests that a weird nanny/religious mentality has taken hold--inappropriately--in the W3C community. It echoes previous codiong "religions" (eg dynamic typing used to be "bad"; so did non-OO coding). There are no "bad" interfaces. Interfaces do and don't meet their requirements, is all.

There has always been things in HTML that have been declared as "bad" in the HTML specs. For example, the IIIR HTML draft declares the <plaintext> element as "bad". Framesets were declared as "bad" in the HTML spec that introduced them, too.