In this article I'll introduce Cascading Style Sheets (CSS) through a brief
historical overview on its origin and some remarks about standards and their
usage. I'll explain what is CSS, why it's been created, why we should know CSS and,
overall, why CSS can be regarded as the present and the future of web documents.
Content and formatting: two separate objects
A web document is, in its essence, made up by two components: the actual document's content and the formatting presented to the user. The task of all SGML-based markup languages (HTML, XHTML, XML, etc.) consists of coding content by specifying its structure and the semantic role of every single element.
Content structure shows the role (or function) that each object plays in the
document's context. For example, in (X)HTML headings, paragraphs and lists are marked up
as h1...h6, p and ul (or ol, etc.),
respectively.
<body> <h1>Heading 1</h1> <p>A paragraph.</p> <h2>Heading 2</h2> <p>A paragraph.</p> <h3>Heading 3</h3> <ul> <li>An item.</li> <li>An item.</li> <li>An item.</li> </ul> </body>
By default, the visual rendering of each element is determined by the browser. For example, headings are generally displayed in bold and have a decreasing font size. They are separated from other elements by vertical margins like paragraphs, while lists have markers on the left side and are pushed rightwards.
In other words, a browser uses its default rules for (X)HTML documents and renders the document accordingly (obviously this is not the case of XML, since this language doesn't have a predefined set of elements). However, an user can always change the default rendering by setting some options in the browser's GUI (Graphical User Interface).
No more tag soup
Before the invention of CSS, authors (web designers,
web developers, content developers etc.) couldn't modify the criteria used by browsers for
document's rendering. To satisfy the increasing, visual needs of authors, new (X)HTML elements
(such as font) and attributes (such as bgcolor) were introduced to
the specifications. The purpose of this addition was actually related to the visual presentation
of web documents, not to their semantic structure. However, the elements mentioned above
allowed authors only to define the foreground and background color of their pages.
There was no way of positioning elements within a page, except for the align
attribute used for images. To build complete, complex and compelling layouts, authors
started relying on tables (whose actual task is to provide a structure for tabular data),
transparent images and other visual tricks that led the markup to become redundant, less
structured and even harder to read.
Authors were used to insert elements without knowing and understanding their semantic role, but only to control the visual layout of their documents. The structural consistence of documents was sacrificed for the design and, consequently, the size of web pages increased exponentially with a significant waste of bandwidth.
What's more, the worldwide spread of WYSIWYG (What You See Is What You Get) editors added a further, harmful factor to this (worst-case) scenario (such programs are visual editors that allow authors to create web pages without editing the code, that is, without knowing markup elements).
Therefore, content became a hodgepodge of ill-formed tags that most developers call a tag soup. Tag soup is the worst-case scenario, especially when thinking of web documents in terms of content accessibility. Assistive technologies encounter several problems when they have to render tag soup documents. For example, when a screen reader runs across a neverending sequence of spacer GIFs or nested table elements, an user might lose his/her way through the document. In other words, the content is no longer accessible, since such assistive programs follow the source code order of a document. Even though some applications (e.g. Jaws) deploy shortcut techniques to deal with the tag soup problem, providing a non-standard document is the worst authoring practice. However, this scenario was only the logical consequence of the lack of proper tools for authoring web documents by separating content from formatting.
The CSS invention
In 1996 and 1998 the World Wide Web Consortium (W3C) released the CSS1 and CSS2 specifications, providing authors with a powerful tool that allows them to write well-formed, semantically correct (X)HTML code, controlling at the same time the visual layout of their documents. Conceptually speaking, CSS consists of a set of rules that instruct web browsers how to render the content inserted in a document. In practice, CSS allows authors to specify the rendering of each (X)HTML element.
Since CSS is interpreted by the rendering engine of a web browser, CSS support has been a real pain in the neck for a long time. Some years ago, browsers misinterpreted the specifications, causing several problems for authors even with simple page layouts. Now the situation is radically changed: browsers such as Internet Explorer, Firefox, Chrome, Opera, Safari and Konqueror support CSS well and their support is still improving. Therefore, many websites with a tag soup mentality have actually become obsolete, as Jeffrey Zeldman pointed out in his famous article for Digital Web.
With the turn of the century, CSS gained a new level of complexity with its third release (CSS3). Now CSS3 allows us to manipulate box and text shadows, rounded corners, gradients, graphical effects such as transitions and transformations and even animations. And much more!
The main benefit for us is a radical change of mentality. Now we can rediscover the web.
The benefits of web standards
Compatibility
W3C standards are the common basis for browsers and Internet devices development. Consequently, a standard compliant site is compatible with past and future browsers and Internet devices. Compatibility doesn't imply a pixel-perfect uniformity in rendering. For example, a document viewed on a handheld device will appear in a different way on a computer screen and vice versa. Nevertheless, the same document remains accessible to any (X)HTML-capable device.
Device independence
Standard compliant documents work well on different programs and devices, such as PCs, palmtops, cellphones and a wide range of browsers (text, aural, braille, etc.) Thanks to CSS we can even create different presentations targeted on a specific device.
Accessibility
Standard compliance doesn't necessarily imply full accessibility, but it's only a minimum level that allows users to fully enjoy a document even when CSS is turned off or not supported.
Code maintenance
Standard code is simpler and neater than tag soup. Each element is inserted on the basis of its structural function and semantic meaning. Updating and modifying the code become simple operations, since such a code doesn't mix structural and presentational elements. What's more, standard code reduces document's size and, consequently, the amount of time required to download a page. Keep in mind that CSS, like images, is stored in the browser cache.
Search engines indexing
As many authors know, search engines index the text contained in web documents. When there is more text than markup, the page is better indexed. CSS allows authors to reduce the amount of redundant markup, helping pages to be better positioned. It's important to keep in mind that search engines tend to honour the semantic of page elements. For example, search engines search for keywords within certain elements, such as (X)HTML headings.
A new philosophy
Standard compliance should be kept separate from mere code validation. A valid document is only a document that honours a known DTD (Document Type Definition), that is, a formal and prescriptive grammar that defines the syntax of a markup language (such as XHTML 1.0) and the contextual relation between its elements. For example, a page that uses tables and spacer images might have all its tags correctly nested, all its attributes enclosed between single or double quotes and, say, all its elements inserted in the right context. Such a page is valid according to the W3C validator, although there is a total and evident lack of semantic and accessibility. In other words, standard compliance is the result of a more complex process that involves several factors. Validation, in my opinion, constitutes only the first step of this process.