When we launched embedit.in last month, the focus was on simplicity. No registration required, no seven-step process, nothing. Just upload a file and click “Embed It!”

Of course, the back end isn’t quite so simplistic: it stores your file, converts it to be viewable in our player, and generates the code for you to embed on your site. That last step presented us with an interesting challenge.

The initial version of the code used the OBJECT tag, complying with HTML standards. It was short, it was simple, and… it didn’t work in Internet Explorer 7.

<object width="466" height="400"
    type="application/x-shockwave-flash"
    data="(url of flash file)">
    <param name="allowFullScreen" value="true" />
</object>

Much has been written about the best way to embed Flash in webpages, and the state of the art is that the EMBED tag is bad, and the OBJECT tag is good, but requires different sets of attributes based on what browser is viewing the page.

That leaves us, therefore, with a need to have different markup depending on the browser, so libraries like SWFObject were born. Every browser gets the correct markup using the OBJECT tag, the HTML standard doesn’t feel violated, and another angel gets its wings.

One problem: it relies on JavaScript being available in the browser and a library being loaded. For an app like Backboard, that’s totally reasonable, but when the entire point is to let people copy a single line of code in to their site, it doesn’t work. So where does that leave us? That’s right, partying like it’s 1999.

<embed width="466" height="400"
    type="application/x-shockwave-flash"
    src="(url of flash file)"
    allowFullScreen="true" />

Hey, look! It works in every browser, it’s just as functional, and the code is even shorter than before. Maybe it’s not standards-compliant, but it’s reliable, and isn’t that the point of standards in the first place?