Following four days of AFN (Away From Network – I did use a keyboard though), I realised that digg.com dugg me and AJAXian once again linked me. Well, not me but the From DHTML to DOM Scripting article.
Notice the title: from DHTML to DOM. Not “why innerHTML is rubbish and you should not use it, never, really, don’t, never ever!”

I also realised that AJAXian had the unfortunate wording in their post that I might have meant that with the article and the comments on the AJAXian post were an interesting read indeed.

However, digging deeper (oh dear), I found that this is an no-barriers-handbags-out-geek-fight topic at the moment as many AJAX enthusiasts and heavy load web application developers (the applications are heavy load, not the developers) rightfully like innerHTML and consider it a necessary and good solution for a re-occuring problem.

Jeremy Keith started it, daring to call innerHTML proprietary in the painless code creation with DOM builder post at the DOM scripting task force blog.
Jonathan Snook responded quickly and wondered what’s wrong with innerHTML.
We all know that Jeremy had been in a painful love/hate relationship with innerHTML for a long time, as he outed himself in December talking about his innerHTML dilemma.
He is not the only one with this problem, as Ryan Campbell of Particletree also considered different methods than innerHTML in April calling it Changing the DOM.

This is all well and good, but is it really that much of a problem?

My “I like to chime in but I really just want to keep the fight going and not get involved myself as I forgot my handbag” award goes to Dustin Diaz who kept the comments closed on his blog entry on the subject called innerHTML and DOM Methods. So why post at all then? Why not just comment on Jeremy’s blog?

I liked the quote:

Well, for what it’s worth. It’s about the user. innerHTML is plain and simply faster. Yes, it’s non-standard, but so is xmlHttpRequest. Sure, I know the W3 is developing a working draft on xmlHttpRequest… I say, let’s standardize innerHTML. Not to mention, it would be easy. Everyone already knows how it works, it’s simple to use. It’s fast. It’s already supported across major browsers. Hey, just so we feel better, why not call it innerXML. That way it’s future compatible when xml becomes more of a standard and better supported.

This is exactly the problem with innerHTML – it is not innerXML. It is a browser/web/html only property, and the DOM is not only for browsers, web and HTML. You can use JavaScript and the DOM to convert XML, you can even script applications with it (check the Adobe site for great Illustrator and Adobe Bridge examples), and the idea is not to keep DOM scripting to the browser or even to HTML as a means of structure. I especially chuckled at the notion that XML will be supported in the future. I know the idea was supporting XML in browsers, but talking about web standards and considering XML a technology of the future is simply missing the mark.

So, here are my ideas about this subject:

innerHTML is pot noodles – Anyone can use it quickly, you put the kettle on and after the water boiled and you let it rest for a minute or so and then it is feeding time. It is:

• very fast and convenient
• cheap and easy to prepare
• well known and available in a lot of stores

The problems are:

• You have no clue what is in the pot noodles
• You have no way of telling someone how to make own pot noodles when there is no shop around their area that stores them.

DOM scripting and using the DOM methods to create a real XML construct instead of a string of HTML is cooking your own pasta sauce:

• You know the ingredients and you measure them properly before applying them
• It is harder and takes longer to prepare, but the outcome is normally del.ici.o.us
• While you cook you learn about different spices, tricks to prepare the ingredients and mix and match them to make the perfect sauce
• You follow a recipe or invent your own – but you do follow a structured method of creating it
• You can explain how to create the sauce to someone on the phone step by step

So by all means: Use innerHTML when speed or ease of use is an issue, but don’t forget that the DOM offers a lot more than just changing HTML documents in a browser.

This just blew my mind:

I would believe that it could be a person really asking for help to get rid of a spyware/trojan infection if he hadn’t used a naughty site as his own URL.

Anyways, why should I know how to get rid of it. I never surf naughty parts of the internet, honestly!

I just put up a proof of concept for the AJAX chapter of my book. For years I have ranted about DHTML multi level menus simply assuming that every user wants to have every page in the sitemap as an item in the navigation.

My idea was to make the enhanced navigation optional and allowing the user to decide initially.
Check out the example:

• Optional AJAX navigation

It uses PHP to only provide a chunk of the full navigation automatically replacing the current link with a strong when JS is unavailable and when JavaScript is available it offers a link that turns the navigation into a multi level tree menu loading the main page content via XHR.

What do you think? Helpful? I think it is a lot less obtrusive than a lot of fancy menu systems out there while offering the same options.
[tags]menu,accessibility,hierarchical menu,treemenu,ajax,javascript[/tags]

I finally reached the AJAX chapter in my book and had to dabble with it for the first time (yes I know I should have done it earlier, but I work behind a proxy in the office that doesn’t let any outgoing requests through).

The first outcome is FeedNav, a RSS feed displayer: Have a look and I’d be happy about feedback here on the blog.

• Check and get FeedNav – an AJAX RSS displayer

I just published a new longer article (40 pages) trying to explain the differences between DHTML and DOM scripting. The article explains what DHTML, the DOM and DOM scripting is and shows how to create a web page with dynamic elements like tabs, a slide show and a big product shot in both ways.

• Check From DHTML to DOM scripting now

The DHTML explanation is annotated with explanations why some of the techniques are a bad idea and the DOM scripting version explains why some of the assets are good ideas. As a summary:

DHTML issues:

1. Script dependence – Users without JavaScript get stuck or get elements that only work with JavaScript but don’t do anything for them.
2. Mixing presentation and functionality – If you want to change the look of the effect you need to hack around the JavaScript.
3. Assuming functionality without testing for it – what it says
4. Keeping maintenance JavaScript based – Maintainers are expected to change the script when they want to change the effect, and search through the whole script.
5. Mixing HTML and JavaScript – what it says
6. Blaming the user – Users get messages like “you cannot use this as your browser doesn’t support it, update your browser” instead of just not getting the functionality if it is not 100% necessary.
7. Taking over the document – one onload to rule them all

DOM scripting assets:

1. Progressive Enhancement – check if things are available, then apply those dependent on them
2. Ease of maintenance – keep the maintenance as easy as possible via dynamic CSS classes and properties at the beginning of the script
3. Separation of Presentation and Behaviour – add dynamic classes instead of changing the style collection
4. Separation of Structure and Behaviour – use dynamic event handlers and generated elements instead of onclick and NOSCRIPT
5. Using modern event handling – more than one onload please
6. Avoiding clashes with other scripts – avoid global variables and encapsulate functions as methods in an object

Of course, you can disagree :-)