2004: The Year of the Cascading Style Sheet,

CSS Viability and Tips to Implementation

Like many technologies, Cascading Style Sheets (CSS) have taken several years to catch on. Some like to attach significant dates to invention. In our Darwinian technology market, very few technologies are widely adopted so I prefer to attach significance to when technologies become applicable. Most notably on the web this year, CSS has "arrived".

CSS has actually been around since the idea of "cascading" was first combined with style sheets to format HTML presentation in 1994. The official W3C CSS 1 recommendation was published in 1996. The idea of style sheets in HTML dates back to the early 90's but before CSS they were application dependant. Style sheets in general can be used to format a wide variety of structured and un-structured documents. The cascading nature of CSS relies heavily on structure. CSS promotes three basic principles:

• Simplified and concise mark-up code
• Consistent application of formatting
• Accessibility and Content Presupposing

All three principles are made possible by a system that takes advantage of the hierarchical nature of HTML and other mark-up languages and separates content from presentation. The "cascading" part of style sheets means that one style is applied down the hierarchy of an HTML document until another style "down stream" takes precedence. The typical metaphor for this application of styles is a cascading waterfall. This image works for the basic principle, but is a bit too chaotic and vague to really be applicable to the full model.

CSS can also be used to present any XHTML or XML document. CSS1 relies on a structured document with tags, so it could apply to some pseudo-XML languages that followed basic wellformedness. CSS2 styles can rely on attributes, so it is safe to say it is limited to documents that follow at least the basic XML rules.

CSS1 was a standard that made it easier to consistently apply text formatting to a web page and across a web site. This version was well received by the web development community since it was relatively straightforward to implement and had a lot of time saving potential. CSS2 built on top of this with a large number of new features to manage layout and presentation.

Heavyweight Boxing

CSS has become the widely preferred replacement for the practice of using "table layout". Tables were used from the late 90's to facilitate control over layout, but the original intent for tables in HTML was to allow a representation of tabular data. The ability to use tables to control width, use cells to position and separate content, and control the visibility and spacing of the cell dividers lead designers to combine this HTML3 tag set with HTML2's image tag. The result was the by-product of decades print media theory publishing a different kind of "content" that HTML was ill suited for. These documents were more like hyper-linked brochures that hyper-text. Table layouts became the first box model for HTML layout.

Since then, a number of designers have improved the black art of table layout, but it remains just that, voodoo. Properly executing table layout requires understanding of a wide range of browser behavior, awareness of accessibility and usability needs, and commitment to "pages of markup for paragraphs of content". The sheer bulk of markup needed for table layout necessitates application software to make it manageable. To this end, site management software like Dreamweaver is well suited, but it only makes a dent in the monstrous task of designing and deploying such sites.

I myself continued to develop intricate nested table layouts until this year. The browser technology simply wasn't there two years ago! Even today, there is a wide disparity between the woeful support of CSS in IE, the first browser to support CSS extensively, and the recent explosion of support in Mozilla, the browser touted as having the most standards compliant support. Because of this disparity CSS is more like a white art, than a science. The good fairy of CSS is certainly the lesser of the two evils*.

CSS provides a box model that requires less framework to be embedded into your HTML and in many cases this framework introduces useful hierarchy. CSS layouts are generally more concise than table layouts and does not require redundant code and spacer images like table layouts do.

The Holdup

Even now, flocking to CSS isn't without problems. The main limitation of CSS is that the technology is designed to layout a document that is structured in a way that strongly correlates to the way it should be presented. CSS can take some elements out of context, but this ability has severe limitations and is implemented least reliably across browsers. Because of the strong correlation to structure and presentation, most web designers find the need to add structure to accommodate the desired visual design. When kept to a minimum, this is neither ideal nor vulgar but rather an acceptable compromise and certainly preferable to table layout. In the worst case scenario CSS is only as problematic at table layout.

The adoption of CSS has been slow. There are currently two versions of CSS in use and another one on the drafting table. All three are more or less backwards compatible including the case where no style sheet is used when the sprit of the technology is followed. The hold up has not been due to a poorly designed standard, but rather a lack of responsiveness in the part of the browser developers.

It took four years for CSS1 to be "fully" implemented in any browser, which came first in Internet Explorer for Mac, which is now among the browsers with the worst support for CSS. As the open source Mozilla movement picked up steam, it began to catch up to CSS. Still in 2004 no browser can be classified as having "full" support of CSS2, but for the most part unimplemented features (in Gecko and KHTML) are limited to features that radically diverge from the way browsers are currently used, such as "paged" content and aural style sheets. Paged content, which is more like PDF than traditional HTML layout is a bona fide part of the CSS2 specification. Aural style sheets, which are intended to apply the principles of CSS to pages when run through text-to-speech engines, is still only a "heads up" recommendation at this point.

