Soon after I bought my first computer I started building simple websites. I had all of the best animated gifs you could find, along with those awesome water ripple java applets and whatever other bells and whistles I could find. It was awesome. I wanted to push the boundaries of this new thing. To make something unique that nobody had seen before. This led me to Macromedia Flash 4. My new hobby slowly taught me how to program, and over time I got pretty good at it. Eventually I landed in New York City and found a job at a tiny little web design shop, building websites for big corporations and loving every minute of it.

During this time the internet was recovering from the big crash at the end of the 90′s and as browsers slowly evolved, so were the websites we were building. But browsers were slow to update back then, so Flash filled a need to move faster and give us more options to explore and new technology to use (and abuse!). Around this time I wrote a little javascript utility to detect the presence of the Flash plugin and conditionally inject Flash into a website or not, and I watched as it grew over the years and became one of the most used utilities on the internet.

Flash was huge. Everyone wanted a flashy website and the only way to get one that any meaningful number of people could see was to use Flash. As browsers struggled to keep up, Flash charged ahead allowing us to build some truly amazing websites. Admittedly, there was some abuse of this technology, but we still charged ahead, trying to discover and build the next generation of user interfaces. Most older companies still thought of the internet as just another medium to advertise on. They wanted a flashy website to show off to their investors and clients and cared less about building something useful. The ubiquity of the Flash plugin made it an easy choice to build these new kinds of websites. We weren’t held back by the limitations of HTML any more, and that let us all explore wild ideas and try things that wouldn’t be possible with HTML or Javascript for years to come.

But now, years later, the browsers are catching up. Mobile devices are becoming more important than desktop computers (a trend I expect to continue for years to come). As more people use the internet in their day to day lives, businesses have realized that having a useful website is more powerful than just a flashy animated advertisement.

A few months ago I noticed that SWFObject usage on the top 10,000 websites was declining for the first time ever (I believe usage peaked in the summer of 2010). Last week, Adobe announced that they would halt development of Flash player for mobile devices, and refocus their efforts on HTML. Since this news was announced, I’ve seen many sad and nostalgic tweets from friends and colleagues. Some seem to be taking the news better than others, and it’s understandable that some people are sad to see Flash go. But it’s important to remember that no single technology is responsible for this awesome thing we call the internet.

This brings us back to my younger self sitting at home in Arizona playing with Flash and Photoshop, building new things. I’ve always loved making things, and I suspect many web developers feel the same. The pleasure of making something great is what drives us, not a specific technology. So don’t be too sad about Flash evolving, or even dying. Just keep making awesome things with whatever tools you have at your disposal.

Discuss this post here: http://news.ycombinator.com/item?id=3227994

It’s taking place at the San Bruno YouTube office this Thursday, July 10th from 10:30am to 5:30pm.

Here’s the blurb about it:

Powered By YouTube is a developer gathering focused on bringing together developers to learn more about the YouTube APIs and Tools. Spend the day at YouTube’s headquarters and learn how to bring YouTube to your website, share best practices, and get hands-on with the APIs. Meet fellow YouTube API developers across a wide range of companies, YouTube engineers and product managers, and leave inspired to enhance your user experience with the YouTube APIs.

Also: It’s free, and you get a free lunch.

It uses the YouTube player Javascript API to synchronize a Google Maps widget with the video (based on the current time of the video). It was pretty easy to throw together, it took maybe 4 hours from start to finish, and I’ve never used the Google Maps Javascript API before.

Check it out.

Yes? Then head over to this signup page and let us know you’re coming. The event is on March 27th, 2008 and will be held at the Google Mountain View campus.

p.s. free punch and pie

The project has moved over to the code.google.com website instead of my blog, so go over there and check out the docs and consider upgrading, as the new version is a lot more flexible than v1.5.

I’d like to give a huge thank you to all of the people who contributed and helped us test out the new release, those no longer with us, and of course to Bobby who is easily the biggest contributor to this new version (and has a new design up on his blog!) and has kept the project pushing forward at a good pace.

Moving foward, we’ll be continuing to work with Adobe to get the word out about SWFObject 2.

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.

We also announced that we are now working with Micheal Williams from Adobe – the author of the Adobe Flash Detection kit to make sure SWFFix can cover all the bases and be used by anyone. Very cool!

Go check out the dev blog and grab the files, then read the docs and try it out. Feedback is very welcome, so soak it in and let us know what you think.

It’s got a fantastic lineup if you are into the whole Ajax thing, so I definitely suggest checking it out.

Check out my session outline for more info.

Also: Flashbelt is only 2 weeks away! It’s JUNE already. Time to hit the upper midwest and talk Flash with all the cool Flash nerds again. If you haven’t looked at Flashbelt and are itching for a conference, this will be a nice one to check out.

