Notice: The following is a “best practice document”. You can follow its advice and live happily ever after, but there might be situations where you cannot apply the ideas mentioned within. This is especially the case when you have to maintain an old product or complex web application. You cannot replace everything in those in one go – as you are very lucky indeed if you get the time and budget – but you can tackle those step by step.

According to many web designers at @media2005, JavaScript is sexy again, and in demand. Ajax is the new CSS was a quote in one of the presentations, that – taken out of context – makes my stomach go wonky.

Working largely with b2b sites and restricted environments, I never knew it was out of fashion.

It is a tool, much like a shovel, a screwdriver or a towel. While a towel is handy in every situation, as every HHGTTG reader knows, JavaScript has its place and its merits, but also its limitations and places it shouldn’t be applied to.

You can use a screwdriver to screw in screws or to clean your ears, however, the latter needs real skill, determination and a lack of fear of injuring yourself. It is much the same with JavaScript, you can use it for great things, but you can also use it to make a product inaccessible, confusing and not usable.

Here are some danger signs you encounter in many a bad script example and tutorials written in the spur of the moment rather than following proper research.

Things that should make you go Noooooooooooooooooo!

1. document.write What this does is write out content to the HTML document, inside the body of the document and merrily mixed with the markup. Bad web developer, bad! Go to your corner! A better solution: reach the element you want via getElementById or getElementsByTagName and then insert your newly created content (via createElement and createTextNode) there.
2. This you encounter a lot in “Accessibility Tutorials” and it should “make sure that every user can use your site”. Actually, it is a sign that the script you use (or did) is bad and should have never been used in the first place. It is like using white-out on the wallpaper after you used your crayons there. Comment: I was asked to clarify this, as web application developers who have to rely on JavaScipt (which is a flaw in the application design IMHO) use noscript to tell the users they need JavaScript enabled. Normally this is added as a warning message at the start of the non-working page. The more logical option in this case would be to have the "no JavaScript" message in the document and replace it with a link to the application when Javascript is available. Check this example page on how to avoid noscript. Turn JavaScript on and off to see the difference.
3. href="javascript:", onclick="javascript:" There is no such thing as a JavaScript protocol on the web. Links use protocols to connect documents. Create real links or don’t use any link at all – do or do not, there is no try!
4. onclick="void(0)" Why would one put effort into creating something that by definition is not doing anything? Glossing over bugs and bad scripting, that’s why. A link that only points to a JavaScript function should be added via JavaScript.
5. document.all , document.layers, navigator.userAgent Unless your defined project environment is MSIE 5.x and Netscape Communicator 4.x (my condolences if it is), there is no need for that any longer. Object detection is so much better than trying to guess what the browser in use is, and the W3C DOM is also more likely to be used in future UAs than the bespoke Netscape or Microsoft ones. (If you say “huh, what?” now, just trust me that everything with document.getElementById is much more stable than the other two mentioned earlier)
6. onmouseover="myCall('I','pity','the','foo',1233,'I aint going on no plane')" Anything crucial to the user experience that you generate via JavaScript needs to be in the document anyways – for users without JavaScript. Reusing this markup is a lot easier, cleaner and more maintainable than sending a lot of parameters. If there is any reason to send parameters, a simple ‘this’ does the trick in most of the cases, as you can navigate through the DOM from there.

On request

And what about innerHTML?

As some pointed out in the comments, innerHTML is another way to create content on web sites. In some cases, it is even the fastest method, as Peter-Paul Koch found out when comparing methods to generate content. However innerHTML is neither standard, nor applicable to any DOM scripting outside the browser environment. There is an excellent discussion about innerHTML on developer-x. My personal view? innerHTML makes it a lot easier, but advertises HTML documents as strings rather than node trees, and that makes it hard for junior developers to go further in their scripting ventures.

Partly inspired by Robert Nyman’s recent post about JavaScript

The reactions of the audience at @media, and many a chat afterwards made it obvious to me that the concept of JavaScript adding the behaviour layer above the HTML markup (or structure) and the CSS (or presentation) has become commonly known.

This is nothing new, after all, Zeldman’s book explained that in 1999 with a nice movie metaphor:

If your web page were a movie, XHTML would be the screenwriter, CSS would be the art director, scripting languages would be the special effects, and the DOM would be the director who oversees the entire production.

However, when it comes to accessibility and ease of maintenance, I’ll dare to make things more confusing now, by telling you there are five levels of web development, each of them with its own technologies and methodologies. Only when all of them work properly and are aware of standards and accessibility / usability constraints we can work without breaking a sweat.

The levels are:

