javascript

Chapter 20: Best Practices
Modern web applications use JavaScript to change styles frequently, so although it ’ s not possible to
completely decouple CSS and JavaScript, the coupling can be made looser. This is done by dynamically
changing classes instead of individual styles, as in the following example:
//loose coupling of CSS to JavaScript
element.className = “edit”;
By changing only the CSS class of an element, you allow most of the style information to remain strictly
in the CSS. JavaScript can be used to change the class, but it ’ s not directly affecting the style of the
element. As long as the correct class is applied, then any display issues can be tracked directly to CSS
and not to JavaScript.
The second type of tight coupling is valid only in Internet Explorer (but not in IE 8 running in standards
mode), where it ’ s possible to embed JavaScript in CSS via expressions, as in this example:
/* tight coupling of JavaScript to CSS */
div {
width: expression(document.body.offsetWidth - 10 + “px”);
}
Expressions are typically avoided because they ’ re not cross - browser – compatible. They should also be
avoided because of the tight coupling between JavaScript and CSS that they introduce. Using
expressions, it ’ s possible that a JavaScript error can occur in CSS. Developers who have tried to track
down a JavaScript error due to CSS expressions can tell you how long it took before they even
considered looking at the CSS for the source of the error.
Once again, the importance of keeping a good separation of layers is paramount. The only source for
display issues should be CSS, and the only source for behavior issues should be JavaScript. Keeping a
loose coupling between these layers makes your entire application more maintainable.
Decouple Application Logic/Event Handlers
Every web application is typically filled with lots of event handlers listening for numerous different
events. Few of them, however, take care to separate application logic from event handlers. Consider the
following example:
function handleKeyPress(event){
if (event.keyCode == 13){
var target = EventUtil.getTarget(event);
var value = 5 * parseInt(target.value);
if (value > 10){
document.getElementById(“error-msg”).style.display = “block”;
}
}
}
This event handler contains application logic in addition to handling the event. The problem with this
approach is twofold. First, there is no way to cause the application logic to occur other than through the
event, which makes it difficult to debug. What if the anticipated result didn ’ t occur? Does that mean
that the event handler wasn ’ t called or that the application logic failed? Second, if a subsequent event
causes the same application logic to occur, you ’ ll need to duplicate the functionality or else extract it into
a separate function. Either way, it requires more changes to be made than are really necessary.
641