Framed

22 April 2004

16 comments

A Blue Perspective: Framed

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.

Categories

, ,

Comments

  1. 1/16

    Hasan commented on 22 April 2004 @ 09:29

    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. 2/16

    The Man in Blue commented on 22 April 2004 @ 10:42

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

  3. 3/16

    Simon Jessey commented on 22 April 2004 @ 20:55

    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. 4/16

    The Man in Blue commented on 22 April 2004 @ 22:05

    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. 5/16

    sn commented on 22 April 2004 @ 23:56

    "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. 6/16

    Simon Jessey commented on 23 April 2004 @ 00:58

    -- 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. 7/16

    The Man in Blue commented on 23 April 2004 @ 01:03

    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. 8/16

    The Man in Blue commented on 23 April 2004 @ 01:06

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

    You could just call 2Advanced.

  9. 9/16

    Anne commented on 23 April 2004 @ 03:23

    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. 10/16

    Jennifer Grucza commented on 23 April 2004 @ 05:08

    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. 11/16

    Michael Koukoullis commented on 23 April 2004 @ 08:53

    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. 12/16

    Jennifer Grucza commented on 23 April 2004 @ 09:12

    "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. 13/16

    Michael Koukoullis commented on 23 April 2004 @ 10:55

    "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. 14/16

    Unearthed Ruminator commented on 23 April 2004 @ 21:47

    "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. 15/16

    Richard Rutter commented on 27 April 2004 @ 18:57

    "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/16

    Ye Chen commented on 24 June 2004 @ 00:15

    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.

  17. Leave your own comment

    Comments have been turned off on this entry to foil the demons from the lower pits of Spamzalot.

    If you've got some vitriol that just has to be spat, then contact me.

Follow me on Twitter

To hear smaller but more regular stuff from me, follow @themaninblue.

Monthly Archives

Popular Entries

My Book: Simply JavaScript

Simply JavaScript

Simply JavaScript is an enjoyable and easy-to-follow guide for beginners as they begin their journey into JavaScript. Separated into 9 logical chapters, it will take you all the way from the basics of the JavaScript language through to DOM manipulation and Ajax.

Step-by-step examples, rich illustrations and humourous commentary will teach you the right way to code JavaScript in both an unobtrusive and an accessible manner.

RSS feed