CODEWITHSUNDEEP
javascripthtmliframeembed
TimKlimowicz
TimKlimowicz

Reputation: 691

Using javascript to write an iframe for a widget - best practices / limitations?

I'm in the middle of development of a third-party widget of sorts (an HTML5/js video player), designed to be embeddable on third-party sites seamlessly, which works in conjunction with a Flash player (the HTML5/js player in this case is a fallback).

To allow external embedding via a single gateway, we're offering embed code that looks roughly like this:

<script src="http://example.com/embed.php?id=12345678&width=400&height=300"></script>

Note the .php extension. What this script does is perform some basic browser agent detection, run a bit of backend logic based primarily on the 'id' query string, and then echo javascript that document.write's to the page the actual embed code.

If it's a Flash-enabled device, the document.write code is the straight <object> Flash embed code (no iframe; straight to their page); if it's an iOS device, it writes the <iframe>, whose src points to an HTML document that is the HTML5/javascript player -- with its own .js in the <head>, a set of <div>s in the body that make up the HTML5/js player, etc.

I'm sure this can be cleaned up / done better. So, my questions:

  1. What steps, if any, can or should be removed?

  2. Is it a good idea to begin with to drop the HTML5/js version into an iframe, rather than write it all to the page directly? What about the external .js that is needed, which we use in the <head>? Also, in the future, we're likely to need some 2-way communication with our site (same domain as the iframe src), so the iframe offers a good way to allow this, correct?

  3. Are there any scope issues I need to be worried about if loaded within an iframe (for instance, our player's version of jQuery conflicting with what's on the third-party parent page)?

  4. Is there anything I can/should do ensure a proper load order so I don't negatively affect the third-party site while our script loads/executes?

  5. Is there a better/smarter option than using document.write to write the final embed code to the third-party page (whether it's Flash's <object> code or the HTML5/js's <iframe>)? Should I be writing this code to a div that we include with the original js line, or is it safe to just document.write it to whatever container it happens to be in?

Thanks! Javascript's scope issues and asynchronous behaviors have never been a strong point of mine...

Upvotes: 4

Views: 3884

Answers (2)

Ruan Mendes
Ruan Mendes

Reputation: 92284

2,3) If using an iframe, a separate jQuery library has to be loaded into that iframe. That may be good enough reason to use an iframe (prevent version problems). The cost of that is downloading jQuery twice unnecessarily in some cases.

5) document.write should always be avoided for reasons mentioned by unclenorton. However, it'd be nice to allow the user to embed it without needing to call any JS. An approach to consider is to pass in the id of the element they want to put the player in to the script tag.

Something like: <div id='my-video'></div> <script src="http://example.com/embed.php?id=12345678&width=400&height=300&nodeId=my-video"></script>

Then your script can hook into the DOMReady/onload event and build the HTML without document.write using

// This should be called from an onload handler
document.getElementById('<?= $_GET['nodeId']?>').innerHTML = myHtmlString;

Or through boring createElement appendChild calls

Upvotes: 2

unclenorton
unclenorton

Reputation: 1625

5) Yes. Using document.write is a bad practice in general. It delays DOM loading and prevents your browser from doing anything else until it is finished.

Instead, think of selecting the wrapper object (using getElementById or jQuery selection), and setting its innerHTML (or jQuery html) property to your pre-assembled embed code.

Upvotes: 1

Related Questions