Engagement/Developer Engagement/Grab bag/HTML5

From MozillaWiki
Jump to: navigation, search

HTML5 is the technology stack that drives the web. It consists of various parts: HTML markup, which is describing what a certain part of a document is, CSS3 which defines the look and feel (and interaction using animations and transitions) and JavaScript which defines the interactivity of what we create.

  • HTML5 is partly a misnomer. The old versions of HTML did nothing else but add meaning to text content by giving it semantic value, linking and including other files like images, objects (in most cases flash movies), sound, video and style sheets. The HTML5 standard now includes a lot of information about JavaScript interfaces for web sites and most importantly a "how to build a HTML5 compliant browser".
  • HTML5 is defined in a joint effort by the WHATWG working group (which includes a lot of browser vendors) and the W3C. The WHATWG runs the wild innovation part of HTML5 - not everything that is in their specification will make it into the final one. The W3C effort is more conservative and therefore more interesting for an enterprise market.
  • HTML5 is open - you learn by viewing the source code of others. This also means it is up to us to write clean HTML5 to set a good example and base to work from.
  • HTML5 is interoperable - products built with it are meant to run on a large variety of hardware. Therefore not all best practices we have on desktop apply to it.
  • HTML5 is meant to be backwards compatible - old browsers that do for example not understand the new form elements should offer a normal text field as the means of entering the information.

HTML5 forms

HTML5 forms allow us to build more interactive applications for our users and get rid of a few of the annoyances we had to deal with in the past:

  • They offer simple client-side validation of form elements. In the past we always wrote that in JavaScript and repeated it on the server which made maintenance harder. It is important to explain though that server side validation is still very much needed as you could bypass the client-side validation with, for example, cURL. It is also worth pointing out that HTML5 forms have a validation API in JavaScript, so if you don't like the way browsers display errors you can roll your own error display.
  • We have new cool elements:
    • Date picker - writing a client-side calendar that localises to different markets is a pain to do - now we don't need that any longer
    • Number fields - they render with up/down arrows and allow simple entry. They also come with min and max and step attributes to define the allowed range and make it easy for users to increase by, let's say 0.1 instead of 1
    • Email/URL/Phone fields - they don't mean much on a desktop but are a total win on mobile devices as they switch the keyboards around and tie into your history and address books - that way you need to enter a lot less and you don't need to switch from alphanumeric to numeric keyboard.
    • Range - renders a slider control - something we never had natively
    • Datalist - is a combo box we had in many other GUI frameworks - it allows for open text entry but offers autocomplete for a preset of values. The really cool thing about this one is that it extends an input for backwards compatibility.

The great thing about HTML5 form elements is that they gracefully degrade to a text input on old browsers. The bad thing about them is that they are not well supported across browsers as this comparison grid by Wufoo shows.

HTML5 File APIs

This is a big topic and might be hard to understand for people. I like to show an example screencast of either of the following examples. The main thing to tell people about the File APIs is that they make it much easier for us to build applications without a server and that we use the end user's computer power for our needs. It is a bit like SETI@home, only for humans, not aliens.

  • Min.us - this is showing how you can drag and drop an image into the browser and then send it to image hosting sites. Explain how much easier that is than uploading them one by one. webm mp4 ogv
  • 64 yourself - this shows how you can drag a file into the browser, convert it and save it back without any server interaction. It also has a cool geek feeling to it :) webm mp4 ogv
  • Motivational poster - our own demo, this shows again how to manipulate an image in the browser before uploading it. webm mp4 ogv

HTML5 Video

HTML5 video was probably the main breakthrough for the new technology. We realised pretty early that the media internet will not stay interesting enough for mass market end users if we keep it strictly text and image based. The benefit of HTML5 video over plugin-based solutions is that the video is just another element in the document. This solved a few issues we had with Flash or Silverlight based video solutions:

  • Videos have a native browser control, which means they are keyboard accessible and assistive technology can interact with them
  • Videos can be styled with CSS much like any other element in the document, you can zoom them, rotate them, add borders, make them transparent and many more things that weren't possible with a Flash embed
  • Videos have a built-in API that allows you to write your own controls, react to the time of the movie, test what video formats are supported and get all kind of information about them that you couldn't get with Flash videos.
  • Videos can easily interact with other parts of the page and can even get generated dynamically. A plugin always was a black box of unknown in your document

Issues with HTML5 video

Of course not everything is rosy about HTML5 video at the moment and the following things are constantly brought up in Q&A sessions with audiences. It is important to make the message clear that there are some issues with it and that sometimes Flash video is the better option (less and less though).

  • Different codecs for different browsers — there is a discord among browser vendors when it comes to defining what constitutes HTML5 video. Whilst Microsoft and Apple favour mp4 files with H.264 encoding (which is also the format for Blue Ray discs), Google, Opera and Mozilla went for fully open codec formats like Ogg Video and Web-M. This means a few annoying things:
    • If you want to support all HTML5 browsers with your videos, you have to convert them into three formats.
    • If you also want to support different mobiles and tablets you will also have to create the video in different resolutions and sizes.
    • One simple way to do this is to use online services. Archive.org for example automatically converts hosted videos (which have to be licensed with Creative Commons or Public Domain) you upload to OGG and MP4, so all you need to do is create a WebM version.
    • Vid.ly converts videos to 20 formats and provides you with a URL that redirects different browsers, mobiles and consoles to the right format automatically.
  • HTML5 video is open, and so is the source file — if people want to offer video in HTML5, then the files will be possible to download. YouTube's HTML5 player goes through a proxy server to prevent this but it can be easily fooled. If people want DRM in their files and prevent users from downloading them they need to use Silverlight or Flash (or host the files on a login-protected server).

HTML5 Audio

Technically HTML5 audio should not be much harder than video but the implementations in browsers right now are not as good as they could be. There are issues with looping sounds for example. One of the issues is that the most used audio format on the web - MP3 - is not an open format.

The benefits of audio are the same as for HTML5 video:

  • Native player controls allow for keyboard access
  • Simple communication with the rest of the page allows for great experiences of audio with other open technologies

The issues with HTML5 have been discussed in detail by Scott Schiller in his 24 ways article "Probably, Maybe, No": The State of HTML5 Audio.

There are however browser specific APIs to work with audio both by Chrome and Firefox which allows for byte-level access to music and you can do great things with those. Having access on such a granular level means you can do all kind of interesting experiments, from syncing animations with the beats per minute of a song up to generating music and voices programatically.

Showcases