Posts Tagged ‘html5’

HTML5

I’m late to the party as usual, but here’s my summary and opinions of the recent fuss over what is and isn’t HTML5.

HTML5 means two things:

  1. A standard published by the W3C
  2. A label (analogous to DHTML or Web 2.0) for a group of new web technologies, including the standard referred to above but also CSS3, SVG and other technologies.

So that’s one precise, technical meaning, and one vague, fuzzy meaning. If you’re talking to developers, web designers, browser manufacturers or CTOs you use the first meaning; if you’re talking to marketing types or CEOs you use the second. If you’re talking to a mixed audience you need to clarify what you mean. It’s not ideal but it’s not the end of the world.

The W3C produced a new logo as part of their effort to promote HTML5. This was marketing activity and the usage seemed to be close to the second meaning above. However, this is the W3C and their core audience is technical and hence expected the first meaning. Some fuss and a few edits to the FAQs later and the situation was clarified.

Meanwhile the WHATWG have decided that from now on they are working on the living standard of HTML and that version numbers are passé.

This actually makes a lot of sense. Browsers don’t implement versions of HTML, they implement a hodge podge of features that appeal to them. Most web sites are thus created based on what works on browsers. When we say that we’re building a site in XHTML 1 and CSS 2.1 we mean the subset of those features that are both useful for the site in question and supported by IE7, etc.

But developing (a site, an API or a browser) to a moving target is difficult and troublesome. Having a standardised version of the spec is useful, it means that my example site using that subset of XHTML 1 can be checked against that standard today, tomorrow and five years from now.

The good news is that there’s no longer two HTML5 standards to cause confusion. Now there’s HTML at WHATWG – an iterative, ever evolving specification that acts as an ideas generator and prototype for the future of the web, and there’s also HTML5 (and maybe one day 6, 7, etc.) at the W3C – a slice of the living standard, reviewed, refined and eventually set in stone as a standard.

I’ve been using parts of HTML5 for over a year now – I’m using a fairly safe subset of features (and <hgroup> which some people seem to have a problem with and want to remove or change) and can refer to the W3C spec for details whilst keeping one eye on the WHATWG for future developments. This seems like a sane approach for most front end developers – there’s a lot of exciting changes coming out and only a few people will have the time and resources to keep on top of all of them.

Still, we’ve got a logo now. 🙂

Tags: , , ,

This week I converted a site from XHTML 1 to HTML5, and as part of this I moved the ARIA landmark role attributes from generic div elements to various new elements. And I got to wondering whether this could have unforeseen consequences.

I know from feedback that the ARIA landmark roles have proved useful for some users of this site, so it would be a bad move if this stopped working because their screen readers didn’t recognise the role attributes on “unknown” elements.

<div role="banner"> vs <header role="banner">

I guess what this boils down to, are there any user agents that (a) support the role attribute and (b) use the DOM as generated by a browser engine that fails to recognise HTML5 elements?

Firefox 2 and Internet Explorer won’t style HTML5 elements (though IE will after applying a little JavaScript magic) but styling isn’t the same as recognised at a basic level.

This seems like an edge case, as most of the reports I’ve found whilst searching have indicated that HTML5+ARIA is a good thing and works, but most of the reports don’t specify versions of user agents used. Does anyone have any links to first hand research into this issue?


Part 1 of a few.

It seems that everyone has started talking about HTML5. I’ve recently converted sfsfw.org (still a work in progress) to HTML5 (ditto) and built a microsite at work in the language.

So, what parts of the brave new world am I embracing?

The new doctype

<!DOCTYPE html>, well that will save a few bytes per page. I’ve never tried to type a doctype from memory before, I’ve always cut and pasted from another project or from an authoritative source, but now I might just type it, saving a few seconds. I can’t help feeling that the lack of versioning information is a making a problem for the future (and let’s not get into the related area of all the things that HTML doctypes do/mean in comparison with what SGML or XML doctypes are meant to mean…).

The new character encoding

<meta charset="utf-8" />, again that will save a few bytes on those pages where I bother to include a meta tag rather than just trusting to the HTTP header (and I know why the belt and braces approach is useful, so long as they both tell the same story).

The new block level elements

<section>, <article>, <header>, <footer>, <aside> and <nav>. These are rather cool. Not immediataly earth shaking but they make code cleaner and debugging easier – less often will I be staring at </div></div></div></div> and wondering whether my current problem is caused by having too few or too many closing div tags.

The new input types

number, tel, email, url are already being used in several forms on visitlondon.com and it makes me smile ‘cos me and a handful of other Opera users get to see the benefit right now. I think these will be my favourite part of the new spec for some time to come.

There’s a lot more to HTML5. This isn’t meant to be a tutorial, just some personal observations and use cases. I’ll try to delve a bit deeper into how I’m using these pieces of code and why I’m using these but not others in future posts.

Tags: ,