In my first post, I described some of the major principles that drive UJS style of development. In this article, I’m going into more detail about separating content from markup.
The Bad Old Days
If you have been around long enough, you’ll remember the days when your only choices for making a web page look half way decent required using Font tags and inline attributes (and don’t forget my personal favorite, the Blink tag) to change the appearance of your content. If you wanted to have all of your headers to look the same, each one had to be styled manually. This also meant if you wanted to make a change, every one had to be updated.
The only real tool available for creating a layout was to abuse the <TABLE>. Nesting tables inside tables inside tables was the really only way to achieve anything more than text and images on the page. I’m not sure how many times I lost entire sections of content due to missing a closing row or cell tag.
Now that all of the major browser are CSS compliant-ish, these hacks are no longer necessary (I know there now a whole new set of CSS hacks). You can now remove all styling information from the HTML markup, leaving it to what is good at. Providing semantic meaning and structure to your documents and putting the style into a separate document that can be applied to all pages on your site.
Now it is possible to remove everything from the html markup except for what is needed to fully describe the semantic meaning of the content. When using html for semantic purposes, you are describing the function of the content, not it’s style or behavior. Here is an example of appearance driven markup:
This looks something from circa 1998, when these were our only options for putting any kind of design on our web sites. Hard Line breaks are being created using the <br> tags, and the <font> tag is being used for styling the text.
Moving to a semantic only would look something like this:
Now the html is used purely to denote the differences in the meaning of the text. Using a <h3> and <p> tags to describe function, not it’s visual appearance. You know have free reign or the layout and appearance of the content.
Separating Behavior from Content
When describing the behavior of web pages in the bad old days, we had the same problem. The only way to really safely attach an event was to do it on the the event attributes on the html itself. For instance, if you wanted to open a new window, it would look something like this:
We are again mixing functionality within our html markup. We can clean this up a little bit by using the onclick event to denote what action should take place.
In the next part, I’ll talk more about progressive enhancement and how to incorporate that into your web pages.