Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Design > Voices That Matter

Web Design Reference Guide

Hosted by

10 Steps to CSS Success: Browser, User, Author

Last updated Oct 17, 2003.

CSS is a technical language. But, it's meant to address many aspects of presentation. In other words, it's a technology for designers—and therein lies the challenge with those who set out to learn it.

Typically, CSS is taught as a technical language no matter the audience. In this series, I'm going to walk the balance beam (I once fell off of one, so don't be surprised if I cause a few bruises along the way) and attempt to find the language to express to a broad audience the fundamentals, complexities and even advanced techniques as to how to master CSS and begin to apply it in an immediate, beneficial way.

Markup is from Mars, CSS from Venus

One of the first things to remember about CSS is that it's all about relationships. The primary relationship that CSS has is to the document, be it HTML or some form of XML, such as XHTML. Markup documents at their best are structural, meaningful, and ultimately, quite linear. As such, markup is definitely the male side of the relationship, providing a firm, if stubborn, foundation for the more temperamental nature of CSS.

To demonstrate this, I've provided a document containing structural components including those necessary for a conforming XHTML document, and semantic use of elements to organize and linearize the content within (Listing 1).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-us" lang="en-us"> 
<head>
<title>XHTML document</title>
</head>
<body>
<h1>10 Steps to CSS Success</h1>
<p>10 Steps to CSS Success is a pain-free way to learn the fundamentals of CSS. The goal isn't to make you a great designer, or teach you to be an expert CSS author. Rather, you'll be given the tools and knowledge often missed by the many individuals who learn from books, online resources, and view source without gaining a more formal understanding of the complexities within CSS.</p>
</body>
</html>

Clothes Don't Make the Man

If I take the document I've just created and open it with a browser (pick a browser, any modern one will do) I find something interesting, if not exactly stylish. And that is that while my content appears plain, with the infamous big, bold, and ugly h1 defaults, serif fonts, and some margins around the body and paragraphs, there's still some color: blue for my links, with the infinitely usable underline beneath (Figure 1).

So while it's not exactly Armani, the document is at least modestly dressed.

Behind Every Man . . .

So, where's this minimalist style coming from? Why, the browser style sheet, of course. With so many references referring to documents that have no obvious style as "unstyled," we've created the illusion that a document, once loaded into a browser, has no style.

This is untrue. In all browsers with CSS support, it is CSS that is responsible for these defaults. And it is with browser style that we must begin to understand the basis of the fundamental relationship between markup and CSS.

Browser Style

Browser style sheets, also referred to as user agent style sheets, are those styles that are native to the browser. In some cases, this means the styles are hard-coded into the browser software. However, some browsers, including Firefox and Mozilla, use an actual .css file to handle the default styling of interpreted documents.

Listing 2 shows h1 and other styles pulled from the Firefox style sheet, showing the default styling of familiar elements.

h1 {
 display: block;
 font-size: 2em;
 font-weight: bold;
 margin: .67em 0;
}

p, dl, multicol {
 display: block;
 margin: 1em 0;
}

Browser style sheets play an important role in the relationship of markup and style, although it's an often misunderstood role. Some concerns of which you should be aware include:

  • Browser styles are always overriden by relevant style rules. This means that browser styles are the weakest link in the application of style—if any rule outside the browser exists for a given element and is integrated with the document in question, that rule takes precedence over the default browser style.
  • Anything left unstyled by authors and users will be styled by the browser. If you write a rule that styles your h1 elements to have a particular font, a specific size, and a color other than the browser style, all those rules will apply. However, those properties you do not include for your element—in this case, properties such as those managing display (block or inline); margin, padding, and so forth—will revert to the browser style.
  • Some frustration on the part of those using CSS to style documents can emerge from a misunderstanding or lack of awareness of the role of browser style. Because browser style will apply in the absence of no other styles, if you're just starting out with CSS or not aware that the browser is controlling the appearance of unstyled elements, it's easy to become quickly frustrated or confused as to why elements continue to have features as they do.

A great way to avoid frustration and tap into the power and understanding of browser style is to always create styles for elements you are sure to be using within your documents. Alternatively, if you want the browser to continue styling aspects of your documents, you can purposely leave those styles out.

Fashionable Authoring

Now that it's clear how markup and browsers interact with regards to style, the next step is to take a look at one of the more temperamental aspects of CSS: Author styles.

Just as many a spouse complains when his or her significant other takes too long to get dressed, but appreciates the end result, so it is with a document and you as the CSS author. CSS takes time not only to understand, but to beautify and perfect. There is no place that those of us working with CSS will find this more true than when developing our own style sheets.

There are three primary author style sheet types: Inline, Embedded, and Linked.

Inline Style

Inline style is style that is added directly to an element using the style attribute as follows:

<p style="text-align: right;">This text will align to the right.</p>
<p>And this text will align left, which is the browser default.</p>

The role of an inline style is to apply style only to the one element, not to any other element within the document or site (Figure 2).

Inline styles always override browser styles and other author styles, as well as certain user styles. Early on in the history of CSS, this made good sense, but it's making far less sense as time goes on and we become more sophisticated in our practices.

