Jeremy Keith — Progressive Enhancement with Hijax
Public health warning – there will be code!
Taking notes on a code-heavy presentation is a difficult challenge; I strongly recommend you grab Jeremy’s presentation slides to accompany these notes.
- AJAX is often treated as all or nothing technology, much like plugins – either you have it, or you don’t.
- Ideally you want to have one site that provides both AJAX and non-AJAX facilities; this is progressive enhancement.
- Progressive enhancement begins with semantically meaningful content; you then add the presentation layer and the behaviour layer.
- Stylesheet must be kept external; inline styles are no better than font tags.
- JavaScript pseudo-protocol is evil; always has been. JavaScript is not a protocol, pseudo or otherwise.
- Inline script, much like inline CSS is a maintenance nightmare and should be avoided at all cost. Both presentation and behaviour layers can be kept external; there’s no reason you can’t.
- Jeremy shows a JavaScript function that scans through the DOM looking for links with a class of “help” and makes them open in a popup rather than the current window. This is the alternative to inline event handlers. This is unobtrusive JavaScript.
Don’t use global variables kids; they’re bad
- Next code walkthrough involves creating an instance of an XMLHttpRequest object; setting up the response handler and calling the object’s open method (define POST/GET, URL and whether it should be an asynchronous request)
- The readyState property: has 4 states, but only the value of 4 really matters to us; that’s the one that says
I’m done, lets rock!
- Returns either responseXML or responseText; responseXML MUST have the correct mime type from the server, repsonseText can be text, JSON, HTML, whatever you want.
- Progressive enhancement with AJAX is very much possible – Hijax is Jeremy’s buzzword for it.
- Step one of Hijax development: build a website using traditional page refreshes.
- Step two: Hijack (get it?) the links and forms using unobtrusive JavaScript
- Server requirements: back-end architecture needs to be modular; pages are then made by joining those modules together when needed. You need to plan for AJAX when deisgning the back-end, but don’t implement AJAX on the front-end until the very end (end)
- Visual feedback is incredibly important; if adding ‘field is required’ errors via JavaScript, add it to the <label> element to help out screen readers.
- Jeremy demonstrates examples of Hijax including shopping cart and contact form. The data the server needs is always contained within the form or the link query string. These values are grabbed by JS and the script returns
falseon success; thereby cancelling the default action for a link click or form submission The browser is no place for business logic
— use the XMLHttpRequest object like a dumb waiter; it is just to carry data around, not to do any heavy lifting with that data.The browser is an unpredictable environment […] you control your server, do all your data processing there
- Jeremy recommends we don’t even use JavaScript table sorting scripts.
- Key benefits of Hijax: no need to build two versions; no duplication of logic (eg: form validation done exclusively on the browser); Keeps your logic where it should be – on your server; keeps your JavaScript file size down.
Sounds very interesting!
Do you know if Jeremy has released any code to do this hijaxing with?
[…] I strongly suggest you head over to the WebDirections website to have a look at Jeremy’s presentation on the topic with a special focus on AJAX. Apart from the slides available at the site I would also recommend to have a quick peek at the live blog notes that Andrew posted during/after Jeremy’s presentation. […]
Troels, there are various snippets of Hijax examples around the interworldwebnet. Jeremy’s “DOM Scripting” book introduces the idea nicely, but his forthcoming title “Bulletproof Ajax” is likely to evangelise the hijax concept with code examples.