Our goal is to let a person, similarly to how you can embed a youtube video, embed a tree of web pages on our SaaS into their own site.
The solution should be good looking, cross-browser, responsive and simple for the end user (ideally, should be search-bot friendly as well).
We are considering two primary options where the customer only needs to copy+paste a code snippet which supports embedding in a portion of the page (ex: the middle column) or full width (ex: everything under a header):
IFRAME: Let the user embed an iframe inside a div, together with a snippet of JS that would resize the iframe as the window is resized.
JS "APP": Let the user paste in a script tag to a JS script/app which would communicate cross-domain (via CORS or JSONP) with our servers.
Ideally, we would like to be able to launch full screen modals from our content.
Questions/concerns for:
IFRAME:
Can an iframe reliably update the URL of the parent’s browser window?
Can we reliably launch full screen modals from an iframe?
Can we reliably get the iframe to resize when the window is resized or iframe content changes?
JS "APP":
How significant is the overhead of dealing with properly encapsulating our app to avoid naming/library conflicts? For example, we will ideally stick to vanilla JS but if we want to use a library like Ember and a customer of ours has an Ember site.
Any non-obvious cross domain gotchas? We will be using CORS or JSONP.
We would like input on both the:
technical limitations of what’s possible to do
practical hurdles we’d have to overcome going down each path.
p.s. We’re also considering a back-up option, which is to “fake” integration, where we host the content on our site with a subdomain URL (similarly to how Tumblr lets people host their blog on something like “apple.tumblr.com”). If we go down this path we imagine letting the user theme the subdomain. We understand the pros and cons of this path. Downsides are, it’s more work for the user, and they need to keep two different sites in sync visually.
I think the best approach is to use the same approach Google and other big companies have been using for quite some time, the embedded script. It is way better looking and semantically unharmful (as an iframe could - arguably - be), and super cross-browser and simple, in fact, just as cross-browser and simple as the code that will be pushed (it can be recommended to be put in a <script async> tag, which will eliminate the need for a crafted async script and, though it won't be as full compatible, it degrades okay and will work very well on most cases).
As to the CORS, if basic cautions are taken, there's no need to worry a lot about it. I would say, though, that if you're planning to do something in Ember or Angular to be embedded, that may be a whole load of scripts/bytes that can even slow down the site/app and impact on the whole user experience, perhaps too much for a component that would be loaded like that. So whenever possible, vanilla JS should always be used in components, especially if Ember/Angular is used because of specific features like binding (specific vanilla JS codes can cover that with much less weight).
I am coding a Web app that needs to have multiple tabs/Web pages open. And I would like them to talk to each other. And I don't want the pages to talk to the server. So is it possible with HTML5/JS? By the way they are all on the same domain name.
I've never come across a webapp which used the browsers tab functionality as a means of navigating. I don't want to say it's wrong, because I don't know your particular requirements and, of course, I haven't played with every single webapp in the world.
However, would it not make more sense to implement your own tabbing system within your web app than rely on a feature of the browser which is probably inconsistently implemented and which may be affected by the user's personal settings?
If you're set on this path, and offline functionality is a definite requirement, then I think your only option is using the LocalConnection feature of Flash, as Brad suggests in the comments. I imagine you could create a bridge with ExternalInterface to pass any data from Flash to the page. The Flash would need do nothing else but marshal the communications (it could occupy a single pixel somewhere on the page). This is a similar approach to the one the dojotookit took with their Flash storage, designed to provide a more capable alternative to cookies.
I think the answer here is that what happens in the view, doesn't have to reveal whats happening behind the scenes.
You can make DOM elements on a page communicate with other DOM elements on the page without making a asynchronous call to the server if thats what you're asking.
If you have two tabs in the.. lets say chrome browser, and you want one DOM element to talk to another DOM element on a completely different browser tab. You have to make that asynchronous call to the server which will shoot one back to the other tab. But you don't have to show that happening in the view :) (This can be done with Node.JS/Socket.io, an example would be a chat room built with HTML5/JS)
Hope this helps
I know this is an older post, but you may want to look into local storage, or even cookies set via javascript.
There are 2 reliable ways you can have pages in other tabs (or across iframes) talk to each other.
The postMessage API allows pages to send messages even when they are on different domains. There are some security issues to be aware of to avoid malicious behavior. You can read about that in the linked article.
localStorage and sessionStorage will dispatch a "storage" event when they are changed. Using this event you can be notified in other tabs when the data has changed. This only works within the same domain. Because this is all you need, it might be the wiser option to avoid any security issues.
I want my customers create their own HTML on my web application and copy and paste my code to their website to showing the result in the position with customized size and another options in page that they want. the output HTML of my web application contain HTML tags and JavaScript codes (for example is a web chart that created with javascript).
I found two way for this. one using iframe and two using jquery .load().
What is better and safer? Is there any other way?
iframe is better - if you are running Javascript then that script shouldn't execute in the same context as your user's sites: you are asking for a level of trust here that the user shouldn't need to accede to, and your code is all nicely sandboxed so you don't have to worry about the parent document's styles and scripts.
As a front-end web developer and webmaster I've often taken the decision myself to sandbox third-party code in iframes. Below are some of the reasons I've done so:
Script would play with the DOM of the document. Once a third-party widget took it upon itself to introduce buggy and performance-intensive PNG fix hacks for IE across every PNG used in img tags and CSS across our site.
Many scripts overwrite the global onload event, robbing other scripts of their initialisation trigger.
Reading local session info and sending it back to their own repositories.
Loading any number of resources and perform CPU-intensive processes, interrupting and weighing down my site's core experience.
The above are all examples of short-sightedness or malice on the part of the third parties you may see yourself as above, but the point is that as one of your service's users I shouldn't need to take a gamble. If I put your code in an iframe, I know it can happily do its own thing and not screw with my site or its users. I can also choose to delay load and execution to a moment of my choosing (by dynamically loading the iframe at a moment of choice).
To argue the point in terms of your convenience rather than the users':
You don't have to worry about any of the trust issues associated with XSS. You can honestly tell your users they're not exposing themselves to any unnecessary worry by running your tool.
You don't have to make the extra effort to circumvent the effects of CSS and JS on your users' sites.
I'm making a HTML5 page (game) which uses lot of popups and all kind of widgets appearing and dissapearing in the same page.
To implement this I could
Have all the popups and widgets listed in the page, invisible (like lot of examples I saw), and keep toggling only visibility.
Add and remove dynamically, using Javascript. I could put each popup as HTML fragment in a separate file (?).
The seconds is "modular" and I like the fact that I have no elements in the page which I'm not acutally using. But I don't know about performance (load HTML each time, DOM insertiong, etc.).
Is there a prefered/standard way to do this?
If we are talking about loading HTML from server, then obviously this won't be efficient.
I don't know what kind of game you are writing but I don't think there will be any visible difference in performance (except for loading data from server) unless you create like thousands popups per second (I doubt it). Let's be honest - your game isn't using like 4GB of memory. :) And if it is, then you're probably doing something wrong. And I do not think there is any standard way. It's more like how you feel it. :)
For example I always try to load every possible data from server with one request and store it on client-side, because most problems with performance is actually related to client-server communication. I also like the DOM to be clean, so in most cases I hold the (hidden) data in JavaScript, except for forms' hidden fields.
On the other hand, if I have for example blog with discussion and I load some additional data (for example user data, which is supposed to appear as a popup after click on the user's name) I tend to store it in DOM elements because it is easier (at least for me) to control it (I'm talking about jQuery and jQuery UI).
Note that it is possible that recreating popups may lead to memory leaks, but it is highly unlikely if you use some popular library like (for example) jQuery UI.
I have to develop a widget that will be used by a third party site. This is not an application to be deployed in a social networking site. I can give the site guys a link to be used as the src of an iframe or I can develop it as a JavaScript request.
Can someone please tell me the trade offs between the 2 approaches(IFrame versus JS)?
I was searching about the same question and I found this interesting article:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Widgets are small web applications that can easily be added to any web
page. They are sometimes called Gadgets and are vastly used in growing
number of web pages, blogs, social sites, personalized home pages such
as iGoogle, my Yahoo, netvibes etc. In this blog I use several
widgets, such as the RSS counter to the right which displays how many
users are subscribed to this blog (don’t worry, it’ll grow, that’s a
new blog ;-) ). Widgets are great in the sense that they are small
reusable piece of functionality that even non-programmers can utilize
to enrich their site.
I’ve written several such widgets over the time both “raw” widgets
that can get embedded in any site as well as iGoogle gadgets which are
more structured, worpress*, typepad and blogger widgets, so I’m happy
to share my experience.
As a widget author, for widgets that run on the client side (simple
embeddable HTML code) you have the choice of writing your widget
inside an iframe or simply inline the page and make it part of the dom
of the hosting page. The rest of the post discusses the pros and cons
of both methods.
How is it technically done? How to use an iframe or how to implement
an inline widget?
Iframes are somewhat easier to implement. The following example
renders a simple iframe widget: http://my-great-widget.com/widgwt' width="100" height="100"
frameborder='0'>
frameborder=’0′ is used to make sure the ifrmae doesn’t have a border
so it looks more natural on the page. The
http://my-great-widget.com/widget is responsible of serving the widget
content as a complete HTML page.
Inline gadgets might look like this:
function createMyWidgetHtml() { return "Hello world of widgets"; }
document.getElementById('myWidget').innerHTML = createMyWidgetHtml();
As you can see, the function createMyWidgetHtml() it responsible for
creating the actual widget content and does not necessarily have to
talk to a server to do that. In the iframe example there must be a
server. In the inline example there does not need to be a server,
although if needed, it’s possible to get data from the server, which
actually is a very common case, widgets typically do call server side
code. Using the inline method server side code is invoked by means of
on-demmand javascript.
So, to summarize, in the iframe case we simply place an iframe HTML
code and point the source of the iframe to a sever location which
actually serves the content of the widget. In the inline case we
create the content locally using javascript. You may of course combine
usage of iframe with javascript as well as use of the inline method
with server side calls, you’re not restricted by that, but the paths
start differentially.
So what is the big deal? What’s the difference? There are several
important differences, so here starts the interesting part of the
post.
Security. iFrame widgets are more secure.
What risks do gadgets impose and who’s actually being put at risk? The
user of the site and the site’s reputation are at risk.
With inline gadgets the browser thinks that the source of the gadget
code code comes from the hosting site. Let’s assume you’re browsing
your favorite mail application http://my-wonderful-email.com and this
mail application has installed a widget that displays a clock from
http://great-clock-widgets.com/. If that widgets is implemented as an
inline widget the browser thinks that the widget’s code originated at
my-wonderful-email.com and not at great-clock-widgets.com and so it’ll
let the widget’s code ultimately get access to the cookies owned by
my-wonderful-email.com and the widget’s evil author will steal your
email. It’s important to realize that browsers don’t care about where
the javascript file is hosted; as long as the code runs on the same
frame, the browser regards all code as originationg at the frame’s
domain. So, you as a user get hurt by losing control over your email
account and my-wonderful-email gets hurt by losing its reputation.
If the same clock would have gotten implemented inside an iframe and
the iframe source is different from the page source (which is the
common case, e.g. the page source is my-wonderful-email.com and the
gadget source is great-clock-widgets.com) then the browser would not
allow the clock widgets access to the page cookies, nor will it allow
access to any other part of the hosting document, including the host
page dom. That’s way more secure. As a matter of fact, personal home
pages such as iGoogle don’t even allow inline gadgets, only iframe
gadgets are allowed. (inline gadgets are allowed only in rare cases,
only after thorough inspection by the iGoogle team to make sure
they’re not malicious)
To sum up, iframe widgets are way more secure. However, they are also
way more limited in functionality. Next we’ll discuss what you lose in
functionality.
Look and feel In the look and feel battle inline gadgets (usually**)
win. The nice thing about them is that they can be made to look as
part of the page. They can inherit CSS styles from the page, including
fonts, colors, text size etc. Iframes, OTHO must define their CSS from
the grounds up so it’s pretty hard for them to blend nicely in the
page.
But what’s even more important is that iframes must declare what their
size is going to be. When adding an iframe to a page you must include
a width and a height property and if you don’t, the browser will use
some default settings. Now, if your widget is a clock widget that’s
easy enough b/c you know exacly what size you want it to be, but in
many cases you don’t know ahead of time how much space your widget is
going to take. If, for example you’re authoring a widget that displays
a list of some sort and you don’t know how long this list is going to
be or how wide each item is going to be. Usually in HTML this is not a
big deal because HTML is a declarative based language so all you need
to do is tell the browser what you want to display and the browser
will figure out a reasonable layout for it, however with iframe this
is not the case; with ifrmaes browsers demand that you tell it exactly
what the iframe size is and it will not figure it out by itself. This
is a real problem for widget authors that want to use iframes – if you
require too much space the page will have voids in it and if you
specify too little the page will have scrollbars in it, god forbids.
Look and feel wise, inline wins. But note that this really depends on
your widget application. If all you want to do is a clock, you may get
along with an iframe just as well.
Server side vs. Client side IFrmaes require you specify a src URL so
when implementing a widget using an iframe you must have server side
code. This could both be a limitation and a headache to some (owning a
server, domain name etc, dealing with load, paying network bills etc)
but to others this is actually a point in favor of iframes b/c it
let’s you completely write your widgets in server side technologies,
so you can write a lot of the code and actually almost all of it using
your favorite server side technology whether it be asp.net, django,
ror, jsp, struts , perl or other dinosaurs. When implementing an
inline gadget you’ll find yourself more and more practicing your
javascript Ninja.
What’s the decision algorithm then? Widget authors: If the widget can
be implemented as an iframe, prefer an Iframe simply for preserving
users security and trust. If a widget requires inlining (and the
medium allows that, e.g. not iGoogle and friends) use inline but dare
not exploit users trust!
Widget installers: When installing a widget in your blog you don’t see
a “safe for users” ribbon on the widgets. How can you tell if the
widget is safe or not? There are two alternatives I can suggest: 1)
trust the vendor 2) read the code. Either you trust the widget
provider and install it anyway or you take the time to read its code
and determine yourself whether it’s trustworthy or not. Reality is
that most site owners don’t bother reading code or are not even aware
of the risk they’re putting their users at, and so widget providers
are blindly trusted. In many cases this is not an issue since blogs
don’t usually hold personal information about their readers. I suspect
things will start changing once there are few high profile exploits
(and I hope it’ll never get to it).
Users: Usres are kept in the dark. Just as there are no “safe for
users” ribbons on widgets site owners install, there are no “safe to
use” sites and basically users are kept in the dark and have no idea,
even if they have the technical skills, whether or not the site they
are using contains widgets, whether the widgets are inline or not and
whether they are malicious. Although in theory a trained developer can
inspect the code up-front, before running it in her browser and losing
her email account to a hacker, however this is not practical and there
should be no expectation that users en mass will do that. IMO this is
an unfortunate condition and I only hope attackers will not find a way
of taking advantage of that and doom the wonderful open widget culture
on the web.
Happy widgeting folks!
Some blog platforms have a somewhat different structures for widgets and they may sometimes have both widgets and plugins that may
correlate in their functionality, but for the matter of the discussion
here I’ll lously use the term widget to discuss the “raw” type which
consists of client side javascript code
** Although in most cases you’d want widgets to inherit styles from the hosting page to make them look consistent with it, sometimes you
actually don’t want the widget to inherit styles from the page, so in
this case iFrames let you start your CSS from scratch.
Why not doing both ?
I prefer to offer third party sites a script like:
<script type="text/javascript" src="urlToYourScript"></script>
the file on your server looks like :
document.writeln('<iframe src="pathToYourWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
UPDATE:
one disadvantage of using an iframe that points to an url on your server is that you do not generate a "real" backlink if someone clicks on an url from your server pointing to your server.
I'm sure many developers/site owners would appreciate a Javascript solution that they can style to their needs rather than using an iframe. If I was going to include a component from a third party, I would rather do it via Javascript because I would have more control.
As far as ease of use, both are similar in simplicity, so no real tradeoff there.
One other thought, make sure you get a SSL cert for whatever domain you're hosting this on and write out the include statement accordingly if the page is served over SSL. In case your site owners have a reason for using SSL, they would surely appreciate this, because Firefox and other browsers will complain when a page is served with a mix of secure/insecure content.
If the widget can be embedded in an iframe, it will be better for the frontend performance of the hosting site as iframes do not block content download. However, as others have commented there are other drawbacks to using iframes.
If you do implement in javascript, please consider frontend performance best practices when developing. In particular, you should look at Non blocking javascript loading. Google analytics and other 3rd party widget providers support this method of loading. It would also help if you can load the javascript at the bottom of the page.
Nice to know that it's not to be deployed in a social networking site... that merely leaves the rest of the web ;-)
What would be most useful depends on your widget. IFrames and javascript generally serve quite different purposes, and can be mixed (i.e. javascript inside an iframe, or javascript creating an iframe).
IFrames got sizing issues; if it's supposed to be an exact fit to the page, do you know that it renders the same on all browsers, the data won't overflow it's container etc?
IFrames are simple. They can be a simple, static HTML-page.
When using IFrames, you expose your widget quite plainly.
But then again, why not have your third party site simply include the HMTL at a given url? The HTML can then be extended to contain javascript when/if you need it.
Pure Javascript allows for more flexibility but at the cost of some complexity.
The big plus of iframes: all CSS and JS is separated from the host page, so your existing CSS just works. (If you want the host site to style your content to fit in, that's a minus of course.)
The big minus of iframes: they have a fixed width and height and scroll-bars will appear if your content is larger.