Page style:

A Blue Perspective: Framed

Framed
22 April 2004

I was having a look around Alex's tutorial for replacing frames with CSS divs, and I couldn't help but be curious as to "why?"

Frames (and even their preferred counterparts, iframes) have held a much maligned position in Web design for a few years now, mainly due to overuse in bygone eras (a role which tables have now begun to fill). But they do have some advantages that aren't captured by simply using the overflow: property. They're still present in Standards, whether you want to use XHTML 1.0 Frameset or the futuristic XFrames.

The idea behind frames is more than just the visual independence which is allowed by using CSS, it is also an independence of the data within each pane. Although the data in panes can and usually is related, reloading one pane does not cause the other to reload. This allows you to separate data and minimise data processing, retrieval and storage – something which cannot be done with static elements on one page, no matter how you present it visually.

To me, this is the key advantage in using frames – the ability to manipulate data in one pane, and effect changes in another while maintaining a consistent visual interface. This goes beyond merely using frames for navigation and allows for server calls and updates of data. Something which cannot be achieved with a static page.

Presenting a single document as if it were framed also introduces burdens on the user. Although frames have fallen out of vogue, most Internet users would probably be aware of them and how they work. By presenting a document as if it were framed, people expect the behaviour of frames, which they are not going to get with a bunch of divs.

So, although I applaud Alex's achievements in the layout of scrolling elements, I'd urge you to consider why you need to use frames in the first place and not shy away from using them when their application is warranted.

Comments

1/16. 22 April 2004 @ 09:29, Hasan wrote:

I'll take a newbie stab at this...I thought the main reason frames were so maligned was they "freak out" a browsers back button, so what if you wanted the frame "look" but not the lack of usability that comes with it? Does that make any sense?

2/16. 22 April 2004 @ 10:42, The Man in Blue wrote:

The back button works fine with most modern browsers and frames, I'm not sure that a CSS one does.

3/16. 22 April 2004 @ 20:55, Simon Jessey wrote:

Incredible as it may seem, I found another use for frames the other day. Fortunately, I was able to convince the client that it was a bad idea, so I avoided it.

She wanted to have (excuse me while I puke) background music playing on her site, uninterrupted by navigation. I discovered that the only easy way to do this was to have an invisible frameset, with the background sound associated with the frameset-containing page.

Fortunately, I was able to convince the client to drop the idea, on the basis that she couldn't navigate her site on her PDA.

4/16. 22 April 2004 @ 22:05, The Man in Blue wrote:

Why does she need the site to function properly on her PDA? She can just jack in some headphones and bliss out to the music. ;o]

5/16. 22 April 2004 @ 23:56, sn wrote:

"most Internet users would probably be aware of them and how they work"

You are too optimistic. :)

Maybe "modern browsers" now how to handle the back button when using frames. But *printing* pages with frames is still "impossible", the output is not the expected.

But the greatest drawback of using frames is the loss of "permaURLs".

Funny that the last time that I had to use frames was because the client wanted music on his site, playing without interruption. :)

6/16. 23 April 2004 @ 00:58, Simon Jessey wrote:

-- Funny that the last time that I had to use frames was because the client wanted music on his site, playing without interruption. :) --

The only other way I can think of doing this is to use a "pop-under", or something like that. I dunno whether that is better or worse!

7/16. 23 April 2004 @ 01:03, The Man in Blue wrote:

Agreed, frames do break some of the rules of web pages, but that's bound to happen when you are trying to model the complex interactions for which they are best suited.

I'd add that I've never personally thought of frames as a good avenue for any conventional Web content, and would consider them only useful in the case of a Web-based application -- something for which their functionality will be fully utilised and the user will take the time to learn.

In such scenarios, development of the "web page" becomes more akin to application development, as you then have to pay more attention to user interaction and functionality, such as printing.

8/16. 23 April 2004 @ 01:06, The Man in Blue wrote:

"The only other way I can think of doing this is to use a 'pop-under' ... "

You could just call 2Advanced.

9/16. 23 April 2004 @ 03:23, Anne wrote:

