This December I spent a couple of days at the HTML5 fast-track course, getting up to speed on various new and coming browser features and API’s. The course was hosted by Trifork who had invited Peter Lubbers – who wrote the book Pro HTML5 Programming to go over the umbrella that is the HTML5 specification. He and his co-host Mathias Bynens did a great job at presenting the most important aspects of the spec. They also managed to communicate the more blurry parts in a way, so we left with a good overview of the maturity of the different browser implementations. So today I will write a bit about some of the things we went over, and hopefully help you learn a bit more about HTML5, while providing you with a bunch of links where you can learn more.
Paving the cowpaths
One of the often used phrases during the course was “paving the cowpaths”, because one of the primary design goals for HTML5 has been to simplify markup and get better value from the practices that a lot of developers already follow. This has meant removing some tags completely, like the font tag, and adding new tags for the most widely used id and class names, like footer, header, aside, nav and so on – based on research done by google.
Along with cleaning up the list of available tags, the syntax for a boilerplate html document was simplified, which has meant moving away from XHTML, so that quotes and closing dashes has become optional, and the doctype and charset declarations are now far simpler.
Compatibility
As always with markup languages a good way to learn is to validate your markup, and for this there is a validator available at html5.validator.nu. One of the things that causes the most uncertainty with regards to HTML5 is browser support. For this there is another validator at html5test.com, that can give you a fairly detailed overview and a score to give you an idea of how HTML5 compliant your browser is.
Especially Internet Explorer previous to IE9 has issues rendering the new HTML5 tags, so to mitigate this we can used what is known as a shiv – one of the more popular ones being html5shiv which is found on google code. This is included along with a bunch of other helpful stuff in a HTML5 template that Mathias helped create called html5boilerplate. The template is a good place to start since it helps set up a basic page with the shiv along with normalize.css, which aligns browser defaults so it is easier to get your site to work cross browser.
HTML5 is a term that actually covers HTML, CSS and JavaScript API’s, which are all implemented to a different degree by different browsers. This makes it necessary to have an easy way to see if a given feature is supported by the browsers you are targeting. To do this up front caniuse.com is a great resource. For some functionality it might be ok to have a requirement stating that some functionality is only available in the browsers that support a given API. Modernizr provides feature detection, so you can test if a given feature is available in the browser.
For JavaScript API’s the third option is to use what is known as polyfills – which are JavaScript libraries that provide different kinds of fallbacks, so you can use some of the JavaScript API’s even from browsers that don’t support them. The list of polyfills is pretty comprehensive, but mostly you will just be needing a few, so it should not scare you off.
BEWARE HERE BE DRAGONS! Not all polyfills are created equal, so while some may be quite painless to use, others might not even provide a viable alternative. For instance a polyfill for forms or validation API’s most likely wont cause you trouble, while one that emulates localstorage by using cookies most likely will hurt you unless you might as well have used cookies in the first place.
Forms and validation
Some of the more obviously needed additions to the HTML5 specification are the new input types and validation attributes. Usually <input type=”text”> has been (mis)used for almost everything, simply because it was the only type flexible enough to represent complex input. With HTML5 we get input types for email, date, color, tel, number, search, url, time, date and range. Some of these implicitly specify validation but we can also use attributes to mark a field as required or specify that it should match a pattern defined as a regular expression. So requiring the user to pick a number between 2 and 10, and allowing him to enter his email you could do be done as cleanly as this.
<input type=”number” required min=”2” max=”10”>
<input type=”email” placeholder=”eg. [email protected]”>
And it should then look something like this.
Another often used feature is placeholders, as you can see in the example. There are also more exotic and experimental attributes like support for speech in Chrome – which you can try out like so.
<input type="text" x-webkit-speech>
As you can imagine the new forms features make life easier for us developers, and on top of that they will help usability once users get accustomed to them. They will however differ from browser to browser, and styling options are limited – so in that regard nothing has changed.
Like I wrote earlier HTML5 really is an umbrella term, so it also contains a range of improvements to CSS – which by itself is called CSS3. The most annoying part is that currently support for CSS3 is also scattered, and some features are implemented in a browser engine specific way. To help get around this sites like css3please.com and css3maker.com can help you generate the CSS you need to do gradients, shadows, rounded corners, transitions and so on. These features will let you design that was previously mostly done in Flash/Silverlight or making heavy use of JavaScript.
Doing nice layouts has always been notoriously cumbersome, but with CSS3 we how have ways of defining columns, grid layouts and flexboxes. This will make it easier to do nice designs, and in time hopefully help us get rid of some of the CSS hacks that are customary today.
Another addition that I have missed from time to time is more advanced CSS selectors. Today we are sometimes using JQuery to add classes that we can then style, simply because JQuery supports more advanced selectors and pseudo-selectors.
Some of the more important ones are nth-child(3), pseudo selectors that align with new tags and attributes like :invalid and stronger attribute selectors like contains [foo*= “a”], starts with [foo ^= “a”] and ends with [foo ?= “a”]. Once again it is one of those things that we are already doing through JQuery, so having them natively will make life a bit easier and give some performance benefits.
Solutions targeting devices like phones and tablets will now have a native way to do specific styling using the new media queries. They allow you to write sections targeting specific medias like screen, 3d-glasses or print as well as specific device orientations and screen sizes.
@media all and (orientation:landscape) { .myItems { float:left; } }
@media screen and (max-device-width: 480px) { .myItems { float:left; } }
@media print { a:link:after { content: " (" attr(href) ") "; } }
The last thing I will point out with regards to design is webfonts. Before webfonts we have been pretty limited when it comes to using different fonts, because they need to be what we called websafe. This basically means that they should already exist on most computers – thus limiting our options to do interesting designs. Webfonts can be linked directly at e.g. google, and then used just like any other font. Libraries like Cufón already allow us to use fonts that are not installed on the client, but it comes at a massive cost with regards to performance, and what you get is actually a canvas, so the text can’t be selected and copied by the user.
The downside to all of these new nice additions is that for now we still need polyfills – to a varying degree. It is still a few steps in the right direction, but as a developer it is hard not think how nice it would be if we didn’t need to patch up applications to support older browsers. I am sure browser support will get there, but until then it is baby steps toward nirvana.
Video
The last area that I will touch on in this post is video. As always with this kind of technology there has been a lot of issues around deciding on formats – simply because there is a lot of money at stake. The good news is that today we are down to two formats that are needed to get support in the top 5 browsers out there. Those container formats are h.264 (mp4) for IE and safari and ogg for the rest. WebM which is googles format is supported by some of the browsers that also support ogg, so it might be preferable, but not strictly necessary. Converting from one to the other is quickly done using tools like Miro Video Converter or a service like vid.ly. To ensure the best browser coverage and help with getting the fallbacks right Video for everybody is your new best friend.
HTML5 gives us tags for video (and audio), so it is almost as easy to show a video as it is an image. There is also a JavaScript API to control the player, which is simple to use. The downside for some business cases is that it is an open format, so anybody can save the video. Even though it is possible to do some hacks to make it more difficult it will be pretty easy for any tech-savvy user to save the video.
To give an example I will leave you with a video from our go-cart tournament here at Vertica, which took place just before our x-mas dinner a little over a week ago.
Subscribe