CSS: The Definitive Guide, 3rd Edition (11 page)

Figure 3-3. Inheritance of styles

Figure 3-4. A simple tree diagram

There is an exception to the upward propagation rule in HTML: background styles
applied to the
body
element can be passed to the
html
element, which is the document's root
element and therefore defines its canvas.

Figure 3-5. Why borders aren't inherited

Figure 3-6. Zero specificity defeats no specificity

Inherit the Bugs

Due to problems in various browser implementations, an author cannot rely on
inheritance to operate as expected in all circumstances. For example, Navigator 4
(and, to a lesser extent, Explorer 4 and 5) does not inherit styles into tables.
Thus, the following rule would result in a document with smaller text everywhere
outside of tables:

body {font-size: 0.8em;}

This is not correct behavior under CSS, but it does exist, so authors have
historically resorted to tricks such as:

body, table, th, td {font-size: 0.8em;}

This is more likely, although still not guaranteed, to achieve the desired effect
in buggy browsers.

Unfortunately, the above "fix" leads to an even worse problem in browsers that do
implement inheritance correctly, such as IE6/Win, IE5/Mac, Netscape 6+, and others.
In those browsers, you will end up with text inside a table cell that is 41 percent
of the size of the user's default font size setting. It is often more dangerous to
attempt to work around inheritance bugs in old browsers than it is to write correct
CSS for updated browsers.

Figure 3-7. Directly assigning styles to the relevant elements

1. Find all rules that contain a selector that matches a given element.
   

2. Sort by explicit weight all declarations applying to the element. Those rules
   marked
   !important
are given higher weight than
   those that are not. Sort by origin all declarations applying to a given element.
   There are three origins: author, reader, and user agent. Under normal
   circumstances, the author's styles win out over the reader's styles.
   !important
reader styles are stronger than any other
   styles, including
   !important
author styles.
   Both author and reader styles override the user agent's default styles.
   

3. Sort by specificity all declarations applying to a given element. Those
   elements with a higher specificity have more weight than those with lower
   specificity.
   

4. Sort by order all declarations applying to a given element. The later a
   declaration appears in the style sheet or document, the more weight it is given.
   Declarations that appear in an imported style sheet are considered to come before
   all declarations within the style sheet that imports them.
   

Under the second rule, if two rules
apply to an element, and one is marked
!important
,
the important rule wins out:

p {color: gray !important;}
Well, hello there!

Despite the fact that there is a color assigned in the
style
attribute of the paragraph, the
!important
rule wins out, and the paragraph is gray. This gray is
inherited by the
em
element as well.

Furthermore, the origin of
a rule is considered. If an element is matched by
normal-weight styles in both the author's style sheet and the reader's style sheet,
then the author's styles are used. For example, assume that the following styles come
from the indicated origins:

p em {color: black;}    /* author's style sheet */
p em {color: yellow;}   /* reader's style sheet */

In this case, emphasized text within paragraphs is colored black, not yellow,
because normal-weight author styles win out over normal-weight reader styles.
However, if both rules are marked
!important
, the
situation changes:

p em {color: black !important;}    /* author's style sheet */
p em {color: yellow !important;}   /* reader's style sheet */

Now the emphasized text in paragraphs will be yellow, not black.

As it happens, the user agent's default styles—which are often influenced by the
user preferences—are figured into this step. The default style declarations are the
least influential of all. Therefore, if an author-defined rule applies to anchors
(e.g., declaring them to be
white
), then this rule
overrides the user agent's defaults.

To sum up, there are five levels to consider in terms of declaration weight. In
order of most to least weight, these are:

Authors typically need to worry about only the first four weight levels, since
anything declared will win out over the user agent styles.

According to the third rule, if conflicting
declarations apply to an element and they all have the same weight, they should be
sorted by specificity, with the most specific declaration winning out. For example:

p#bright {color: silver;}
p {color: black;}
Well, hello there!

Given the rules shown, the text of the paragraph will be silver, as illustrated in
Figure 3-8
. Why? Because the
specificity of
p#bright (0,1,0,1)
overrode the
specificity of
p (0,0,0,1)
, even though the latter
rule comes later in the style sheet.

Figure 3-8. Higher specificity wins out over lower specificity

