Question

I’ve got a flash player (using JWPlayer) that plays an audio file. The file plays fine.

How do I provide the embed code for end-users to copy, so they can post the player and play the audio file on their own site directly? Should I be using HTML <pre> tags somewhere? Or JavaScript to generate the embed code / link?

For example. SoundCloud has:

<object height="81" width="100%"> <param name="movie" value="https://player.soundcloud.com/player.swf?url=http%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F31988157&amp;show_comments=true&amp;auto_play=false"></param> <param name="allowscriptaccess" value="always"></param> <embed allowscriptaccess="always" height="81" src="https://player.soundcloud.com/player.swf?url=http%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F31988157&amp;show_comments=true&amp;auto_play=false" type="application/x-shockwave-flash" width="100%"></embed> </object>   <span><a href="http://soundcloud.com/chris_ilett/the-fray">The Fray</a> by <a href="http://soundcloud.com/chris_ilett">chris_ilett</a></span>

And YouTube has:

<iframe width="420" height="315" src="http://www.youtube.com/embed/FL7yD-0pqZg" frameborder="0" allowfullscreen></iframe>

What are the benefits of having an <object> and an <iframe>?

Lastly, on the main site. Any time an end-users visits the audio page. The web app increases the views_count. If I am using <object> or <iframe>. Will I still be able to track the number of views somehow?

Answer 1

iframe vs object

The main reason for YouTube’s use of <iframe> (i.e. “the benefit”) is that it allows them to change how the video is actually displayed – without the website that’s embedding the video having to change its <object> element. I.e.:

• YouTube can serve different content depending on the browser – i.e., if the browser doesn’t have FlashPlayer installed, they could output an HTML 5 <video> element in the <iframe> instead. In the future, you might want to do the same (with an <audio> element), so <iframe> might be a good choice for flexibility in the long term.

• It’s easier for YouTube to change how the content is output in case of bugs etc. In other words, if for some reason (to mak FlashPlayer 12 behave, for example) they need to add or change a <param> in the HTML or something else, they can do that without every person embedding their videos having to change it themselves.

The code

You would probably use Ruby to output the actual code, although you could use Javascript too – it would need to be generated somehow in order to reflect the exact audio that’s supposed to be played. As for putting it in <pre> tags, it’s not a technical necessity – just a matter of a better user experience – simply because it’s easier to tell where the code starts and ends.

Which tags to use exactly is just a matter of philosophy. Some would say “use a <code> element (to indicate it’s code) and style it to display as a block element”; others would say “just us a <pre> element since it’s already a block element”; and some would say “Combine the two: <pre><code>...</code></pre>“.

Tracking

You can track either. The requests for the audio will always be sent to your server, so it’s possible to use tracking in either case. The case of <iframe> is easier to track in the same way you’re already doing it, though – since the src of that iframe will just be a link to a simpler version of your audio page (only showing the actual player), you can increase views_count in exactly the same way as in the audio page.

As for <object> advantages

Why does SoundCloud use <object> exclusively? Just guessing here…

Either they just haven’t gotten to it yet, or they’ve decided (quite rightly in some regards) that a completely predictable, working <audio> element is a bit into the future, and not worth it just yet.

Or they have that philosophical dislike of the <iframe> element that some developers have (me included in some ways – I only use it if absolutely no other alternative makes sense).

The user (i.e., the one who’s embedding the sound) may also intend to use it in a place where <iframe> would cause troubles, isn’t directly supported (e.g. some CMS’s) etc.

Also, although I doubt it’s their reason, it means one more hit to their server – letting users embed <object> will retrieve the flash content directly. If they use <iframe>, SoundCloud will be hit by an additional request per embed – one for the HTML and one for the audio file (and, for FlashPlayer, one for the swf file).