Not so long ago, professional web designers would gleefully pile HTML, CSS, and JavaScript code

into a single file, name it index.html , and call it a web page. You can still do this today, but be prepared
for your peers to call it something rather less polite.

Somewhere along the way, web designers realized that the code they write when putting together a web
page does three fundamental things: - It describes the content of the page. - It specifies the presentation
of that content. - It controls the behavior of that content. They also realized that keeping these three
types of code separate, as depicted in Figure 1, “Separation of concerns”, made their jobs easier, and
helped them to make web pages that work better under adverse conditions, such as when users have
JavaScript disabled in their browsers. Computer geeks have known about this for years, and have even
given this principle a geeky name: the separation of concerns.

Now, realizing this is one thing, but actually doing it is another—especially if you’re not a computer
geek. I am a computer geek, and I’m tempted to do the wrong thing all the time. I’ll be happily editing
the HTML code that describes a web page’s content, when suddenly I’ll find myself thinking how nice
that text would look if it were in a slightly different shade of gray, if it were nudged a little to the left,
and if it had that hee-larious photocopy of my face I made at the last SitePoint office party in the
background. Prone to distraction as I am, I want to make those changes right away.

Now which is easier: opening up a separate CSS file to modify the page’s style sheet, or just typing
those style properties into the HTML code I’m already editing? Like behaving yourself at work
functions, keeping the types of code you write separate from one another takes discipline. But once you
understand the benefits, you too will be able to summon the willpower it takes to stay on the straight
and narrow.

Three Layers
Keeping different kinds of code as separate as possible is a good idea in any kind of programming. It
makes it easier to reuse portions of that code in future projects, it reduces the amount of duplicate code
you end up writing, and it makes it easier to find and fix problems months and years later. When it
comes to the Web, there’s one more reason to keep your code separate: it lets you cater for the many
different ways in which people access web pages.

Depending on your audience, the majority of your visitors may use well-appointed desktop browsers
with cutting-edge CSS and JavaScript support, but many might be subject to corporate IT policies that
force them to use older browsers, or to browse with certain features (like JavaScript) disabled. Visually
impaired users often browse using screen reader or screen magnifier software, and for these users your
slick visual design can be more of a hindrance than a help. Some users won’t even visit your site,
preferring to read content feeds in RSS or similar formats if you offer them. When it comes time to
build these feeds, you’ll want to be able to send your HTML content to these users without any
JavaScript or CSS junk.

The key to accommodating the broadest possible range of visitors to your site is to think of the Web in
terms of three layers, which conveniently correspond to the three kinds of code I mentioned earlier.
These layers are illustrated in Figure 2, “The three layers of the Web”.

When building a site, we work through these layers from the bottom up:
1.We start by producing the content in HTML format. This is the base layer, which any visitor using
 any kind of browser should be able to view.
2.With that done, we can focus on making the site look better, by adding a layer
of presentation information using CSS. The site will now look good to users able to display CSS
styles.
3.Lastly, we can use JavaScript to introduce an added layer of interactivity and dynamic behavior ,
which will make the site easier to use in browsers equipped with JavaScript.
If we keep the HTML, CSS, and JavaScript code separate , we’ll find it much easier to make

sure that the content layer remains readable in browsing environments where the

presentation and/or behavior layers are unable to operate. This “start at the bottom”

approach to web design is known in the trade as progressive enhancement. Let’s look at

each of these layers in isolation to see how we can best maintain this separation of code.

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:

<a href="666.html"><b>don't click this link!</b></a>

It can take the form of inline CSS applied with the style attribute:

<a href="666.html" style="font-weight: bold;">don't click this link!</a>

It can also include the secret shame of many well-intentioned web designers—CSS styles

applied with presentational class names:

<a href="666.html" class="bold">don't click this link!</a>

Note: 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:

<a href="evil.html">don't click this link!</a>

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:

<a href="evil.html" class="warning">don't click this link!</a>

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:

<span class="heading">A heading with an identity crisis</span>

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;"></a>

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>a { color: red; }</style>

⋮
<a href="evil.html"></a>
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"></link>

⋮
<a href="evil.html"></a>
And in 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? This is 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="alert('don\'t click this!');"></a>

•You can include JavaScript code at the top of your HTML document in a script tag:

<script type="text/javascript">
alert("Don't click the link!");
</script>
⋮
<a href="evil.html"></a>
•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"></a>
And in script.js:

// 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 theright way to use JavaScript in this course, we hope to help change

that.
The Right Way
So, how much does all this stuff really matter? After all, people have been building

websites 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 websites, 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, through the rest of this course, 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.