UPDATE: Apparently, there’s only 50 tickets left for Flashbelt, so get your tickets now if you are planning on going!

I’ll be giving a talk called Progressive Enhancement with Flash that will cover stuff like:

• Using SWFObject (maybe SWFFix by then) to embed Flash content
• Using progressive enhancement to allow search engines to properly index your content and increase SEO for Flash websites
• Flash content vs. Flash style, and how to treat them differently
• Deep linking and back button support in Flash

And a few other areas. I should also be able to talk about SWFFix a bit (hopefully it will be fully released by then, but who knows).

Go check out the Flashbelt page for more info. I can’t give you a direct link to my session, but it’s listed there in the session list. Hopefully I’ll see some of you there!

We’ve put up a dev blog on the site, and will be asking for help and feedback throughout the development cycle, so head over and watch the blog for updates in the coming weeks.

Bobby also has a great A List Apart article out today that talks about the problems with current Flash embed techniques.

This is a great example of using Flash where Flash can do something better than HTML. And doing it in a way that uses progressive enhancement so it doesn’t require Flash. It’s just that Flash makes it better.

SWFMacMouseWheel is another addon for SWFObject that listens for mouse events and passes in the mouse wheel events to your Flash movie using ExternalInterface. Very cool solution to a problem that has annoyed many Flash developers. Go check it out.

SWFMacMouseWheel

SWFAddress is a small script that sits on top of SWFObject and provides deep linking for Flash websites and applications. In other words it enables the Back, Forward and Refresh buttons of the browser and creates unique URLs with page titles that can be sent over email or IM.

SWFAddress uses the ExternalInterface functionality introduced in Flash Player 8. It has been tested on the following browsers:

* Internet Explorer 6.0 and 7.0
* Mozilla Firefox 1.5
* Safari 2.04
* Opera 9.02

It’s a great little script, and something I’ve wanted to put together for a long time. Even better: It was designed to work with SWFObject, so if you are already using SWFObject to embed your movies, it’s really really easy to just slap in some deep link and back button support.

Go check it out.

* But hey, it’s not really a competition, use whatever works best for you.

It’s understandable to want to try and force browsers to display your plugin content in a way that adheres to “Web Standards”. It’s a very popular subject, and it’s been covered a few times before. These two recent articles don’t uncover anything new, other than bringing to light (via the comments on them) that Javascript is the only viable method of embedding Flash (and other plugin based) content on the web today.

Now I’m going to say something here that might seem a little controversial, but I really want to get the point across, so I’m going to use some ‘shock and awe’ tactics:

Using only the object tag to embed your plugin content (especially Flash content) is fucking stupid.

There. I said it.

You may say that I’m a bit biased because I wrote some fancy pants Javascript Flash embed script. Maybe I have a hidden agenda of world domination based on plugin detection. So while I no doubt would like to dominate the world, let me say that my reasons for advocating the use of Javascript are much more mundane.

This post was originally going to be titled “Flash Satay considered harmful,” and since the main topic are these “Web Standards” compliant ways of only using the object tag to embed plugin content, I’ll focus on the issues with doing so:

• “Click to activate” in IE. The only way to get around this is to use Javacript.
• No plugin detection. While Ben says ‘meh’ to this, it’s a very important aspect of the user experience. If I have Flash Player 6 installed, and I visit a site that uses Flash 9 content, my player will go ahead and try to play that swf anyway. I could end up seeing half of the content, or broken content, or who knows what. Do you really want to show your users broken content?
• Issues in older Safari versions: Safari pre 1.2 will completely ignore param tags, which are often used to pass information to the plugin. This means broken content for your users.
• Support for the object tag varies widely from browser to browser. Do you think that just because you work around all the quirks in the 3 main browsers today, it will still work when the next new browser is released?
• A bug in Flash Player 9 can cause the browser to crash if you have more than one swf on the page and are using ExternalInterface to communicate with Javacsript. While this isn’t specifically related to how the swf is embedded, SWFObject does include a fix for this issue.
• Using Flash Satay or other ‘object only’ methods will not stream your Flash movies to the user – this means extra work for you in creating a ‘loader’ swf
• JAWS will ignore it.

It’s a pretty long list, right? Now if you compare that to the user experience when using SWFObject (or other Javascript based techniques), you can see a noticable difference:

• The only time a user doesn’t see Flash is if they have Javascript turned off, or they don’t have the required version of the Flash Plugin. This one is a two parter: One, do you think that people really turn off Javascript but leave Flash on? Consider the type of person who turns Javascript off. They are probably the über nerd user who considers anything that isn’t text to be completely evil. They browse the web using Lynx. They probably stay a mile away from the Flash Plugin anyway. The beauty of the way SWFObject works is that even these people get content if you set it up right. Since you put alternate content ‘under’ your swf, they will just see the alternate content. As long as you set it up right (you do, don’t you?) they may never even know they are missing out on Flash content.
• They don’t have to click your movie once to ‘activate’ it
• Their browser doesn’t crash just because you had two swfs on the same page that use ExternalInterface
• They only see Flash content if their browser and plugin support it.

