Posts Tagged ‘html’


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: , , ,

Part 1 of a few.

It seems that everyone has started talking about HTML5. I’ve recently converted (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 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.

Via Zeldman I learn that the W3C’s XHTML working group is shutting up shop at the end of the year.

What does this mean for XHTML? In terms of standards, XHTML 2.0 is dead, and the only games in town are now the XHTML 1.x family and the XHTML syntax of HTML 5.

Which in practical terms means almost nothing at all. XHTML 2 wasn’t gaining any support form browsers, authors or advocates. It wasn’t backwards compatible, progress was glacially slow and nobody was talking about it. It was already dead. This move is just the W3C accepting reality.

I rather like the cheeky way that Mark says it in song.

Tags: , , ,

I’m ill. :-(

So only a short post today. Opera have released more data from their MAMA survey, including this gem:

MAMA used a MySQL SMALLINT data type (max. value: 65,535) to store the quantity of comments on a page. Surprisingly, in the most extreme cases this was not big enough. Only 1 URL was found to exceed this in MAMA’s URL set […] MAMA stored its maximum value of 65,535, but a live analysis showed 146,376 comments in a 9.2MB HTML file!

Opera Software have been busy (sadly not busy fixing the problems Opera browser has with Gmail) and have released the findings of MAMA – a huge study into what the web looks like at the code level. I love this sort of study, but I am a huge geek.

This made me laugh out loud, from the part of the survey looking at whether HTML validates:

Authoring feature used Criteria used to match Quantity validating Total quantity using technology Percentage validating
IIS Web Server Detection of “iis” string in HTTP header Server field 24,743 883,854 2.80%
Apache Web Server Detection of “apache” string in HTTP header Server field 110,834 2,347,328 5.38%

Pages served from IIS are nearly half as likely to validate as pages served from Apache. Is anyone surprised by that finding? Is it due to the difficulty of making ASP (classic or .NET) output valid code or is it due to the mindset of the typical ASP developer?

Let’s get this straight – here we have someone who argues passionately about standards in various public fora but he now says that his sites don’t validate? Sounds like a hypocrite.

Let me explain. Of course my sites, such as my home page, my blog and my hobby sites all validate. What I’m talking about are the sites that populate my CV. Why do none of them validate?

Mostly I blame other people.

I hand over a perfectly validating template and then an ASP coder or a web editor starts shoving all sorts of crap in there. They mix up XHTML and HTML syntax in the same document, they don’t encode ampersands, they forget alt attributes, the nest elements incorrectly, they don’t understand character sets. So after a few months all the pages have been hacked about and nothing validates anymore.

So what am I to do when a job spec asks for examples of validating web sites?

Tags: ,