10 Steps to CSS Success: Browser, User, Author

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>

NOTE

Structural components of a document include the required declarations for
conformance (in this case, the DOCTYPE declaration) along with certain elements
that form the structure of that document: html, head, title, and body elements.
Further structure can then be added via the use of meaningful elements as
they are required.

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.

If you're on Windows and have Mozilla or Firefox installed, you can
search for the file "html.css," which is the default browser styling
for the Mozilla and Firefox browsers. On Macintosh OS X, navigate to the
Applications folder, highlight the Firefox logo, select CTL+click, and choose
Show Package Contents. From there, choose Contents > MacOS > Res
and you'll find the html.css file within the Res folder.

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.

TIP

If you're working in a team environment, it's always best to create
as many styles for the environment in which you're working. Additionally,
document what you're styling and why, and use comments in your style
sheets to indicate where you haven't styled something and why. This
will help your teammates work more efficiently.

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.

NOTE

Specificity will be discussed in an upcoming edition of "10 Steps to
CSS Success."

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.

CAUTION

Dreamweaver users working with Dreamweaver's Draw Layers feature should
be cautioned that doing so creates absolutely positioned divs with
inline style. While a nice feature in theory, in practice it's really
a poor way to go about contemporary, effective site design. Avoid the Draw
Layer feature and rely on Dreamweaver's other useful CSS tools instead.

Embedded Style

Embedded style is style that is added to a document using the style element
in the document 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.

NOTE

An interesting reason to use embedded style is if you are styling HTML email.
I'm an old-school purist about some things, and HTML email is not something
I'm pleased about (I could go on). However, if you find yourself in
the position of having to style for email, embedded style might be your best
bet in terms of styling for as many email clients as possible.

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):

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.

NOTE

Another kind of author style sheet, imported style, behaves much like linked
style but has the unique ability to not only be imported into an HTML or
XHTML document, but into other style sheets as well. I'll address imported
style in greater detail in a future article.

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.