Over at the webaim forum, James Pickering has brought up the topic of ISO HTML once again. Check his post for the differences between HTML and ISO-HTML. It is an intriguing concept, as ISO is a standard every business owner understands, rather than a W3C guideline. However, the strictness of it will be its downfall. Most of all, I was very confused and annoyed by the bit about scripting:

Scripting is not yet considered to be sufficiently stable and mature to be included in an International Standard, so the HEAD [W3C 7.4.1] element content model does not include the SCRIPT[W3C 18.2.1] element.

More about the ISO HTML standard can be learnt from the ISO HTML user guide. If you manage to achieve it, you can add yet another cool badge to your page:

Makes one wonder why nobody bothers advertising ISO 9241 - Usability compliance.

On a lighter note, if you are also enraged and scared by the ambiguity of some programming and scripting languages when it comes to variable formats and testing, PPL - the Paranoid Programming Language might be just your cup of tea. Speaking of which, the kettle whistles…

I hate The Scorpions but I can feel a wind of change. While there was many a flamewar on mailinglists, forums and chatrooms in the last few years it seems that we finally realised that airy designers, dysfunctional developers, usabilitistas and accessibility zealots actually all have the same goal: Delivering good, successful web sites

The recipe for those is easy:

• Solve problems the user has
• Offer content the user wants
• Deliver it in a slick and beautiful fashion
• Make it darn easy to use
• Make sure it works at least on the basic level for everybody

Now, whoever claims to be able to do all of the above is either highly gifted or a stinking liar.
Therefore we need to hop on our toes and glance over the garden fence to see what the others do, the finger painting kids one side, the ones building huge sand castles on the other, and the ones feeding the sandcastles to other kids and write down their impressions on a piece of paper in the last garden.

The other problem with our pie in the sky wish list is the harsh business world:

• The user issues are assumed by marketing (“They want to buy our product, everybody needs it”)
• The content is provided by business (“We got lots of material, our newspaper press releases from 1981 onwards and all our business case papers, 430 pages each!”)
• The design is defined by the 1962 guideline for internal memos or the new 3D logo creator of the CEO’s son
• There is no feedback on how hard it is to use the site, visitors just leave and the developer gets blamed for being crap at SEO.
• The stake holders heard of accessibility and know it has something to do with putting an “AAA” banner on the site or get sued.

So there – we are a bit stuck. But that should not stop us from learning and sharing, because if we ever get to talk to a stakeholder with him/her listening (wedging them in toilet doors is an option, or stealing the TP roll and make them listen till we give it back), we better have some good material based on facts at hand.

But oh, woe is us – when we look around for good tutorials we will find a lot of material written by someone of group A for group A, B for group B and so on…

• Design tutorials talking about typography and colours and harmony not considering the restrictions of the web
• Scripting tutorials with yet another foo(bar) example with no real-life connection
• CSS tutorials assuming everyone uses Opera or Firefox
• Accessibility tutorials that look like someone forgot to connect a style sheet, just to find out there is actually one, but it looks just like the browser standard.
• CSS or scripting tutorials showing that it is possible to do something that was meant to be achieved by the other, or even by HTML.

What we need is better tutorials, aimed outside our area of expertise and delivered slick, painless and with a practical use. Collaboration is the key to that.

• Scripters should liaise with designers to get their code examples designed in a nice fashion and their articles re-edited to make them understandable to somebody who does not consider regular expressions a valid mean of communication
• Designers should liaise with HTML developers, scripters and accessibility gurus to see if what they want to achieve is feasible and where the pitfalls are.
• Accessibility and usability people should get input from designers to understand why some things were designed the way they are and find a consensus, and to get help making their own texts prettier and illustrated.
• Everybody should grab someone outside our world and see if the things we write are understandable

This all should not be restricted to our blogs, but should also happen before something gets published in web zines. While a lot of editors of web zines are great writers and know a lot about getting messages across, their technical knowledge might be limited. Not all of them employ or invite technical reviewers and experts and that is why we end up with a lot of tutorials that are buggy or flat out wrong and yet very successful.

So please, think a bit before submitting the next article and get some more people involved to sort out the issues and add the nice wrapping paper before giving your ideas to the public.

Things that are not helpful and have to go:

• Bleeding edge tutorials working in a small environment advertised as a cool new feature rather than an experiment
• Scripts for their own sake – without a real business task at hand (business stakeholders would never ask for coloured scrollbars if they hadn’t seen them somewhere)
• Untested functionality breaking in a big percentage of the browsers in use or in modern browsers
• “Hey I can do in X what we rightfully did in Y for years” tutorials
• Tutorials with examples focused on one level but violating the other two badly – if you want to explain a cool JavaScript idea, make sure your HTML is semantically correct, validates and you leave the styling to the CSS.

“Don’t judge a book by its cover” is a nice idea, but that is exactly what people do, so let’s sell standards based development as a nice shiny and easy to grasp parcel, rather than a bit of string, some crumbled wrapper and a almost unused box.

Both the register and the BBC report about a test study conducted by SciVisum that found 10% of the UK retail sites tested failing in Firefox.

This is not really a surprise – it is a shame but no surprise – considering the state and age of some of those sites.
The problem with web standards and business is that it is much harder to follow them when there is maintenance to be done and not initial development.
Maintenance projects have a lower budget, and any change is meant “just to fix things and update the content”.
Rather than cleaning the site we patch and grudgingly fall into the same bad coding prinicples that were applied when the site was done initially – with bad browsers like IE4 and Netscape Communicator as the main goal.

What confuses me were some of the figures:

While most people still use Microsoft’s browser, Firefox is slowly making inroads.
Its share of the browser market grew to 8% in May, up from 5.59% at the beginning of the year, according to US-based analysts NetApplications.

What browser market? NetApplications is a site metrics tool, and depending on the site, figures will look a lot different (here it is 40% FireFox vs. 20% MSIE).

A real eyepopper was that one though:

This is largely because web developers are used to testing their sites just using IE rather than so-called standards-compliant browsers, which only use code ratified by the World Wide Web consortium.

I didn’t know the w3c ratifies the sourcecode of Firefox and Opera :-).

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.

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