HTML has had frames from early days, but they are deprecated in the latest version. Many browsers (I have tried with Internet Explorer) don't even display frames properly.
Why has this been done? What was the drawback in frames?
Jakob Nielsen wrote a 1996 column that criticized frames. Some key points:
Frames prevent users from properly bookmarking pages. When a bookmarked frameset page is loaded, users' previous mouse clicks inside the frames do not matter. Only the outer URL is saved, and users have to navigate to where they were manually.
Frames present challenges for printing web pages. Printing all the frames at once is not suited to the different dimensions of paper (and users can get only the first pageful that way). Users generally have to right-click the frame they want and choose the appropriate context menu option.
Users coming from search engines may not have access to navigational elements if they are located in another frame — they are directed to only that frame the search engine found the text in.
While "framesets" (the most common type used on late 1990s/early 2000s web pages) are dying, the iframe (short for inline frame) remains alive and well. In fact, recently iframes have been found useful in today's "mashup" web applications, and extensions to the iframe are currently proposed in the HTML5 specification.
For example, Facebook, in its API for app developers, uses them to seamlessly integrate third-party apps with their own site while minimizing the security risk. (In this model, all third-party code remains on a separate domain, which is good for security reasons.)
Frames are not deprecated in HTML. They are obsolete in HTML 5, and just discouraged before this version. This has been clearly mentioned in the specified links.
Not to answer the OP but rather balance the bashing of framesets.
I find them great and nothing comes close to them when you want your menu intact and still:
Visually incorporate 3-rd party pages/apps (phpmyadmin or similar)
Viewing doctypes other than html (pdf's or images).
Due to its width="x,*" you get a simple "responsive" behaviour.
Also, you can provide smooth menu-animations while fetching main contents.
Used with sense, they're super.
Related
This is more a theoretical question than a coding question. I am trying to create a epub, with some interactive components. Now to separate the code, I put each interactive component in a separate html file. Typical interactive components will be a questionnaire.
What will be the best way to link this to my epub, two options I am considering are:
Iframe - the interactive component will display as a part of the book, and users will seamlessly complete the activity.
External link - an Icon will be displayed in the book, which will serve as a link to a new page, this page will contain the interactive component.
I would like to keep the epub according to epub 3.0 standard.
Any suggestions or alternative solutions I can research?
Either approach is compatible with the standard since external links are allowed and scripting within an iFrame is also allowed (known as scripting in a container).
The broader question is what are you trying to achieve? If the user is sent to an external page in a browser then the browser will have to post the results back to some server since the browser can't write the results back to disk or the EPUB.
It also depends on whether the EPUB Reading System is browser-based itself or an app. It is an app then in theory the app might know how to log info locally (though that would require jumping through some hoops that could have security implications.
So what is the goal here?
I really want a way to have one single file for, for example, the navigation bar and the footer so that I don't have to go through all of my pages (only 20 or so, but anyway...) to update it. So I've realized that frames (iframes? What's the difference) can help me with this.
Additionally, I've heard a lot of places that frames are a no-go in web design for some reason. Is this to do with SEO?
Can I use (i)frames safely? Are there alternatives that keep the url http://www.domain.tld/pagename.html ?
Whatever you do, don't use frames/iframes for page layout.
Your best bet is to use a server-side scripting language to build your page. That way, you can have the individual components in separate files (which makes maintenance easy) and then compose them using the scripting language.
So I've realized that frames (iframes? What's the difference)
An iframe embeds a document in the middle of a page.
A frame is part of a frameset, which consists of an entire page.
can help me with this.
They could, but have plenty of drawbacks (mucking up linking, printing, causing scrolling issues, etc). Use an include (e.g. php or ssi) or template system (e.g. template toolkit's ttree) instead.
Adding to these two good answers, from the SEO point of view a frame based site is also might be a bad idea.
Google supports frames and iframes to
the extent that it can. Frames can
cause problems for search engines
because they don't correspond to the
conceptual model of the web. In this
model, one page displays only one URL.
Pages that use frames or iframes
display several URLs (one for each
frame) within a single page. Google
tries to associate framed content with
the page containing the frames, but we
don't guarantee that we will.
See this
As a side note, have yo considered 301 redirect? It is not precisely keeping the same address, rather the opposite but it might be what you want if I understood your concern.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I haven't used frames since 1998. They seem like a bad idea and in all my development I've never had a situation where frames were the right solution, or even a decent solution.
However, I'm now working with an internal web application written by another group and the entire site is built in a - header, left side menu, right side content - frameset.
For one, when VPN'd to my network I constantly get a "website.com/frames.html" cannot be found." error message. This doesn't happen when I'm on the internal network.
Second, the app has a built in email/messaging system. The number of unread messages is shown in the left side menu frame as "Messages (3)" but the count doesn't update as I read the messages. The developer told me since it was in a frame I needed to right click on the menu and 'Refresh'. Seriously????
So, my programming related question is, what reasons do you have for not using frames in a website?
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
11.2 Non-conforming features
Elements in the following list are entirely obsolete, and must not be
used by authors:
[...]
frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
They almost always make people angry. What more do you need?
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Getting contradictory messages about that, hope they're not.
I cannot imagine support for it would stop, since a gazillion sites use them.
Some additional questions about that:
Why should they phase out this tag?
Any alternative for it?
Support for <iframe> is still there in HTML 5, so I don't think this will change in the near future.
To answer your other questions:
<iframe>s (as frames in general) are most of the time not user-friendly:
They don't allow easy access of the content in the frame via an URL (without losing the content outside of the frame at least).
Most "technophobe" users are irritated by frames.
As far as I know they are slower to render for browsers
Alternatives include dynamic page generation (SSI, PHP, Rails and so on) and using JavaScript / AJAX to change contents of e.g. a <div>
To be clear: I'm talking about <iframe> as an interface element. Not a hidden element for loading other stuff like e.g. Google Mail does.
In my opinion the W3C jumped the gun in dumping iframes from the Strict HTML and XHTML doctypes. In theory you would use the <object> element to add foreign objects to your document, but browser differences and limitations have made this a nonstarter for many developers. With the much-more-pragmatic HTML 5 (which is still a draft), iframes are back and even have two new attributes: seamless, and the intriguing sandbox.
IFrames are not obsolete, but the reasons for using them are rare.
Using IFrames to serve your own content creates a "wall" around accessing the content in that area.
For crawlers like Google, It's not immediately clear that cotent in an iframe will be ranked as highly as if the content were simply part of the page. For many, this is reason enough not to use it.
It makes the DOM for the IFrame less accessible by tools like jQuery, prototype etc..
Reasons for using iframes:
It's great for walling off other people's stuff from other domains but it doesn't integrate smoothly. (stylesheets, javascript etc...)
Integrating multimedia can sometimes be done easier via an iframe as opposed to using the embed tag.
Really, really specialized cases like gmail's case where they are using it for sounds and history management.
I would also answer that there is no need for the removal of iframes, it's a needed tag and will be around for a while.
Iframes are obsolete for page layout. Never use them instead of good CSS layout, even table-based layout is better.
Good reasons for using iframes are:
ads: adwords for example uses this technique, it is good for encapsulating - ad css won't destroy your page.
hidden iframe: it can be used for hundreds usable things, like tracking, ajax-alternative, etc.
I've seen lots of forums that suggest the Object tag as a replacement for IFrame, which probably works in most cases.
For example, I had a PDF showing in an IFrame (because there were other things we need to show on the page besides only the PDF) and was able to get it to display fine using Object.
What was:
<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>
Became:
<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
<p>[Show this message if displaying the PDF did not work]</p>
</object>
But Object was not a suitable replacement to fill the requirement to be able to print ONLY the PDF portion of the page.
An IFrame is like its own window within the page (a window within a window, basically), and once you get the window object, you can call .print() on it, like:
jQuery("#confirmed_pdf").contentWindow.print();
IFrame has a contentWindow property, that's what makes printing only that part possible. Object does not have a contentWindow property, so there's no way to print only the section of the page.
So, it seems like if you're just using IFrame to display something, there's other tags like Object that can be used instead. But if you need to interact with the contents of the IFrame in certain ways, then IFrame may be necessary.
IFrames are used a lot with AJAX. GMail for example, uses nine hidden IFrames I believe.
IFrames are not dead, but Frameset/Frames are dying.
In the last 2 releases of IE (IE7/IE8) zooming in Frames (not IFrames) has created disastrous results.
By all means use IFrames, but IMHO stay clear of Framesets/Frames.
At my previous company, we provided a hosted application that customers would integrate into their own websites. At times, they would use an IFrame to do this, fitting our hosted page into their existing designs. Sometimes this was even done seamlessly (ie. the IFrame had no borders or scrollbars, it just looked like part of the page). I considered this to be a good use of the tag.
They can be extremely useful in some circumstances, but those are limited. In particular embedding common functionality across multiple sites.
For example I have a client who runs a number of Scottish goods e-commerce sites. As part of this we have developed a couple of simple applications to locate possible clan names from your surname or your choice of tartans (giggle if you wish but tartans are worth $700 million a year to our economy). The database behind this is surprisingly large (nearly ten thousand rows in the core names and tartans tables) and fairly regularly updated.
So we have the applications set up to run on one website and then embedded these into our other websites using an iframe, enabling simple javascript parameter passing so we can integrate the selection of a tartan or clan with functionality on the embedding site. The iframe is set as noborder so it appears completely seamless to the end user.
Of course there would be other ways of doing this, but the use of an iframe is simple and robust. And it's certainly not obsolete.
Horses for courses... <iframe>s are like anything else... for the right purpose they're the right tool; for the wrong purpose they're an ugly hack, or worse.
In Ajax, <div>s are often the more appropriate container. In some places the activity of passing-off external content as part of your own site, as supported by <iframe>s, is inappropriate.
My team used an <iframe> the other day as an ideal way to give users access to their HTML e-mail history - the e-mails were complete <html> pages which we wanted to insert easily into our web template. <iframe>s were absolutely perfect for presenting that data]'.
On the other hand, <iframe>s should almost always be removed or disabled in any user-submitted content which is output back onto the site, because in that context they are a major security issue.
The google gadget specification currently relies on iframes: http://code.google.com/apis/gadgets/docs/spec.html
Currently they are the only simple way to provide isolation for javascript apps that are pulled from multiple domains/providers.
Also many of the widgets that people embed on their websites from third-parties use iframes.
While they do have their drawbacks, iframes provide a pragmatic solution to common problems on the web. I'd have to guess that they will be around for some time to come.
Compliance and Security issues can also drive you to use Iframes; Shopping carts are popular IFrame-based implementations when you want to visually incorporate a shopping cart as part of some web pages without taking on full responsibility for the payment processing side of things.
We commonly deliver an Iframe to integrate our eCommerce stuff and clients like how turnkey it can be.
I work for a company that used frames for everything from pull down menus, lists, content blocks, etc just to cover the intricacies of .net web forms. The application is very slow and only runs on IE. Don't do this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Somewhere along the line I picked up the notion that using iframes is 'bad practice'.
Is this true? What are the pros/cons of using them?
As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.
One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.
However I've seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.
Usually, if you can do it without an iframe, that is a better option. I'm sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.
With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.
They're not bad practice, they're just another tool and they add flexibility.
For use as a standard page element... they're good, because they're a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to "sandbox" internal pages into an iframe so poor markup doesn't affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don't want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.
For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.
It's 'bad practice' to use them without understanding their drawbacks. Adzm's post sums them up very well.
On the flipside, gmail makes heavy use of iFrames in the background for some of it's cooler features (like the automatic file upload). If you're aware of the limitations of iFrames I don't believe you should feel any compunction about using them.
Having worked with them in many circumstances, I've really come to think that iframe's are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.
Consider the possibilities ... if used for parameterized content, they've created an interface. And in a professional site, that interface requires an SLA and version management - which are almost always ignored in rush to get online.
If used for active content - frames that host script - then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.
If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.
So, although, occaisionally useful within a site, they are rather unsuited to mashups. You're far better looking at real portals and portlets. Worse, they are a darling of every web amateur - many a tech manager has siezed on them as a solution to many problems. In fact, they create more.
Based on my experience a positive side for iframe are when calling third party codes, that may involve calling a javascript that calls a has a Document.write(); command. As you may know, these commands cannot be called asynchronously due to how it is parsed (DOM Parser etc). An example of this is http://sourceforge.net/projects/phpadsnew/ I've made use of iframes to help speed up our site as there were multiple calls to phpadsnews and the site was waiting for the response before proceeding to render different parts of the page. with an iframe I was able to allow the site to render other parts of the page and still call the Document.write() command of phpads asynchronously. Preventing and js locking.
There are definitely uses for iframes folks. How else would you put the weather networks widget on your page? The only other way is to grab their XML and parse it, but then of course you need conditions to throw up the pertenant weather graphics... not really worth it, but way cleaner if you have the time.
The original frameset model (Frameset and Frame-elements) were very bad from a usability standpoint. IFrame vas a later invention which didn't have as many problems as the original frameset model, but it does have its drawback.
If you allow the user to navigate inside the IFrame, then links and bookmarks will not work as expected (because you bookmark the URL of the outer page, but not the URL of the iframe).
It's worth noting that iframes will, regardless of the speed of your users' internet connection or the contents of the iframe, cause a small (0.3s or so) but noticeable slowdown in the speed your page downloads. This is not something you'll see when testing it locally. Actually, this is true for any element added to a page, but iframes seem to be worse.
When your main page loads in HTTP protocol and parts of your page need to work in HTTPS protocol, iFrame can beat jsonp hands down.
Especially, if your dataType is not natively json and needs to be translated on server into json and translated on client back into e.g. complex html.
So nope - iFrame is not evil.
They are not bad, but actually helpful. I had a huge problem some time ago where I had to embed my twitter feed and it just wouldn't let md do it on the same page, so I set it on a different page, and put it in as an iframe.
They are also good because all browsers (and phone browsers) support them. They can not be considered a bad practice, as long as you use them correctly.
I have seen IFRAMEs applied very successfully as an easy way to make dynamic context menus, but the target audience of that web-app was only Internet Explorer users.
I would say that it all depends on your requirements. If you wish to make sure your page works equally well on every browser, avoid IFRAMEs. If you are targeting a narrow and well-known audience (eg. on the local Intranet) and you see a benefit in using IFRAMEs then I would say it's OK to do so.