Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for February, 2007.

Archive for February, 2007

Talking about Ajax and Accessibility at Abilitynet

Monday, February 19th, 2007

Today I was parachuted in to Abilitynet to give a quick talk about Ajax and accessibility as their original presenter couldn’t make it. I had given the same talk in German last year and updated some of the information on it before going there.

Talking about Accessibility and Ajax

Showing off the new and cool Yahoo! Accessibility Stakeholder Group shirt (“what is the button for?” Braille!) I spent an hour talking about the ins and outs of Ajax and its accessibility issues. You can download the presentation – PDF 400KB for some light reading.

What I found in the demos that I showed and the subsequent testing with different screen readers (IBM homepage reader and newest Jaws) is that it is not enough to assume that you know what screen readers do. While the changing of the link text as shown in example 3 and 4 actually is considered a good practice to tell screen reader users that something changed it only makes sense when the user re-reads the current line in Jaws and it even is worse in HPR, as the user gets asked to reload the page or press “Home”. The intended focus shift in example 4 (and partly nicked from Gez Lemon’s example) didn’t work either, I am sad to say.

It really seems that we either have to start hacking for different screen readers or just wait until WAI ARIA Live Regions are supported cross-browser and platform.

In any case, this is also a good thing as it keeps people from testing something with one screen reader and considering it accessible after that. Blind users are as diverse and different in their internet usage as sighted people are.

Review: The Book of JavaScript, 2nd Edition: A Practical Guide to Interactive Web Pages

Wednesday, February 14th, 2007

I was sent a copy of Thau’s new book “The Book of JavaScript, 2nd Edition: A Practical Guide to Interactive Web Pages” to review and I wrecked my brain for several weeks as to what to write about it. I showed the book to other colleagues and bloggers who’ve been approached by the publisher to write about it and we all faced the same issues reviewing it. We all were happy about the opportunity, but didn’t want to write a really bad review as there is not much to gain in negativity.

In essence – the book is a wasted opportunity of a re-write and brushing up of a once good book.

I got inspiration as to how to tackle this review when I watched an episode of Scrubs, which featured an older doctor that everybody in the hospital loved and saw as a mentor. This doctor asked a new intern to perform an outdated and possibly dangerous technique on a patient. As the person almost died, people started to realise that the doctor they all admire hides his lack of improvement and ability to learn new techniques behind a very likeable façade. In the end, they had to let him go as this made him a danger for the patients.

This book is exactly the same as this doctor. Thau wow-ed thousands of people with his JavaScript tutorials on in the past and he has a splendid way of writing and making the readers engage with the book. As a reader of his work it is easy to feel good about quickly learning something you thought you’d never understand. The feel good factor of this book is amazing and the comments on amazon prove that.
In the first edition of this book released long ago this was a great asset to make people go out there and write their first JavaScripts in a matter of minutes. It comes with a price though: the lack of warnings about possible dangers or failures of the techniques mentioned in the book makes it very easy to write unsafe scripts that are a nightmare to maintain.

If you buy a JavaScript book now you expect state-of-the-art information as JavaScript is hot and we learnt a lot from our past mistakes. An equivalent in the non-computer world would be that if you were to buy a book on car technology you’d expect some information on hybrids and eco-friendly cars as much as all about the combustion engine.
This book is like a detailed explanation of how to fix 1940s tractors.

In recent years JavaScript has undergone a massive change: as browsers support the standards set by the W3C like DOM and CSS at least to a stable degree we are able to use these techniques to write scripts that are agnostic of what browser they are executed in. Instead of relying on a browser we simply test for the objects we want to use and only use them after our scripts were successful in detecting them. We also don’t rely on JavaScript but enhance functionality that works without it to make the experience for the end user smoother. These concepts are called progressive enhancement and unobtrusive JavaScript and are never once mentioned in the book, which is a shame as they ensure that when new browsers come out you don’t have to re-visit your scripts and fix them.

The book is very much geared towards browsers and advertises browser sniffing as a valid way of finding out if your script will be OK to execute. It also happily mixes HTML, JavaScript and CSS in one document without separation – something that Zeldman taught us as early as 1998 not to be a clever way of development.
I cannot believe that Thau himself lacks that much insight into how things moved forward in the JavaScript world. My guess is that the book was not re-edited technically (except for a new screenshots) but only extended with a new chapter on Ajax. The mention of which is “coming soon” and which hasn’t been upgraded since 2002 as great DHTML resources shows that there was not much research happening.

