Article
Simply JavaScript: The Three Layers of the Web
Page: 1 2
HTML for Content
Everything that's needed to read and understand the content of a web page belongs in the HTML code for that page -- nothing more, nothing less. It's that simple. Web designers get into trouble when they forget the K.I.S.S. principle (Keep It Simple, Stupid) and cram non-content information into their HTML code, or alternatively move some of the page's content into the CSS or JavaScript code for the page.
A common example of non-content information that's crammed into pages is presentational HTML -- HTML code that describes how the content should look when it's displayed in the browser. This can include old-fashioned HTML tags like <b>, <i>, <u>, <tt>, and <font>:
<p>Whatever you do, <a href="666.html"><font color="red">don't
click this link</font></a>!</p>
It can take the form of inline CSS applied with the style attribute:
<p>Whatever you do, <a href="666.html" style="color: red;">don't
click this link</a>!</p>
It can also include the secret shame of many well-intentioned web designers: CSS styles applied with presentational class names:
<p>Whatever you do, <a href="666.html" class="red">don't click
this link</a>!</p>
Presentational Class Names? If that last example looks okay to you, you're not alone, but it's definitely bad mojo. If you later decide you want that link to be yellow, you're either stuck updating both the class name and the CSS styles that apply to it, or living with the embarrassment of a class named “red" that is actually styled yellow. That'll turn your face yellow -- er, red!
Rather than embedding presentation information in your HTML code, you should focus on the reason for the action -- for example, you want a link to be displayed in a different color. Is the link especially important? Consider surrounding it with a tag that describes the emphasis you want to give it:
<p>Whatever you do, <em><a href="evil.html">don't click this
link</a></em>!</p>
Is the link a warning? HTML doesn't have a tag to describe a warning, but you could choose a CSS class name that conveys this information:
<p>Whatever you do, <a href="evil.html" class="warning">don't
click this link</a>!</p>
You can take this approach too far, of course. Some designers mistake tags like <h1> as presentational, and attempt to remove this presentational code from their HTML:
<p class="heading">A heading with an identity crisis</p>
Really, the presentational information that you should keep out of your document is the font, size, and color in which a heading is to be displayed. The fact that a piece of text is a heading is part of the content, and as such should be reflected in the HTML code. So this code is perfectly fine:
<h1>A heading at peace with itself</h1>
In short, your HTML should do everything it can to convey the meaning, or semantics of the content in the page, while steering clear of describing how it should look. Web standards geeks call HTML code that does this semantic markup.
Writing semantic markup allows your HTML files to stand on their own as meaningful documents. People who, for whatever reason, cannot read these documents by viewing them in a typical desktop web browser will be better able to make sense of them this way. Visually impaired users, for example, will be able to use assistive software like screen readers to listen to the page as it's read aloud, and the more clearly your HTML code describes the content's meaning, the more sense tools like these will be able to make of it.
Best of all, however, semantic markup lets you apply new styles (presentation) and interactive features (behavior) without having to make many (or, in some cases, any!) changes to your HTML code.
CSS for Presentation
Obviously, if the content of a page should be entirely contained within its HTML code, its style -- or presentation -- should be fully described in the CSS code that's applied to the page.
With all the work you've done to keep your HTML free of presentational code and rich with semantics, it would be a shame to mess up that file by filling it with snippets of CSS.
As you probably know, CSS styles can be applied to your pages in three ways:
inline styles:
<a href="evil.html" style="color: red;">
Inline styles are tempting for the reasons I explained earlier: you can apply styles to your content as you create it, without having to switch gears and edit a separate style sheet. But as we saw in the previous section, you'll want to avoid inline styles like the plague if you want to keep your HTML code meaningful to those who cannot see the styles.
embedded styles:
<style type="text/css">
.warning {
color: red;
}
</style>
⋮
<a href="evil.html" class="warning">
Embedded styles keep your markup clean, but tie your styles to a single document. In most cases, you'll want to share your styles across multiple pages on your site, so it's best to steer clear of this approach as well.
external styles:
<link rel="stylesheet" href="styles.css" />
⋮
<a href="evil.html" class="warning">
Example 1.1. styles.css
.warning {
color: red;
}
External styles are really the way to go, because they let you share your styles between multiple documents, they reduce the amount of code browsers need to download, and they also let you modify the look of your site without having to get your hands dirty editing HTML.
But you knew all that, right? We're dealing with a JavaScript book, after all, so let's talk about the JavaScript that goes into your pages.
JavaScript for Behavior
As with CSS, you can add JavaScript to your web pages in a number of ways.
You can embed JavaScript code directly in your HTML content:
<a href="evil.html" onclick="JavaScript code here">
You can include JavaScript code at the top of your HTML document in a <script> tag:
<script type="text/javascript"><!--//--><![CDATA[//><!--
JavaScript code here
//--><!]]></script>
⋮
<a href="evil.html" class="warning">
CDATA? If you're wondering what all that gobbledygook is following the <script> tag and preceding the </script> tag, that's what it takes to legitimately embed JavaScript in an XHTML document without confusing web browsers that don't understand XHTML (like Internet Explorer).
If you write your page with HTML instead of XHTML, you can get away with this much simpler syntax:
<script type="text/javascript">
JavaScript code here
</script>
You can put your JavaScript code in a separate file, then link to that file from as many HTML documents as you like:
<script type="text/javascript" src="script.js"></script>
⋮
<a href="evil.html" class="warning">
Example 1.2. script.js (excerpt)
JavaScript code here
Guess which method you should use.
Writing JavaScript that enhances usability without cluttering up the HTML document(s) it is applied to, without locking out users that have JavaScript disabled in their browsers, and without interfering with other JavaScript code that might be applied to the same page, is called unobtrusive scripting.
Unfortunately, while many professional web developers have clued in to the benefits of keeping their CSS code in separate files, there is still a lot of JavaScript code mixed into HTML out there. By showing you the right way to use JavaScript, we hope to help change that.
The Right Way
So, how much does all this stuff really matter? After all, people have been building web sites with HTML, CSS, and JavaScript mixed together for years, and for the majority of people browsing the Web, those sites have worked.
Well, as you come to learn JavaScript, it's arguably more important to get it right than ever before. JavaScript is by far the most powerful of the three languages that you'll use to design web sites, and as such it gives you unprecedented freedom to completely mess things up.
As an example, if you really, really like JavaScript, you could go so far as to put everything -- content, presentation, and behavior -- into your JavaScript code. I've actually seen this done, and it's not pretty -- especially when a browser with JavaScript disabled comes along.
Even more telling is the fact that JavaScript is the only one of these three languages that has the ability to hang the browser, making it unresponsive to the user.
Therefore, we'll do our darnedest to show you the right way to use JavaScript, not just because it keeps your code tidy, but because it helps to keep the Web working the way it's meant to -- by making content accessible to as many people as possible, no matter which web browser they choose to use.
JavaScript Libraries
As I mentioned, one of the benefits of keeping different kinds of code separate is that it makes it easier to take code that you've written for one site and reuse it on another. Certain JavaScript maniacs (to be referred to from this point on as “people") have taken the time to assemble vast libraries of useful, unobtrusive JavaScript code that you can download and use on your own web sites for free.
Throughout Simply Javascript, we build each of the examples from scratch -- all of the JavaScript code you need can be found right there. Since there isn't always time to do this in the real world, however, and because libraries are quickly becoming an important part of the JavaScript landscape, we'll also look at how the popular JavaScript libraries do things whenever the opportunity presents itself.
Here are the libraries that we use in the book:
Not All Libraries are Created Equal Watch out for sites offering snippets of JavaScript code for you to copy and paste into your web pages to achieve a particular effect. There is a lot of free code out there, but not all of it is good. In general, the good libraries come in the form of JavaScript (.js) files that you can link into your pages unobtrusively, instead of pasting JavaScript directly into your HTML code. If you don't feel confident to judge whether a particular JavaScript library is good or bad, ask for some advice in the SitePoint Forums, or just stick with the libraries I just mentioned -- they're all very good.
Let's Get Started!
Enough preaching -- you checked out this article to learn JavaScript, right? Clean HTML and CSS are nice and all, but it's time to take the plunge into the third layer of the Web: behavior. The chapters of Simply Javascript that follow the one from which this article is reproduced deal in greater depth with this topic -- and because we're feeling generous, we've decided to throw them in for your delectation! So don't forget to download this chapter as a PDF, as well as Chapter 2: Programming with JavaScript and Chapter 3: Document Access.
In Chapter 2, you'll learn that as JavaScript is a programming language, you must get your head around the way computer programs work -- which to some extent means learning to think like a computer -- in order to use it most effectively. The simple concepts introduced in this chapter -- statements, variables, expressions, loops, functions, and objects -- are the building blocks for every JavaScript program you'll ever write.
And Chapter 3? While certain people enjoy writing JavaScript code for its own sake, you wouldn't want to run into them in a dark alley at night. As a well-adjusted web developer, you'll probably want to use JavaScript to make changes to the contents of your web pages using the Document Object Model (DOM). Lucky for you, we wrote a whole chapter to show you how!
Then, of course, there's more...
Get ready to start using some cool (and unobtrusive) JavaScript!