- A: The CSS revolution
- B: Separation of presentation and structure
- C: Separation of behavior and structure
- D: Separation of behavior and presentation
- E: Accessibility overview
- F: Rules of accessibility
- G: The example scripts
This chapter is from the book
This chapter is from the book
This chapter is from the book
B: Separation of presentation and structure
The basic idea of separation of presentation and structure is to make sure the HTML defines structure, and only structure, and that all presentation is defined in a separate CSS file. No more <font> tags or presentational tables in your HTML! If you need to specify a font or a grid, do so in CSS.
A discussion of the separation of CSS and HTML seems to have no place in a JavaScript book. Nonetheless, there are a few aspects of this separation that influence the way you should code JavaScript.
CSS modification
JavaScript allows you to modify CSS; i.e., you can make a link red in the CSS, and later on overrule this style with JavaScript and make the link green. Sometimes this is quite useful, since style changes allow you to pull the user’s eyes to the HTML element you need her to focus on—an error message, for instance.
We’ll discuss the ins and outs of CSS modification in Chapter 9, and we’ll see that CSS modification becomes much harder without a properly separated CSS presentation layer.
As we’ll see in 9E, the changing of the className of an element is usually the best way to effect CSS modification. For instance, if Form Validation finds a user error in a form field, it changes the CSS class of that field:
// obj is the form field
obj.className += ‘ errorMessage’;
// in CSS
input.errorMessage {
border: 1px solid #cc0000;
}
The point is that this trick only works if you have properly separated presentation and structure. The class errorMessage has to be defined in CSS in order for the style to change, and that in turn is only possible (or, at least, workable) if you started out with a proper CSS presentation layer.
Modify structure or presentation?
JavaScript allows you to change the presentation of your Web site and also allows you to change the structure of your HTML document–-in fact, most example scripts do so.
Usually it’s clear whether a script should change presentation or structure. Sandwich Picker, for instance, is all about moving the <tr>s that contain sandwiches the user selected to the correct table—the search results table at the top of the page or the order table just below it. This is an example of a pure structure change.
XMLHTTP Speed Meter contains an animation; it changes the CSS width of the element holding the gray background image, while the document structure stays the same. This is an example of a pure presentation change.
In a few cases, though, you can change either the HTML or the CSS. Usable Forms is the clearest example. The purpose of that script is to hide form fields until the user needs them. You can hide form fields in two ways: make them invisible by CSS (display: none) or remove them entirely from the document structure.
The user doesn’t care which of the two we choose; in either case the form fields appear only when they’re needed. Nonetheless there are a few differences between the two methods.
First, I feel that changing forms in response to user actions is a change in structure, not in presentation. The form fields should not just be hidden from view, but should be entirely removed from the document. Once the user has checked or unchecked several form fields, and the script has reacted by showing or hiding form fields, every visitor will eventually see the unique document structure he or she needs.
Of course this is a theoretical consideration, and you should feel free to disagree with me, even though I don’t think a similar case can be made for hiding the form fields by CSS.
There’s a practical component, too. When a form is submitted, the browser creates name/value pairs for all form fields, and sends them to the server. If we hide the unnecessary form fields by means of CSS, the fields themselves are still part of the form—they’re just hidden. Therefore they, too, are sent to the server, even though that’s not necessary.
Conversely, if, as in Usable Forms, these form fields are entirely removed from the document structure (hence also from the HTML <form> tag), they aren’t sent to the server, for the simple reason that they aren’t part of the form at the moment it is submitted.
I found these two reasons sufficient to make Usable Forms operate by changing document structure instead of presentation. Although you may disagree with me, you should spend some time thinking about such issues when you encounter them.