The new version is a complete rewrite from SWFObject 1.5, so we’ll need lots of testing before we officially launch it and replace the older SWFObject and UFO scripts, and since we have Adobe involved, they will be including this embed system in the Adobe authoring tools in the future.

The SWFObject project is moving to Google Code, where you can download the source from svn, grab the latest build, or file bugs or read documentation.

I’ve also created a new Google Group for SWFObject support questions and discussion.

If you are at MAX today, our presentation is at 2:45pm in room W-196c and it’s called “Flash Detection and Embedding: An open source solution”.

If you can’t make it today, we’ll be doing it again tomorrw (Wednesday) at 11am in room W-185d.

Go get it!

Changes:

1. [updated] SWFObject.write() now returns true or false depending on whether the SWF content was written to the page or not (true if it is, false if it is not)
2. [changed] The ‘com’ namespace has been removed, now everything lives in the ‘deconcept’ namespace only, instead of ‘com.deconcept’ namespace
3. [updated] I made a couple of very small changes to get rid of warnings in the mozilla script debugger when the debugger was in strict mode
4. added ‘the mark of the web’ to the examples pages to (hopefully) prevent the ActiveX bar from appearing at the top of the page when viewing these files locally in IE on Windows.
5. [changed] And last, but certainly not least: FlashObject is now known as SWFObject because of legal reasons

The namespace change is significant if you are directly accessing any of the internal functions inside SWFObject, like the getPlayerVersion() call. This should be easy enough to modify. I’ve also left in the reference to ‘FlashObject’ so if you want to upgrade, but don’t want to update your HTML pages just yet, you should be able to just drop in the new swfobject.js file, update the references to that script, and your SWF files will still show up.

As for the name change: Yes, it has been a pain in the ass, but not as painful as I thought it would be. So far the renaming of the functions / documentations has only consumed a few hours. Changing the mailing list from FlashObject to SWFObject was a bit trickier, and I’m considering just moving it to Google groups instead of the current mailman setup I’m using now.

As for the overall effect of the renaming, I’ve come to think that it may actually be a good thing for SWFObject once the dust settles. There was a small blog blitz about the subject, which caused a small spike in traffic to the blog, which will probably just end up informing more people about the script. Current users will have a few small changes when they want to upgrade to the newest version, but it’s nothing that will take a huge amount of time. And since I was in Toronto at FITC when it happened, I had the chance to hang out with a few Adobe people and discuss the issue with them. They all agreed that it wasn’t really a good thing, but that there’s no reasoning with that feral beast that is the Adobe Legal Team®™.

I do, however, have concerns for other open source projects out there with the word “Flash” in the name. For them, changing names may not be so easy.

As for an update on the entire “using the word Flash” situation, Adobe (I’m told) is working on a response to everything, so hopefully in the next couple of weeks we’ll get a more comprehensive official statement from them that will clarify any outstanding questions.

Download SWFObject now.

UPDATE: As always, you’ll probably get a faster response to your support questions if you join and mail the SWFObject mailing list instead of mailing me directly.

So I wrote the article – nothing too spectacular, just a spiffed up version of the existing FlashObject page. Then I waited. Then came a very odd e-mail: their legal department didn’t like that I used the word “Flash” in the project name, and asked if I would be averse to changing it. Well, I’m not really attached to the name, so I considered it for a bit, but decided that changing the name would be too much hassle, especially since so many people are already using the script and it’s gained quite a word of mouth following. So I imagined that all the people that know about it would hear all about this new great script called SWFObject and think it was some new thing. I can see the conversation now. “No thanks, I don’t need to use SWFObject, I already use FlashObject, and it’s just fine.”

Well I asked Adobe to compromise, and possibly give me permission to use the Flash name. I offered to place a little tag-line along with all the information about it, something like “Flash is a registered trademark of the Adobe Corporation, used with permission.” (Or something like that, you get the point).

Well, a few weeks have gone by, and tonight I finally got the response back: No deal. Apparently Adobe is really clamping down on the people using the word “Flash” in their projects, even if they are open source. I’m not sure how this will affect other projects, or Flash communities (My guess is that communities like OSFlash and Flashcoders will be fine, but anything that distributes a product with the name “Flash” will need to change – but this is just a guess).

