The chapter on (X)HTML attributes introduced (amongst others) the style attribute, one of the core attributes, and gave a brief description of what it did. What I'm sure you've discovered by now is that it has a very serious drawback: If you want to repeat the style attribute's effect over more than one element, you have to repeat the attribute for every element (unless, of course, it's a child element of an element that already has the effect you want).
If you've been using the style attribute and thought it was tedious, you were absolutely right. If you thought that there must be a better way, you were right all along.
The style attribute is just a taste of Cascading Style Sheets, or CSS for short. As you use (X)HTML to give your webpage structure, the purpose of CSS (which refers to the language as well) is to use for presentation—in other words, make that structure look good.
Quick note: CSS is almost always used to refer to the language: when talking about an actual cascading style sheet, the normal abbreviation is stylesheet. That is the convention I will use in this book.
Earlier in the book, I presented 5 presentational elements (b, big, i, small, and tt) and implied that, at one time, such markup had been in regular use. So why the switch to CSS?
Before CSS was made an official recommendation by the W3C you had something called presentational HTML
which controlled how a webpage looked (I say HTML
because XHTML wasn't around yet). This method had a lot of issues.
The appearance of text was controlled either by using the header elements for big text, the presentational elements I mentioned in Chapter 8, or with an element called font. Indenting paragraphs could be done either by using the blockquote element, or, if you wanted just the first line, by horrid abuse of the dd element.
Furthermore, a webpage's layout was done using tables. Remember how complex even a simple table looked? Well, that's all website designers had to work with at the time—and as rowspan and colspan attributes were a necessity, you really had to keep an eye on which cells expanded to where.
Worst of all were the browser wars, fought between Internet Explorer and Netscape. Each browser had proprietary markup, which was a fancy name for elements that Internet Explorer recognized and Netscape did not, or vice versa.
Because so much HTML coding was required to achieve basic effects, many pages ended up having more HTML code than actual content—a phenomenon called code bloat (tag soup refers to the same thing).
Accessibility, which sounds like another buzzword floating around but simply means making your page as easy to use as possible, was severely compromised by all this. Screen readers (used by illiterate, vision-impaired and blind people) had difficulty making sense of the morass of markup used in such pages. So did text browsers. And, because of the file sizes involved here, pages took a long time for users who had dial-up internet connections—that is, they connected to the internet over a phone line— to download.
That last bit is important. Today—at least in some circles—dial-up access is considered something of a joke. But before CSS was created (we're talking before 1996), dial-up internet connections were very common—and there are still areas even within developed nations with no other affordable way—or no other way whatsoever—to connect to the internet.
With the use of presentational markup, redesigning a webpage could take a ludicrous amount of time.
For example, if you wanted all your third level headers coloured blue, you used an element called font. If you wanted it underlined and in italics, you had to use separate tags for each (underlining was handled by an element named u). The whole mess looked like this:
h3 Elements Blue With Presentational MarkupAnd you did it for every single h3 element in every single page. If you later decided they should be red and without italics or underline, you had to change every single h3 element in every single page!—and hope you didn't miss one, which would then stick out like a rustbucket jalopy on a Lexus showroom floor.
Heaven help you if you had to change the layout. With the use of tables for layout, if you had your page navigation on the right side of the screen but decided you wanted it along the top or down the left side of the screen, you had to recode the entire table to do this. And, again, do this for every single page you wanted to change.
I'm sure you've seen many websites with print-friendly pages
. This was because, with presentational markup, what was on your screen was usually what got printed, resulting in the waste of paper and ink alike. Therefore, simpler print-friendly pages were created—in short, a second copy of each page intended for printing had to be created and maintained.
No wonder website designers got fed up.
CSS was created to take all presentational aspects from (X)HTML, leaving the markup language with only the duties of providing structure for the content—(X)HTML's original purpose.
This accomplished many things.
For one, code bloat no longer needed to be an issue. Tables, which by nature take a lot of coding, no longer needed to be used for layout, cutting massive amounts of coding. The cumulative effect of several nested elements and attributes could pared down to one element and one or two attributes providing the information CSS needed to work with. All this allowed (X)HTML documents to be smaller, which cut down on the bandwidth required to send them.
With CSS, the visual appearance of an element no longer mattered—if you didn't like its default appearance, you could always override it with CSS. This meant that elements could be used for their original purpose—and semantic code (in other words, code that makes sense) is one of the cornerstones of accessible webpages.
CSS also made redesigns much, much easier, since one didn't have to meddle with the (X)HTML at all—just rewrite the CSS.
To demonstrate the freedom this gave website designers, I suggest you take a look at the CSS Zen Garden sometime. The URI is http://www.csszengarden.com. The rules set forth forbid designers to alter the XHTML (that's what the page is written in), but they can do as they please with the CSS.
More recent developments have allowed for different style sheets for different media: You no longer have to create a print-friendly
webpage—simply create a print-friendly
style sheet. You could also design for other media (like palm-top computers) without creating other webpages. In fact, there is an entire branch of CSS that has absolutely nothing to do with visual effect—instead, it is used to control how a page sounds when listened to through a screen reader.
An easier question is who doesn't,
but there is one important factor when it comes to working with CSS: Not all browsers support CSS to the same extent. Internet Explorer 8 apparently has full support for CSS 2, but earlier versions do not. Therefore, when I talk about CSS rules, selectors, declarations, properties, and values, keep in mind not all are supported by all browsers.
There are, however, browsers that offer no support at all to CSS. I'll mention a few of them, and explain why such browsers shouldn't be a concern.
Who on earth uses either of these? The oldest version of Internet Explorer with any measurable popularity is Internet Explorer 4, with a usage of 1%%. That's not a typo; only 1 in 10,000 people on the Internet use IE4, which works out to under 1.5% of everyone who uses Internet Explorer itself.
Therefore anything older than IE4 can safely be considered insignificant.
But while these browsers don't actually benefit from the use of CSS, they do benefit from two things that the use of CSS for presentation permits: semantic (X)HTML and the lack of presentational markup—in short, webpage structure that makes sense.
To make matters easier in demonstrations of stylesheets, I will identify each element by an ID based on the element name and which occurence of that element it is. For example, the second paragraph in the page would be identified by its element name, p
, and its number, 2
. These would be separated by an underscore, resulting in an ID of p_2
. By the same rules, the first h1 element would be h1_1
. This is simply to help you keep track of which rule affects which element. For example, below is the code of the webpage created in Your First Webpage, with the relevant IDs added.
Your First Webpage, With
id Attributes Added