Component Workshop Ltd

Well the problem of course isn't as bad as it may seem, most sites with this "problem" can be placed in to one of two camps, each with a common solution that will ultimately make for a better web (for everyone).

1. Sites that didn't need Flash in the first place.

So many sites that are entirely written in flash really don't need to be, I'm talking about many of the Luxury Brands, almost every Game or Movie site.

For example take a look at the Prada.com website (I know your always visiting that site anyway, right?)

It is one great big flash app, no HTML for the unlucky iPad user, but dig a little deeper, the site when running in a browser that does have flash is so simple it could easilly be written using standard web technologies that work on any browser (Never mind HTML5).

The site is basically a navigation element which has rudimentary transitions and a nice full screen background, thats it! Come on guys, why are you using Flash for this? It makes no sense! You are aleanating so many of the people that can afford to buy your products!

I can't believe who many site out there are like this, a small percentage of them are as bad as the Prada.com site a most don't have full screen flash content, but even if you have a small amount of Flash on your site, I suspect you put it there for a reason, and that reason will be lost on so many people these days.

2. Sites that don't need Flash anymore.

OK, times are changing, 12 months ago you needed Flash for the really rich elements of your site (or at least you think you did) but today we have things like HTML5 and CSS3 right? Well no, not really, HTML5 and CSS3 are great (and open) but support, even partial support is only available on the latest and greatest versions of  a handfull of browser and most certainly not on the most popular one Internet Explorer. So Flash is the right choice here then right? Well no, almost always not i'm afraid!

All browsers have the ability to render rich content the problem is, they all have different ways of doing it, Some (like Internet Explorer) have VML support and others like (FireFox) have SVG support, but for the most part they can all render vector graphics, and can all perform acceptable levels of animation and transitions, the problem is the differences in implementation, it makes it almost impossible to be sure that your content will render the same on each browser.

What we need is a common interface that abstracts away all this complexity, and believe it or not, we already have this, several open source projects exist that do exactly that, our favourite is Raphaëljs and without going into all the techy details it allows a designer to create rich vector based content that will work on all major browsers (yep, thats exactly what Flash does) including Safari on the iPad and other iOS devices.

OK, so why do i hate flash? Well i don't, I actually love it! Its been an amazing technology that has driven the web forward by an immeasurable distance, but like all great technologies its time for others to stand on its shoulders and take us even further.

I truly believe that adoption of pure HTML5 and CSS3 will be the next frontier of the web, but while we wait for the rest of the world to embrace this we should be moving to more browser friendly technologies that map closer to HTML5 and CSS3.

So, back to the post title, Converting Flash to HTML5!

If you need any flash content Converting to HTML5 please contact us, we have an experienced team of Web Designers and Developers who can generate iPad friendly versions of the most demanding Flash content.

If you read the popular tech news sites you'll probably already know that HTML5 comes with handy a handy <video> tag, timed media playback (a la Flash), off-line storage and a canvas tag. These are the changes that will certainly have the biggest impact, but HMTL5 will bring quite a bit more than that to the table.

I say will bring (future tense) rather than brings (present tense) on purpose. The current crop of browsers have very selective HTML5 support.

The Doctype

One of the changes that has been introduced is a new doctype and simplified meta tags for declaring the charset. This is great, because every time I start a new project I have to go and hunt for a doctype to use. This is HTML5:

<!doctype html>

Seriously! That's it. That will also, rather cleverly, be the doctype for HTML6 and beyond. The idea is that HTML specifications will be written in such a way that older browsers will degrade gracefully and in a very predictable manner when they encounter an element they don't understand. This is a very noble goal, and I really hope it works out.

It's also worth giving a quick example of the lang and charset declerations in HTML5:

<!doctype html>
<html lang="en-US">
<head>
  <meta charset="utf-8">
   ...

Semantic Mark-up

One of the goals of the HTML specification writers' has, for a long time, been to provide better mechanisms for making tags describe semantic elements of a document, the idea being that stylesheets would allow us to transform plain, semanticly-laid out text as beautifully presented data.

That dream took a big step forward when HTML4 was banished and XHTML became king. XHTML's authors made it clear that tables were for describing tabular data, not for making columns or headers. We all struggled to get to grips with some of the quirks of CSS, but we are there now - we can quite easily lay-out a print-quality design using largely semantic data and CSS.

While undeniably the right thing to do, this has lead to our documents becoming collections of meaningless <div> and <span> tags. This isn't a major issue for graphical browsers, but what if you want to automate the processing of a website and extract as much information as possible about the content without knowing anything about it ahead of time. For example, you couldn't process the links in a complex page and know which were intended purely for site navigation and which were part of the content.

So the first change in HTML5 that we'll discuss are the new tags. The most interesting include:

header
nav
section
article
footer
address
dialog
dl

Probably the only tag that makes no sense just reading it is dl, which is 'description list' (for describing terms and definitions). Address is also worth a quick note -- it isn't for postal addresses in general; it's purely to tag contact details for the 'page'. For example, if this page had an address tag, it'd go around my name and email address.

The header, nav, section, article and footer tags in particular, I believe, will be block-level elements. That is, they will behave exactly like div tags. Unfortunately, because none of the current browsers understand the HTML5 doctype, they don't know what to do with the tags and they default to being inline elements.

You can work around this in FF and Safari by declaring the tag as a block level element in your CSS:

<style type="text/css">
header { display:block; }
section { display:block; }
etc...
</style>

The only modern browser line that won't style these new tags with just the above CSS is Internet Explorer. However, it seems there's a kludge that will make it work -- in a script tag you need to create a dom level element for each of the types of tag you will use and will need to style. E.g.,