Taking all of the above into account, the choice is very clear: Javascript wins hands down. Any questions?

Now that all of that is taken care of, I wanted to address a couple of things:

First, these types of posts are not good for the Web Standards community. Basically what’s happening is highly visible people (even if they aren’t that well known, they still carry the WaSP name, or have articles on well respected online publications like A List Apart) are posting information that is bad for your users. Even worse is that they are doing it in the name of “Web Standards” and not taking into consideration any of the other options outside of pure HTML. This is extremely bad for the Web Standards movement. It makes the standards advocates look like crazed zealots who don’t care about user experience, but only care about adhering to the written rules exactly how they are stated even if it hurts them.

Second, you may be saying “well, if I can’t use the object tag, then what good is it?” and that is a FANTASTIC question. What good is it? Beats me, because the object tag is completely and utterly broken in nearly every web browser out there. Want to do something about it? Maybe you could join WaSP and create a task force to fix how browsers handle plugins?

UPDATE: I added this as a comment below, but wanted to put it in the main post as well: I want to say that as for Flash Satay: It was fantasic for the people who use(d) it, and in it’s time it was great. But now that certain big issues with it have been discovered, and Flash has changed over time, it’s time for it to retire. This is something I’ve been meaning to mention for a while, and it was sort of implied on the SWFObject page. So, since we are on the subject, it’s time to give it up.

UPDATE (8-17-2006): Ben has posted a follow up.

The issue is that onbeforeunload is being triggered even when a user clicks a link that contains a javascript link, which causes the cleanup routine to trigger, which makes all your swfs on the page dissapear in IE.

This has now been fixed, and 1.4.4 includes all of the ‘fixes’ that are needed to date, including the streaming media fix, and the Flash Player 9 ‘out of memory’ errors.

Download Now

* One new issue that can arise with the addition of the cleanup routines, is if you are including the swfobject.js script in your pages more than once, you will cause more ‘out of memory’ errors. If this happens, make sure you only insert the swfobject.js file in your page only one time.

This release only contains a single fix for a new issue that occurs when using Flash Player 9.

If you have multiple swf files embedded in a single HTML page, and at least one of those files uses ExternalInterface to add a callback, when you leave the page you will get an error that says “Line 56: Out of Memory”.

This only occurs in IE – no other browsers are affected, and it only happens when using Flash Player 9 whether you are using SWFObject or not.

The problem is in some new Javascript code that was inserted into Flash Player 9 to fix a bug in the IE browser. This IE bug affected swf files that connected to streaming media servers – to learn more about it you can read this blog post.

After working with Adobe, we came up with a Javascript fix for the streaming media issue and I used a variant of this code in the 1.4.2 version of SWFObject. All was fine then, until Flash Player 9 was released, and it turns out Adobe included their own Javascript (that is very similar to the fix in SWFObject) to fix the streaming media problems in IE. The only problem is that the code they used doesn’t like it when there is more than one swf embedded in a page.

So to get to the point, this new version of SWFObject just removes the ‘bad’ code that Flash Player 9 inserts into the page and instead uses the cleanup code from the previous version of SWFObject that has been working fine for Flash Player 8.

Go grab a copy now – anyone using ExternalInterface needs to be aware of this issue and should upgrade their SWFObject script immediately if you have any pages with more than one swf embedded in it.

Here’s a direct download link, or you can get it out of the SVN repository, or visit the SWFObject page and get it from there.

This is a general maintenance release that fixes a couple of bugs, and improves version detection in Internet Explorer. Here’s the changelog:

• [updated] added one more fix for a related issue to the audio streaming bug listed below, thanks to Ben Longoria for the fix – this should take care of all the streaming audio issues, if you are still having problems after this update, please let me know
• [updated] updated the detection code for IE/ActiveX browsers to fix a crash that could occur when the user had Flash Player 6.0.21 or 6.0.23 installed (Thanks to Michael Williams at Adobe for the code to fix this (and the Adobe detection kit))
• [fixed] updated the getQueryParamValue method to fix a bug that would return the wrong value if you had two variables that ended with the same string (Thanks to Aran Rhee for discovering the issue and providing a fix)
• [fixed] fixed a couple of strict js warnings that crept back in sometime after the 1.4 update

I’ve also created a Subversion repository for SWFObject. If you are familiar with SVN, you can do a checkout from http://svn.deconcept.com/swfobject/.

Go get it!

