Getting Your Hands Dirty With HTML5
What can you do with it now, what in the future?
Intro
Next iteration of HTML spec. Long overdue for overhaul. What are we trying to achieve? Do things you can’t do now without JS, for instance. Working on HTML and XHTML together. Authors can choose which is most appropriate for them.
Design Principles
- Compatability – Browsers must remain compatible with existing content, old sites MUST still work.
- Degrade gracefully – make new features work in, or at least not break, new browsers.
- Don’t reinvent the wheel – fix what we already have, don’t reinvent it from scratch.
- Pave the cowpath – consider Use Cases – look what authors already do and improve where neccessary.c.f. Microformat Date/Time pattern.
- Evolution, not revolution – make incremental improvements. Can’t discard existing content and start fresh.
- Solve real problems – ensure work is relevent to web developers. Identify the problems first, then find solutions.
- Priority of Constituencies – have to prioritise the needs of:
Users, authors, implementers, spec writers, theoretical purity - Secure by design – protect end users from malicious intent
- Separation of Concerns – Separate presentation, structure, semantics where doing so provides real benefits. <b> and <i> are still in the spec.
- DOM Consistency – minimize differences between HTML and XHTML, allow scripts to work now.
- Avoid needless complexity – authors won’t use something complex if they don’t understand it
- Well-defined Behaviour – 97% of web has syntax errors! Define precisely what browers must do with all possibly bad input.
- Handle Errors – authors make mistakes all the time, the spec must define how browsers handle the errors.
- Media independence – make sure pages work on different media, devices and platforms.
- Support World Languages – support pages in any language, bi-directional text etc
- Accessibility – provide for the needs of users with disabilities. Built-in preferred over add-on accessibility, where possible.
When can we start using HTML5?
As soon as the browsers start implementing the features. FF3, IE8 support some of the spec.
What can I do with it?
Common elements of a blog – header, main nav, article, sidebar, footer. So we get:
<header> element – for site-wide header, not H1. Title/subtitle etc.
<nav> element – screenreaders could jump straight to it easily
<article> element – for the main body
<aside> element – for sidebar etc, pullquotes.
<footer> element – for copyright info
These can add more consistency than using <div>s and variable class names.
<section> elements can be nested – each of which has H1 – without worrying about correct nesting of H1, H2 elements.
<time> – for posted date of blog item. Attribute has machine-readable timestamp, tag wraps human-readable content.
<figure> – represents image(or table etc)+caption, <legend> nested inside to associate it together.
<caption> not used for reasons of backwards compatibility.
<meter> – attributes shows rating of content – the bar is drawn by the browser not meant as a graphic. Eg, content of element is 3/5, the bar is drawn by the user agent. Also progress bars
<progress> for dynamic (ajax) apps.
<video> – native video support in browsers, DOM APIs for providing custom interfaces, no more dependance on Flash. Browser provides the controls etc. Casual authors can quickly cope with video files.
<canvas> – dynamically draw graphics and text, graphics-oriented DOM APIs.
Offline Web Apps – offline caching APIs, local storage, SQL database.
Developer Tools – HTML5 conformance checker – exceeds the capabilities of traditional DTD bases validators. Gives more useful info.
Parsing HTML5 – libraries for python, ruby. off-the-shelf parser reduces reliance on RegExpr hacks.
The Community – diverse group of individuals and organisations. W3C, WHATWG trying to work together. Open to everyone.
How to Contribute – general feedback, develop tools, research, community participation.
