Develop Reference

What are the pitfalls of embedding using iframe

I am experimenting with Elm to build a reusable dashboard-like UI to be declaratively configured via yaml files.
The yaml files would specify a group of embeddable web-apps (not only elm based but ideally also react/angular/vue) to be included in each instance of this UI, for example by specifying a label and a repository url.
I have tried using the traditional Elm/React way to take over a standard non-iframe dom element with various problems. (mainly, elm replaces the element it takes over, meaning various apps cannot share the same container)
If you want you can see the entire proof of concept here
https://github.com/Dansvidania/mondrian-elm
Are there better ways? (I am sure there are) But also, what are the problems I might encounter if I did decide to go with iframes? I only find anecdotal evidence against iframes, and (in particular for sandboxing) they seem ideal.
Thanks in advance

From Cam Jackson's Micro Frontends artice on martinfowler.com
Just as with the server-side includes option, building a page out of iframes is not a new technique and perhaps does not seem that exciting. But if we revisit the chief benefits of micro frontends listed earlier, iframes mostly fit the bill, as long as we're careful about how we slice up the application and structure our teams.
We often see a lot of reluctance to choose iframes. While some of that reluctance does seem to be driven by a gut feel that iframes are a bit “yuck”, there are some good reasons that people avoid them. The easy isolation mentioned above does tend to make them less flexible than other options. It can be difficult to build integrations between different parts of the application, so they make routing, history, and deep-linking more complicated, and they present some extra challenges to making your page fully responsive.

I use iframes without issue.
Communicating with javascript code embedded in an iframe works but I always feel such code is nailed together and lacks elegance.
I set up messages between the parent web page and the iframe to overcome domain issues and also to clarify the communication that occurs between the parent page and the iframe.
Cookies and iframes do not play well cross domain - but this can be resolved.

iFrame or a remote JS File

I've got a complex page that can be customized and should be embedded in some clients' websites. For each client it should look the same, but the parameters can be little different. The page also contains a custom object that uses a plugin in the browser.
I had 2 idea to accomplish this:
Using an iFrame - so I just embed my page and pass parameters in the
querystring.
Using a remote JS file - like Facebook SDK and others
work. Passing parameters in the JS code. As I understand, I can just put some 'parent' div on the page and the remote JS file, which should fill the parent div with the needed elements.
Which one should I use? What are the cons / pros of each one?
Thanks!

Take a look at this article which has an in depth look into the ways of what you're trying to achieve.
Pros of IFrame:
If the owner of the mashup page is really concerned with security, malicious scripts running in the widget, then the IFRAME approach is preferable, because the widget’s script will have limited access to the host page and hence couldn’t make much harm to the page where it's embedded into.
Also, this approach is preferable if the owner of the widget wants to control the layout and styling of his/her widget. Since the IFRAME is essentially a separate web page, the mashup’s CSS scripts can’t do much harm to the widget.
Cons:
it is slow, resource intensive [on the browser], and does not give the owner of the mashup page an ability to style the widgets the way s/he wants.

