DOM scripting Health and Safety

My favourite pieces to commission when I jobbed as a packer at a chainsaw factory were the health and safety instruction videos. "Never check the level of petrol by holding a lighter to the opening" and "Never keep the blade between your legs when trying to start the chainsaw" were just two of the highlights.

Health and safety measures are important – they ensure that our work environment is enjoyable and will not make us sick. Just because our job is handling user agents and typing funky words into an editor does not mean we shouldn’t follow some of our own.

Right now, DOM scripting with JavaScript is hot again (the over 3000 unique hits on my post about outdated JavaScript techniques proved that to me) and we run into the danger of overusing it or using it in the same obtrusive ways we used JavaScript when DHTML was the flavour of the month.

When your tool is a hammer, everything looks like a nail, or – in some cases – a thumb.

Let’s not bash anything in sight or mince our own thumbs. DOM and JavaScript are there to enhance the structure and interact with the presentation of a web site – and not replace them.

Ideas that prevented me from repeatedly hitting my thumb:

1. Don’t create HTML that should be there without JavaScript. Re-use what is already in the page instead. An accessible site starts with a semantic, well-structured HTML document. If that is not given, there is no chance we can be accessible. Not creating HTML via DOM makes the product a lot easier to maintain. Non JS-savvy colleagues won’t have to butcher your code to make a change on the page.
2. Generated HTML follows the same rules as written HTML: Don’t create invalid HTML. We stopped using CSS to make elements look like headers instead of using real header elements. The same applies to the DOM - redundant HTML elements to fix a design or add a design feat are – well, redundant, no matter what technology was used to add them. By the way, this also applies to server side scripting.
3. Be aware of visitor and user agent restrictions. An example are my fabulous clickable headers of the Unobtrusive JavaScript course. They look handy, work cross-browser and were developed with a clear separation of structure, presentation and behaviour. Where they fail is when you try to use them with a keyboard. The power of the DOM seduced me to turn a header into a hover-able and clickable element, but there is no way to use it without a mouse. That is why I will add a real interactive element to the headline – a link – to make them work for keyboard users (and possibly screen reader users) as well (thanks must go to Stéphane for flagging that up to me).
4. Understatement is class. Before adding all kind of cool new JavaScript features and make everything hover, click and move it is a good idea to lean back and think: "Is this really necessary? Do I add it to help the user or do I add it because it is cool?"
5. Don’t break too many conventions. As posted earlier, I see the web as a secondary media, and assuming that the visitor pays detailed attention to our web sites is more narcissism than reality. If we need to explain functionality to the visitor in a piece of text, there is a big chance that we will confuse rather than help. Example? Users hitting the back button on AJAX apps and pure Flash sites.
6. Leave a clean desk. Especially in distributed developments it is of utmost importance that everybody speaks the same "code language" and that handovers are painless and quick as the code is already properly documented. Define an in-house coding standard, comment your code where applicable and there will be a lot less stressed faces and moaning when people get assigned to projects.