Where do you store that information? How do you associate it to the DOM nodes? I will present three approaches to this problem..

Method 1: The squeaky clean

The first method is relatively straight-forward: You add ids or classes to your DOM nodes. Then you include a dynamically generated javascript library in your document.

The problem with this is that the generated javascript library is requested in a new request which makes it nescessary to provide this request with the nescessary context to generate it. You also need to write code which finds your DOM nodes and finds the data from the included javascript library and associates both. You also walk over the server side data twice: Once to generate the DOM nodes and once to create the javascript library.

Method 2: Compromising

The second approach is to compromise a little on the separation ideal and render the javascript data from the first method right into the page source.

You don’t need to carry the context for the data into a second request for the javascript library, but you still need to wak the data twice on the server side, you still need to associate the DOM nodes to the data, and you have a big block of js data in the head section of your document.

Method 3: Annotating DOM nodes with JSON

I thought about a way to directly associate the DOM with additional data. JSON seemed to be a good format to store the data. At first I thought about using a custom attribute but I did not like the idea of invalid HTML markup. Then I got another idea:

Why not use the event handlers? Something like

<a href="/no_js" onclick="return { foo: 'extra', bar: 1};">Link</a>

works pretty well. It is totally valid HTML, the onclick contains valid javascript code which can also be easily parsed by other tools. (It is basically just a JSON string wrapped with a “return [...] ;” ) When javascript is disabled, the link just executes normally and can provide non-javascript functionality. The data can be retrieved by executing “var data=linkNode.onclick();”. “But what about the fake event handler?” you might ask. Well.. if someone clicks on the unmodified link in a javascript enabled browser: nothing happens. The script just returns some data and does nothing else. The return code will be ignored by the browser environment due to this age-old, pre-DOM standard of canceling the event if the handler returns false and just going on if it returns true — since the data is something it evaluates to true so it’s just ignored.

On the server side things get much easier. Not only does no context need to be carried into another request but you also only need to walk over the data once. You can ouput the HTML and the additional javascript data into the same part of the document.

I admit that this approach bends the rules of separation a little, but in my opinion that’s ok.

• It uses onclick=”" but does not really put any code in there, just some data
• The semantics of the original markup are kept as they are. The method only allows to annotate this “base data” with additional information.
• The pros vastly outweigh the cons

• Content
  The content of the web application expressed in semantic HTML markup, enriched with additional ids and classes to refer to in the other layers
• Layout
  CSS rules for styling the content
• Behaviour
  Javascript code transforming the DOM to provide a better user experience

While this wisdom is very much common place for the first two layers, many people still don’t do the Behaviour layer correctly. There are several important points to this:

1. Build every single page so that it works well without any javascript. Do not rely on javascript for navigation or load content via javascript etc.
2. Build your scripts so that they use DOM methods to transform the non-javascript page into a better page using javascript.
3. Use w3 DOM scripting in your pages. No document.write nonsense, no onclick=”" for events. If you want to or have to support Internet Explorer that means using additional addEvent methods. (See the links for John Resig’s excellent addEvent )

Links:

• A List Apart: Separation: The Web Designer’s Dilemma
• mezzoblue Markup Guide – about semantic HTML markup
• John Resig – Flexible Javascript Events