I've had similar issue some time ago. You bassicaly have three options to choose depending how secure and flexible your plugin should be.
iframe
pros
fairly secure - you can present data that should be viewed to specyfic user only and allow passing sensitive data to your service. Page that includes your plugin will not have access to it.
page that includes your iframe will not be able to modify it's content to confuse user
cons
slow
limited communication between your plugin and the page(may be solved by between-window post message/porthole, but this is not perfect)
page still may scam users into beliving they see your plugin, while present own copy or use click jacking
if you include any assets from 3-rd party server that bit of security you had is lost
limited to rectengular box
script
pros
extremly flexible
easy to implement variety of callbacks to react on events on the page
fast
may integrate with interface of the page in many different ways and spots
cons
basically can be modfited in any possible way by page that includes it. You have no controll what users will see in the end.
redirect through your service and then back
pros
most safe solution
cons
hardest to seamlessly integrate
may not interact with other elements of website that uses plugin(since when users see your plugin they are't seeing source website anymore)

Javascript isn't good for SEO, is it?

If I decided to use some javascipt in my website like
$('#body').load(URL);
or
$.get(URL, {param:value}, function(){ ... });
or
window.title = 'TEXT';
Is it good for SEO? Or am I recommended to use pure PHP for data on the page for SEO purposes?

The question of if javascript is good for SEO or not is missing the point. We should pretty much assume that any content which is only available by javascript will not be crawled by the search engines. Google at least claims to be able to crawl some javascript only content but is fairly tight lipped about what exactly they can crawl. Other search engines probably don't crawl it and it's certainly the case that not all do. So assume it doesn't get crawled.
That doesn't mean it's bad for SEO.
If the content will contribute to your SEO, then it's bad for SEO. If the content is neutral to SEO, then it's neutral for SEO. So the answer to your question really depends on the nature of your content. If the content is part of your SEO campaign, then stick with server-side HTML generation be it PHP or some other method. Otherwise the question of SEO has no bearing on the decision to to use javascript or not. Accessibility would be another thing to take into account. Javascript only content is terrible for that.

The larger search engines can/do render limited amounts of javascript. However, for SEO purposes your best bet is rendering the content via HTML rather than javascript. A good rule of thumb is to utilize HTML for content/expressing limited content structure (e.g. paragraph type text = p, lists = ul/ol, headings = h1/h2/h3, etc...), CSS for presentation, and JS for client side programming. With that being said, always ensure a good user experience first. If you can do the above while providing a great user experience, great! If you can't, users first. Its likely you can keep both users and bots happy 95% of the time if you take the time to do so.
Further reading (sorry, I can only post one link as a new user):
Matt Cutts Interview (Check out #26 on Google Javascript Rendering)
A spider's view of Web 2.0
EDIT Added that for "a new user" ;) ~ drachenstern

I think first you should consider what SEO means. It means "Search Engine Optimization" ... how does a search engine get data in the first place for it to be optimized?
It does a GET on the page and whatever data is returned in the GET is processed. No JS engine. No POST data. So you should be optimizing for whatever data is returned on a GET.
Additionally, you tagged this with PHP, but the question has nothing to do with PHP.
Have you seen any of the questions on this list?
https://stackoverflow.com/search?q=javascript+seo

No Sir, Google does not translate flash and java script properly so it may not crawl those area using java script or flash content. I suggest you should keep your website simple but if it is necessary to keep flashy/java script content then you should keep a text base backup.

The first thing you should be asking is not what is good for SEO, but what is good for users. For users, loading data with JavaScript will give them an interactive page, where they can start seeing the page immediately while it is still loading and where the page can update without having to reload it.
From Google's Webmaster Guidelines and article on Cloaking, you should not assume that crawlers can understand JavaScript. This does not mean that you should not use JavaScript on your website, but rather that you should provide the textual equivalent in noscript tags, for use both by users with JavaScript disabled
as well as for crawlers, bearing in mind that the content of these noscript tags should be roughly equivalent to what was shown with JavaScript enabled; showing different content to users and to search engines is called "cloaking" and is frowned upon to say the least.

Google doesn't (yet) execute a page's Javascript (JS). So if your JS replaces/creates content on a page then the content would normally be invisible to the crawlers (not good).
But, the Googlers have implemented a url hack that enables your server to create pages (from the server, not from JS), with all the different varients of your JS page's content.
This solves the SEO problem of Ajax powered pages. At least for Google searches...
See Crawable Ajax

Javascript or any scripts for that matter should never be used to house your sites content, ever! The entire web is driven by HTML and CSS, and in rare cases XML languages, everything else is a headache when it comes to SEO. Ask yourself this question, what exactly is SEO and what is it that search engines are indexing? Javascript and all programming/scripting languages are proprietary, this means that they are NOT standards as defined by the W3C, which means they are essentially worthless when it comes to indexing content. On the other hand, HTML, CSS, and XML are real standards developed for the web! It's ok to use scripts to add additional functionality to your pages, embed apps like social networking plugins, etc, but you should never use them to hold your websites HTML, CSS, or actual content ever, for any reason. Here's a link to a good article that will explain why you should be using HTML and CSS, and not a million scripts, optimizing webpages using proper html markup. Scripts cause other problems besides code that is hard for search engines to decipher. For one, they are harder for browsers to process, causing pages to load much slower than "static" pages made with HTML and CSS would. Pages made with PHP tend to create "dynamic" URL's that users and search engines cannot read. This is why Google recommends people who use jsp or PHP for their webpages include a sitemap, otherwise your links will never be found and might as well not exist. Stick to the conventions! Lets face it, we have standards for a reason. If every electronic component in your home required had a different type of plug that required a special socked, and all those devices had differing voltage and amperage requirements, what would happen? You would essentially burn down your house! And, you'd be spending 5 hours a day at the hardware store looking for those special adapters to fit your wall sockets with. If you plan on designing a website, use scripts for embedding apps or connecting with a database only, and use HTML and CSS to build "static" webpages. Also, use text links, as they are both human and search engine readable, and easy to index and make sense of. Never use scripts for your links. Programming and scripting can be fun, but not on the internet its not.
Search engines index HTML, CSS, and content (multi-media, graphics, videos, text, thats it!) everything else is pointless and annoying to both users and search engines alike. For best results use XML and design a custom language.

Google can crawl, index and rank javascript generated content.
But... it uses an old Chrome version (42) with an old javascript render engine.
The consequence is that your javascript code needs to work in older browsers and older chrome versions (older than 42). So no fancy ES6 functions, you need to use polyfills or use Babel for example.
Although you can do a lot with javascript (like click events or inject your mobile menu), it's recommended to still use a-href instead of a button with a javascript event and then using a function to get to a new page.
You can check the mobile testing tool from Google: https://search.google.com/test/mobile-friendly and check the errors/warnings/logs. If the rendered output looks like intended, Google will see your content.
In search console you can also ask to index the page. Sometimes the javascript crawler is first, sometimes the 'classic' crawler.
Doublecheck it some days afterward by googling a sentence or paragraph from your page.
There's no answer about if it's better or not. Content is content and Google should rank your website, SPA, PWA, AMP site, PDF document, online Doc, wikipage, and so on based on their content, not on the underlying technique.
If you are familiar with JavaScript, give it a go.
Regards, Peter

Javascript widget (similar to Facebook Like) script vs Iframe approach

When building a social bookmarking button widget for usage in other websites there are a few challenges. We just recently opensourced the clientside aspects of this. (blog post here: http://www.mellowmorning.com/2010/08/03/creating-your-own-diggfacebook-liketweetmeme-button/)
Basically the goal is to replace the chosen elements
love it
With a button showing how many other people loved it.
There are two approaches to this.
- replace the A with html (script approach)
- replace the A with an iframe (iframe approach)
There are rather complicated differences between these approaches. One particularly annoying is the inability for the script approach to communicate with its popup.
Can anyone suggest a workaround to communicate between the login popup and the button. (IE. when you love something through the popup?, how do you update the count on the button, without being stopped by same origin protection..)
Which approach do you recommend. Iframe or Script and why?
These are the differences I encountered: Iframe vs Script
Iframe:
Popup communication possible
The script approach cannot communicate with popups it creates due to the same origin restrictions. The iframe however can be of the same domain as the popup and freely communicate. This gives a better user experience when for instance logging in.
Easier to develop
The iframe approach is easier to develop and requires less code.
Parallel download in IE
IE doesn’t download the count scripts in parallel, but it does do so for the IFRAMEs. Making this approach somewhat faster.
Independent CSS
External sites don’t interfere with your button’s css if you use an iframe technique. The disadvantage is that it makes things likes hovers impossible to integrate with the other site. (For example Fashiolista’s compact button).
Independent
The iframe approach makes it very hard for other sites to game the users like/love action. With a script approach a foreign site can simply call your javascript to fake someone loving the product. This freedom can be abused but also allows for mashups.
Script:
Slower dom load
Creating iframes takes a lot more time for the browser.
Slower perceived load
The script approach allows you to format the buttons before the data is loaded. Vastly increasing the perceived load speed.
No shared functionality
Buttons can’t share functionality. So when someone logs in for one button its is not possible to update the others.

There is of course a third option too, which is a hybrid between the iframe and the script approach.
You can use script to hook into the pages DOM (gives a loot of freedom with regards to different uses), and to create a hidden iframe pointing to your domain.
The script could communicate both with the current document, and with yours using Cross Domain Messaging and in turn with the popups using the iframe as a proxy.
Of course, the XDM does impose some difficulties, but if you use a proved solution like easyXDM, then it shouldn't be much of a problem.
Here is an example that shows how to interact with a popup.

Basically 2 questions
- Which is the best approach
- Workaround for the popup communication difficulties the script approach faces
Thanks for the popup information!
What is the underlying technology to support these cross domain popups?
If i understand your third option correctly:
- foreign site loading our js
- js replacing dom elements
- js opening hidden iframe to own domain
How do I then open a popup which still allows for communication with our js loaded into the foreign site? For that the popup would need to be instantiated by the iframe right? And we would need a method to communicate with the iframe. I thought im not allowed to do anything with the iframe except setting its window.location.href. Could you explain how that works?

Are iframes a terrible idea? [closed]

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'm building a widget, and I've been using iframes to present content within it. At some point, I might start serving third party HTML and JS, so I thought iframes would be a good idea.
It does make the widget javascript a little more complicated, and I'm concerned that this might not be the best implementation.
Do you have any advice? It would be a huge help to hear what other people think about iframes.

No, nothing wrong with iframes. Iframes are probably a better idea if you're going to start serving third party content.
The upcoming HTML5 spec also plans to build more security features into iframes for situations like this, so I would consider it good practice to use them now also.

Before XMLHTTPRequest became widely used, people were using a combination of JavaScript and iframes to serve up content in a dynamic fashion without doing full page refreshes.
There's lots of information about developing sites this way so you should have a relatively easy time of it finding workaround to a lot of the snags that you are likely to hit.
The one thing that I have found to be a pain is cross-domain use of JavaScript in iframes. If the page you embed in the iframe is from a different domain than the "parent" page, browsers have security restrictions against letting you access one from the other. The trick is for both pages to declare
document.domain = 'somedomain.com';
There's plenty of stuff on the Web about this kind of workaround.
Good luck!

One thing I discovered recently is that .aspx pages embedded inside iframes sometimes have problems with losing cookies, which led to lost session state in an application I was involved with.
For me, it was in a scenario where a different development shop was consuming one of my .aspx pages in their own page. This means we were on seperate servers, which may or may not be salient.
Apparently this was caused by the parent page rejecting cookies for the child page... As goes the session cookie, so goes the session.
The specific mechanics of how this works are a little involved: More Details
This problem did not impact FireFox, but it did show up in IE7 and it was a real mystery for a few hours.
Also, I have to contradict the article I linked to above on one point. The article says that you don't get this if the containing page is also an .aspx... In this case, that was not true because both pages were .aspxs.
That casts some doubt on everything else the article says about this situation, but it did lead to a resolution, so that's something as well.
As the article suggested, I put in the following code, which injects a p3p (Privacy Preferences Project - I had never heard of it) header in the page's Init event:
HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")
...And that fixed the problem.

I'm going to disagree with the majority and say that yes, iframes are an absolutely terrible idea. Anyone that has worked within the Web Design community for a while will agree that iframes are pure evil and should be avoided unless ABSOLUTELY essential.
My reasons for believing that they are bad is because they break the navigational pattern of a web page. By using an iframe you can effectively break the back and forward buttons on browsers and confuse your users. It breaks the entire idea behind the HTTP protocol; that a URL will always lead to a unique location. If the iframe were a horse it would've retired long ago. There are other ways to serve content dynamically and these should be used instead.
If you're creating a widget then the immediate concerns with using iframes disappear (bad for Search Engines, bad for Bookmarking, etc), but either way content would be better served dynamically or even in a new window rather than in an iframe.

There is only one "really bad" thing with them that I'm aware of.
If your 3rd party does some JavaScript, that attempts to modify their DOM a bit too early... IE6 and IE7 will throw the oh so unhelpful "Operation Aborted" error, then blank out not only the iframe, but the entire surrounding page. (e.g. your site appears down)
It isn't fixed in IE8, but the crash is better handled.

Personally, I'd avoid it if you can without too much hassle. Using Javascript (or AJAX if you need to load them dynamically), you can quite easily just use a div and change the contents as necessary - in some cases this will give you much more flexibility and will simplify your JS, especially if there's a lot of interaction between your widget and the rest of the page.
That said, I'd investigate both options, and if the JS path seems too tricky or complicated, just go with iframes.

In my experience, iframes are either hacks or time-savers - make sure that if you're using them they're neccesary for those reasons. If you have control over the content (or can gain control through mirroring or scraping) you should consider using AJAX or server-side includes to pull external data onto and push it off of the page - it'll end up being more flexible, more robust, and easier to manage in the end.

Depends what the widget does. Iframes have their place, but they do cause few layout headaches (not to mention making your js more complicated) so most people tend to avoid them unless absolutely necessary..

iframes, like frames, are just controls to use for the task at hand. As such, it is neither good nor bad in itself, but could be good or bad based on the task at hand and the client's requirements. As far as I know, all modern browsers (and non-linux users) will be able to "see and consume" iframes without a problem.

A good option is to use the overflow CSS property. The default value is visible but you can set it to hidden, scroll or auto. I would use auto in your case. If your content gets too big it will look like you have an iframe but it is still right on the page.
see: overflow property

Iframes are not evil they are just another tool like anything else and to determine their merits you have to determine the context in which they will be used. Google Image Search, and several other high profile sites, use iframes for limited purposes.
In general I find they are used for branding or to enable a user to return to a site that redirects the user off site.
Note, if you are using cross domain iframes e.g. an iframe that refers to a domain outside where the page is being served you are limited by design for security reasons and cannot access through javascript the internals of a DOM outside the domain it is associated with.
Also please note many sites prevent their site from being embeded and will stripe the iframe off (redirecting the top url to their domain).

Not necessarily, as long as the content within the iframe is predictable.

Technically there is nothing wronger with iFrame that with alternatives. But semantically, there are evil.
The Web is based on HTTP, a protocol that says a given URL will always leads to a unique ressource.
Using iFrame, you just serve several ressources melted in a web pages behind one URL for all of them. If you have concerns about how the Web should grow, it's troublesome. What's more, for the search engine robots, it's tricky.

There are several usability and accessability issues with iframes. Some browsers and screenreaders can not display iframes, so you should provide alternative content:
<iframe src="content.html">
<p>
This content will only be displayed by browsers that do not support
iframes. You should provide a link to the content, or in your
case an alternative way to use your widget.
</p>
</iframe>
If you start serving third party content, you should watch out for the iframe grabbing focus after it has finished loading. While a minor annoyance for regular users, it can be very confusing for users browsing with screenreaders.

Re: "the entire idea behind the HTTP protocol; that a URL will always lead to a unique location"
I serve my entire CMS from the same URL for security and scaleability (using mostly POST instead of GET parameters). I don't want secure content visible without authentication, and a dispatch system makes development easier for me as I don't have to worry about authentication for every new page.
Also, for some applications SEO is not applicable (such as for web-based ERP).
I use an iFrame for serving content from a PHP generated assembly tree. I don't want the tree (and node visibilities) refreshed whenever the user wants to view details for a part/assembly.

There is a significant issue with iframes that hardly gets a mention but which bugs the stuffing out of me.
Our colleague has a lifetime of work invested in a dynamically changing database which we have loaded into Google Docs spreadsheets which we then display on our site alongside a lot of supporting material.
There is absolutely nothing to stop someone grabbing the iframe code out my page source and shoving it onto their page. Now they are getting all our data, refreshed right up to a few minutes ago, served to their page for absolutely nothing at all.
If a google iframe could be tied to a specific domain, that would stop that in its tracks.
Any ideas, bright sparks?