SWFObject, née FlashObject 1.4 released

New version is out! The new version is 1.4, and there are only a few small changes/additions:

Go get it!


  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.

FlashObject to become SWFObject

A couple of months ago I was asked by Adobe to write an article about FlashObject for their Devnet site. I happily agreed, as the Devnet site is pretty high visibility in the Flash community, and it would really get the word out about FlashObject.

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.

FlashObject Breeze presentation

I gave a presentation to the Minnesota Flash Users Group last night all about FlashObject and the benefits of using it. It went really well aside from my technical issues – When I first logged in, it worked fine, but after I adjusted my microphone, my browser crashed and then wouldn’t work at all after that. Firefox and Safari both would just hang when I tried to log in to the breeze room.

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.


I’m heading up to Toronto for FITC tomorrow evening. Unfortunately I’m not giving a presentation – I suppose Canadians don’t believe in good Flash Player detection ;) – but I’m sure I’ll have a good time anyway.

If you see me wandering around, feel free to say ‘hi’. (I look like this)

Where is the Web Browser Plug-in Task Force?

Let’s face it, using plug-ins in your website is a pain in the ass. Most of the documentation provided by plug-in makers is either grossly outdated or non-existent, and when you do find useful information, one plug-in maker might have you use one method, and another has a completely different set of rules.

HTML has had proper support for plug-ins for a long time: the object tag, which is flexible enough to handle pretty much anything you can throw at it. But because of the [wrong] way many browsers interpret this information, many plug-in vendors still require (or at least suggest) the use of the embed tag either along with or instead of the object tag. Why is this? It’s 2006! Lets put some pressure on these companies to make things easier for us as developers. Why can’t I layer HTML over my Flash content or my Quicktime content? Why does Internet Explorer make me use this crazy classid attribute when specifying a mime type should suffice?

It’s time to clean up the world of browser plug-ins. It’s not enough to just sit back and say plug-ins suck, or that the very nature of them doesn’t fit into the ‘Web Standards philosophy.’ Whether you like it or not, they are here to stay. Standardizing them won’t be easy (If things like this were easy, the Web Standards Project wouldn’t exist), and it will probably take years to do, but it’s something that really needs to be done.