After spending a few hours investigating, Danny noticed that when they weren’t using SWFObject to embed the swf, they didn’t have the problem. So they called me late on a Sunday night to help figure out what the problem was. To make a long story short, the issue was this:

When you embed a swf using innerHTML in IE 6, and stream content to the Flash Player, when the user leaves the page (either by reloading it, hitting the back button, or closing the browser window with another browser window open), the audio will keep playing until the video ends or until the user closes all of their open IE windows.

Working with another developer, we found a very odd resolution at first – if we removed the Id attribute from the object tag, it would fix the problem – no more ghosted audio. The downside to this was that it also broke ExternalInterface calls going into the swf. I tried many other ways to reference the swf, but it seemed that without that Id attribute there, Flash Player wasn’t able to add the Javascript hooks to the page when the plugin was loaded.

After that I started playing with all kinds of different methods including using document.write instead of innerHTML, (which fixed the issue) but the drawback of using this was so great I kept looking for another way to fix it. Without innerHTML, I would have to change the way SWFObject works, move the placement of the Javascript code on the page, and then add more code to clear the alternate content before writing the swf to the page. All of this made that option unacceptable. I also tried using DOM methods to embed the swf file, but that ended up being such a headache I quickly gave up on that as well. Using the DOM to embed plugins is the fastest way to a headache: you think CSS is bad cross browser? Try getting plugins to work…

At this point I gave up, and e-mailed a couple of Adobe contacts. Luckily I’ve had a lot of contact with them lately because of the Devnet article and the whole FlashObject name change thing, so I figured they owed me anyway ;).

I put together a test case (HUGE thanks to Gene Dymarskiy at IBCTV for setting me up with a stream from one of their servers to test against – Gene sent an e-mail to the SWFObject mailing list the day after we found this bug, so was also eager to find an answer to it) and sent the details over to Adobe and waited for them to check it out. A while later, I got some Javascript code back from a Flash Player engineer that with a little tweaking, fixed the problem. Here’s the code that I’ve added to SWFObject:

/* fix for video streaming bug */
deconcept.SWFObjectUtil.cleanupSWFs = function() {
  var objects = document.getElementsByTagName("OBJECT");
  for (var i=0; i < objects.length; i++) {
    for (var x in objects[i]) {
      if (typeof objects[i][x] == 'function') {
        objects[i][x] = null;
      }
    }
  }
}
if (typeof window.onunload == 'function') {
  var oldunload = window.onunload;
  window.onunload = function() {
    deconcept.SWFObjectUtil.cleanupSWFs();
    oldunload();
  }
} else {
  window.onunload = deconcept.SWFObjectUtil.cleanupSWFs;
}

As you can see, it simply checks the page for object tags when the page unloads and loops through their properties looking for functions, and if it finds one, it sets it to null. I’m assuming this is cleaning up some leftovers Flash Player inserts because of the new ExternalInterface stuff, but I haven’t looked too deep into the cause of it.

I’ve just updated SWFObject to v1.4.1 to include this code. If you are using streaming content, this update is a must – if not, you can hold off as this was the only change to the code.

UPDATE: I realized this morning that the title of this post is slightly misleading – this is not a Flash Player bug, but a bug in Internet Explorer 5 and 6 in the way the browser handles the Flash Player. The issue doesn’t exist in IE 7.

UPDATE 2: It seems that there is still one issue remaining with this that can’t be solved. I haven’t tested it extensively, but it appears that when you leave a page using a link from within a Flash movie, the audio will continue, but if you leave the page using the back button or using an HTML link, the audio will be stopped. The bug was introduced when Microsoft introduced the Eolas changes, so it may be fixable in a future update. I’ll post more info here as I get it.

UPDATE: The latest SWFObject (v1.4.2) fixes all of the known isues with this, so if you are still seeing the problem, go update and you should be fine.

* If you want to check out the player, which has TONS of great content loaded into it, you can try these urls:

• http://www.nbc.com/Late_Night_with_Conan_O’Brien/videos/
• http://www.accesshollywood.com/accessvideo/
• http://www.bravotv.com
• http://www.scifi.com (click on any video)
• http://www.usanetwork.com (click ‘lauch video player’ in top right corner)

The player was built so it can be re-skinned on the fly for all the different networks or shows. Dig around a bit, there’s so much great content in there – especially some of the Conan and SNL stuff.

If you are already familiar with the script, you probably won’t get anything new from the article, but if you are new to it, you should head over and give it a read. It’s basically the SWFObject page, only profesionally edited and tidied up.

Go have a look.

Also, in case you missed it, Adobe.com now uses a slighly customized version of SWFObject for their site wide Flash Player detection and embedding.

Also, notice the humping unicorns on my t-shirt I’m wearing in the photo I gave them ;)