What is HTML5?
HTML is the language used for building websites.
What we see is not solely because of HTML – it’s the CSS that gives it shape.
An HTML page is a machine-readable page, the underlying structure.
Getting that structure right is important for SEO, because Google doesn’t ‘see’ the page as we do, only the code.
HTML5 enhances the existing language of HTML, giving it more flexibility and more power.
What isn’t HTML5?
It’s not a whole new language.
It’s not a futuristic new way of writing webpages.
It’s not CSS3 (but they go hand in hand and I will talk about it)
Unfortunately, it’s not universally supported yet.
When will it be ready?
Never. But already. W3C is moving away from releasing an entire specification in one go, and is updating the specification as browser makers start using the functionality. It’s built to be backwards compatible with old browsers, with some fallback occasionally necessary.
HTML5 and CSS3 are continually evolving specifications, so we can use as much or as little as we like now. In fact, HTML5 doesn’t even exist! The specification is now called HTML, to reflect the continuous updating of the spec.
Browsers (even IE!) are starting to understand that it is driven by their users’ innovation as well as by them. Having a standard across all the new technology makes sense for browser makers as it ensures their browser won’t be sidelined.
Even so, there are differences between browsers. Not just which HTML5 elements they support, but how they support them. We’ll have a look at these later.
What’s in it so far?
HTML5 reflects the way the web is changing – you can’t be sure that all users will be sitting in front of a desktop or laptop computer – they could be on their phone, a tablet, a TV, or an as-yet-uninvented device.
HTML5 is all about structure, so we’ll leave the look and design of the page to CSS and the designers. But I need to stress how important code structure is: it makes pages clearer, easier to style, better to read, quicker to load and more search engine friendly.
This is the hard part to explain to clients: you can have a page that looks exactly the same, but the underlying structure can be good or bad. So what structural elements does HTML5 have?
New semantic elements
What do we mean by semantic elements? An element is the building block of HTML, the tags that you’ll see on an HTML page, such as a <div>, an <h1>, an <a>, and so on.
Most of the tags have a meaning associated with them – the <html> tag goes around the whole document and tells the browser where the HTML document starts and stops, a <p> paragraph tag tells the browser that it’s a block of text, and so on. These elements are: html, head (but we’ll gloss over these for the time being), body, h1-h6, p, div, ul, ol and dl.
Web designers have been using the <div> tag as an empty block–level container to hold all sorts of different content – headers, footers, sidebars, blog posts, and so on. They’d then use an id or class attribute to hook up stylesheets to that div in order to position and style it.
However, the structure of a document was difficult to tell when the same element was used to denote lots of different parts. HTML5 introduces a new range of block level elements: article, aside, dialog, figure, footer, header, hgroup, menu, nav and section.
Inline level elements are ones that fit into the run of the page, such as an <em> tag to emphasise text, or the <a> tag to use as an anchor. In HTML these are: span, a, cite, strong, em, abbr, img, amongst others.
Again, HTML5 gives us a few new tags to define parts of the document: address, mark, small, time, details, meter. These fit within the body of the text to define different elements.
So for instance, whereas before you might have marked up a document like fig. 1, now you can mark it up like fig. 2. You can style the elements exactly the same, so the site will still look the same, but Google and other text readers will know what parts of your document are important, which is the navigation, and so on.
This has another benefit – different devices can latch on to different parts of the document to, for instance, build a table of contents or create a print version of a page.
So new semantic elements give us greater control on how our page is structured. There are also some useability additions that have some real benefits, especially in the mobile world.
Forms are ubiquitous on the web, and over the years web designers have been ingenious in making life easier, creating colour pickers, range sliders and AJAX autocompleters. HTML5 has added a range of inputs which make form filling even easier.
Currently we have text inputs, password inputs, file selectors, radio buttons, checkboxes and submit/reset buttons. The new input types, widely supported by Opera and, to a certain extent, Safari, are: date (lots of them!), email, color, number, range, search, tel and url, and some new elements in output, datalist and keygen.
You can see, in Opera, that the new input types react differently, calling a date picker and color picker, and having a user-friendly slider and number selector. Datalist gives you a list of potential choices (like a dropdown list) but also allows you to type your own choice (no more slecting ‘Other’ and then typing in your own option!).
Keygen is not widely enough supported to be worthwhile but help keep your form data secure by keeping a secure key on the server and in your browser and cross checking in subsequent form submissions. Output is a holder for the result of a form.
Why are these useful? Firstly, it makes form validation easier. Many browsers will have automatic checking of form fields, so an email address, a URL or a phone number can never have garbage data entered. Dates don’t get confused (mm/dd/yy or dd/mm/yy) and you don’t have to mess about with Javascript to create a colour picker or calendar.
What happens if a browser doesn’t support it? In all these things, there are fallbacks. Browsers that don’t recognise the tag, it uses a default, so we get the following (fig. 6 – 11). Even in IE6!
The other benefit is in user entry. In devices without built-in keyboards, the space available for the keyboard is at a premium. If you know that the input has to be a number, only showing a numeric keypad is an advantage. The iPhone (using Safari) has different keyboards for URLs (with a .com button) and email addresses (with an @ sign) (fig. 3, 4 and 5)
Lastly, there are the multimedia tags: audio, video and canvas. Canvas is a tag that started life to allow Apple users to create widgets. It essentially allows you to draw on the browser using Javascript. It’s good for games and online graphic effects, and is used in the text replacement technique Cufon, and there are a lot of people making some pretty cool things using canvas.
The audio and video tags are a huge step: having native audio and video playback makes it quicker to load and gives the user more control over the playback control. Flash, which is used in most places, is a good compression and playback tool but relies on an (often unstable) plugin. YouTube now uses HTML5 video in supported browsers.
Here’s where one of the browser differences kicks in: different browsers can read different codecs. A codec is a way of compressing video – so the difference between a .wav and an .mp3 for audio, or the difference between an .mpg and an .avi for video.
| VIDEO CODEC SUPPORT IN UPCOMING BROWSERS |
| CODECS/CONTAINER |
IE |
FF |
SA |
GC |
O |
IP |
AN |
| Theora+Vorbis+Ogg |
• |
3.5+ |
† |
5.0+ |
10.5+ |
• |
• |
| H.264+AAC+MP4 |
9.0+ |
• |
3.0+ |
• |
• |
3.0+ |
2.0+ |
| WebM |
9.0+* |
4.0+ |
† |
6.0+ |
10.6+ |
• |
2.3‡ |
In addition, H.264 has some rather gnarly licensing issues. So there’s no common encoding that all browsers can use – in fact, the current thinking is rather complicated: offer all different encodings with a Flash fallback. At the moment most browsers will have a Flash plugin, so why waste time re-encoding your video?
Essentially, it’s about progressive enhancement. Having the video tag means that if Flash does drop out of favour in future browsers (as it has on Safari for the iPhone and iPad) your users can still view the video. Also, as the video tag is an HTML tag, you can manipulate it the same way you could with any other tag, and control it using Javascript.
Lastly, there are some attributes that you can give to these new tags that will help out: placeholder, that puts default text in an input; contenteditable, which gives you more control over whether a user can edit; lots more rel attributes saying where a link goes and how it relates to the current page; datetime, allowing you to specify a machine readable time (great for things like articles or offers); and the brilliant data-*, which allows you to attach any relevant data within a tag without exposing it to the user, almost like a storage system for tags.
They’re the new elements, which give us even greater control over the structure of our website, help search engines crawl our content better and allow us to separate out structure and design even more.
Web APIs
The other part of a web page structure is the technology it uses. All server-side technologies (such as ASP or PHP) serve up an HTML page, but most of the processing is done on the server. The client’s browser is given a dynamically generated but static page.
Javascript is used to dynamically change this static page – you can use it to do simple calculations, validate forms and highlight errors, and so on. And with AJAX, Javascript can even pop back to the server, make a request, and return to the page, without the page having to be resubmitted.
Browsers are becoming more and more powerful, taking advantage of faster processors in personal computers. HTML5 introduces a range of APIs (Application Programming Interfaces) that allow you to use the browser (and the device itself) to do a lot of processing.
Some of these can be fairly widely used, others will be brilliant but are a little too exclusive at the moment. Bear in mind that the iPhone and Android phones use a Webkit browser, which has good support for this stuff, so is something to bear in mind for future mobile developments.
-
Web sockets
An open connection with the server to allow data back and forth
-
Server sent events
Like push notifications, where the server can send info to browser
-
Web storage
Taken over from WebSQL, to be able to store data on the clients browser. Works better than cookies or sessions, as they are specific to the window or group of windows.
-
Draggables
Something that has to be done with Javascript at the moment, allows users to move things around on the page
-
History
Problems with the back and forward buttons (for example with the Dashboard) are solved! You can intercept back button clicks or send a click to the back button
-
Web workers
Usually web pages are sent as a whole page, but web workers can take several processes and run them all concurrently.
-
Clipboard
Copying and pasting has always been a little tricky – some workarounds include using Flash, but that has its own issues
-
File API
This allows you to manage files better, by dragging and dropping files from your desktop to a browser window, allowing better file transfer and easier file manipulation.
The following have very definite advantage in the mobile sphere:
-
Cache manifest
The cache manifest allows you to specify which files you should cache to use in an offline situation, essentially allowing you to use a website even when you lose connectivity.
-
Contacts
Use your computer or devices address book to get phone numbers, email addresses, physical addresses and so on.
-
Geolocation
Find out where you are!
-
Web Messaging
This allows different browser windows to communicate with one another – currently to do this you would have to store sessions, which is very clunky.
-
Web Notifications (dropped)
Usually websites use popup windows or modal overlays to give the user feedback. But imagine if you can hook into a universal browser notification system, to display messages – you can leave your email open in a background window and still be notified when new messages come through.
-
Media capture
Allow websites to capture, edit and manipulate media such as images, audio or video and save back to your computer. Use webcams and microphones to capture video and audio.
There are tools to do this on your computer already, but the important thing is that you can all of this in the browser. Websites will soon be able to do most of the things that you need separate programs for (in a similar way to Google Docs and Gmail taking the place of Word and Outlook).
In fact, the Google OS uses these ‘cloud’ services exclusively, so you keep almost everything on a website.
So that’s HTML5 covered, now on to the related issue of CSS3.
How does CSS work?
Cascading Stylesheets are the next stage up from the document structure: they lend form and layout to the document, and style the semantic structural blocks you’ve put in place with HTML.
So, for instance, you can say that you want all paragraphs to have a margin above and below them, that you want headers to be a certain font, colour and size, and so on.
CSS2 is now almost universally supported in browsers, and there is a new approach to CSS3. Similar to HTML5, browser makers are leading the way, with suggestions and comments from users helping them work out new features, which the W3C then turns into the specification. This is why you’ll often see “vendor prefixes” in CSS files: to allow users to use up to date CSS but without making other browsers fall over, prefixing a new and snazzy CSS term with –webkit, -moz, -o, -ms and so on mean it will be ignored by any other browser.
In reality, this means you often have to redeclare terms, until the standard is fixed upon. To get an element with the id of ‘sidebar’ to have a 4 pixel rounded corner I would have to write:
#sidebar {
-webkit-border-radius:4px;
-moz-border-radius:4px;
border-radius:4px;
}
(The last one is there so that when it becomes a standard the style will be picked up).
So CSS3 is developing modularly, with parts of the spec being brought in as and when the browser makers agree on syntax and spec. So what modules are available?
CSS Modules
Lots of CSS3 properties are in this transition stage, so using them is a case of progressive enhancement.
It’s a good buzz word to use with clients, but what does it mean? Well, unless you’re a designer, you might think that rounded corners look lovely, but aren’t an integral part of the design of a site. So you add the CSS above and give a little extra treat for the growing number of people using advanced browsers.
With something like rounded corners, it’s possible to do using images, and extra divs, and a few other tricks, but they cloud the HTML code with unsemantic elements, aren’t scalable, require extra fixes themselves (what if it’s on a patterned bg?) and have the overhead of downloading more image files from the internet.
The best way round this, and the way of avoiding a common problem in the step between design and dev, is to design in the browser. If the client sees a JPG of a design, he’ll want the website to look exactly the same. No matter how well you explain that different browsers, screen sizes, colour balances etc. can affect websites, they’ll go back to the static design.
Developing in the browser allows you to show the design to the client in the browser they will always use. If it’s IE6, you’ll get feedback early on that things don’t look right, and you can fix them early. If he’s using Chrome, he’ll see all the jazzy effects. If he comes to see us and we view it here, and it looks different, then you can explain the “different browser, different monitor, different user” model.
So now on to the fun bit: what toys are available for us to use?
There are 45 modules (!) available, only 2 of which are at the Proposed Recommendation stage (ie the spec is ‘set’).
Some of the cool ones are:
- Selectors/User Interface
- Grid
- Multicolumn
- Text
- Media Queries
- Borders
- Transformations (2D and 3D)
- Math(s)
Why use unsupported elements and styles?
So if there’s so much patchy support for both HTML5 and CSS3, why use it? Years back, when the web was new and exciting, people were so excited to have information online it didn’t make a huge difference how that data was displayed.
Now, the web is everywhere, and people are using it not just at their desktop, but on laptops, tablets, phones, TVs, consoles, and lots more. In the same way that a computer in a car used to be a big thing, and all new cars now have several, the internet is informing our lifestyle.
So presenting the same data in multiple ways becomes more and more important. HTML is a logical progression, giving users more power to take control of the internet rather than serving it up as a prepackaged page. No two user experiences are the same, so we need to make sure we cover as many of those as possible.
Obviously we shouldn’t ignore those who are on less-advanced browsers, if we know it’s still a core part of our user base. But if you’re making a web app, then you can, and should, use the correct tools for the job, and technology that was current in 2001 (when IE6 came out) is now very dated.
The same is true of styling. Adding the extra flourishes and details is something that will reinforce the decrepitude of older browsers, and encourage browser makers to do more to update their browsers.
Chrome is already on version 10 of their browser, after 2 and a half years. It took Microsoft 5 years to upgrade from 6 to 7. The web moves quickly, and soon these will be everyday items in a web developers toolbox.
Browsers can use these tools now, and we lose out if we spend too much time looking back. They lend themselves to faster loading times, easily indexable and understandable pages, and user interaction.
Why is it important to Epiphany?
Epiphany doesn’t offer SEO, PPC or Web Dev in isolation. It’s an interactive thing – each feeds into the others. We understand that site optimisation is more than just driving traffic to the site, and that your website itself feeds into that crucial Google ranking or position on the Results Page. Plus, traffic being driven to a site means little if it doesn’t convert, and the usability of pages affects this.
We keep up to date with what search engines do to rank your page, and site optimisation is one of those. Pages that use native browser technology take less time to load, which makes the site better: better for users, better for server loads and better for Google.
It is important for any company working in the computer and internet industry to keep up with new technology, not just to be able to use the right buzzwords with clients, but to be able to explain our reasons for using it and, importantly, to deliver real measurable results.
Lots of the things we’ve talked about today don’t impact our web dev much currently, but may well be the cornerstone of future development projects. I know the R&D team, and the web dev team, are interested in doing more with web sites, with web apps and with mobile development, and this stuff can help us with that.
So the next time clients come to us and say “Is it built in HTML5?”, hopefully you can give a slightly better informed answer than you could an hour ago!
