Part 3
In this series we are examining the future of Flash and whether it will make its way to Apple devices.
As part of the discussion, we’re looking at the viability of HTML 5. This is fair because when people speak of a possible replacement for the features of Flash, they often cite HTML 5. To do an honest evaluation, we need to look at how HTML 5 actually performs.
HTML is a markup language no matter what version we’re talking about. Using Javascript/CSS/HTML, you can already do some pretty interesting things in terms of moving things around the screen and creating masks. As a result, sites that use some minimal animation to add to the user experience and direct attention in a specific flow can be accomplished already.
The Languages
Javascript is the language used to manipulate the DOM (HTML) client-side. That is not going to change, nor is Javascript likely to change much given the death of the ECMA 4 update to the language.
JS is a very loose language, not object-oriented as one would usually think of it. There are no classes, no access modifiers, no abstracts or interfaces. That said, it is a well-known language and there are a great many resources online for it and many instructional books. Coding in JS is pretty predictable. Most of the difficulties in coding for the web come not from Javascript, but from the exceptionally poor and fragmented HTML treatment of the DOM (the document object model that determines how a web page should render in a browser).
The DOM is the Thing
Different browsers treat the DOM differently, and in fact they have their own layout engines, including WebKit, Gecko, and Trident to name three of the most popular.
I won’t mince words when I say that standards for HTML and the DOM move along at the pace of a large lumbering committee. HTML 5 is no exception. Nor is it a new idea. The next version of HTML has been in the works since mid-2004. This from the w3 site: “The current HTML working group charter was issued on 7 March 2007. The group is chartered to continue its work through 31 December 2010″.
Does this mean we’ll have HTML 5 by the end of the year? No. The actual W3C candidate recommendation is slated to possibly be available in March of 2012. And that is the recommendation, not the actual approval. The full approval…who know? Possibly 2022, but it faces many obstacles before then.
Keep this in mind: along with the actual recommendation, the group is required to create a comprehensive test suite for the HTML specification, as well as all validation tools. And they need a ‘classic HTML’ version as well as an XML version.
Given the very slow process of approval for the next HTML, different organizations have decided they simply can not wait for the W3C approved candidate and have begun implementing individual parts of HTML 5 on their own. But what feature is adopted into which layout engine for what version of any browser is completely unregulated. Worse than that, the makers of the various browsers compete for market share and it is all to easy for them to differ on how HTML features should be implemented. This is not a new tale, it goes back to the netscape days. As an example, we could look at the canvas element.
When people mention killing plugins with HTML 5, they’re often referring to the canvas element. This element was introduced into WebKit by Apple for Mac OSX and then the Safari browser. This joined the already proposed SVG (scalable vector graphics) standard which was competing with Microsoft’s proposed VML standard. It is notable that by introducing their own element, Apple was able to patent the canvas element in 2005 making it a proprietary markup. Later they volunteered to provide royalty-free licensing to the W3C for use of the canvas element in HTML 5.
Ian Hickson, author of the current HTML 5 specification had this to say:
“So Apple decided to make up some new tags. To be precise they invented a new element, a new attribute, and a new value. The new element is canvas, an element that does nothing except provide a DOM interface for graphics drawing…Here is Apple introducing their own proprietary markup to the Web, without going through any sort of standardization first…Proprietary markup is proprietary markup, whether it is HTML-based, XML-based, or any other language such as PDF, Microsoft Word, XAML, or Flash.”
Apple dashed ahead, making an element for their operating system, but they liked it so much they included it into their browser as well.
Apple is not along in introducing proprietary markup and formats, others include Adobe, Microsoft, Mozilla, and many more.
The point is that when people talk about HTML 5 being the next big thing, the question should remain ‘what HTML 5 are we talking about?’. Is it the one Apple is pushing, or someone else, or whatever finally gets standardized ten years from now?
For developers and content creators, this lack of any solid standard has meant never-ending frustration with HTML-based content. And it has been going on this way for many years. Perhaps it will get better in the future.
How About Right Now?
But if you deal in the here-and-now, how usable is HTML 5, and if you choose to use it can the canvas element compare to what can be done with Flash?
Regarding animation, the canvas element has serious shortcomings, as stated by the Mozilla Developer Center:
“Since we’re using script to control canvas elements, it’s also very easy to make interactive animations. Unfortunately the canvas element was never designed to be used in this way (unlike Flash) so there are limitations.
Probably the biggest limitation is that once a shape gets drawn it stays that way. If we need to move it we have to redraw it and everything that was drawn before it. It takes a lot of time to redraw complex frames and the performance depends highly on the speed of the computer it’s running on.”
To do canvas animation, one must create a description of the the canvas using HTML markup, and following that it is possible to use javascript to start changing the properties of shapes on the canvas at timed intervals.
You get a simple 2D drawing API to work with.
This next part is my personal observation.
I find it very difficult indeed to find animation and interactivity examples done in HTML 5 using the canvas element online. One of the very best javascript programmers I’ve ever known worked extremely hard for weeks to create a JS-only demonstration, and it was awesome in some browsers, but it ran so badly in others that it had to be replaced by Flash. The Flash replacement was done in a couple of days.
JS/HTML based animation suffers from a serious lack of a decent IDE to work in. At this point, it is not being accomplished by designers or animators - it is being done by people who code in JS. When I look into the source of some of the examples, I find code so long and laborious it makes my eyes rot. Here’s an example:
http://www.cs.helsinki.fi/u/ilmarihe/canvas_animation_demo/mozcampeu09.html
Take a look at the source. I am NOT slamming the developer, indeed I am in awe. But the fact remains this could be done in Flash in an afternoon and require next to no code.
Looking through the source (and it is cool that I can look at the source by the way) of popular examples, I am reminded very much of what was being done circa Flash 5, except without the tools of the Flash IDE.
To do a simple movement or fade is no problem. There is no way to do a “timeline animation” though some smart people have tried to write their own solutions for this.
Without the tools available to Flash developers, creating immersive experiences is going to be a much slower process.
And at the end of that process, you still have to worry about cross-browser issues.
Does it Matter?
Will the viewing public settle for javascript-style animation and interactivity online? With the iPhone, Apple is saying that the web is for interacting in a simple way. For anything more immersive or complex - well there’s an app for that. They want you to leave the browser and do your playing and experimenting in a separate application which you got from their app store.
While that may be acceptable for many (perhaps even preferable) on a small-screen mobile solution, will this be okay on the desktop? We will know in time I suppose.
Additional Reading:
Hixie’s Blog re: unrecognized HTML tags