HTML: To Frame or not to Frame 21
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: (Score:3)
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
mphall@cstone.nospam.net
Yes, and No... (Score:2)
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 (Score:2)
Biggest gripes: arrow keys and development time (Score:2)
Re:Tables much nicer than frames (Score:2)
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
mphall@cstone.nospam.net
Jakob Nielsen on 'Why Frames Suck' (Score:3)
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. (Score:3)
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 (Score:2)
Re:Biggest gripes: bookmarking and printing (Score:1)
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 (Score:1)
Re:Why frames are bad site design. (Score:1)
Here's a point: Everybody pipes up and says "frames are bad because XXXXX", of which some are valid, but a few are not:
Re:Why frames are bad site design. (Score:1)
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
>""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 (Score:1)
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. (Score:1)
<?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 (Score:1)
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:
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 (Score:1)
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 (Score:1)
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. (Score:1)
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 (Score:1)
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.
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. (Score:1)
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. (Score:1)
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.