Framesets and frames - your opinions - the pros and cons 1

[Foamcow]

Since this comes up from time to time and normally hijacks someone elses question I thought I would start a thread especially.
Use this thread to give your reasons for recommending or not recommending the use of framesets.
Personal opinion is perfectly valid, but try to back it up with at least some logical reasoning.

Foamcow Heavy Industries - Web design and ranting
Buy Languedoc wines in the UK

 

[trollacious]

Here's a question for you, CliveC. What makes the main page of a framed website work fine if I type in the URL, but when I go there from the bookmark I have in IE for the site, the main page frame shows "The page can't be found". Refreshing the page sometimes brings up the "lost" page, but not always. If you want to see the code, it's at

http://www dot

gavinbros dot com, a local auctioneer's business.

Lee

 

[BabyJeffy]

In 8 years of contracting in London I have NEVER worked on a single internet site (for a paying client) that used frames. Even back last century the clients I worked for regarded frames as both quirky and redunant for their internet facing presence. I have worked on one intranet CRM solution that used a frameset to facilitate AJAX-like functionality (for NN4 and IE4 Windows browsers within a strictly managed intranet environment).

There is some validity to the argument that serving navigation in the main page can cause extra bandwidth usage - and this is true also of the extra bandwidth generated by the actual frameset document. But this is hardly a reason to actively choose to use frames over SSI. It may be a contributing factor for a specific instance - but it then needs to be weighed equally with other pros and cons.

When I hear people say "What if Javascript is turned off?", I am tempted to say "then you will have a frustrating time surfing most sites on the world wide web".

So you actually [!]did[/!] say it then, didn't you? It's an uninformed statement that shows a lack of understanding of the reason Javascript functionality was mentioned in the first place (wrt this discussion).

