Ben Ward

Ajaxising

. Updated: .

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:

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.

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"> [...]

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.

Comments

Previously, I hosted responses and commentary from readers directly on this site, but have decided not to any more. All previous comments and pingbacks are included here, but to post further responses, please refer me to a post on your own blog or other network. See instructions and recommendations of ways to do this.

  1. Si Jobling

    Seeing as I can’t attend @media Ajax due to personal commitments, it’s been useful to read other’s opinions of the conference, especially those who aren’t particularly “Web Celebs”.

    It’s refreshing to see an honest opinion about, what sounds like a pretty bad example of implementing “AJAX” into a Web app that, quite frankly, doesn’t harness the true power and intention of JavaScript. Implementing non-Standard code into your HTML is just asking for trouble, specifically if that content could be implemented using the correct markup (the example enclosed with fathers and children could, and probably should, be a simple unordered list with class selectors on each list item).

    Thanks for the write up though Ben – I’ll be looking forward to your thoughts from Tuesday’s session.

  2. Martin

    You are not alone with your experience of the N95:
    http://beyondthetype.com/2007/8/30/n95-update-3-months-on

    Great phone which I really like but there is some usability issues which can make things quite frustrating at times..

    Martin
    (reading your update on @media ajax via technorati)

  3. Emil Stenström

    Hi!

    I also attended the @media ajax conference and I have to agree on the first part of PPKs presentation: his app could well fit into the page metaphor. On the other issue, he wasn’t really using invalid attributes, he just proposed that as one way to store the data on the server. My guess is that he would replace them with javascript on the client later on. He needed the info on the clientside to build the graphs.

    None the less, good writeup!

  4. Matt Robin

    Great article Ben, very thorough!

    I’m glad Derek’s presentation went well, and I’m very disappointed to read that PPK’s gig was so very wrong!

    In fact, reading the HTML snippet you provided made me groan (and not in a good way!) To give such misleading content at a presentation – from someone of his expected good reputation – is definitely alarming…and I hope it’s not a sign of things to come! Ajax, despite the hype, is really quite good stuff (as far as I can tell), so it would be a waste if we see it implemented badly on the Interwebs based on the poor guidance from some of the alleged experts!

  5. Ben

    Emil,

    On the other issue, he wasn’t really using invalid attributes, he just proposed that as one way to store the data on the server. My guess is that he would replace them with javascript on the client later on. He needed the info on the clientside to build the graphs.

    Just to respond to this, because having started out on a blunt whim of ‘it matters’ I feel should at least maintain the corrections.

    The attributes PPK wrote into his HTML were invalid. They don’t exist in the HTML4 spec. I find it hard to justify making up new attributes in any situation (we have the open-ended class attribute, after all), although efforts like ARIA (introducing the role attribute from XHTML2 into HTML) at least have some organisation behind them to support their recommendation. Making up attributes on a whim is just bad form, though.

    And to expand on the reasons why he didn’t need the attributes at all: The data was loaded from an Ajax call to the server. The application received XML back, which contained all of the data needed to map the relationships. Having parsed the XML, all the relationship information is already on the client side. There’s no need for it to be written into the HTML elements themselves. An object can just remain in JavaScript, mapping the ID attribute of the HTML elements, to the extended data about the relationships. Writing it into the HTML is not only invalid, but also adds expensive steps to read the data back from the DOM again.

    Hope that clarifies.

  6. Jim

    I thought he was comparing HTML vs. XML (vs. JSON vs. CSV) at that point as a mechanism for transporting data from the server to the browser. With the point that HTML requires extra attributes to store the relationships. I think the HTML that was added to the page, and rendered in the browser, had invalid attributes removed.

    I could be remembering the talk incorrectly, though.

You can file issues or provide corrections: View Source on Github. Contributor credits.