HTML: To Frame or not to Frame

Dan Burns asks: "I work in a large firm and manage the website there and our website uses Frames for navigation and a scrolling news ticker. A consultant has been hired to develop an add on to the site. The work that she is doing will not work in within the frame structure and she insists that frames have been deprecated in order to support her style of design. I could care less if the group she is creating this for wants it this way, but I question the statement that frames have been deprecated. Is there any justification to this statement or is she blowing smoke? "

From the w3c itself:

[MichaelH]

Looking at the list of new and deprecated elements [w3.org] carried in the w3c's [w3.org] specification for HTML 4, I see:

The following elements are deprecated: APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, STRIKE, and U.

and

The new elements in HTML 4.0 are: ABBR, ACRONYM, BDO, BUTTON, COL, COLGROUP, DEL, FIELDSET, FRAME, FRAMESET, IFRAME , INS, LABEL, LEGEND, NOFRAMES , NOSCRIPT, OBJECT, OPTGROUP, PARAM, S (deprecated), SPAN, TBODY, TFOOT, THEAD, and Q.

It could be that she's gotten confused over the fact that the w3c also identifies "frameset HTML" as a "flavor" of HTML. But the frames-related tags aren't marked as deprecated anywhere in the document posted as "latest" on the w3c's page.

I'm guessing she's trying to use what she thinks is a $10 word (deprecated) to describe a design concept (unneeded and inappropriate).
------------
Michael Hall
[e-mail]

Yes, and No...

[bueller]

Frames certainly aren't dead, but you should ask 'does this really need a frame?'

In the majority of cases, if not all, the use of frames can be replaced by nested tables. And there is an increasing trend to do this.

Using tables instead of frames will increase the number of potential users who can make sense of your website. If you have a frames based website, you should also provide a non-frames version out of consideration for people using a browser that doesn't support frames.

Anyone authoring a website with Frontpage (ugggh) will invariably have a frame based website when they don't need to. This means that a lot of mom and pop websites, as well as small commercial websites have frames.

Larger commercial sites are tending to not use frames unless they have a really good reason. Look at the source code for sites such as Oracle TechNet [oracle.com], Wired [wired.com], and About.com [about.com] for examples of sites that use tables over frames. Interestingly, Oracle Technet has only recently made the change and Oracle [oracle.com] still uses frames.

Many commercial software packages for website design favour tables over frames. Macromedia [macromedia.com] Dreamweaver will do this I think, although their site uses frames.

Webmonkey [hotwired.com] has a good guide to how to construct frames, but the article does say
ask yourself: Do I really need frames at all? Most of the time, the answer is no. In my opinion, frames are only appropriate when you have a complex navigation structure going on - especially one that involves retaining a search query while reloading the search results (as in Cocktail [coktailtime.com] or Net Surf Central [netsurfcentral.com]).

At the end of the day the person you've hired has been asked to provide functionality into your existing web site, and while they shouldn't be stopped from making suggestions on how to improve your site, they do have a job to do. I'd be surprised if having frames actually prevents functionality being added.

Tables much nicer than frames

[penguinboy]

Especially when you're doing dynamically created content, nested tables provide the same visual effect as frames, but are supported by MANY more browsers than frames (for example, it really sucks to not be able to load a site with lynx). I've several websites, sometimes using frames, sometimes using tables. Frames definetly can cut down on code duplication when you want navigation bars on every page, etc.; but only at the expense of lower browser compatibility. Tables make for a nicer looking product that will load in any browser (even lynx), though you may find yourself copying a lot of the same code to every page if you want navigation bars but don't do dynamic page generation (open a template, stick in content from one file, navbar from another, send page to client). Just my $0.02

Biggest gripes: arrow keys and development time

[greybird]

My biggest gripes about frames are: 1- The keyboard interface for using up/down arrows to scroll requires that the frame being scrolled has the keyboard focus. This means you have to move/click over the scrolling frame before you can use the keys to scroll, which is tantamount to making the arrow keys useless. As a user preferring keyboard to mouse, I would much rather have the whole page scroll than have to use the mouse. 2- As a developer, I know creating content for frames is more costly. In addition to dealing with one "page" split over multiple HTTP requests, there is the issue that frames can't resize dynamically to fit their content, meaning that layout using pixel sizes is many times necessary, which in turns causes all kinds of compatibility problems. Last but not least there is the problem that browsers just don't support frames consistently, and I almost always have to write browser-specific code to get them to work properly. Worst of all is trying to support a frames or no-frames preference.

Re:Tables much nicer than frames

[MichaelH]