I'm not sure XFrames will ever happen. The specification is "filled" with errors and there isn't a lot of discussion about it either.

For web applications it is fine to use frames imo, since you can require things from your users. Web pages however shouldn't be build with frames. Caching has so much improved that the "visual effect" is almost the same with CSS build pages as it was with HTML frames.

The biggest problem is search engines and that it gets more difficult for disabled people to access the page (although those arguments probably have been overused).

10/16. 23 April 2004 @ 05:08, Jennifer Grucza wrote:

I agree that frames can be fine for web applications, where it can be undesirable for the user to be able to bookmark individual pages (like if they need to login to the application anyway, or if functionality is context-dependent).

Another use for an invisible frame is for asynchronous requests to the server. Sure, you could have your main frame refresh itself until the operation is complete, but the user could always navigate away from that. Plus it's clunky and ugly looking to see the window flashing every second or so as it refreshes. If you had an invisible frame refreshing itself, then when the operation was complete, that invisible frame could tell a visible frame to display some sort of alert to the user.

11/16. 23 April 2004 @ 08:53, Michael Koukoullis wrote:

Frames..I hate them...good theory but no good in the real world.

Boomarking is a pain.

Major search engines regularly link to pages within in a frameset. When you browse to them you dont see what the author intended i.e. the full frame set.

Frames can be useful for dealing with the statelessness of browsers, in 1999 we built an online education chat room through a browser that managed to mimic a real time client. In hindsight would never do that again, there are more elegant ways to do this nowadays.

12/16. 23 April 2004 @ 09:12, Jennifer Grucza wrote:

"When you browse to them you dont see what the author intended i.e. the full frame set."

Well, using javascript, you can detect this and redisplay the page with the whole frameset. Of course, for this to work, javascript needs to be enabled.

13/16. 23 April 2004 @ 10:55, Michael Koukoullis wrote:

"Well, using javascript, you can detect this and redisplay the page with the whole frameset. Of course, for this to work, javascript needs to be enabled."

99.9% of sites with frames don't use this javascript you mention. My point being frames just don't work in the real world because of mass abuse, frames have lost credibility.

14/16. 23 April 2004 @ 21:47, Unearthed Ruminator wrote:

"frames just don't work in the real world because of mass abuse, frames have lost credibility."

Which is why I only see them used on an internal web application I support (that could really stand to be rewritten, but that's besides the point).

15/16. 27 April 2004 @ 18:57, Richard Rutter wrote:

"frames just don't work in the real world because of mass abuse, frames have lost credibility."

Frames don't fail due to mass abuse, they simply make some common actions difficult or impossible; namely printing and bookmarking.

Frames tend to be used for three purposes; two bad, one good:

1) Bad: Frames used to keep something permanent while browsing the rest of the site, usually music. This is bad because it make bookmarking impossible (right-click aside). Could be better achieved with a pop-up window containing stop-start controls.

2) Bad: Frames used to keep the site logo and/or navigation constantly visible. Bad because it makes bookmarking, printing and deep linking difficult or impossible. The same effect is more usefully achieved with CSS, or not at all - lose the vanity, accept theat people will scroll and provide 'back to top' links.

3) Good: Frames used in applications, for example Webmail mimicking Outlook. This provides faster loading as only the relevent data is loaded, it enables more permament application 'states', a more familiar application-like feel. There is generally no need for bookmarking application screens, and printing is often a separate function in itself.

Frames *can* still be useful. (But still require invalid mark-up to remove frame borders cross-browser).

16/16. 24 June 2004 @ 00:15, Ye Chen wrote:

Frames don't work well with web apps where there is scoping involved such as using say struts on a jsp page. If you have data from a FormBean scoped to one frame page and you want the other frame to display some info from this bean the other frame page can't get the same state information and vice versa unless it's forced by a lot of javascript. However, for simpler pages I don't see the problem.

Post your own comments

Fields marked with an asterisk* are mandatory. All HTML tags will be escaped. http:// strings in comments will be auto-linked.




Archives