For some special situations where I don't use swfObject or similar to insert flash content I've used this solution:

theElement.innerHTML = '<embed width="580" height="327" flashvars="xmlpath=test" bgcolor="#000000" scale="noscale" src="/flash/theFlash.swf" type="application/x-shockwave-flash"/>';       
theElement.innerHTML += ""; //force IE and safari to render correctly


<id id="theElementToBeReplaced">The alternate content for non JS-capable UA</div>

Ok, I admit it doesn't look very nice. But I've found that it works in every browser I've encountered, and it's fast and simple, and this without the use of any twice cooked flash satay-solution or detection.

Is there any problem with this solution? Does it work in all environments (my tests, including those from Litmus says so)?

  • Well, then you should continue using. The only issue I can think of is it requires javascript to show the flash content. o.k.w over 9 years ago
  • That's true, it's can be good do remember that you could maximize accessibility by not using javascript to insert flash. However, there is nothing that says you can't use a <embed> and/or <object> inside the replaced element ("theElement"). Jens Hedqvist over 9 years ago
  • Note: Updated question to clarify my current usage of this solution. Jens Hedqvist over 9 years ago

2 answers


SWFObject allows you to detect the user's Flash version and run a seamless upgrade - this is useful if your expected user base is expected to use a version of flash older than that run on your site. For sites involving more complex flash integration, this feature is indispensable, forcing your users to the latest version available.

Additionally, using SWFObject allows a callback function on the success or failure of the flash load, and thus provide corresponding exit strategies. For example, you may have tracking in place that forces you to make an API call once the flash loaded successfully - you could integrate that into your flash object, but how much nicer to run a success callback function!

Skimming the SWFObject documentation reminds me of all the pro features of using it. Like you said, it still works to use rudimentary JS innerHTML writes, but the SWFObject expressInstall.swf and the programmatic feel it gives to adding flashvars and other parameters make it feel more natural.

Answered over 9 years ago by neatlysliced
  • + 1 for reminding me of the pro functions that sometimes comes handy. Jens Hedqvist over 9 years ago

Other than not degrading nicely with non-js-enabled UA's, that is really all SWFObject does for you. If you're unable to load SWFObject (or even jQuery) then I don't see any reason why you couldn't use this.

Answered over 9 years ago by Nathan DeGruchy
  • Well not entirely true. The element "theElement" in this case already contains the fallback content, and is replaced when JS is present. The traditional insertion method, as used by swfObject as well serves embed to some browsers and object to some. For no reason if the above solution works fine?? You could easily build a config that's neater then swfObject with this method... Jens Hedqvist over 9 years ago