Finally, under the fourth rule, if two rules
have exactly the same weight, origin, and specificity, then the one that occurs later
in the style sheet wins out. Therefore, let's return to our earlier example, where we
find the following two rules in the document's style sheet:

h1 {color: red;}
h1 {color: blue;}

Because its rule comes later in the style sheet, the value of
color
for all
h1
elements in the document will be
blue
, not
red
. Any rule that is contained in the document
with a higher weight than the imported rule wins out. This is true even if the rule
is part of the document's style sheet and not part of an element's
style
attribute. Consider the following:

p em {color: purple;}  /* from imported style sheet */
p em {color: gray;}    /* rule contained within the document */

In this case, the second rule shown will win out over the imported rule because it
is a part of the document's style sheet.

For the purposes of this rule, styles specified in the
style
attribute of an element are considered to be at the end of the
document's style sheet, which places them after all other rules. However, this is a
largely academic point, since inline
style declarations have a
higher specificity than any style sheet selector in CSS2.1.

Order sorting is the reason behind the often-recommended ordering of link styles.
The recommendation is that you array your link styles in the order
link-visited-hover-active, or LVHA, like this:

:link {color: blue;}
:visited {color: purple;}
:hover {color: red;}
:active {color: orange;}

Thanks to the information in this chapter, you now know that the specificity of
all of these selectors is the same:
0,0,1,0
.
Because they all have the same weight, origin, and specificity, the last one that
matches an element will win out. An unvisited link that is being "clicked" is matched
by three of the rules—
:link
,
:hover
, and
:active
—so the last one of those three declared will win out. Given the
LVHA ordering,
:active
will win, which is likely
what the author intended.

Assume for a moment that you decide to ignore the common ordering and alphabetize
your link styles instead. This would yield:

:active {color: orange;}
:hover {color: red;}
:link {color: blue;}
:visited {color: purple;}

Given this ordering, no link would ever show
:hover
or
:active
styles because the
:link
and
:visited
rules come after the other two. Every link must be either visited
or unvisited, so those styles will always override the
:hover
rule.

Let's consider a variation on the LVHA order that an author might want to use. In
this ordering, only unvisited links will get a hover style; visited links do not.
Both visited and unvisited links will get an active style:

:link {color: blue;}
:hover {color: red;}
:visited {color: purple;}
:active {color: orange;}

Of course, sometimes such conflicts arise when all the states attempt to set the
same property. If each state styles a different property, then the order does not
matter. In the following case, the link styles could be given in any order and would
still function:

:link {font-weight: bold;}
:visited {font-style: italic;}
:hover {color: red;}
:active {background: yellow;}

You may also have realized that the order of the
:link
and
:visited
styles doesn't
matter. You could order the styles LVHA or VLHA with no ill effect. However, LVHA
tends to be preferred because it was recommended in the CSS2 specification and also
because the mnemonic "LoVe—HA!" gained rather wide currency. (There's some bitterness
out there, apparently.)

The ability to chain pseudo-classes together eliminates these worries. The
following could be listed in any order without any negative effects:

:link {color: blue;}
:visited {color: purple;}
:link:hover {color: red;}
:visited:hover {color: gray;}

Because each rule applies to a unique set of link states, they do not conflict.
Therefore, changing their order will not change the styling of the document. The last
two rules do have the same specificity, but that doesn't matter. A hovered unvisited
link will not be matched by the rule regarding hovered visited links, and vice versa.
If we were to add active-state styles, then order would start to matter again.
Consider:

:link {color: blue;}
:visited {color: purple;}
:link:hover {color: red;}
:visited:hover {color: gray;}
:link:active {color: orange;}
:visited:active {color: silver;}

If the active styles were moved before the hover styles, they would be ignored.
Again, this would happen due to specificity conflicts. The conflicts could be avoided
by adding more pseudo-classes to the chains, like this:

:link:hover:active {color: orange;}
:visited:hover:active {color: silver;}

Chained pseudo-classes, which lessen worries about specificity and ordering, would
be used much more often if Internet Explorer had historically supported them. (See
Chapter 2
for more information on this
subject.)

It is possible that a document will contain presentational
hints that are not CSS—e.g., the
font
element.
Non-CSS hints are treated as if they have a specificity of
0
and appear at the
beginning
of the author's style
sheet. Such presentation hints will be overridden by any author or reader styles, but
not by the user agent's styles.