• The behaviour layer – Executed on the client, defines how different elements behave (Javascript, Action Script)
• The presentation layer – Displayed on the client, the look and feel of the site (CSS, images)
• The structure layer – Displayed on the client, the mark-up defining what a certain text or media is (xHTML)
• The content layer – On the server, the text, image and multimedia content that are in the site. (XML, DB)
• The business logic layer – On the server, defines what is done with incoming information and determines what is returned (Backend, various environments)

The Business Logic Layer needs to

• provide the different states in a styleable and changeable format

The Content Layer needs to have

• Text that is easy to understand
• Text that makes sense without a visual representation (wrong example: “click on the links below”)
• Alternative text for every image, sound piece or video that is content
• Text that is fit for the web (KISS, structured into headers, paragraphs and lists)
• Explanations of Acronyms and Abbreviations
• Content images need to be unambiguous for the colourblind and text in images needs to have a sufficient size and contrast.
• Information to the users of changes necessary to her environment (example: “opens in a new window” or “PDF document, 182kb”)

The Structure Layer needs to

• provide a consistent document structure with the content available as early as possible
• provide the “invisible accessibility enhancements” like accesskeys, link relationships and table serialisation aids.

The Presentation Layer needs to

• ensure that text can be zoomed without making the site unusable
• ensure that the interactive elements of the site are easy to find
• ensure that images and foreground and background have enough contrast and are unambiguous to the colourblind
• give the site a consistent navigation
• Aid the user through business processes
• Separate content into easily understandable units

The Behaviour Layer needs to

• ensure that all the functionality is available to the user regardless of input device
• make the user experience as easy as possible by cutting down on options until they are necessary

Raising awareness of this might help in the future, and accessibility / usability will not be considered a “plug-in” added in the final week of the project lifecycle any longer.

I must have been kissed by a Muse at @media, because I had another idea, that I’d like to get help with.

The problem

• There are far too many outdated, obtrusive and plainly badly written tutorials and scripts out there
• As they have been around for a long long time, they are ranked very high in search engines, and new, interested developers will find them instead of The Good Stuff™.

The dilemma

As the developer or writer of these scripts and articles, you do have the choice of the rock and the hard place:

• You hardly have the time or the inclination to rewrite the articles, sometimes they have been published by a third party and you cannot do that.
• You don’t want to delete them, as you do get visitors, and they might be persuaded to explore your publications more and find The Good Stuff™.

One solution

What I thought about, and many people at @media agreed is that there should be an option to keep these scripts and tutorials for achived reasons and tell the visitor about The Good Stuff™
The idea is to set up a service, which I intend to call Obsoletely Famous (yes, I miss Futurama), which is basically a RSS feed listing good, modern articles and resources for the topic at hand.

(Basically a pre-filtered del.icio.us, as many people linking to it sadly enough does not necessarily mean it is a good quality resource, it is simply popular, probably by oversimplifying the issue at hand. A good example of that are a lot of ALA articles, where the real good information ended up in the comments, but not many users go there)

As the developer / maintainer of the script you can set up a bridge page (or a custom error page) that tells the visitor that the above was fun while it lasted, but the list here actually shows better ones.

The benefits

• We re-use the high google ranking to promote The Good Stuff™
• We help writers and scripters / developers to back off things they are not proud of any longer without giving the visitors alternatives
• We ensure that newer users find The Good Stuff™
• New writers of The Good Stuff™ can easily reach more people

The plan of action

Give me the bricks, and I’ll build the house

Basically, we need to identify our areas of expertise and define The Good Stuff™ links. Then I can set up the RSS feed and create some example bridge pages. In the long run, I might persuade my evolt colleagues to host it.

Areas covered:

• JavaScript
• DOM JavaScript
• CSS
• HTML
• Visual Design
• Usability
• Accessibility

We can start by listing some here in the comments.

Check your own stuff

• Let’s all go through what we have online and see what is a possible candidate for becoming obsoletely famous (I know for a fact that 75% of my onlinetools.org is). Squint your eyes and look at it in a menacing way – make it aware that its days are numbered^*
• Scan your bookmarks for good, modern tutorials and name them here.

^* optional

I realised this morning that my new ALA article about complex dynamic lists was released, the signs were obvious:

What really put a big grin on my face was the following browser stat though:

I just finished EasyNav, a PHP script that automatically highlights the current page in a site navigation.

All you need to use it is generate your navigation as a nested list of links and include EasyNav in your pages. The current link gets automatically replaced with a “strong” element and gets the ID “current”. The parent list item gets the ID “active”.

This allows you to use the CSS examples of Listamatic to style your navigation.

EasyNav also allows for different navigations to be generated, dependent on the ID of the root UL.