This is not about HTML5
HTML5 has been called many things – the next big thing, killer of Flash, herald of the semantic web and liberator of those who surf beneath a never-ending twilight of banner-ads. Like the ‘Web 2.0’ it has been mutated into a buzzword, and like any good buzzword the usage of the word hardly represents what it’s supposed to anymore.
Editors note: This really is about HTML5.
HTML5 is not animation, it’s not visual, and to read purely about HTML5 is boring**.** I mean ok, I don’t find it boring, but if I went through it in detail, then in all likelihood you’d find it boring. And that’s because for the most part, HTML5 isn’t new. There are some new things, yes - but they’re technical, and not even ‘ground-breaking’ technical, just obvious technical. The rest of it well, you could do that beforehand – so it probably doesn’t count as new. Nevertheless;
What is in HTML5?
- Local data storage
Forget tracking cookies, we’re talking about downloading tens or hundreds of Megabytes of data and saving it on your machine. Why you ask? Well, how about preloading. If you could download files you might need later while you’re looking at other things, everything is going to load faster. Just like Google Gears, which you may have seen in Firefox or Chrome.
- Local databases
Do you like searching for data, but hate waiting for results? Imagine if a slice of the database could be downloaded to your machine and you could work from that – it’s going to be faster to find those results. You could even find those results when you’re not online. Much like the local data storage point above, but a little cooler.
- Drag-and-drop behaviours
Drag files in and out of the web-browser. So much easier to work with than browsing for individual files each time you want to upload or download, and especially useful when you think of the up and coming ‘cloud storage’ mentality. I remember seeing an early implementation of this concept in Internet Explorer, of all places.
- Native video & audio playback
The so-called Flash killer, that isn’t. [link to http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html] The ability to offer video and audio playback without the need for a plugin like Flash, Quicktime or Windows Media Player. It’s currently the only way to get your files playing back on an iPhone or iPad, but is also a great leap forward in terms of making your content accessible to those without the aforementioned browser plugins installed.
- Better web form capabilities
Whenever you fill out a form, such as a contact form, your online taxes or even the comments form at the bottom of this page, your data is being checked to make sure it’s valid. If you want something more complex, like a date picker, colour picker or auto-completion, that currently needs to be created from scratch. With HTML5, that will all become much easier to implement, and familiar and standardised for the end-user.
- The Canvas
Dynamic graphics. The other ‘Flash killer’ feature of HTML5, which introduces the ability to draw graphics with code. That includes everything from creating graphs and charting to freeform mouse drawing tools. As you might have guessed, you’d normally have to draw this sort of thing with Flash, but now you’re free of that restriction.
We know where you are, literally. Imagine what you could do with that. You’ll see this a lot more with smartphones, which already have the technology to know your location, but with Geolocation as part of HTML5, I don’t think it’ll be too long before you’re setting your real-world location into your browser as standard. Huzzah for localised singles’ adverts.
There’s more I assure you, but that’s the selected highlights.
Each of these features already has some form of existing implementation, but the purpose of bringing them into HTML5 is to remove the dependency on those existing behaviours. We’re all about web applications now rather than web sites, so standardising what we’ve already got is about levelling off the building blocks for the next generation of web sites.
And as we’ve already got non-HTML5 implementations of these features, it makes it much more possible to gradually introduce these features – sidestepping the chicken-and-egg scenario by importing some old chickens.
HTML5 and Mobile development
Mobile development has been a driving force for adoption of HTML5 in websites. This might be because the mobile devices have had their technologies and their web-browsers developed recently, so the code bases for them are newer and don’t have to maintain any compatibility with older versions and don’t have legacy code or legacy users to worry about.
Desktop adoption problem #1: the legacy user
The problem with adopting HTML5 for the desktop is that a decent chunk of the internet continues to suffer under the oppressive regime that it Internet Explorer. They may willingly inflict this upon themselves, or they may suffer the pains of a corporate network, where some moron IT Technician rules that everyone must use Internet Explorer version 6.
HTML5 is thankfully supposed to be backwards compatible, but things have to be done in a gracefully-degrading way, checking for the availability of a feature before trying to use it, and always not relying on a specific feature without implementing fallback technologies. That means you have to duplicate your work and build the same system in different technologies, upping the development and testing time significantly.
All of this brings up the main adoption problem for those targeting the desktop user: Why develop it in HTML5 if I’m going to have to develop it in Flash anyway as a fallback? ideological warfare, I’m afraid.
TL;DR [link to http://www.urbandictionary.com/define.php?term=tl;dr]
You can use everything HTML5 offers today, although you need to keep in mind graceful degradation and use an existing implementation of the same feature as a backup, or only use HTML5 features on non-critical elements of your web site.