Needless to say, I’m slightly annoyed by all of this, but in the end it shouldn’t really affect the project all that much (I hope). Soooo starting immediately, and as I find time to update the documentation and code downloads, FlashObject is now known as SWFObject.* I’ll be updating the main page to redirect to http://blog.deconcept.com/swfobject/ in the next day or so. If you have links pointing to the old page, feel free to update the links and change your link text/other info to SWFObject.

* I’m not really a huge fan of the name SWFObject, but I want to keep the ‘Object’ part in there to at least keep some semblance of recognition in there for the users who are already using the script, or have already heard about it. I also hate when people pronounce SWF as “swiff”, but since this is the internet, it will be hard to force people to call it S.W.F. Object. And that takes more time to say than “S.W.F. Object” anyway. So feel free to call it “Swiff Object” when talking about it “in real life.”

UPDATE (4-27-2006): John Dowdell posted a bit more info about this on his blog. Go read the Adobe Trademark guidelines.

I ended up switching to my new Intel Mac Mini at the list minute and presented on that. But I guess Adobe hasn’t updated the Breeze screen sharing plugin to support the Intel macs yet, so I was stuck copy/pasting code into the whiteboard. I think it still turned out pretty well, so if you are new to FlashObject, this presentation might be a good overview of the advantages of using it.

You can view the presentation here. Enjoy! And thanks to the Minnesota User Group for asking me to present.

The second issue is that we have a number of security vulnerabilities in IE that are scheduled to be addressed in our next release of security bulletins on Tuesday April 11, 2006. As you know, in order to reduce the complexity of updates and to improve quality, we ship all IE updates as cumulative updates. As a result, the April security updates will include the non-security ActiveX change to respond to the Eolas case.

If you’ve been following this at all since back in December, you’ll already know that you can use FlashObject to get around these changes and your users won’t need to ‘activate’ anything. But for those of you who are new to this issue, you can read an old blog post of mine that covers all the details and links out to all the important sites you might need to check out. It also covers a small bug in the update that I’m hoping has been fixed in this latest release (the script debugging issue).

Hope everyone enjoys the update!

It doesn’t matter.

To understand this answer, you need to understand what Flash is. And to do that, you need to understand modern web development philosophy. First off, you need to embrace web standards. Semantic markup and separating content from style and behavior is the only way you should be building your sites. Many web standardistas have been recommending this method of web development for years, and rightly so. However, this post isn’t the place to go into the whys of this type of development, so I’ll skip that part and just say this about how it’s done: There are three areas of front-end web development: Content, Style, and Behavior. You should always keep these three things separated as much as possible.

That brings up the question: “Where does Flash fit into this three pillar method of web development?” Is it content? Is it behavior? Is it style? While it could be considered all three, most professional Flash developers will remove the content from their Flash movies and load it in using Flash remoting or XML files. That leaves us with style and behavior.

Style is added using CSS. Generally when you add images to your HTML that are purely presentational (no text or required content in them) you should add them in using CSS. In most cases you don’t want Google to index them because people don’t search the web for ‘top left rounded corner gif.” They search for content. Even if Google upgrades their crawler someday to read CSS files and index the images, they probably wouldn’t use the information for more than statistical analysis because of this.

Behavior is generally added using Javascript. Maybe you want a new window to open set to a certain size, or you want to use some fancy Ajax to let users rate something without refreshing the page. This should all be added unobtrusively, and if the browser doesn’t support Javascript, it will hopefully still work. Unfortunately, not everyone considers this, and these days Javascript is becoming more and more of a requirement to use most websites. So you should always provide some sort of alternative for non-Javascript users. When it comes to indexing behavior, Google will for the most part not index your Javascript files. Even if it did, most web users would have no idea what the .js file they are looking at actually does. When using Javascript to change your document, Google will not read the ‘final’ page, but only the raw HTML file. Google does not render Javascript ¹.

Now that you know all of this, it’s time to look at how to treat your Flash content. Since we’ve determined we don’t want Google to index our swf files, but we do want it to index the content displayed inside them, what is the best way to go about this?

As stated before, if you are building Flash sites professionally, you probably move all your content out of your Flash movie and into an XML file or keep it in a database. This makes it much easier to allow Google to index this content by using progressive enhancement.

