Stephen Sulzberger’s Blog

January 12, 2008

Why SWFObject is better than AC_RunActiveContent.js for flash embedding

Filed under: Flash,Web development — Stephen @ 1:41 pm

Some advantages of using SWFObject over Macromedia’s AC_RunActiveContent.js approach (that most places don’t talk about):

  1. SWFObject degrades gracefully. If flash isn’t detected, the “flashcontent” div element never gets replaced with the flash object script. This being the case, you can use xhtml compliant code that’s far cleaner and more robust than anything Macromedia supports out of the box. Interestingly, Macromedia doesn’t even support alternative content when their implementation is called using the jscript. They allow a <noscript> content area, but in that case you’re limited to only having a replacement <img> instead of full-blown replacement content.  
  2. SWFObject entails terser code. When using SFWObject, you’re only placing/calling your flash script once instead of multiple times. Notice, for example, that Macromedia requires the flash object to essentially be placed twice, thereby duplicating your work outright. Needless to say, SFWObject’s code implementation is far more elegant and much easier to maintain.
  3. SWFObject contains an efficient and robust framework that has extensive functionality built right in. As it stands, Macromedia’s implementation has no (or at least an extremely cryptic) method for doing things like, for example, passing flash argument variables. In fact, a quick glance at Macromedia’s AC_RunActiveContent.js file shows that their rendering mechanism is proprietary to the point of absurdity. Case in point, notice Macromedia’s AC_FL_RunContent() function for generating the <embed> object – if that’s not ad hoc, I don’t know what is. Dirty, cumbersome, and the perfect example of unnecessary overhead that bars anything from being readily transparent or extensible.  
  4. And, of course, all of the regular advantages.

Some caveats:

  1. SWFObject doesn’t work if/when javascript is disabled. I personally consider this a small point, but it’s still a valid shortcoming. Of course, it seems to me that browsers that are running without javascript enabled are likely to be running without flash enabled, either; this is hardly the sort of crowd that most web applications (relying on flash, nonetheless) have to cater to. Incidentally, Macromedia’s approach doesn’t suffer this setback given their use of <noscript>. 

EXAMPLE

Anyone familiar with Macromedia’s suggested method for deploying a flash component will find the following typical:

   <script src="app/flash/default3/AC_RunActiveContent.js" type="text/javascript"></script> 

   <script type="text/javascript"> 

     if (AC_FL_RunContent == 0) { 
       alert("This page requires AC_RunActiveContent.js."); 
     } else { 
       AC_FL_RunContent( 
              'codebase', 'http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0', 
              'width', '770', 
              'height', '190', 
              'src', 'data/flash/flashObject', 
              'quality', 'high', 
              'pluginspage', 'http://www.macromedia.com/go/getflashplayer', 
              'align', 'middle', 
              'play', 'true', 
              'loop', 'true', 
              'scale', 'showall', 
              'wmode', 'window', 
              'devicefont', 'false', 
              'id', 'flashObject', 
              'bgcolor', '#ffffff', 
              'name', 'flashObject', 
              'menu', 'true', 
              'allowFullScreen', 'false', 
              'allowScriptAccess','sameDomain', 
              'movie', 'data/flash/flashObject', 
              'salign', '', 
              'base', 'data/flash/' 
              ); //end AC code 
          } 

    </script> 

    <noscript> 
       <object id="_objflashObject" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" 
          codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0" 
          width="770" height="190" align="middle" type="application/x-shockwave-flash"> 
           <param name="allowScriptAccess" value="sameDomain" /> 
           <param name="allowFullScreen" value="false" /> 
           <param name="movie" value="data/flash/flashObject.swf" /> 
           <param name="quality" value="high" /> 
           <param name="bgcolor" value="#ffffff" /> 
           <param name="base" value="data/flash/" /> 
           <img src="images/flashReplacement.gif" alt="banner" /> 
       </object> 
    </noscript> 

Using SWFObject, one can replace the above using about 1/4 the code:

   <script type="text/javascript" src="data/scripts/swfobject-1.5.js"></script> 

   <div id="flashcontent"> 
     <img src="images/flashReplacement.gif" alt="banner" /> 
   </div> 

   <script type="text/javascript"> 
     var so = new SWFObject("data/flash/flashObject.swf", "flashBanner1", "770", "190", "9", "#fff"); 
     so.addParam("allowScriptAccess", "sameDomain"); 
     so.addParam("base", "data/flash/"); 
     so.write("flashcontent"); 
   </script>

2 Comments »

  1. […] 1.5 is used quite a bit. I like the simplicity. Stephen Sulzberger’s Blog compares SWFObject to Adobe’s default plugin detect and embed script AC_RunActiveContent.js […]

    Pingback by SWFObject, addParam, and addVariable « Log Book — March 30, 2009 @ 6:03 pm | Reply

  2. Great blogpost, great looking blog, added it to my favorites.

    Comment by MeloFefeKeemn — November 25, 2009 @ 10:08 am | Reply


RSS feed for comments on this post. TrackBack URI

Leave a comment

Blog at WordPress.com.