External stylesheets and selectors

After finally learning how to change the visual appearance of pages in the last chapter, you're probably raring to go and eager to learn as many properties and values as you can. Before we continue, however, I have a confession to make: the style attribute that I showed you is not considered the best way to add CSS to webpages. The reason I showed you this way first, and not the recommended way, is because it's the easiest way of getting styles onto a page (and, therefore, the quickest) and because its downsides nicely demonstrate a few important points about building websites.

First of all I'll show you the best practice way of adding styles to a page, and then I'll explain why this is recommended over using the style attribute.

External stylesheets: Rules and Selectors

Keeping it DRY

As you may noticed during the exercise at the end of the last chapter, adding the same CSS to every instance of a HTML element is very repetitive, something which external stylesheets overcome. Not only is this repetition fairly tedious, but it's also prone to error. Even assuming that you are copy and pasting the same style attribute from element to element - as opposed to typing in the deceleration by hand - each time you do so increases the likelihood that you might make a mistake; pasting the text in in the wrong place, perhaps, accidentally overwriting par or all of an existing attribute, or even skipping an element altogether.

There's a principal in programming called DRY, which stands for Don't Repeat Yourself. In essence, this is a shorter way of saying what we ave just covered above: each time you have to type the same piece of text it increases the likelihood of error, so it is better to only define something once, and then reuse it.

Writing DRY code is also extremely valuable when we want to change things later. Imagine that in six months time you wanted to change the font on all of your paragraphs. Think how much more difficult that would be if you had to do it on every individual element, rather than changing one property value pair in an external stylesheet. Avoiding repetition reduces the chance of mistakes, and makes it easier to modify your code when you want to change things in future.

Separating our concerns

The other reason why using the style attribute on individual elements is considered bad practice is to do with what is called the separation of concerns. This is another principal that says that the content of a document and its visual presentation should be kept separate, with as little overlap as possible. A page's HTML document should only define what the content is, and any CSS files should only include rules for styling content. In the real world this is never completely possible - combination selectors (which we'll cover in the next chapter) do need to know about the HTML structure to a certain extent, and classes in html (also the next chapter) rely on there being a cosponsoring entry in the stylesheet - but we should aim to follow it as best we can.

Why should we care about separating content and styling? Part of the reason is about re-usability. At the moment, we're only working on a single web page, but most sites have many different pages, all sharing a similar visual presentation. By keeping all of their CSS in one (or sometimes multiple) stylehseet, and referencing that from each document, websites' can avoid having to define the same styles more than once, and make it easier to update them all in future; the DRY principal again.

The other main reason to separate content and styling is to do with how they are consumed. Most of you reading this book probably read the content on a webpage by visiting the site in a browser, using the site's default styling. However, this is far from the only way that content is accessed. Most of the visits to a typical website are not actually made by humans, but by automated scripts called 'bots' or 'spiders'. The most well know of those, called 'crawlers', are operated by search engines (google, yahoo, bing, yandex etc) to discover pages on the web and download their content to a database. When someone makes a search this database is then consulted, so relevant pages can be displayed on the search results page quickly.

Automated scripts like this don't care about what a page looks like, only what the content is, so it would be pointless to also make then download all the instructions for how to style the page.

Aside from bots, there are also lots of ways that human visitors interact with webpages where the style would be irrelevant. The 'reader' view now built into many browsers takes the content of a page and displays it in a way to make reading easier. Likewise, assistive technologies such as the screen readers used by the blind or those with visual impairments that read a page out to the user are mainly interested in the content, not the styling (only a handful of CSS properties are taken into account by screen-readers, we'll cover them later).

By treating content as independent from styling, we can ensure that our decisions on how to define that content - what HTML elements to use etc - are made purely on the basis of what it should mean, not how it should appear. It's very easy to fall into the trap of picking a HTML element by how it makes the content look, not what it makes the content mean, and doing so is a disservice to all the users (human or machine) who don't need to this.

If you're now suddenly getting anxiety about picking the wrong elements, or having a nightmare trying to change your pages in future, please don't worry. All this chapter is hoping to demonstrate is that keeping your content separate from your styling is better for you and your visitors and explaining why that is. From now on we're going to exclusively use external stylesheets and try and reuse things as much as the language allows us. It does mean a few more things to learn initially, but it will make your life easier in the long run; trust me.