I’ve been getting this question from my colleagues lately, and I think it’s a valid one to ask. The fact that it’s being asked shows that people are thinking about best practices and how to best meet the needs. However, the fact that it’s being asked also shows that people really don’t understand a fundamental principle of web standards.
How do web standards and Javascript get along? How do you employ Javascript that is web standards-compliant? It’s a tough question, and so far, I haven’t come across a clear answer.
A properly-developed, web standards-compliant site (or even just a page) should have separation: content, presentation, structure, and function. A quick recap on those: content is the important information on a page (primarily text and images), presentation is how that content should appear to the user, structure is the HTML that defines the various parts of the page that the content falls into, and function (or more specifically, functionality) is the browser scripting that drives some of the interactive features on a site.
The first major break was between content and presentation. Then came structure. These were culiminated with the creation of the CSS Zen Garden. Given, the textual content is baked into the Garden’s code, and the separation between presentation and structure is trivial. (As a side note, the marriage of the items is just as important as the separation.) This was great stuff. And even though the Garden’s been around a few years, now, the movement is just getting to the fourth and final piece: function.
And make no mistake, folks, this storm is coming.
But what does this mean for you, the developer? Thankfully, it’s not too complicated, at least from a comprehension perspective. Implementing? Well, that’s another issue.
Under the idea of separation for web standards, Javascript should be separated from the page upon which it acts. This means no in-page Javascript, including onclick, onmouseover, onload, or other such event-driven methods. Code is placed into one or more external files, which are then loaded by the browser. This is the same way presentation is/should be applied to each page.
Naturally, this is a little worrisome to developers, since many of us have become very dependent on having that functionality. If we don’t have those methods in-line, how do we control the functionality? We’re used to slapping in an onclick event on <a href> tags to solve our click event patterns. Never mind the countless onmouseover/onmouseout events we use for effects.
Introduce self-awareness. At least insofar as Javascript methods can be self-aware, anyway. Instead of HTML elements having code to handle the event, a Javascript loaded through the onload event finds HTML elements through the Document Object Model (DOM) and inserts the appropriate handlers into the various elements. It’s transparent to the user, and a Javascript developer can modify method behaviours without ever touching the HTML structure.
Loading up the onload event, however, is not a wise idea. Not only is it ugly, eventually the call will become so long that you won’t be able to maintain it. Introduce the onload handler. With a simple piece of code, you can set up a method stack that calls other Javascript methods. The methods are popped and pushed as needed, defined by a controlling function or static list. A very simple version — an array — would look like this:
function onloadEvents() {
for(var i=0; i<loadarray.length;i++) {
eval(loadArray[i]);
}
}
Very simple, very crude, but it works. (Too many evals can slow down a script dramatically, so don’t get carried away.) Events are added to the onload handler through array declarations:
loadArray[loadArray.length] = "functionName()";
A smarter script creates an object list of items, calling them in turn.
I know what you’re thinking: that’s a lot of extra work. It is, and it isn’t. It is because you have to think about how your page is built, and how functions would recognize the patterns needed
Where additional work comes into place is the need to build the initialization methods and set up an onload handler (such as above). Once it’s done, though, the rest should be relatively easy.
This is all in theory, and is something that I think about a lot. There’s a lot of “what-ifs” to consider. My personal favourite is: What if this is a one-off situation? Do I spend the time and code to build a one-off onload handler? This is the one I usually end up stumping myself on.
In CSS, one-offs aren’t such a big deal. You create a single class, set up the formatting, and let the browser apply it as needed. But Javascript doesn’t apply automatically. It needs to attach itself, not unlike a leech (just not so bloody). And that’s where you can get caught. Do you take the side of lighter Javascript files and run the method in the HTML, thus defeating the idea of separation? Or do you follow the perceived standard and risk code bloat?
It’s a question I keep asking, and so far, I’ve yet to find an answer. The zen of Javascript and web standards is coming. The question is: who will find the inner peace first?