When following the sprit of CSS, browsers that do not support the technology can still be used to access the content, though it will not be as "pretty" or concisely laid out. Instead, content is shown in exactly the order it appears in the HTML, thus true to the structure. This emphasizes the importance of a well thought out hierarchy. The real stumbling block is the browsers that incorrectly implement CSS, Both IE for Mac and Windows have unique problems with CSS. Opera is another browser that has incomplete and inconsistent support, but in most cases it is better than IE. Mozilla's Gecko engine is generally considered to be the most standard's compliant browser with Safari's KHTML is a close second.

CSS layout isn't easier than table layouts, it is just better. It is better in the sense that it is more practical, more powerful, generates simpler HTML, and has the potential to be more accessible than tables. Learning CSS layout is yet another hurdle, it doesn't give something for nothing.

Style Rules

A Cascading Style Sheet is a set of rules telling the browser how to display elements in a page. Every browser has default rules for each tag, these defaults are more or less fairly consistent among browsers. Traditionally, these defaults were changed by setting an attribute such as bgcolor for a table cell or vlink in the body tag, or wrapping them with a formatting tag, such as the font or b tag. The problem with this methodology is that when you want to change the default formatting broadly this must be done on a per tag or at best per document level. Some templating technologies helped with layout and navigation areas of a page, but not the content that was to be inserted into the template.

With cascading style sheets you can specify styles on multiple levels. The broadest levels allow the sharing of style sheets across document, thus keeping management easy. This sort of style rule is commonly used for setting the preferred font-face and sizes for a site. The broad rules are kept in separate files so that they are loaded once when first used and then cached to reduce loading time the next time they are used. This method can be used to define styles for browsers that support CSS1, but not CSS2 though these are rare, and it can be used to define style sheets for different media, most notably print versus screen, though these are also not widely supported or used yet. Following the rules of cascading, these rules are easy to override by placing a rule at a narrower level closer to the content to be affected.

The middle road between being narrow and broad is to define style rules for a document in a style tag in the head tag of the document. Any rules specified here apply to the entire document and override any rules established outside the document. This is useful for complex rules that only apply to certain layouts or are not needed in most documents. This is also the best way to for an individual to insert styles. They replace the universal rules for as long as they are present, but when removed the universal rules come back into effect. Like styles from other documents, the narrow methods of applying styles take precedence over document specific styles.

The narrowest level allows the application of style to individual elements inline with the code. This can be accomplished by wrapping a tag to apply style around a group of elements or in the attribute of a single tag. These rules carry the strongest weight with the content they are associated with and take precedence over broader rules. Styles specified in the attribute of a tag take precedence over the style applied by another tag wrapping that it. Adding too many of these types of styles can create code that is as bloated as traditional HTML, so use should be limited to elements that are truly unique to piece of content in one page.

Rules in CSS have a basic syntax:

selector { property: value; }

Each rule has a selector followed by a block containing zero or more declarations inside a {} pair. The selector can be the name of the tag to be affected ( all p tags for example) or a more complex selector. Each declaration is a property followed by a colon and one or more values followed by a semi-colon. If there are multiple values they are separated by commas. A simple rule would be:

p {font-face:"Verdanda",sans-serif; margin: 10em, 5em, 10em, 5em;}

This rule says apply the font face Verdana (or the default sans-serif if Verdana is not available) and a margin of 10ems to the top and bottom and a margin of 5 ems to the right and left of every p tag. There are tons of defined properties. Even touching on them goes well beyond the scope of this document. As you can see, CSS does not look like HTML at all. It is a well defined specification and is strict like XML. If part of a line in a Cascading Style Sheet is invalid the whole line is ignored.

The mesh of broad to narrow rules is one way CSS rules are applied. Content can be completely controlled with this level of knowledge and nothing else. CSS, however has some additional features to make applying style sheets more concise and powerful. One way to take advantage of the concise nature of external or document wide style rules, but apply them in a narrow way to give them high priority is with class and id selectors. The narrow way to apply a style to one piece of content that appears in several pages but only once per page is by an id based style. In the content, an id attribute is assigned to a tag. This id must be unique within the document, an alphanumeric word or number. This method makes the code lighter than inline styles and cane take advantage of caching if the id is used across multiple pages. Class based styles are identical to id based styles except that classes can apply to as many tags as desired. This type of selector can also be set to apply to any tag or only tags of a certain type and class. Following the broad to narrow cascading rules as before, a class rule that applies to any tag will be replaced class rule that applies to a tag of a specific type (when the class and tag match) and if there are any id rules that apply to the tag they will take precedence over class rules. Other selector rules let you simple pattern matching based on other attributes and the relationship of tags to other tags in the hierarchy. These rules are weaker than class and id selectors, but stronger than other linked or imported rules rules that apply to specific types of tags. Selectors can even be based on relationships between tags of a specific class or with a specific id. There are also special pseudo-classes that describe tags in certain states like a:visited for links that have been recently viewed.

