But I still say that the introduction of the iPad is a signal of doom for Flash-as-a-format. On the other hand, as Adobe gets more serious about producing HTML5, SVG, Canvas, JavaScript from their Flash IDE, well…

Don’t worry, Flash isn’t dead yet, but it’s clear that the tides are changing these days, with more devices entering the market that do not (and cannot) have Flash installed. Frankly SWF is no longer the reliable format it once was. Yes you can reach 90+% of the desktop browsers, but what about the millions of mobile web users?

So lots of people have had the same idea: Adobe needs to update its tools to output in Open Web formats. Simple, no? Instead of Save As SWF, Save as Web App, right?

“But wait!”, I hear some Adobe lovers cry. Rendering across browsers isn’t consistent! The DOM is a mess! There are tons of CSS layout bugs! SVG/Canvas support across browsers is uneven at best! There are many features that aren’t even supported in some browsers yet!

Hogwash. OpenLaszlo foresaw this transition years ago. GWT does the same thing.

You Adobe folk are bright engineers. You just have to make it work. Exactly like you made it work, and continue to make it work, across Windows, OSX and Linux graphics systems. The rendering layer is at the browser now, not the operating system.

There are lots of JavaScript frameworks that help to smooth out the script and DOM bumps. There are tricks you can do until SVG/Canvas feature X is consistently supported. Someone already figured out how to render SWF files using SVG+JS, for goodness sake.

And guess what – two of the major browser engines are open source – which means if a particular feature is missing in those implementations you can put an engineer on it for two months so that in the next version of the browser, it will be there for you.

You just need to think ahead.

As I’m sure you are.

Speaking of plugins, I’ve been watching this guy continue to improve his SVG viewer (a SWF file that runs in Adobe’s Flash player) with about an update per week. Interesting idea (which has been pursued before incidentally). I’ll be really impressed if he can get the thing to a point where SMIL and scripting can be implemented.

Still, nothing beats some type of native support. In the meantime, I’d even accept ‘native’ plugin support from the big stick-in-the-muds. I still haven’t ruled out the idea that one day in the future, the Silverlight or Flash plugins might suddenly be able to render SVG directly, with no translation step in between. Here’s hoping for Flash 11 and Silverlight 3… Why not? They both already support a scripting engine, interactivity, XML parsing, animation, vector graphics, gradients, etc. Hm, why not, indeed.

Flickr Badges

Flickr is a pretty popular site for sharing photos with friends, family and the world. Flickr even lets you embed ‘badges’ of your recent or popular photos into your own web page using HTML or Flash. Of course the Flash badge has some animation effects that are not easily achievable in HTML. I thought I’d use FakeSmile + SVG to create my own badge. I started with some backend code that Rob has had kicking around in his repository for almost two years.

You can see the results to the right and also on my personal info page. The badge has been tested in Firefox, Opera or Safari. There seems to be some trouble with the Renesis 1.1 plugin for Internet Explorer, so please stay tuned there. The badge can be seen full-browser here (sorry for the low-quality rasters, I’m only grabbing 75×75 pixel thumbnails from Flickr at the moment).

The images are cached from Flickr using a bit of PHP and the Flickr feed is checked every hour for new photos. If you want to see the source of the PHP, please click here.

SMIL Timesheets

Others have started experimenting with FakeSmile, too. Usually the people that I talk to that have used SMIL are pretty delighted with the technology. It’s a shame that it’s not well-supported across modern browsers yet – perhaps it has something to do with the slow public response rate of the SYMM Working Group?

However, while Opera (and now WebKit) have started to support SMIL within SVG, there are no browsers that support SMIL Timesheets yet. So FakeSmile will have to do for now (here’s another alternative that I have not experimented with).

You can think of SMIL Timesheets as the counterpart to CSS for web pages. If stylesheets are like the set decoration of your web page, then timesheets are like the choreography. What’s really nice about this is that you can have a nice, concise bit of markup representing your content (the images, in this case) and then you can externally link to a separate timesheet to animate the web page. You can use CSS selectors to apply animations to any of your web elements and use the same timesheet across multiple pages. You can see my SMIL Timesheet here.

If anyone wants to send me a SMIL timesheet with other cool effects, please feel free (look for my email address here). Perhaps I’ll eventually have my PHP pick a random effect one day.

FakeSmile

The FakeSmile script has come a long way since David released it a few months ago. It implements a decent amount of SMIL and SMIL Timesheets so that you can actually use these technologies now while the browser vendors catch up. David has also recently included a full version of jQuery inside the FakeSmile script, so it’s beefed up with lots of power now. I think he will probably be releasing minimized/compressed versions eventually.

[Update: I should also acknowledge Damian Cugley for being the original inspiration behind Rob starting his project]