Progressive enhancement is a method of web development that goes hand in hand with Web Standards. You start with your HTML (your content), then add CSS (your look and feel), then add in additional behavior (Javascript, Ajax, Flash, any other interactivity that isn’t handled automatically by the browser).

The best way to add Flash progressively is by using Javascript, or more specifically, a script like FlashObject. First you lay out your page as if you aren’t using Flash. If you are using a database for your content, you can spit out that data as HTML where the Flash movie will go on the page (or maybe just a preview of the content, it’s up to you to show Google the content you would like indexed). Then you use FlashObject to replace this content only if the user has Javascript enabled and the required Flash plugin version.

Here’s a small example of what that might look like:

<div id="flashcontent">
    This is replaced by the Flash content if the user has the correct version of the Flash plugin installed.
    Place your HTML content in here and Google will index it just as it would normal HTML content (because it is HTML content!)
    Use HTML, embed images, anything you would normally place on an HTML page is fine.
</div>
<script type="text/javascript">
    // <![CDATA[
    var fo = new FlashObject("flashmovie.swf", "flashmovie", "300", "300", "8", "#FF6600");
    fo.write("flashcontent");
    // ]]>
</script>

This causes Google to skip the Flash swf files and only index the HTML (the content!) you place on the page. You can place links to other pages, images, whatever you want Google to index, and when a viewer with a browser that supports Flash visits your site, they will then see the Flash content. This gives you full control and much greater predictability over what content Google will index. And if your content is pulled from a database that is editor controlled, your pages will update and be re-indexed as the content changes without the need to re-publish all your swf files.

¹ Currently Google does not render the Javascript on a page, but there are rumors that they are developing a new crawler based on Firefox (they employ a number of Mozilla foundation members) that will index pages based on how the browser sees them, instead of the raw HTML content. This means HTML hidden by CSS may not be indexed, and pages that are altered by Javascript after they load will be indexed how they appear to the user. However, this is all rumors and until it happens Google will ignore your Javascript content.

Note: In this article I use the ‘Google’ name often, but it can be interchanged with any search engine, as they all work roughly the same way.

Today I saw somone taking this a bit further: They were using sIFR to embed a Flash movie on the page, and then passing in the replaced HTML content into the Flash movie as a flashvar.

Now this is nothing new – Claus Wahlers created SEFFS a while back that does just this (I think in his example he loaded the entire XHTML document), and sIFR does this but on a very small scale.

Up until today I never really saw much of a benefit to doing something like this. Usually your site would be run from a database anyway, so you could output your navigation and page content from your database as alternate content, and then use that same data again for the XML file that your Flash movies would read. But today I think I finally realized how cool this might be: Imagine removing all the server calls from your Flash movies when they request their XML configuration files, or imagine saving the user’s bandwidth by not loading all that content twice.

So I came up with a proof of concept of this technique using FlashObject:

How it works

First, embed your Flash movie just as you normally would using FlashObject. Then, to pass the data into you Flash movie, you just need to add one line of code. The whole thing looks like this:

var fo = new FlashObject("passdata.swf", "passdata", "300", "300", "8", "#ffffff");
fo.addVariable("xmlData", encodeURIComponent(document.getElementById("flashcontent").innerHTML));
fo.write("flashcontent");

You can see that I’m simply taking the same element that I target with FlashObject, grabbing the innerHTML of that element, URL encoding it* and then passing it into Flash as the variable xmlData.

Once the data is in the Flash movie – It’s available on the first frame as _root.xmlData, we take that string, and create an XML object out of it. That code is very simple, and looks like this:

var xml = new XML();
xml.ignoreWhite = true;
xml.parseXML(unescape(_root.xmlData));

That’s it! You now have a nice and tidy XML object you can use to generate your Flash content, and it will always match your alternate content perfectly. Your users don’t have to download the content twice (once in the HTML, once in the XML file Flash would load, or duplicated in the swf) and you saved your server an extra call from the Flash movie.

View a working example here, and you can download all the files in the example here.

* Using encodeURIComponent to support double byte characters.

FlashObject has been gaining a lot more popularity lately, and with it the number of requests for help has gone up steadily (what, my tutorials aren’t good enough? ;)). So I created a mailing list just for FlashObject related questions!

Sign up now by going here and filling out the form. (And make sure you watch your spam folder for the confirmation e-mail!)