Application

In real world documents, cascading style sheets can be used effectively with templates just like table based layouts were. It is sometimes easier to make dynamic templates using template properties in Dreamweaver with cascading style sheets because the template property can be applied to the style sheet rather than the tags in the body. In fact, once the paradigm shift has been made, a lot of things are easier when working with style sheets. So how does this cascading really help?

In addition to the broad to narrow rules we have already discussed, style rules cascade down the hierarchy of your HTML file. This means styles applied to one tag are applied to tags inside of it unless the default rules override this. For example, if you apply a font-family to the body tag it will cascade down to all other tags inside. Every tag, other than a few like the pre tag, should have a matching font. In practice, some browsers still have a buggy implementation of this cascading, but for the most part it works. You should do some basic testing and add rules as needed to make sure pages appear as you desire in your target browsers. An example of a rule that doesn't cascade is font size. When you apply font size to the body tag it doesn't cascade down to the other tags because most have their own default size rules. Fortunately these rules are all relative sizes to the body tag, so the only time you need to write a rule for every tag is when you don't like the defaults. Borders and margins are another example of a style that does usually cascade down the HTML hierarchy. The default rules for browsers were defined with common practices in mind, so the most common things designers do require fewer rules.

The real meat of learning to use Cascading Style Sheets is understanding it's "Box Model". The basic premise is that all tags in your content have a box around them. Normally these boxes do not overlap and are arranged so that they are positioned from left to right, and when horizontal space runs out, top to bottom. Since tags can contain tags, boxes can contain boxes. Some boxes, like any box containing text, will stretch to fit the width of it's containing box so nothing will be placed to the right. Other boxes have a fixed width so as space allows any siblings that follow will be placed to the right. Boxes can have padding, borders, margins, fixed or percent widths, and a wide variety of properties that are set just like any other property of the tag. The positional behavior can be changed too. Boxes can be told to float to one side, left or right. Each box that is told to float left or right will move as far in that direction in the parent box as possible, moving all other sibling boxes out of it's way. The first floating box in a group will have the highest priority and go the farthest in it's direction, each subsequent floater will have to deal with the remaining space on the same line. When room runs out on a line the remaining boxes are moved to the next. Normally two floaters going in the same direction will appear side by side as room allows. If this behavior is not desirable, the box can be told to clear in a direction. A box that clears will automatically go to a new line if it isn't the first floater in the direction is it told to clear, and takes all the boxes that follow, with it to that new line. Float and clear are the primary tools of laying out elements in the CSS box model, there are more, but the resources in the last section are much better places to learn all the tricks.

For designers that are content to use text links for navigation, CSS can be used to create elaborate and accessible roll-over effects for links and even navigation menus. Style sheets make it easy to "skin" a web site, so that it's appearance can the customized to a user's preference, such as in a portal. This same skinning can make repurposing a template for a different use easier than with table layouts. The key is the separation of presentation from the content. In this case the navigation is part of the content, but the layout can be attached to the style sheet rather than the HTML.

Resources

If the promise of CSS have peaked your curiosity, or you tried CSS before and were disappointed, I encourage you to use the following resources to learn more. CSS is a developing technology, and it is far from perfected, none the less it is where the industry is going. Table based layout will no doubt be around for another decade or more, but it is no longer the only way to have sophisticated layout.

The CSS Zen Garden is a great place to see the power of CSS. Their links are a bit chaotically arranged, and not all are useful for learning. Some links are great for advanced CSS. I recommend this as a first and last stop on your path to CSS enlightenment. At first, it's a great place to see how CSS can make one page look many different ways without ever changing the HTML. Once you understand the basics of CSS it's a good place to pick up tricks and see a box model in use.

Floatutorial is the #1 easiest way to learn the CSS Box model I have seen. Listutorial and Selectutotial are also great step by step walk thoughts of practical application of CSS. CSS Panic is another resource for links you might want to check out. SELFHTML has a good section on CSS, so does HTMLDOG.

Positioning is Everything is an excellent source for information on the various bugs associated with CSS in browsers. The CSS Crib Sheet is a great trouble shooting resource. Rich In Style is another source for known bugs.

* The real lesser of the two evils really depends on the developer's individual situation. There are some designs that can be accomplished in a relatively cross browser compatible fashion with table layouts that cannot be done with CSS. Personally, I feel that for the advanced developer there is nothing wrong with using either or both methods. They each have strengths and weaknesses. Mixing the two can dilute or combine the strengths or weaknesses depending on your implementation.