I had the pleasure of presenting a session on Dreamweaver CS4 to some of my colleagues today, and in the process ended up on my “web standards” soapbox. That’s not unusual, as this is a subject that I feel very passionate about, and thankfully my colleagues embraced the message wholeheartedly. Following the presentation though, one question arose around the idea of removing JavaScript from the page.

One of the coolest of new features in Dreamweaver CS4 allows you to take all of the “local” JavaScript code and externalize it with the click of the mouse – complete with unobtrusive attachment of events.

The question was basically “what’s the point” – is it because JavaScript is “bad” and you’re trying to be sneaky with it, or simply to clean up the HTML code itself. I got about halfway into my email response to the question when I realized that this might be worth posting here.

The issue with JavaScript as part of the HTML page is not that it is “illegal”, afterall <script> is a valid HTML element. It has more to do with the “best practice” of separation. In real life we talk about the need for a separation of church and state because they each have their own “realm of authority” – or at least we hope they do. But in the web content world there are really three things that need to be separated: markup, presentation and behavior.

In the long forgotten stone-age of the internet, markup was routinely mixed with presentation much as the alchemist mixed their secret potions in the hope of getting gold. As designers we wanted big, bold, red headlines and the font tag was wielded with complete disregard for the semantic “meaning” of the text to which it was applied. But thankfully within a few years CSS was born. With its advent, it was suddenly possible to return to a more simplistic and semantic markup – afterall this is what Tim Berners-Lee and company had in mind when the original HTML specs were conceived. The idea of markup was to describe an element’s purpose or meaning without regard for how it would be presented. And with CSS, we could use an h1 or h2 to emphasize the importance of an element, but style it however we wanted without it losing its “meaning” in relation to other elements. Not only did this lessen the amount of markup that we had to deal with, by externalizing  the CSS we had achieved two other important goals. First, we could modify a single CSS rule and effect all (or some) of the page elements spread across multiple pages in one fell swoop. Second, we began the journey down the progressive enhancement road.

If you’re like me (old), then you might remember those early days of the web as the browsers began their slow embrace of CSS. But then again, maybe you don’t remember those days – or you didn’t “notice” it, because you didn’t have a browser that supported CSS. And that’s the important part. If you didn’t have the latest and greatest browser, you still got content (if proper seperation of markup and presentation techniques were used). It’s all about properly marking up the content to begin with. Then, the presentation “layer” can work its magic in numerous ways. In fact, as my good friend Dave Shea’s site, CSS Zen Garden, so wonderfully illustrates, the very same semantic HTML markup can be presented in an unlimited number of ways. (Side note: if you’ve never visited Dave’s shrine to CSS creativity, run, don’t walk over there!)

Today, it’s fairly safe to say that the concept of separating markup and presentation is a “standard” and being implemented “for the most part” around the web world. But with today’s more “rich, interactive” web (read: Ajax) we find ourselves once again polluting our markup. And it’s for the very same reasons that we began separating markup and presentation that we should separate markup and behavior. We can reap the same rewards as well. By attaching JavaScript to elements unobtrusively, we eliminate a large part of unnecessary markup. Secondly, by centralizing the code into an external JavaScript file, we can make site-wide changes more easily. And finally, if we’ve adhered to the “leave no one behind” mantra of progressive enhancement, the page doesn’t “need” the JavaScript in order to deliver its content to the user agent. Instead, the page (and experience) is simply enhanced by its presence.

Thanks to my colleague for prompting me to write this – I hope it makes sense – and either way, I would love to hear your thoughts and comments on the subject.