Once you are signed up, send any problems or issues you might be having (it’s ALWAYS better if you include code samples or a link to the page you are having issues with) or even new feature requests.

Enjoy!

• [Changed] When calling FlashObject.write() you can now pass an HTMLElement reference. Previously you needed to pass a string (the Id of the element to write the Flash content to)
• [Changed] Made changes to the plugin detection routine that would cause a crash in browsers running certain versions of the Flash plugin. Read a comprehensive description of the issue and the fix.
• [New] You may now specify a specific URL to redirect the user to after they complete an ExpressInstall process. Previously the script would always redirect them to the page the Flash movie was embedded in, but when using a popup window this is not always the best solution. See the ExpressInstall section of the FlashObject page for more information.
• [New] FlashObject now integrates seamlessly with the Javascript Integration Kit. More information on this is forthcoming in a new blog post.
• [New] I’ve used Dojo Shrinksafe to strip out the extra space in the flashobject.js file. FlashObject now weighs in at just a hair over 6kb. Super tiny! The FlashObject ‘source code’ (un-shunken Javascript) is included in the FlashObject zip file in the ‘source’ folder. I also made a number of small syntax changes to reduce the size even more.

I’ve updated the FlashObject page to reflect these changes. I recommend that everyone should upgrade if you are using any older version of FlashObject. If you are upgrading from v. 1.2, you can simply replace your flashobject.js file and you should be ready to go. Versions earlier than 1.2, you may need to make minor adjustments to your embed code (see the changes to v. 1.2 for help with that)

UPDATE (1-25-2006): Found a small bug in this latest version that caused the Flash movie to not load on IE 5.01 on PC. The bug has been fixed and the zip/source has been updated. Please update to the latest version if you are using 1.3 and have a lot of users using IE 5.01 (does anyone have a high number of those anymore?). The new version number is 1.3b.

So how does all of this affect you being a web developer?

Basically, the functionality changes work like this:

When using an applet, object, or embed tag to insert a plugin into an HTML document, that plugin will not allow user interaction until the user clicks on it. Microsoft calls this process “Activating an ActiveX Control’s Interface.”

In the case of the Flash plugin, it means that your Flash movies will not work until a user ‘activates’ it first by clicking on it. The details are still a bit fuzzy, and I can’t find a developer preview of IE 6 or IE 7 that include this new functionality to test this new functionality (If you find one, please let me know) (see below). This is a slight improvement over the previous ‘fix’ which was a small dialog prompt for each ActiveX control on a page. Now you just have to click on each control to activate it (if you want to interact with it).

Microsoft says “We believe over the next six months, most customers will be running copies of Internet Explorer with this behavior.” The changes will be rolled into IE 6 through security updates to Windows, and included in IE 7.

But that’s so stupid! How do I fix it?

Thankfully, Micosoft offers a fairly easy way around all this nonsense: Embed your Flash movies using Javascript. Head over to the FlashObject page* and start using it (you should be using it anyway, everyone else is!). You may also want to retrofit your old websites that don’t use Javascript since this change will affect every website. If you are using quicktime, you can always use my QTObject script which works the same way that FlashObject does, but for the Quicktime plugin.

UPDATE (1-22-2006): Apple has recently released a new script that is similar to my QTObject script to prepare people for the upcoming IE changes.

* UPDATE (2-21-2006): After testing with a patch (search the page for ‘English’ to find the download link) that Microsoft released recently released (and with some help from Dan Freeman) it turns out that you must have ‘Disable Script Debugging’ checked in the Advanced options of IE in order for the controls to be activated as they are embedded. If you have Script debugging on (it’s off by default) then you will still need to activate each ActiveX control on the page.

Also: Macromeida/Adobe has a new Active Content Developer Center.

UPDATE (3-1-2006): Microsoft has released the update. There’s more information and a nice list of possible issues you might have after installing the update on this Microsoft KB article page.

UPDATE (3-24-2006): Looks like Microsoft is set to roll out the Eolas changes to everyone around April 11th. Get ready.

UPDATE (3-29-2006) Microsoft announced their future plans for releasing the patch to customers today.

UPDATE (5-9-2006): Adobe posted what looks like a very rare edge case regarding an out of date jscript.dll causing users to always activate ActiveX controls, even if they are embedded using Javascript in the proper way.