If code duplication is bugging you badly, there's always a nice, lightweight solution like genpage [freddyfrog.com], which is what I use for my generally neglected homepage.

With genpage, you can set up template and content files. The template has all the junk in it you don't want to type more than once, the content file is just that: vanilla HTML you want in the body. The content file declares which layout file it wants to be wrapped in, and Bob's your uncle.

Better yet, genpage just looks for stuff in a directory called ~/content and uses the templates found in ~/layout to produce a web site in ~/www, which a periodic cron job can happily squirt up to your live site nightly using sitecopy.
------------
Michael Hall
[e-mail]

Jakob Nielsen on 'Why Frames Suck'

[Chris Siebenmann]

One of the better summaries is Why Frames Suck (Most of the Time) [useit.com], one of Jakob Nielsen's Alertbox [useit.com] columns. He's revised his opinions a couple of times since the original (it was written in December of 1996), but still holds to them; check out his "Top Ten Mistakes" Revisited [useit.com] column, for example.

I strongly recommend his entire site, [useit.com] which is full of advice on various web design and usability issues. You may not agree with all of them (I'm not sure I agree with him about scrolling web pages), but I've found the issues he raises all worth thinking about.

Why frames are bad site design.

[Pyr]

1. Older browsers can't see them, and if someone's been ignoring those "Upgrade Your Browser So You Can See My Site!" noframes notices for this long, they're certainly NOT going to upgrade just for you.

2. Most search engine robots can't go through frames sites. If they can't go through, you can't get indexed. If you can't get indexed, nobody finds your site.

3. Bookmarking, Bookmarking, Bookmarking. You want people to bookmark your site, right? Do you really expect them to bookmark the first page of your site and THEN go surfing to the correct page every time they want to see something? Alternatley, if they DO know about the right-click bookmark frame page trick, you're going to have to have ALL the navigation you had frames to take care of on each one of those pages so people can get around if they're going to a single bookmarked/linked page.

4. Many many people find those scrollbars everywhere incredibly annoying. You can't use ANY kind of tiled background (when you scroll, the background doesn't match up, looks dumb..but so do tiled backgrounds)

Okay. Now, the reasons people use frames.

1. Ease of navigation.
If your site depends on frames to give it good navigation, you need help. It's NOT that hard to implement a good table-based navigation scheme that doesn't have the problems of the frames-based design.

2. Pages don't have to reload.
Yes, it will speed up your current site, but if you REALLY need frames to give it that extra little speed increase you really need to learn image optimization and alternate ways of doing design that don't involve huge graphics.

3. Can change one frame file and all the pages are changed.
This can be also done with SSI, CGI, ASP, or Front Page Includes. There's no reason why you SHOULDN'T be able to use any of these methods, and you will often find these are MORE useful for frames (Can change copyright info, etc.)

There we go. If you want a more in-depth discussion of frames, point your browser over to C|Net's Builder Buzz [builder.com] and do a search for "Frames"

Re:Biggest gripes: bookmarking and printing

[Col. Klink (retired)]

My gripes are: (1) makes bookmarking a pain in the butt, and (2) makes printing the entire page impossible.

Re:Biggest gripes: bookmarking and printing

[Corrado]

(2) makes printing the entire page impossible.

This is no longer true in IE 5.x. It has the option to print the entire page, frames and all, if desired. Pretty cool for a Micro$oft thing.

Later...

frames hide backend

[dfahey]

One useful thing about frames is that a programmer can hide complex navigation from web application users. I prefer to use 'get' calls for navigating users through web apps, which tend to make for long urls. I would rather not have a user even see this part of the application's backend. For many of the online applications I develop, there is a set flow to the pages. If a user tries to mimic one of the 'get' calls, he could cause the data to become out of sync. I could check for the proper creditials to prevent a user from navigating where he shouldn't, but I would rather save time counting on the fact that the backend is hidden well enough from curious users.

Re:Why frames are bad site design.

[G-funk]

Here's a point: Everybody pipes up and says "frames are bad because XXXXX", of which some are valid, but a few are not:

• "what about older browsers?" I have to say, if a browser is so old it can't display frames, then it sure isn't going to handle a complex graphical navigation table either.
• "Use ssi,cgi,asp,php,lmnop,or xyz!" just because every slashdot reader (except me) can write perl, doesn't mean other people should have to. and compared to serving a plain frames page, server-side parsing is sloooooooooooooow.
• "search engines don't work" - so put tags in your index.html. And let's face it, unless you've been around for years, ir the customer knows how to use a search engine properly, and/or is looking for you in particular, chances are they aren't going to find you anyway. I love searching for "java programming" or something similar and getting "nasty teen amateur cheerleaders" or whatever.
• "If you need a speed increase you suck anyway: I'm a web developer for a living, and I'm still stuck on a 33.6 connection. We don't all live in the US where access is cheap and fast.