Problems with inline style include:

  • Inline style applies only to one discrete element. Originally an advantage in small site scenarios, this has now become clearly a disadvantage for larger sites. It's very rare that anyone will have just one discrete style necessary in a site of 10 pages or more, and even then it's more manageable to place the style elsewhere, as searching for the inline style should a change be desired becomes troublesome.
  • Inline style adds weight to documents. In recent years, much thought has been given to how to streamline markup so that it loads and renders more quickly in browsers, enhancing the user experience and making the document easier to manage across different media such as print and handhelds, as well as the screen. Adding inline style is perceived as equivalent to presentational HTML, and it's easy to see why when we compare the earlier example to the following:
    <p align="right">This text will align to the right.</p>

    Ironic, isn't it, that the presentational markup actually contains fewer bytes than the style necessary to achieve the same results?

  • Inline style may become obsolete. Because of these reasons, and the concern that mobile and alternative devices (which XHTML is, in part, designed for) won't support the style attribute, using inline style isn't a good habit to get into. In fact, the W3C XHTML 2.0 specification (still in draft) states that the "use of the style attribute is strongly discouraged in favor of the style element and external style sheets." As such, it's pretty clear the W3C itself is keeping the style attribute around more for backward compatibility than forward movement.

There are only two reasons that inline style in contemporary practices should be used. The first is for diagnostics. Inline style, because of the weight it carries in the markup/style relationship, is more specific. This means that if you're having trouble getting a given style to work, you can apply the style inline. If it now works, you know you've got a conflict elsewhere that needs to be resolved. Just be sure to resolve the conflict and remove the diagnostic inline style prior to publishing the document, and you're good to go.

The second reason is a selfish one, and it's called laziness. Sometimes it's just faster to drop in an inline style and be done with it. This is especially true when working with blogs or content management software. Instead of changing a template, it just seems easier to give the element a quick style and move on.

Okay, I admit it. I do this quite often as is evidenced on my blog. So I'm cheating, really, and it's better if I just let you know my bad habits shouldn't become yours. That said, I now take back my reason number two and revert to this advice for inline style: Avoid it at all costs except as a temporary diagnostic tool.

Embedded Style

Embedded style is style that is added to a document using the style element in the document head.

<head>
<style type="text/css">
p {text-align: right;}
</style>
</head>

Embedded styles control the styles for that document only. So, all the p elements in this document will get this style, unless an inline style exists. Embedded styles will trump any styles in linked style sheets.

As with inline style, embedded sheets are falling out of favor because of the management and page weight concerns. Also, as with inline styles, embedded style sheets can be useful in diagnostics. One reason I use embedded style is when I'm building a document and want to work only in that document. I create an embedded style as I build and style the document, but then I move the embedded style out of the document into a linked style sheet.

Linked Style

Linked, also referred to as external style sheets are the holy grail of style. In this case, style is placed in a separate document with a .css extention and linked via the link element in the head portion of your document(s):

<link rel="stylesheet" type="text/css" src="style/screen.css" media="screen" />

While inline and embedded style rules will override rules in the linked style, linked style is the most widely used and flexible of style sheet types. There are many reasons for this, including the following:

  • Linked style manages multiple documents. Whether one or one billion, a single style sheet can be used to manage styles. Want to change a style? Open the style sheet, make the change, save the sheet and voila! Your one billion documents attached to that style sheet are updated.
  • Linked style is cached. When a browser encounters a linked style sheet, it downloads and interprets it. Then, the styles remain in cache until another style sheet is called for. This improves document performance because documents are more streamlined, and the browser has to utilize fewer resources. The end result? Faster loading pages, reduced bandwidth requirements, and happier users—no matter what their connection speed.
  • Multiple linked style sheets can control presentation of multiple media formats. Want all your pages to print to a certain style? Create a print style sheet. Handhelds of interest? Those devices that support CSS will allow you to style your documents specifically for the handheld device. Linked style gives you myriad ways to manage numerous styles effectively for a variety of media, which is one of the most powerful and growing areas of CSS design.

There's Always A User

Even in the best of relationships, at some point, a user appears. Attempts at humorous metaphors aside, the user is the most important participant in a Web site, and CSS takes this into account.

User style sheets (also referred to as reader style sheets) exist to give the user the option to override your styles. Now, why on earth would someone want to alter your beautiful design? Usually, the reason is related to accessibility. If an individual is color blind or requires high contrast, he or she can create a style sheet and apply it via the browser.

User style sheets are underused, but they're important to understand because of their relationship to your style sheets. Your style rules will always override a user style if there's a pre-existing style, except in the instance of the !important declaration.

This declaration, which has become erroneously popular with CSS authors in recent years, was created for the primary purpose of creating a balance between user style and author style. If I, as the user, absolutely require a specific style to address a need, I can add the !important declaration within my rule:

p {font-size: 22px; !important;}

This will make my style more important than your unimportant style. However, and this is a very key issue, if you, as the author, add the !important declaration to a rule, you'll trump me. This is why it is very poor practice to use the !important declaration in author style sheets.

As with inline style, it can be a great way to diagnose problems—drop an !important into a declaration and that rule trumps. If the style applies, you know you've got conflicts somewhere in your style sheets. Go fix them, then strip out the !important declaration. Otherwise, you leave your special needs users without a means of overriding your styles. While designers might balk at the suggestion that a user has a right to mess up your design, this is a feature very specific to the accessibility of the Web, and should be treated as such.

Getting it Sorted

This article has introduced you to an aspect of what is known as sort order. Remember earlier on when I used the term application hierarchy and conflict resolution? Well, without getting too jargony, the information here shows the application hierarchy, sort order, and portions of conflict resolution between browser, author, and user styles, as well as within author styles themselves.

These concepts are part of what puts the "Cascade" in Cascading Style Sheets. In upcoming editions of 10 Steps to CSS Success, I'll cover other aspects of sort order and the Cascade, providing invaluable foundations for you to gain control over your CSS and, ultimately, create far more manageable, useful, and beautiful sites.