I’m back from day one of @media Ajax. I’m here because JavaScript is my weak hand. It’s the technology I’ve worked with the least, although I’m plenty experienced as a programmer more generally. It’s been a really very interesting day indeed, although perhaps not entirely for what I’ve learned.

Following sessions from Dion Almaer & Ben Galbraith of Google and Ajaxian, Mike Stenhouse, Derek Featherstone, Christian Heillman and PPK, it’s seems as though the ‘Ajax’ professional is on pretty rocky ground. The conference has been excellent, but the messages coming out are mixed.

On the positive side, Mike Stenhouse is adapting his designer role to accommodate more interaction between the backend and frontend development processes. Derek Featherstone has got accessibility for JavaScript techniques increasingly concise and — and for the this I respect him greatly — he’s not afraid to just declare when some implementation is wrong.

For the past four years, web standards have risen from the fringe ‘proper way to do it’ to being the best practice. Web Standards are not just proper, they are right and they are best. Accessibility is not something you tack on if there’s time, it’s not something you integrate in the face of legal requirements. It’s the accepted right thing to do. It’s correct. It’s a fundamental part of being a professional web developer and integrating accessibility concerns into your web development process isn’t optional.

It’s always been questionable quite what planet Google develop on. On the one hand they employ one editor of the HTML 5 specification, on the other hand they produced the mark-up abominations of Gmail, Google Calendar and Google Reader. The impression you get from Dion and Ben is that Google see the web, and the HTML and CSS that powers it, as a massive inconvenience. Really, they’d much rather just write end-to-end Java rather than these lowly, primitive web technologies. But that’s how Google are, it seems. Peter-Paul Koch, however, should know better.

PPK’s presentation irritated me immensely. He intended to highlight some intricacies of implementing an Ajax application, but his example set a shockingly bad example for everyone in the audience. He demonstrated a family tree, with two outrageously unacceptable assumptions from the outset:

• That the data his application presented was unsuitable for representation in a conventional, pages-based web site.


• That adding proprietary attributes to HTML is acceptable.

Because he did not map his application to a conventional pages structure, he claimed justification to produce a single-page, JavaScript-only solution with no fallback, and no URLs.

I’m quite confident that everything can be mapped to a multiple page structure somehow. But, PPK’s example data not only can map to URLs, but actually maps very well indeed.

The family tree focuses on individual people. You focus on a single person and view their siblings, spouse(s), parents and children. You click another family member and the view changes. Every single individual person in a family tree is a resource. A resource can (should) have a URL. If every individual person has a URL, you can operate without JavaScript. Adjustments to the displayed depth of ancestry or progeny should then be passed through the query string; that’s what it’s for.

• http://example.com/person/1232?ancestors=4&descendents=2


• http://example.com/person/343


• http://example.com/person/2000?ancestors=2

Second, he proceeds to embed data about the family members into semantically neutral HTML, using invalid attributes. It’s not acceptable to abuse HTML like this. PPK’s snippet came out something akin to this:

<div class="person" father="3" mother="5" sibling="2" child="17"> [...] </div>

That’s not OK. It’s not OK to preach that sort of HTML misuse to a room expecting to be lectured in best practice by an expert. It is wrong. Worse, it’s not even necessary.

In this situation, the only attribute you need on a each ‘person’ node is an ID. That ID can be used to map to a data object structure that remains in the script layer. There’s simply no need to write the data relationships into HTML at all.

Honestly, it’s concerning. Here we are in possession of a quite young technology with which it would be quite easy to create a whole generation of terrible, harmful web applications. With it we could — as Mr Langridge so wonderfully suggested — ‘destroy the web’. That’s why we are having conferences like this. We need to set and enforce strong baseline principals. We need need to stand up for the last three years of best practice that events like @media have tried so hard to encourage. If someone is trying to push new best practice in JavaScript whilst disregarding mark-up, CSS and accessibility we need to call it out and declare that it wrong.

Ajax — which seems to have become a catch all term for any modern JavaScript now — is a great opportunity to enhance applications. We can create user experiences that go beyond anything that’s been possible before. But those visions, ideas and grand steps forward are worth absolutely nothing if we throw away everything we already know in the process.