My .02 -Gfunk

Re:Why frames are bad site design.

[cdonat]

>""what about older browsers?" I have to say, if a browser is so old it can't display frames, then it sure isn't going to handle a complex graphical navigation table either."

Lynx is not old...

On the Page I am currently building I have a graphical table based Navigation scheme with Javascript support. So there is amlost every buzz word exept frames in it. Still it works with Lynx.

The IMG tag allowes to set ALT for alternative text to be displayed if the image can not be displayed.

A carefull design allowes to make the navigation to be at least aceptable without tables (Lynx doesn't support tables as well).

By replacing empty Images with the real ones via ONLOAD in the BODY tag makes Javascript parts only visible when Javascript is enabled and not disturbing people with Javascript off, or another Browser.

It is all possible without frames. Of course it needs work, etc. but it results in Pages that are definately better viewed on many Browsers.

>""Use ssi,cgi,asp,php,lmnop,or xyz!" just because every slashdot reader (except me) can write perl, doesn't mean other people should have to. and compared to serving a plain frames page, server-side parsing is sloooooooooooooow."

So you're a "web developer" guy ... Learn Perl and PHP at least before you call yourself one. BTW server-side parsing is not neccessarily slow. You can still make shure that people can cache the parsed Pages, You yourself can "cache" them by generating static Pages and delivering those via your CGI Script and only update them when the static Page is older than all the Pages nedded to create it.

>""search engines don't work" - so put tags in your index.html. And let's face it, unless you've been around for years, ir the customer knows how to use a search engine properly, and/or is looking for you in particular, chances are they aren't going to find you anyway. I love searching for "java programming" or something similar and getting "nasty teen amateur cheerleaders" or whatever"

There are many ways to improve that. Use Meta Tags, update your site as often as you can (forces the Spider to index it again), etc.

>""If you need a speed increase you suck anyway: I'm a web developer for a living, and I'm still stuck on a 33.6 connection. We don't all live in the US where access is cheap and fast."

My experience is that reusing images by using "../image.gif" like hrefs would speed up very many Pages much more than those frames.

Don't gert me wrong. If there was a significant improvement by using frames I may consider it (I hae a Page using Layers for a Game e.g.). But since I usually whant as many people as possible to view the Pages I create I also test them with "only for real Programmers" Browsers like Lynx. I never really got a frames empowered site working with Lynx without loosing any improovement I get from frames.

Instead of xyz and fnorp-fnorp, try m4

[Sesse]

m4 lets you do a server-side include, once :-)

I use it for my site, so I can have _both_ a frames and a non-frames version. In addition, if I need it, I can make gzip/compressed version (for HTTP/1.1 compression), I can add a new button to all non-frames pages at once, etc. etc. etc. m4 is your friend. And it's GNU...

/* Steinar */

Re:Why frames are bad site design.

[pen]

"Use ssi,cgi,asp,php,lmnop,or xyz!" just because every slashdot reader (except me) can write perl, doesn't mean other people should have to. and compared to serving a plain frames page, server-side parsing is sloooooooooooooow.

I'm sorry... but what is so hard about this:

<?php Include("./inc/navigation.inc"); ?>

As for server-side parsing being slow,... if you don't know perl, how could you possibly know about how fast or slow it is? AFAIC, that's not where the bottleneck is...

--

No good answer

[goliard]

A look at the other threads shows there's lots of frames vs. (nested) tables argument going on here.

Frankly, there is no good answer. Frames suck for all the reasons frames suck. Tables suck because:

• On at least one major platform (a WinTel 'chine (>ptui!<) running Netscape) exceeding 6 nested tables is often fatal. Strangenesses can result from nesting only three.
• There are gratuitous graphical hacks (without which, our marketing department assures me, our company cannot survive) which can only be done through the clever use of frames.
• What version of Lynx are you people using? Using tables for formatting text can look appalling in Lynx.

Upshot: Why are we trying to make pages look like the interfaces to applications? That's how we got into this mess. The tools just don't do what we're trying to get them to do.

Sorry to be a party-pooper.
----------------------------------------------

Re:frames hide backend

[Chris Siebenmann]

DANGER: if Internet users can cause bad things to happen to your site (databases getting out sync, etc) by submitting manual 'get' calls or the like, you need to do all that painful verification. Or sooner or later some joker who doesn't like you will come along and bring the house down.

Even if it's only an internal intranet application, you might want to do at least some verification just in case. People and programs can do all sorts of whacky things.

'Hiding' the backend in this way is a form of security and reliability through obscurity. Insert standard discussion of the relative merits and problems of that here, if desired.

Frames

[GrokSoup]

Generally, I avoid frames as much as possible. That said, there are some wonderful arguments for them, including how they make it possible to frame other kinds of remote content inside of consistent local nav banners. I really is a big help.

Against the preceding you really have to chalk navigation problems. Nothing drives me battier (almost nothing) than being forced to bookmark a root page and then have to navigate my way to some deeper page. Ugh.

P.

Re:Why frames are bad site design.

[guran]

Lynx is not old...

C'mon! In the real world there are only two browsers and unfortunately the one from The Evil Empire is the better one.
I could probably write a very good text-only interface, just in case someone is using his own home built toy browser, but seriously, anybody using any browser except the two big ones:
a) knows enough about the web to download another browser if he/she wants to
b) is willingly using a more "primitive" product.

Now I go to great lengths not to cause trouble for people who have slow connections, poor knowledge about the net or for any other reason is cannot upgrade, but if you actively decide not to be able to view a w3c-compliant page, then I'm not the least sorry for you.

So you're a "web developer" guy ... Learn Perl and PHP at least before you call yourself one.

Im a web developer too. I can use perl, but I dont. It is too hard to maintain. Most of the time I actually use asp on the Evil Empire platform. My clients have the money to pay MS so why should I make it harder for myself. Of course I would prefer linux/apache for personal use and No Way would I use MS for a really critical high load site, but again no holy war, please!

You can still make shure that people can cache the parsed Pages

Yes the problems begin when I don't want them to cache anything. Both IE and netscape are buggy there.

My opiniom about frames?
If you dont know how to use them: don't
If they make your page better: Use them, but make sure that you use them right.

Personally I do no frames

[josepha48]

I personally think frames suck, and several people have stated good reasons why frames suck.

See the posting -> From the w3c itself: Frames have not been depreciated in HTML 4.0.

The company I just left uses frames. Here are the propblems that I saw with there application and there use of frames.

• If you have frames you need to have scroll bars. They didn't. They assume that they can enforce users to use a resolution of 1024x768, on a 17" monitor. Many users refuse to do this as they claim they cannot read the text or it hurts there eyes. scrolling is bad for the eyes too.
• If you are designing an application and need to have that many frames or that many nested tables you may want to rethink the design to have less content on the page, or lay the content out better. Remeber HTML 4.0 support the div tags also which allows one to lay out content better and place it better.
• Forcing a certain browser requirement is bad if you are on the internet, but if it is an intranet, you can upgrade the users and make it a requirement. Many companies are moving towards IE5.0 as it actually has implemented more of the HTML4.0 features as opposed to Netscape 4.x however Mozilla is looking real nice, but needs some clean up (IMHO). Personally I'd prefer opera as it is faster than both of those browsers, and smaller, however it costs money. Opera also implements more HTML 4.0 features than Netscape or IE5.0

Learnign HTML is not that difficult, and the best resource out there is www.w3.org. There are also many examples at bother netscape and IE developers sites, and dozons of books.

send flames > /dev/null

Re:Why frames are bad site design.

[cdonat]

1. "knows enough about the web to download another browser if he/she wants to"
2. "is willingly using a more "primitive" product."

OK:

1. Have you ever thought about blind people who have to stick to lynx sice that is currently the only solution they can use?
2. There are still other platforms around. I remember how I hatet netscape for inventing frames before any Atari browser could view them, because I could not afford a new computer those days.

I still think that one only should use newest technology on web pages if one thinks about people who can't view it. Most new features at least allow to get around such problems

"Yes the problems begin when I don't want them to cache anything. Both IE and netscape are buggy there."

The question was if dynamically generated content needs to be slow. There is no reason to assume that. I know, that there are problems with really dynamically generated content.

Re:Why frames are bad site design.

[guran]

Sorry, I was not in the best of modes when I wrote that. What got to me was the implication that "Real web people use perl and lynx"

When I design a page I think about the people who *wants* to wiev it. If I know that those people appriciates a feature, and that they can use it, then OK. If I dont know anything about them, then I'm much more conservative.
Peace, OK?

'Bout frames again:
I've seen good framed designs and bad no-frames designs. If you are a good developer you can use both methods. If you are bad, then simple rules like "always avoid frames" wont help.