Do iframes still fit the mold of current web standards? The technology is old but I am seeing them resurface - especially with the new youtube embed code being iframes and facebook just allowing custom tabs to be iframes as well.
My question is basically: Are the acceptable?
Have a look at this SO question: Are IFrames (HTML) obsolete?
In short: They are part of the HTML 5 draft and will be sticking around. If used correctly, I think they are acceptable. :)
I agree with everyone that they should be a last resort, but there are certain things that demand the use of iframes.
For instance, there's no better way to do ajax file uploading than posting to an iframe and then reacting to the iframe's onload event to handle it.
Yes, my company still uses iFrames to embed third-party content on our site.
They still have a place but, IMHO, should be a last resort.
A lot of components such as Facebook's social widgets or Youtube's embeded player use iframes.
I also use some, when needed. Of course I don't abuse it because it's not adapted for all situations.
Related
I'm having trouble finding a way to embed a notion page in an html page. I use iframes to embed spreadsheets but Notion doesn't allow that. Is there any way to do that?
<iframe loading="lazy" src="https://dusty-agate-32f.notion.site/b52eb9b2cf3845c4a59128b7ce1c2228?v=7a8a1bb42918428d8e4b7991214cf2b7"></iframe>
Thank you!
I recently had the same issue, it looks like Notion doesn't allow iframes, it blocks the requests.
I found this tool online: www.notioniframe.com to generate an embeddable URL and the iframe HTML code to include it in any web.
In order for the iframe to work, first make sure the Notion page is public.
Secondly, there isn't an official way to do it, according to this post.
As an alternative, you can export as HTML.
I have been spending my past week on the Internet to find at least one hint about it. There are no tutorials or even SO questions available. What I am trying to find is that when some website uses some library like oEmbed to embed content of other websites on their website, they fetch embed code from its link. For example, when you post a YouTube link on Facebook or other social networks, they automatically fetch their embed code. I know how to fetch embed code but what I don't know is how to provide embed code that can be fetched by other websites by using a link of my website's content?
I want that my article should be embedded in some special way. Not like the default layout of that website. So is there any META tag or something in HTML where I can put embed code for other websites?
I don't think what you want is possible. You can use special meta-tags that specific sites (e.g.: Facebook, Twitter, Linkedin) will interpret, and that will help you customize the share a little (still using the "host site" style). But as far as I know, there's nothing you can do to provide style/code of your own.
And it makes sense from a security point of view: embedding external code from an unknown source is potentially dangerous and no site would/should allow you to do it. Even if they do allow it, they should pre-process the code and sanitize it (adapting your style/code to their style/code) to prevent possible threats.
As suggested by Alvaro Montoro, I searched on the Internet about how to become an oembed provider. Following are the links I found:
https://timnash.co.uk/becoming-oembed-provider/
http://freear.org.uk/content/5-steps-being-oembed-provider
You may want to use the CSS !important directive.
http://css-tricks.com/when-using-important-is-the-right-choice/
Need some advice to use iframe for widget or not.
Will some addons/plugin block the IFrame in browsers?
Use of IFrames for me has no adverse effects.
All the big companies use IFrames for Ad serving, Widgets. We use Iframe for delayed download of a file.
There are heaps of use cases to use IFrames so its not as bad as it sounds. I never came across any plugin or add-on which blocks IFrames.
Even though you can do pretty much everything using Javascript too but end of the day IFrames allows more control over the content I would say.
iframes are pretty common. one example of a popular use is the facebook like button. http://developers.facebook.com/docs/reference/plugins/like/
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 10 years ago.
I was talking with a colleague about a problem we were having and he suggested that one possible solution was to use an IFrame.
I haven't needed to use an IFrame for he last 5 years and I've done full time web application development, but it made me wonder if the concept of the IFrame and Framesets is something that is supported by browsers for backwards compatibility but really shouldn't be actively used in development any more?
it's one of the major application integration methods for facebook and myspace. and most wysiwyg html editors rely on iframe. thickbox uses iframe. drupal uses iframes. and on and on... so not sure if it's so very simple to just call iframe obsolete. i imagine it'll be actively used for a good long while still...
It's the fastest and easiest way to get any of a number of google services into a web page, where the fuller control of the API integration is not needed.
Like anything else, it is situational. It's far from dead, and there's no reason it should be dead. The web's moving to looser coupling, and IFrame is in line with that.
At best the IFrame isn't ideal for rendering local content, but, like others have said, it is the only way to get external web-content into an application without an API and for that reason it is very important to modern web-development.
No, it shouldn't.
It's a cheap standard way to integrate functionality in a single page. Also allows some useful techniques such as COMET
Not sure if it should be dead. For one of the application I worked on for the manufacturing industry, they wanted multiple tabs to be able to run multiple programs on the same page. Knowing using just regular divs using Ajax would just be a little too much for this intensive app, we used iframes. Of course, it doesn't look like iframes to the end user (using some creative Javascripting and CSS), it looks like just a regular tabbed program.
So, saying it's dead is probably a little too soon unless there are better alternatives.
It's extensively used in ad tracking and conversion tracking; it's one of the easiest ways to put a beacon into a site unobtrusively.
I think that iFrames are not dead yet, they can be used for a lot of things and though they slow the loading speed of a website (with a few miliseconds, depends on the content).
iFrames maybe, Framesets NO. this is what i think. some things can be done only with iframes believe me i searched for another solution for a long time but for eg. a jscript can be used 2 or more times with iframes but when used on a single page it may cause conflicts and sometimes only the first thing that was using the javascript is working.
so sometimes iFrames are the right way to do it, if you can`t do it any other way.
No, its commonly used in junction with AJAX.
For example, on a page where you have ongoing AJAX requests you can't disrupt the response by closing it etc. BUT, you may need to provide a file download on the same page which would normally disrupt the AJAX request. To avoid the conflict, you serve the file download through an IFrame so that the AJAX on the host page isn't disrupted.
That's at least one use case for it =)
Iframes are not dead. They are the only method of fighting several extremely annoying bugs in MSIE (such as div overlapping a <select>), and are widely used in banner exchange networks.
If you consider the fundamental building blocks of the web you will realise that the iframe should never be removed. I have the feeling that many web developers do not properly understand the concepts of data centric systems and prefer to work in a procedural, top-down, application centric manner. There are many things done with async HTTP requests and Javascript that should simply use an iframe.
There are two fundamental concepts when it comes to linking content in a data centric world like the web - cross referencing and embedding. Hyperlinks are used to cross reference data while iframes are used to embed data. URLs are used to reference data in both cases.
A simple example is linking to an image. Cross referencing an image would be done as follows:
Link to the image
While embedding an image would be achieved as follows:
<iframe src="someImageURL" />
Of course you could use the "img" element to embed an image instead, but that is specific to images... I vote that the "img" element be removed in favor of using the more generic and flexible iframe.
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.