The book smacks of a re-write that went terribly wrong. It is like a “best of” CD of an artist that didn’t want to release a new album but was bound by contract to do so. To make the collection more interesting the label put a “previously unreleased” or “rare live” track at the end and voila – new album!

The new Ajax chapter is OK in explaining the basics of Ajax and features exciting examples but also lacks proper technical editing. For example there is no mention of what to do when the connection doesn’t work properly – using a timeout to tell the user to re-try. There is also no mention as to how to provide links that work without Ajax and override their functionality when JS can be applied. You can build your first Ajax apps with the information provided, but you also create apps that break very easily and are open to attacks. The PHP examples provided don’t check any form data for injected scripts or third party URLs and the book never mentions that this could be a problem.

Overall I am terribly disappointed by this rewrite. The cool title, the oldschool aura about Thau and his engaging way of writing could have been a recipe for a really good JavaScript book for beginners and hobby users. The outdated examples and advertising of unstable techniques as feasible solutions mean that you might as well buy the first edition second hand and go and read an online tutorial on Ajax.

Both Jeffrey Zeldman’s Designing with Web Standards and Steve Krug’s Don’t make me think had a second edition re-write last year and prove that you can build up on an old great book and make it even better and thus worth while spending money on although you have it already on your bookshelf.

I am sorry that I cannot say anything nicer, but that is how it is. I am not a big fan of saying bad things about people or products. If I rip on you personally in public then it is a sign of affection – or that I am terribly drunk – actually most of the time both.

Going to Singapore to give a DOM Scripting and Ajax Workshop

Wednesday, February 14th, 2007

I am proud as punch to announce that I am going to be in Singapore holding a workshop on DOMscripting and Ajax for Pebbleroad on 28th and 29th of March.

This is the rough schedule:

Day 1

  • Understand the nature and basic principles of JavaScript
  • Avoid making mistakes of the past and prepare for future browsers and platforms
  • Create easy-to-maintain scripts that can be easily localised and internationalised
  • Use JavaScript to create engaging and accessible interfaces

Day 2

  • Bridge the gap between server and client with Ajax
  • Use a JavaScript library to make your life a lot easier
  • Use third party content in your products via APIs and JSON
  • Solve common accessibility problems

Who should attend?

  • Web Developers/designers with basic knowledge of JavaScript
  • Web Designers who want to create dynamic, engaging interfaces and not sacrifice accessibility

console.log() for Internet Explorer with Faux Console

Tuesday, February 13th, 2007

Nearly every modern browser supports the console.log() command to print out data during debugging without having to resort to alert() and pressing enter until you go nuts. Of course Microsoft Internet Explorer does not, which is why I found myself getting false error reports from collegues when sending them code to check out (I naturally use Firefox with Firebug).

To change this situation I wrote a small JavaScript that simulates a console only when your browser does not support it. This means that you can use console.log() safely and even MSIE will show you the output in a small dynamically generated DIV on the page.

P.S. Robert, should I have called this “The only simulated debugging console you will ever need?”

Q&A: How can I track the change in a form field before the form was submitted

Monday, February 12th, 2007

Q: I need to know when a user has changed the content of a form field before submitting the form. It’d be easy in PHP to compare the value stored in the DB with the $_POST value of the field, but this needs to happen in JavaScript.

A: There are several ways to do that. You could loop through all the fields when the document has loaded and store their values in an array and loop through and compare with that one when you submit the form (catching this via a submit handler on the form element and not when a button was clicked as the user might hit the enter to submit the form). However, this means you need to loop twice and when you run the loop to read out the values when the document has loaded the user might already have started editing the field. A much cleverer version is to run only one loop when the form was submitted and compare each field’s defaultValue property with the value property. It is not that known, but every field has a defaultValue property that stores what has been the value in the value attribute when the element was rendered. The value property stores what was entered in the field at the time you read it out. When the two don’t match, the user has altered the field.

This has been published in the Q&A session of the UK based paper magazine “net”. Reproduction rights were given by the publisher.