In many ways, the Cascading Style Sheets (CSS) specification represents a unique development in the history of the World Wide Web. In its inherent ability to allow richly styled structural documents, CSS is both a step forward and a step backward -- but it's a good step backward, and a needed one. To see what is meant by this, it is first necessary to understand how the Web got to the point of desperately needing something like CSS, and how CSS makes the web a better place for both page authors and web surfers.
Back in the dimly remembered early years of the Web (1990 -1993), HTML was a fairly lean little language. It was almost entirely composed of structural elements that were useful for describing things like paragraphs, hyperlinks, lists, and headings. It had nothing even remotely approaching tables, frames, or the complex markup we assume is a necessary part of creating web pages. The general idea was that HTML would be a structural markup language, used to describe the various parts of a document. There was very little said about how these parts should be displayed. The language wasn't concerned with appearance. It was just a clean little markup scheme.
Then came Mosaic.
Suddenly, the power of the World Wide Web was obvious to almost anyone who spent more than ten minutes playing with it. Jumping from one document to another was no harder than pointing the mouse cursor at a specially colored bit of text, or even an image, and clicking the mouse button. Even better, text and images could be displayed together, and all you needed to create a page was a plain text editor. It was free, it was open, and it was cool.
Web sites began to spring up everywhere. There were personal journals, university sites, corporate sites, and more. As number of sites increased, so did the demand for new HTML tags that would allow one effect or another. Authors started demanding that they be able to make text boldfaced, or italicized.
At the time, HTML wasn't equipped to handle these sorts of desires. You could declare a bit of text to be emphasized, but that wasn't necessarily the same as being italicized -- it could be boldfaced instead, or even normal text with a different color, depending on the user's browser and their preferences. There was nothing to ensure that what the author created was what the reader would see.
As a result of these pressures, markup elements like <B> and <I> started to creep into the language. Suddenly, a structural language started to become presentational.
Years later, we have inherited the flaws inherent in this process. Large parts of HTML 3.2 and HTML 4.0, for example, are devoted to presentational considerations. The ability to color and size text through the FONT element, to apply background colors and images to documents and tables, to space and pad the contents of table cells, and to make text blink on and off are all the legacy of the original cries for "more control!"
If you want to know why this is a bad thing, all it takes is a quick glance at any corporate web site's page markup. The sheer amount of markup in comparison to actual useful information is astonishing. Even worse, for most sites, the markup is almost entirely made up of tables and FONT tags, none of which conveys any real semantic meaning to what's being presented. From a structural standpoint, these pages are little better than random strings of letters.
For example, let's assume that for page titles, an author is using FONT tags instead of heading tags like H1, like this:
<FONT SIZE="+3" FACE="Helvetica" COLOR="red">Page Title</FONT>
Structurally speaking, the FONT tag has no meaning. This makes the document far less useful. What good is a FONT tag to a speech-synthesis browser, for example? If an author uses heading tags instead of FONT tags, the speaking browser can use a certain speaking style to read the text. With the FONT tag, the browser has no way to know that the text is any different from other text.
Why do authors run roughshod over structure and meaning like this? Because they want readers to see the page as they designed it. To use structural HTML markup is to give up a lot of control over a page's appearance, and it certainly doesn't allow for the kind of densely packed page designs that have become so popular over the years.
So what's wrong with this? Consider the following:
Unstructured pages make content indexing inordinately difficult. A truly powerful search engine would allow users to search just page titles, or only section headings within pages, or only paragraph text, or perhaps only those paragraphs that are marked as being important. In order to do this, however, the page contents must be contained within some sort of structural markup -- exactly the sort of markup most pages lack.
A lack of structure reduces accessibility. Imagine that you are blind, and rely on a speech-synthesis browser to browse the Web. Which would you prefer: a structured page that lets your browser read only section headings so you can choose which section you'd like to hear more about; or a page so lacking in structure that your browser is forced to read the entire thing with no indication of what's a heading, what's a paragraph, and what's important?
Advanced page presentation is only possible with some sort of document structure. Imagine a page in which only the section headings are shown, with an arrow next to each. The user can decide which section heading applies to him and click on it, thus revealing the text of that section.
Structured markup is easier to maintain. How many times have you spent long minutes hunting through someone else's HTML (or even horizontal margins are not collapsed. If you somehow manage to have two block-level elements next to each other, and each has a margin, the margins will not collapse. The easiest way to illustrate this principle is to set margins on two images and then have them appear on the same line, as they do in Figure 8-6:
your own) in search of the one little error that is messing up your page in one browser or another? How much time have you spent writing nested tables and FONT tags, just to get a sidebar with white hyperlinks in it? How many line-break tags have you inserted trying to get exactly the right separation between a title and the following text? By using structural markup, you can clean up your code and make it easier to find what you're looking for.<IMG SRC="test1.gif" STYLE="margin: 5px;" ALT="first test"> <IMG SRC="test2.gif" STYLE="margin: 5px;" ALT="second test">
Granted, a fully structured document is a little plain. Due to that one single fact, a hundred arguments in favor of structural markup wouldn't sway a marketing department away from the kind of HTML so prevalent at the end of the twentieth century. What was needed was a way to combine structural markup with attractive page presentation.
This concept is nothing new. There have been many style sheet technologies proposed and created over the last few decades. These were intended for use in various industries and in conjunction with a variety of structural markup languages. The concept had been tested, used, and generally found to be a benefit to any environment where structure had to be presented. However, no style sheet solution was immediately available for use with HTML. Something had to be done to correct this problem.
Copyright © 2002 O'Reilly & Associates. All rights reserved.approaches will require the use of classes as well as simple element selectors.
As an example, let's say you have a design where all H1 elements should be green, most H2 elements should be blue, and all hyperlinks should be dark red. However, in some cases H2 elements should be dark blue because they're associated with different types of information. The simplest way to handle this is to put a class of dkblue on each
Let's return to the happier realmof how things should work. Thanks to color andbackground-color, you can create some niceeffects. This example is shown in Figure 6-18:For example, if you have images with ALT text offig-1, fig-2,fig-3, and so on, and want to match any of them,you could use this selector:
This is a less likely use for |=, but it'sstill perfectly valid. Note that the previous rule would not matchthe value figure or config, asneither of them starts with fig- or is simplyTITLE attribute. This attribute is notoften used, but it could become important in the future. Why? Itbecomes important when there is more than one LINKtag -- and there can be more than one. In these cases, however,only those LINK tags with a RELof stylesheet will be used in the initial displayof the document. Thus, if you wanted to link in two style sheets withthe names basic.css andsplash.css, the markup would look like this:
By making the W3C the keeper of the XML standard, it ensures that no one vendor should be able to cause interoperability problems to occur between systems that use the open standard. This should be reassuring to most companies making an investment in this technology, by being vendor neutral, this solution proposes to keep even small companies out of reach of big companies choosing to change the standards on them. For example, if a big company chooses to change the platform at its whim, then most other companies relying on that platform suffer. By keeping all data in XML and using XML in communications protocols, companies can maximize the lifetime of their investment in their products and solutions.
By being language independent, XML bypasses the requirement to have a standard binary encoding or storage format. Language independence also fosters immense interoperability amongst heterogeneous systems. It is also good for future compatilbilty. For example, if in the future a product needs to be changed in order to deal with a new computing paradigm or network protocol, by keeping XML flowing through the system, addition of a new layer to deal with this change is feasible.