Clive, modern sites are built to run with or without javascript... they degrade so that non-javascript users can get the same functionality (do some reading on Web Accessability before you reply on this point... it's not just about screen readers, either... it includes handhelds and mobiles as well). This is equally true of sites that use AJAX as well... I have built such sites... and you can see GMail working without Javascript (as an independant third part site).

While we are on the subject of large sites, having a menu in each page requies endless redundant transmissions of data. Some say that the menu is cached. I may be wrong but I have never seen any evidence of that and it doesn't even seem logical that just a portion of the page (a non-image) could be cached. Seems to me that it may just be another urban myth that when repeated enough times seems to come to be true.

Any thoughts?

I agree that this is an urban myth. As you say, there is little fact to the statement that a part of an HTML page will be cached (just because it doesn't necessarily change between two pages).

It is possible to put the navigation entirely into a linked Javascript file (which would be cached)... but this then breaks the navigation for all users (and user agents) that do not support Javascript (and that includes our search engine crawlers). I would not recommend this approach - but it is the only example I could think of that would prove the "myth" true.

Along with everyone else (except CliveC) I agree that bookmarking a framed page is a real pain in frameset based sites. I find I want to bookmark specific pages (whilst CliveC finds it acceptable to bookmark only the top level domain name)... if I want to bookmark the top level then I can... but if I want to bookmark deeper content, I cannot.

There are ways to achieve "deep linking" and also maintain the frameset... these require server-side or javascript "jiggery pokery". That's a fact. Therefore (because of the extra coding and attention required to do it) this counts as a CON - and a very good reason to avoid using a frameset approach for your site.

Since you did not comment on the use of framesets off the web should I assume that you concede that this might be a good use of framesets?

Given SSI is not available without some kind of server... then using a framed solution may indeed be an appropriate way to deliver content off the web.

It could be as practical to have a full SSI version and then use a program (Offline Explorer for example) to crawl the site and create a stand-alone HTML version before delivery to the client (for use offline). Changes would require re-crawling the SSI version of the site and delivering the replacement stand-alone HTML to the client... this may be a suitable way of handling a specific case.

It's another one of those examples where there are always many ways to achieve the same result - and so you need to consider other factors before reaching a formal conclusion. These "other factors" could be out of your control. This is true of all the points that Foamcow has raised.

This thread is an opportunity to point out the PROs and CONs and help guide people to make their own informed decisions. It is not a petition to remove framesets from the web! Nor is it (or any TT thread) designed to malign people.

Cheers,
Jeff

[tt]Jeff's Page @ Code Couch

http://www.codecouch.com/jeff/

http://www.codecouch.com/jeff/blog/

[/tt]

What is Javascript? FAQ216-6094

 

[ca8msm]

modern sites are built to run with or without javascript... they degrade so that non-javascript users can get the same functionality

Personally, I agree and when developing websites, javascript is the last thing that I add to the site. I create the site so that it is accessible to all users regardless of whether they have javascript enabled. I've always been of the opinion that javascript should only be used to enhance the site and should not be relied on (feel free to correct me if anyone disagrees with this!). Most sites that use frames go against this as they rely on javascript to keep the frames in sync with what the user should be viewing. For example,

Take your site Clive (

http://tubularity.com/)

and imagine I am searching google for your site (I hope you don't mind that I used your site for an example but this does describe some of the problems I see with framed sites, and as you use them extensively you are probably best placed to counter these arguments). I used the search term "tubularity professional website" and came up with the following results:

http://www.google.co.uk/search?hl=en&q=tubularity+professional+website&meta=

The first result that I see is the information that I'm looking for and therefore click the link to go into your site. This is where the experience starts to differ depending on my browser and therefore I'll explain the two different scenario's I got. I often don't have javascript capabilities so I'll explain what happened with this first:

1) Without JavaScript
Clicking the link took me to

http://tubularity.com/twssec01.htm

where I could see a box with a description, some features and a link to a sample site. What I couldn't see was a logo of what site I was on, nor could I see any text of which site I was on. There was no navigation menu so I couldn't get back to the site's homepage to view any other details that I may have wanted to view.

2) With JavaScript
Clicking the link took me to

http://tubularity.com/twssec01.htm

where, with the help of this javascript function:

if (top.location == self.location)   {
    self.location.replace
    ("index.php")

I was redirected to

http://tubularity.com/index.php.

This wasn't actually the page that I wanted to view, but that didn't really matter as a menu was available to me and I could click on the Professional Website button to get me to where I was originally going.

Now, with the first scenario I was obviously a bit lost and I don't think that would be the type of experience I would want to have my user's to have, especially if that was their first impressions of my site and the services I offered.

The second scenario however, is exactly the type of experience I would want to have my user's to have (maybe apart from being redirected back to the index page). The site was well laid out, I was easily able to navigate it and the response time was very quick. However, I now know that users without javascript will be having a very hard time of it and I would try to rectify that.

If the site had been created without frames then I would have to include the menu as part of each page and there would obviously be an overhead to this. According to my browser, the menu page is actually only 2.25 kB (2299 bytes). This, to me, is a fairly small overhead to have on each page and, if it means that I don't have to worry about user's without javascript or users who want to bookmark a particular page and not be redirected back to the index page when they try to view that bookmark, then I would be much happier to go with that.

I really like the idea of having a quick response whenI click a link, and that only certain parts of the page are refreshed as necessary but I do think the use of frames has overcomplicated what is a relatively straight-forward website.

Balancing the two scenario's results above, I would always go with the intentions of appealing to a wider audience regardless of their browsers settings and therefore I'd go with a non-framed site in both this and most web applications that I developed. This maybe just a personal preference, but I believe it's one that is fully justified and one that a lot of people will also have. If anyone doesn't agree then please feel free to show what solution could be implemented to avoid those issues.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[ChrisHunt]

The sort of applications where framesets are useful are large parts inventory systems, technical manuals that require intelligent navigation rather than relying on search engines [...] documentation requiring navigation but where the application is not on a website at all.

I quite agree. There are a number of specialised applications where framesets are a useful tool.

Whenever a newbie asks a question about a frameset the advice offered is usually a blanket condemnation of framesets

That's because the questions asked rarely, if ever, refer to one of those specialised applications (where we agree that framesets are appropriate), but to a "standard" web page (where most of us agree that they usually aren't).

So if you were coding a site where deep linking was important then framesets might not be a good choice. However in some applications it might be beneficial to use a frameset to specifically avoid deep-linking.

I suppose there might be some cases where deep-linking should be discouraged (though I can't think of any sensible ones). But if so, you've only added another item to the list of "specialised applications where a frameset is useful". It's hardly a case of "throwing the baby out with the bathwater".

For me, difficulty of deeplinking was the killer argument against framesets on my site. If you're looking to build your Google page rank, you need to make it as easy as possible for people to link to your site, and to link to where they want to. While it's possible to make framed sites deeplinkable, the extra overhead involved for the potential linker in digging out the necessary URL is going to cause some of them not to bother. That's a risk I choose not to take.

a classic case of what I call "Chronic Frameset Avoidance"

The thread linked to seems perfectly sensible - if you want the aesthetics of the frameset - a fixed header over scrolling contents - but you don't want the disadvantages re: bookmarking etc., this is the approach to take. OK, I'd like to rely more on CSS than JS, but it's certainly not laughable. Real CFA is where a complex assemblage of <iframe>s and/or javascript is used instead of a frameset. That's just silly.

having a menu in each page requies endless redundant transmissions of data. Some say that the menu is cached.

Can you prove that last assertion? I don't recall anybody saying that the menu would be cached in a regular web page. What's true is that the images (if any) used in the menu and other repeated content will be cached. A couple of hundred bytes of HTML is not going to make much difference to download times - it's the images that are the real issue. Of course there are special cases where large amounts of un-cacheable redundant data would need to be sent with each page, and in such cases frames might be a suitable alternative approach. But that's only jut another special case, rather than an argument for widespread use of framesets.

I'll finish with a quote that sums up the argument perfectly for me:

A frameset is just a tool in the toolbox. Sometimes it is an appropriate tool and sometimes it is not. Probably most websites have no reason to use framesets. This does not mean that we should throw the tool away.

Exactly. It's a tool, use it properly.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[CliveC]

This thread is an opportunity to point out the PROs and CONs and help guide people to make their own informed decisions. It is not a petition to remove framesets from the web! Nor is it (or any TT thread) designed to malign people.

Ok! let's not malign people...
Oops! What is this?

So you actually did say it then, didn't you? It's an uninformed statement that shows a lack of understanding of the reason Javascript functionality was mentioned in the first place (wrt this discussion).

I was refering to the mythical user with a javascript enabled browser who surfs with Javascript turned off.

Along with everyone else (except CliveC) I agree that bookmarking a framed page is a real pain in frameset based sites.

I conceded this point.

Although your tone seems unfriendly and antagonistic you have actually confirmed much of what I have said:

There is some validity to the argument that serving navigation in the main page can cause extra bandwidth usage

I agree that this is an urban myth. As you say, there is little fact to the statement that a part of an HTML page will be cached (just because it doesn't necessarily change between two pages).

Given SSI is not available without some kind of server... then using a framed solution may indeed be an appropriate way to deliver content off the web.

I would also just say that the subject of framesets does not really belong in the web design forum. Had I started the thread I would have put it in the HTML & CSS forum. HTML at its basic level is just a file type. The file type makes it a good vehicle for delivering offweb (as well as onweb) content because most everyone regarless of platform usually has an HTML capable browser.

Kind regards!

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://citywastepaper.com

 

[BabyJeffy]

Clive,
Understanding the way that people use the internet is key to becoming a professional in this industry. Your comment below clearly outlines your own depth of understanding of those that actually use the internet...

I was refering to the mythical user with a javascript enabled browser who surfs with Javascript turned off.

I'll be sure to refer my "mythical" userbase to you next time I am asked to do some development work... with your informed stance I'm sure they will continue to embrace the internet.

Cheers,
Jeff

[tt]Jeff's Page @ Code Couch

http://www.codecouch.com/jeff/

http://www.codecouch.com/jeff/blog/

[/tt]

What is Javascript? FAQ216-6094

 

[CliveC]

JavaScript is just another red-herring in terms of the frameset debate. If you read carefully you will note, that in answer to Foamcows theoretical application, I answered that Javascript was unecessary.

This debate has become subject to TD (thread deterioration). On the bright side I think that we have made some headway.

1. Framesets can work OK in Lynx-type browsers which includes the Blackberry.
2. Repetitious menus or data in each page are not cached and do increase bandwith.
3. Framesets do not require a server and can therfore be used for offweb content.
4. Framesets should not be used if bookmarking or deep-linking are requirements.
5. Framesets do not deserve blanket condemnation.

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://citywastepaper.com

 

[CliveC]

Lee,

I was unable to recreate the problem that you described and so I have no idea what the solution might be.

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://citywastepaper.com

 

[ca8msm]

Clive - what would be your solution to the problems I came across then, and why would a frameset be a better solution than a standard page where those problems wouldn't arise?


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[trollacious]

I deleted the shortcut from my Favorites, then added it back in (have done this 3 times previously, I believe), and it works fine now. Thanks for trying, CliveC.

Lee

 

[Sheco]

What happens if the user doesn't have javascript enabled?

Forget them, yours isn't the first site that gives them fits and it won't be the last. Also these people are so parinoid that they won't be buying anything over the intarweb anyhow.

 

[CliveC]

ca8msm

Sorry, I just thought that even though our posts may have crossed, that I had already answered your questions. I suggested that without forcing frames into a frameset you may be able to achieve your purpose and still use a frameset.

I have conceded twice now that bookmarking is difficult with a frameset. However, I did provide a non-Javascript tongue-in-cheek suggestion to frameset bookmarking even though Jeff sez:

There are ways to achieve "deep linking" and also maintain the frameset... these require server-side or javascript "jiggery pokery". That's a fact.

My question to you is "Do you want a solution?" or do you want to stick with the idea that:

I would always go with the intentions of appealing to a wider audience regardless of their browsers settings and therefore I'd go with a non-framed site in both this and most web applications that I developed.

This idea pre-supposes that the be-all and end-all of website development is to appeal to a wide audience and to have recognition on search engines. What use is that for local non-mail-order businesses?

The reason that I did not resond to Chris Hunt's post is because he seemed to be mostly agreeing with me and actually used one of my quotes to summarize his position. His main difference with me was that he was suggesting that any valid use of framesets was just some specialized case. I do not think that online documentation is all that specialized but neither do I want to argue the point.

Frames is not the same as Frameset although they seem to have become to be used as if they were. You can have a frame or frames without needing to have them necessarily in a frameset.




Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://citywastepaper.com

 

[ca8msm]

Clive,

I thought you had answered BabyJeffy's posts as you quoted his comments however I didn't think you had offered a solution to user's without JavaScript so thanks for your reply.

This idea pre-supposes that the be-all and end-all of website development is to appeal to a wide audience and to have recognition on search engines. What use is that for local non-mail-order businesses?

Obviously most websites will have a different purpose and the people that they are trying to appeal to will differ. Surely though, the large majority of sites (whether they are selling anything or are local/national/international etc) will have been created for one main purpose and that is to expose the company (or whoever the site is for) and generate interest. That being said, I'd expect that most sites would like to do well as possible in terms of people being able to find their site and search engine's will obviously be one way to increase potential visitors to the site. This, however, may not be true if the site if not available to the general public. I made my comments with public sites in mind.

Forget them, yours isn't the first site that gives them fits and it won't be the last.

I've always tried to make sites that degrade well to those users as it may not be up to them as to whether they can use javascript or not. I may not have worded my reply correctly as I didn't just mean those who had specifically disabled javascript; what I should have said was those user's who, for whatever reason, are browsing without javascript capabilities (e.g. it could be that they are disabled users who don't have this capacity in their browser, they could be in a situation where there browsing experience is locked down or it could simply be their choice that they don't want it on). Should we really just forget about them if they fall into any of those categories?


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[Sheco]

Should we really just forget about them if they fall into any of those categories?

It depends.

If you are the one selling web development services then you want to upsell maximum compatibility.

If you are the consumer of web development services then there might be more effective ways to spend your money... perhaps translating it into Spanish, French, Japanese, etc? It might not even be worth the extra development time to ensure compatibility with browsers other than Internet Exploder.

 

[Foamcow]

It might not even be worth the extra development time to ensure compatibility with browsers other than Internet Exploder.

Isn't that quite an "old skool" way of thinking? Modern web development techniques negate the need for extra development time to make things work in browsers other than IE.


Sorry I've been absent from this thread, had a busy day or two.

And again, sorry Clive. I've got to comment on these points:

1. Framesets can work OK in Lynx-type browsers which includes the Blackberry.

They work, but not very well. Whereas a non framed site (put together correctly) works great.

2. Repetitious menus or data in each page are not cached and do increase bandwith.

Images may be cached, but you are correct, SSI fragments aren't cached.

3. Framesets do not require a server and can therfore be used for offweb content.

But there is another, more portable option (i.e. a PDF) that offer better layout control and graphical ability/quality.

4. Framesets should not be used if bookmarking or deep-linking are requirements.

I'd say that's pretty much a basic requirement. Surely it's one of the core principles of the web.

5. Framesets do not deserve blanket condemnation.

No they don't. But equally, they aren't an answer for 95% of "problems" and as was pointed out the vast majority of people using them have no real need to and do so out of a misguided belief that they are the only/easiest/best way to create their website.
Ergo, they appear to get blanket condemnation as they simply aren't the best solution most of the time.

Going back to my theoretical web application (site). I know of no way to refresh 2 documents with a single click unless javascript is used.
Actually, I suppose you could create multiple framesets or using a server side language to pass parameters to a script that returns the frameset with the relevant pages loaded into it.
I would consider either of those methods to be adding a layer of complexity to a simple scenario though.


Much else of what I could say at this point has already been said by other people.

Foamcow Heavy Industries - Web design and ranting
Buy Languedoc wines in the UK

 

[CliveC]

RCIS Reading Comprehension Inabilty Syndrome

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://citywastepaper.com

 

[CliveC]

Sorry! Missed the smiley face emoticon

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://citywastepaper.com

 

[Foamcow]

Tell me, what is it that I didn't comprehend? Seemed all pretty plain to me. I read your "summing up" and disagree with what you said, or rather I disagreed with the sentiment.
Where was the lack of comprehension?


IOAS - I'll leave that one for you to work out.

Oh, I forgot...



Foamcow Heavy Industries - Web design and ranting
Buy Languedoc wines in the UK

 

[ChrisHunt]

Let me test my reading comprehension then. We've all agreed that frames present obstacles to linking and bookmarking. Does this statement:

This idea pre-supposes that the be-all and end-all of website development is to appeal to a wide audience and to have recognition on search engines.

mean that we all agree that frames suffer in SEO terms?

There is a lot of misinformation out there dating from the days when SEs couldn't index frames at all, that's clearly not true now. But by splitting the content of a single logical "page" between several frames you're making it more difficult for any of them to rank highly. Not to mention the PR-crippling effect of reduced linking.

Incidentally, localised operations should still want to rank on search engines. Sure, they may be pushing the URL in other ways - but customers might well register the fact that they have a website, without noting down the URL. When they want to visit the site, they'll google for it. It would also be desirable to rank high in localised searches like "widgets springfield", if that's what you sell and that's where you are.

Still, we're perhaps reaching consensus around the proposition that frames are OK as long as...
[ul]
[li]You don't want people to bookmark the pages of your site[/li]
[li]You don't want people to link to the pages of your site[/li]
[li]You don't want to rank highly in search engines[/li]
[/ul]
That seems like a pretty small niche market to me. For the rest, I shall retain my "blanket" advice not to use frames.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[CliveC]

Chris

No I don't agree that that frames suffer in SEO terms?
Can we leave that aside for the moment?

There is a lot of misinformation out there dating from the days when SEs couldn't index frames at all, that's clearly not true now.

I am not being mean at all but I would be interested to know when you discovered this and, if you know, when it ceased be true.

I think the reason for our misunderstnding of one anothers position is that you are thinking in terms of website design where slick and asthetically pleasing sites, using modern methods and that are perhaps used for basically marketing purposes. I, on the other hand, am think more in wider terms of website applications.

I suppose there might be some cases where deep-linking should be discouraged (though I can't think of any sensible ones).

Ok!

Well how about this widely used web application:
1. It clearly is a candiate for a frameset
2. A primary consideration is that it should not be able to be deep-linked
3. Neither should it appear on search engines
4. It is important for speed not to transmit static unchanging page data

Would you concede anything if I could show you such a site?

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://citywastepaper.com