<script type="text/javascript">
document.createElement('header');
document.createElement('section');
etc...
</script>

I haven't actually tested this myself in IE, but I understand it'll work in IE6+. That tip, by the way, I found on http://www.css3.com/.

So what will a HTML5 document look like? Well, let's imagine a typical layout with a header, a tab bar, a navigation panel down the left, an article with several sections and some authorship information.

Such a template might look like this:

<header>
  <h1>ACME Design</h1>
  <ul id="tab-bar">
    <li><a href="#">home</a></li>
    <li><a href="#">about</a></li>
    <li><a href="#">contact</a></li>
  </ul>
</header>
<nav>
  <h2>Related Content:</h2>
  <ul>
    <li><a href="#">Another Page</a></li>
    <li><a href="#">Another Page</a></li>
    <li><a href="#">Another Page</a></li>
  </ul>
</nav>
<article pubdate="2009-01-07T21:09+01:00">
  <section>
    <h1>Article Section Title</h1>
    <p>Blah blah blah</p>
  </section>
  <section>
    <h1>Another Section</h1>
    <p>Yada yada yad</p>
    <aside>Information not directly part of the section content, but loosely related</aside>
  </section>
</article>
<footer>
  Copyright + footer links
</footer>

Now, one thing that surprised me in the HTML5 spec is that the tab-bar and footer links aren't inside separate nav elements. Here's what the W3C say about it:

There's also a second ambiguity -- it seems that the header should really only contain one header element (I.E., an h1), and that if you have more than one header element, they should be in a hgroup tag that is inside header. That's a bit of a grey area for me, not least because some of the official HTML5 code samples put links and such like in the header element (as I have done above). Hopefully it'll become clearer when people start really adopting HTML5.

Hopefully the above example will give you an idea of the most important tags that will become the norm for nearly every HTML page in the not-too-distant future. I really like the descriptiveness of the HTML source with these new tags, so I think it's a very good thing.

New Form Elements - Web Forms 2.0

This is quite an exciting development, but sadly only one of the current-generation browser engines supports any of the new tags and attributes (in case you are wondering, it is Opera) so this is all still some way off.

There are two new elements:

<datalist></datalist>
<output></output>

Datalist is set to replace table as the preferred method of display the results of dynamic data queries, with tables being used for static tabular data only. Output is just a semantic tag that marks a block of content as being the output of whatever is being described (for example, program output if talking about a command line utility). Datalist is not yet supported by any browser.

There are quite a few new input type options:

datetime
datetime-local
date
month
week
time
number
range
email
url
add
remove
move-up
move-down

Those are quite exciting for no reason other than it will hopefully make form validation in JavaScript almost non-existent -- especially when paired with the new attributes that can be applied to input tags:

min
max
step
pattern
required
form
autocomplete
autofocus
inputmode
list
template
repeat
repeat-min
repeat-max

autocomplete is already widely implemented (as a privacy feature), but now it's official. autofocus is a great addition that is long over-due. Required and pattern are also pretty exciting. Hopefully nearly all of our client-side form validation can be described by attributes once HTML5 is widely adopted.

Cross Document Messaging

This feature is ready to use now in all current browsers apart from Opera. If you have a frame, iframe or popup window you can use it's handle and call postMessage to raise an event in the remote page. This appears to be an answer to the cross-site scripting issues that now have lead to restrictions on doing this using current Ajax tools. Hopefully it won't lead to lots of new cross-site-scripting vulnerabilities - I haven't checked the restrictions around sending cookie contents to remote domains in an iframe that has been generated by naughty un-escaped user-input, but I suspect it is all taken care of.

Here's an example of sending a message between two pages -- the first function would be on a page that is loading the second page in either a frame or a new window, and posts a message to on some event, maybe a button click. Note that the second parameter ('*') of postMessage is target-origin (i.e., the domain name of the target page). * is a wildcard, so no check is performed, but in the real world you would set it to the expected domain, for added security:

function sendMessage()
{
  var iframeEl = document.getElementById('myIFrame').contentWindow;
  iframeEl.postMessage('message text', '*');
}

The receiving page will need to register a handler for the 'message' event on the window object. The handler function receives event args, usually defined a 'e', and this has origin and data properties. Origin is the originating domain name, so we can validate that we trust the sender:

window.addEventListener('message', onMessage, false);

function onMessage(e)
{
  if (e.origin == 'mydomainname.com')
  {
    alert(e.data);
  }
}

Video and Audio tags

These tags will one day make embedded media a breeze, though for now limited codec support means Flash video will probably still be the most popular way to add video to a web page.

The video and audio both accept a controls attribute, to toggle the browser-default playback buttons. A src tag is used much as with images. You can add width, height and poster attributes to videos -- poster is used to display an image while the video loads.

Here's an example of both tags in use:

<video src="movie.ogv" controls poster="preview.jpg" width="640" height="400">
    <a href="movie.ogv">Download</a>
</video>

<audio src="song.mp3">
</audio>

As you can see in the video tag, you can provide additional html content - commonly a download link.

Another useful feature is the ability to supply multiple sources:

<video controls poster="preview.jpg" width="640" height="400">
  <source src="movie.mp4" type="video/mp4">
  <source src="movie.ogv" type="video/ogg">
</video>

The final, and potentially most exciting and useful feature is Javascript control. If you give your media tags an id, you can create a reference to them to call playback functons and respond to playback events:

var media = document.getElementById('welcomevideo');

function rewind()
{
  media.currentTime = 0;
  media.play();
}

In progress

Sorry, this article is taking way to long to write. I've still got off-line storage to discuss and I want to include a comprehensive list of new tags and features, maybe in a fancy PDF fact-sheet. I'll try and add these things by the end of this week...