Value Syntax Conventions

Throughout this book, there are boxes that break down a given CSS property’s details, including what values are permitted. These have been reproduced practically verbatim from the CSS specifications, but some explanation of the syntax is in order.

Throughout, the allowed values for each property are listed with a syntax like the following:

Value: <family-name>#

Value: <url> ‖ <color>

Value: <url>? <color> [ / <color> ]?

Value: [ <length> | thick | thin ]{1,4}

Any italicized words between “<” and “>” give a type of value, or a reference to another property’s values. For example, the property font accepts values that originally belong to the property font-family. This is denoted by using the text <font-family>. Similarly, if a value type like a color is permitted, it will be represented using <color>.

Any words presented in constant width are keywords that must appear literally, without quotes. The forward slash (/) and the comma (,) must also be used literally.

There are a number of ways to combine components of a value definition:

• Two or more keywords strung together with only space separating them means that all of them must occur in the given order. For example, help me would mean that the property must use those keywords in that order.

• If a vertical bar separates alternatives (X | Y), then any one of them must occur, but only one. Given “[ X | Y | Z ]”, then any one of X, Y, or Z is permitted.

• A vertical double bar (X ‖ Y) means that X, Y, or both must occur, but they may appear in any order. Thus: X, Y, X Y, and Y X are all valid interpretations.

• A double ampersand (X && Y) means both X and Y must occur, though they may appear in any order. Thus: X Y or Y X are both valid interpretations.

• Brackets ([…]) are for grouping things together. Thus “[please ‖ help ‖ me] do this” means that the words please, help, and me can appear in any order, though each appear only once. do this must always appear, with those words in that order. Some examples: please help me do this, help me please do this, me please help do this.

Every component or bracketed group may (or may not) be followed by one of these modifiers:

• An asterisk (*) indicates that the preceding value or bracketed group is repeated zero or more times. Thus, “bucket*” means that the word bucket can be used any number of times, including zero. There is no upper limit defined on the number of times it can be used.

• A plus (+) indicates that the preceding value or bracketed group is repeated one or more times. Thus, “mop+” means that the word mop must be used at least once, and potentially many more times.

• An octothorpe (#) indicates that the preceding value or bracketed group is repeated one or more times, separated by commas as needed. Thus, “floor#” can be floor, floor, floor, floor, and so on. This is most often used in conjunction with bracketed groups or value types.

• A question mark (?) indicates that the preceding value or bracketed group is optional. For example, “[pine tree]?” means that the words pine tree need not be used (although they must appear in that order if they are used).

• An exclamation point (!) indicates that the preceding value or bracketed group is required, and thus must result in at least one value, even if the syntax would seem to indicate otherwise. For example, “[ what? is? happening? ]!” must be at least one of the three terms marked optional.

• A pair of numbers in curly braces ({M,N}) indicates that the preceding value or bracketed group is repeated at least M and at most N times. For example, ha{1,3} means that there can be one, two, or three instances of the word ha.

The following are some examples:

give ‖ me ‖ liberty

At least one of the three words must be used, and they can be used in any order. For example, give liberty, give me, liberty me give, and give me liberty are all valid interpretations.

[ I | am ]? the ‖ walrus

Either the word I or am may be used, but not both, and use of either is optional. In addition, either the or walrus, or both, must follow in any order. Thus you could construct I the walrus, am walrus the, am the, I walrus, walrus the, and so forth.

koo+ ka-choo

One or more instances of koo must be followed by ka-choo. Therefore koo koo ka-choo, koo koo koo ka-choo, and koo ka-choo are all legal. The number of koos is potentially infinite, although there are bound to be implementation-specific limits.

I really{1,4}? [ love | hate ] [ Microsoft | Netscape | Opera | Safari | Chrome ]

The all-purpose web designer’s opinion-expresser. This can be interpreted as I love Netscape, I really love Microsoft, and similar expressions. Anywhere from zero to four reallys may be used, though they may not be separated by commas. You also get to pick between love and hate, which really seems like some sort of metaphor.

It’s a [ mad ]# world

This gives the opportunity to put in as many comma-separated mads as possible, with a minimum of one mad. If there is only one mad, then no comma is added. Thus: It’s a mad world and It’s a mad, mad, mad, mad, mad world are both valid results.

[ [ Alpha ‖ Baker ‖ Cray ], ]{2,3} and Delphi

Two to three of Alpha, Baker, and Delta must be followed by and Delphi. One possible result would be Cray, Alpha, and Delphi. In this case, the comma is placed because of its position within the nested bracket groups. (Some older versions of CSS enforced comma-separation this way, instead of via the # modifier.)

Eric Meyer

This edition was one of the most challenging projects I’ve ever undertaken, for both technical and personal reasons, and I was helped immeasurably along the way by so many people. I’ll do my best to remember everyone, but if I left you out, I am sorry.

To the creators of CSS, Håkon Wium Lie and Bert Bos, thank you for your foresight. The web would be a much poorer place without your work.

To the implementors at various browser makers who have done so much, and come so far together, thank you making so many things possible.

To git, the version-control software, my thanks for the last-minute rescue when it was discovered that an entire chapter (“Lists and Generated Content”) had gone missing, but was easily restored from past commits.

Special thanks are due to Simon St. Laurent, who believed in my ideas for releasing a book one chapter at a time, who kept the project waiting for me when I had to take an extended period of time away, and who worked tirelessly with me to move things forward in whatever way I proposed.

To my co-author, Estelle, for stepping up to help me out when I needed it, for your keen reviewers’ eye, and for your wonderful contributions to this edition, all my gratitude.

A number of other people helped me understand CSS when it didn’t make sense to me, often going several rounds of explanation. Some of them go back a few editions, but most of them helped me adjust to the new patterns in CSS for this edition. Alphabetically, by last name: Rachel Andrew, Rossen Atanossov, Tab Atkins, Amelia Bellamy-Royds, Dave Cramer, Elika Etemad, Jen Simmons, Sara Soueidan, Mel Sumner, and Greg Whitworth. My abject apologies to anyone I left off by oversight.

To the whole community of web designers and developers who stood with me through the hardest passage I have ever known, friends and colleagues and strangers alike, I owe you more than I could ever say. In some ways, I owe you my life. Thank you for hearing me.

And to my family—my wife Kat, and my children Carolyn, Rebecca, and Joshua—you are the home that shelters me, the suns in my sky and the stars by which I steer. I could never have come this far without you. Thank you for everything.

Eric A. Meyer

Cleveland Heights, OH

19 July 2017

Estelle Weyl

I would like to acknowledge everyone who has worked to make CSS what it is today and all those who have helped improve diversity and inclusion in tech.

I would like to recognize those who work tirelessly with browser vendors and developers in writing the CSS specifications. Without the members of the CSS Working Group—past, current, and future—we would have no specifications, no standards, and no cross-browser compatibility. I am in awe of the thought process that goes into every CSS property and value added to, and omitted from, the specification. People like Tab Atkins, Elika Emitad, Dave Baron, Léonie Watson, and Greg Whitworth not only work on the specification, but also take their time to answer questions and explain nuances to the broader CSS public, notably me.

I also want to acknowledge all those who, whether they participate in the CSS Working Group or not, dive deep into CSS features and help translate the spec for the rest of us, including Sarah Drasner, Val Head, Sara Souidan, Chris Coyier, Jen Simmons, and Rachel Andrew. In addition, I want to acknowledge and thank people who create tools that make all CSS developers lives easier, especially Alexis Deveria for creating and maintaining https://caniuse.com/.

I would also like to acknowledge and express my appreciation of all those who have contributed their time and effort to improve diversity and inclusion in all sectors of the developer community. Yes, CSS is awesome. But it’s important to work with great people in a great community.

When I attended my first tech conference in 2007, the lineup was 93% male and 100% white. The audience had slightly less gender diversity and only slightly more ethnic diversity. I had actually picked that conference because the lineup was more diverse than most: it actually had a woman on it. Looking around the room, I knew things needed to change, and I realized it was something I needed to do. What I didn’t realize then was how many unsung heroes I would meet over the next 10 years working for diversity and inclusion in all areas of the tech sector and life in general.

There are too many people who work tirelessly, quietly, and often with little or no recognition to name them all, but I would like to highlight some. I can not express how much of a positive impact people like Erica Stanley of Women Who Code Atlanta, Carina Zona of Callback Women, and Jenn Mei Wu of Oakland Maker Space have had. Groups like The Last Mile, Black Girls Code, Girls Incorporated, Sisters Code, and so many others inspired me to create a list at http://www.standardista.com/feeding-the-diversity-pipeline/ to help ensure the path to a career in web development is not only for those with privilege.

Thank you to all of you. Thank you to everyone. Thanks to all of your efforts, more has been done than I ever could have imagined sitting in that conference 10 years ago.

Estelle Weyl

Palo Alto, CA

July 19, 2017

Replaced and Nonreplaced Elements

Although CSS depends on elements, not all elements are created equally. For example, images and paragraphs are not the same type of element, nor are span and div. In CSS, elements generally take two forms: replaced and nonreplaced.

<img src="howdy.gif" >

Element Display Roles

In addition to replaced and nonreplaced elements, CSS uses two other basic types of elements: block-level and inline-level. There are many more display types, but these are the most basic, and the types to which most if not all other display types refer. The block and inline types will be familiar to authors who have spent time with HTML markup and its display in web browsers. The elements are illustrated in Figure 1-1.

Figure 1-1. Block- and inline-level elements in an HTML document

Inline-level elements

Inline-level elements generate an element box within a line of text and do not break up the flow of that line. The best inline element example is the a element in HTML. Other candidates are strong and em. These elements do not generate a “break” before or after themselves, so they can appear within the content of another element without disrupting its display.

Note that while the names “block” and “inline” share a great deal in common with block- and inline-level elements in HTML, there is an important difference. In HTML, block-level elements cannot descend from inline-level elements. In CSS, there is no restriction on how display roles can be nested within each other.

To see how this works, let’s consider a CSS property, display.

You may have noticed that there are a lot of values, only three of which I’ve even come close to mentioning: block, inline, and list-item. Most of these values will be dealt with elsewhere in the book; for example, grid and inline-grid will be covered in a separate chapter about grid layout, and the table-related values are all covered in a chapter on CSS table layout.

For now, let’s just concentrate on block and inline. Consider the following markup:

<body>
<p>This is a paragraph with <em>an inline element</em> within it.</p>
</body>

Here we have two block elements (body and p) and an inline element (em). According to the HTML specification, em can descend from p, but the reverse is not true. Typically, the HTML hierarchy works out so that inlines descend from blocks, but not the other way around.

CSS, on the other hand, has no such restrictions. You can leave the markup as it is but change the display roles of the two elements like this:

p {display: inline;}
em {display: block;}

This causes the elements to generate a block box inside an inline box. This is perfectly legal and violates no part of CSS. You would, however, have a problem if you tried to reverse the nesting of the elements in HTML:

<em><p>This is a paragraph improperly enclosed by an inline element.</p></em>

No matter what you do to the display roles via CSS, this is not legal in HTML.

While changing the display roles of elements can be useful in HTML documents, it becomes downright critical for XML documents. An XML document is unlikely to have any inherent display roles, so it’s up to the author to define them. For example, you might wonder how to lay out the following snippet of XML:

<book>
 <maintitle>Cascading Style Sheets: The Definitive Guide</maintitle>
 <subtitle>Third Edition</subtitle>
 <author>Eric A. Meyer</author>
 <publisher>O'Reilly and Associates</publisher>
 <pubdate>November 2006</pubdate>
 <isbn type="print">978-0-596-52733-4</isbn>
</book>
<book>
 <maintitle>CSS Pocket Reference</maintitle>
 <subtitle>Third Edition</subtitle>
 <author>Eric A. Meyer</author>
 <publisher>O'Reilly and Associates</publisher>
 <pubdate>October 2007</pubdate>
 <isbn type="print">978-0-596-51505-8</isbn>
</book>

Since the default value of display is inline, the content would be rendered as inline text by default, as illustrated in Figure 1-2. This isn’t a terribly useful display.

Figure 1-2. Default display of an XML document

You can define the basics of the layout with display:

book, maintitle, subtitle, author, isbn {display: block;}
publisher, pubdate {display: inline;}

We’ve now set five of the seven elements to be block and two to be inline. This means each of the block elements will be treated much as div is treated in HTML, and the two inlines will be treated in a manner similar to span.

This fundamental ability to affect display roles makes CSS highly useful in a variety of situations. We could take the preceding rules as a starting point, add a few other styles for greater visual impact, and get the result shown in Figure 1-3.

Figure 1-3. Styled display of an XML document

Before learning how to write CSS in detail, we need to look at how one can associate CSS with a document. After all, without tying the two together, there’s no way for the CSS to affect the document. We’ll explore this in an HTML setting since it’s the most familiar.

The link Tag

First, consider the use of the link tag:

<link rel="stylesheet" type="text/css" href="sheet1.css" media="all">

The link tag is a little-regarded but nonetheless perfectly valid tag that has been hanging around the HTML specification for years, just waiting to be put to good use. Its basic purpose is to allow HTML authors to associate other documents with the document containing the link tag. CSS uses it to link stylesheets to the document; in Figure 1-5, a stylesheet called sheet1.css is linked to the document.

These stylesheets, which are not part of the HTML document but are still used by it, are referred to as external stylesheets. This is because they’re stylesheets that are external to the HTML document. (Go figure.)

To successfully load an external stylesheet, link should be placed inside the head element, though it can also appear inside the body element. This will cause the web browser to locate and load the stylesheet and use whatever styles it contains to render the HTML document in the manner shown in Figure 1-5. Also shown in Figure 1-5 is the loading of the external sheet2.css via the @import declaration. Imports must be placed at the beginning of the stylesheet that contains them, but they are otherwise unconstrained.

Figure 1-5. A representation of how external stylesheets are applied to documents

And what is the format of an external stylesheet? It’s a list of rules, just like those we saw in the previous section and in the example HTML document; but in this case, the rules are saved into their own file. Just remember that no HTML or any other markup language can be included in the stylesheet—only style rules. Here are the contents of an external stylesheet:

h1 {color: red;}
h2 {color: maroon; background: white;}
h3 {color: white; background: black;
 font: medium Helvetica;}

That’s all there is to it—no HTML markup or comments at all, just plain-and-simple style declarations. These are saved into a plain-text file and are usually given an extension of .css, as in sheet1.css.

The filename extension is not required, but some older browsers won’t recognize the file as containing a stylesheet unless it actually ends with .css, even if you do include the correct type of text/css in the link element. In fact, some web servers won’t hand over a file as text/css unless its filename ends with .css, though that can usually be fixed by changing the server’s configuration files.

<link rel="stylesheet" type="text/css" href="visual-sheet.css"
   media="screen, projection">

<link rel="stylesheet" type="text/css" href="basic.css">
<link rel="stylesheet" type="text/css" href="splash.css">

<link rel="stylesheet" type="text/css" href="basic.css">
<link rel="stylesheet" type="text/css" href="splash.css">

<p class="a1">This paragraph will be gray only if styles from the
stylesheet 'basic.css' are applied.</p>
<p class="b1">This paragraph will be gray only if styles from the
stylesheet 'splash.css' are applied.</p>

Alternate stylesheets

It’s also possible to define alternate stylesheets. These are defined by making the value of the rel attribute alternate stylesheet, and they are used in document presentation only if selected by the user.

Should a browser be able to use alternate stylesheets, it will use the values of the link element’s title attributes to generate a list of style alternatives. So you could write the following:

<link rel="stylesheet" type="text/css"
   href="sheet1.css" title="Default">
<link rel="alternate stylesheet" type="text/css"
   href="bigtext.css" title="Big Text">
<link rel="alternate stylesheet" type="text/css"
   href="zany.css" title="Crazy colors!">

Users could then pick the style they want to use, and the browser would switch from the first one, labeled “Default” in this case, to whichever the user picked. Figure 1-6 shows one way in which this selection mechanism might be accomplished (and in fact was, early in the resurgence of CSS).

Figure 1-6. A browser offering alternate stylesheet selection

Note

As of late 2016, alternate stylesheets were supported in most Gecko-based browsers like Firefox, and in Opera. They could be supported in the Internet Explorer family through the use of JavaScript but are not natively supported by those browsers. The WebKit family did not support selecting alternate stylesheets. Compare this to the age of the browser shown in Figure 1-6--it’s almost shocking.

It is also possible to group alternate stylesheets together by giving them the same title value. Thus, you make it possible for the user to pick a different presentation for your site in both screen and print media:

<link rel="stylesheet" type="text/css"
   href="sheet1.css" title="Default" media="screen">
<link rel="stylesheet" type="text/css"
   href="print-sheet1.css" title="Default" media="print">
<link rel="alternate stylesheet" type="text/css"
   href="bigtext.css" title="Big Text" media="screen">
<link rel="alternate stylesheet" type="text/css"
   href="print-bigtext.css" title="Big Text" media="print">

If a user selects “Big Text” from the alternate stylesheet selection mechanism in a conforming user agent, then bigtext.css will be used to style the document in the screen medium, and print-bigtext.css will be used in the print medium. Neither sheet1.css nor print-sheet1.css will be used in any medium.

Why is that? Because if you give a link with a rel of stylesheet a title, then you are designating that stylesheet as a preferred stylesheet. This means that its use is preferred to alternate stylesheets, and it will be used when the document is first displayed. Once you select an alternate stylesheet, however, the preferred stylesheet will not be used.

Furthermore, if you designate a number of stylesheets as preferred, then all but one of them will be ignored. Consider the following code example:

<link rel="stylesheet" type="text/css"
   href="sheet1.css" title="Default Layout">
<link rel="stylesheet" type="text/css"
   href="sheet2.css" title="Default Text Sizes">
<link rel="stylesheet" type="text/css"
   href="sheet3.css" title="Default Colors">

All three link elements now refer to preferred stylesheets, thanks to the presence of a title attribute on all three, but only one of them will actually be used in that manner. The other two will be ignored completely. Which two? There’s no way to be certain, as HTML doesn’t provide a method of determining which preferred stylesheets should be ignored and which should be used.

If you don’t give a stylesheet a title, then it becomes a persistent stylesheet and is always used in the display of the document. Often, this is exactly what an author wants.

The style Element

The style element is one way to include a stylesheet, and it appears in the document itself:

<style type="text/css">...</style>

style should always use the attribute type; in the case of a CSS document, the correct value is "text/css", just as it was with the link element.

The style element should always start with <style type="text/css">, as shown in the preceding example. This is followed by one or more styles and is finished with a closing </style> tag. It is also possible to give the style element a media attribute, which functions in the same manner as previously discussed for linked stylesheets.

The styles between the opening and closing style tags are referred to as the document stylesheet or the embedded stylesheet (because this kind of stylesheet is embedded within the document). It will contain many of the styles that will apply to the document, but it can also contain multiple links to external stylesheets using the @import directive.

The @import Directive

Now we’ll discuss the stuff that is found inside the style tag. First, we have something very similar to link: the @import directive:

@import url(sheet2.css);

Just like link, @import can be used to direct the web browser to load an external stylesheet and use its styles in the rendering of the HTML document. The only major difference is in the syntax and placement of the command. As you can see, @import is found inside the style container. It must be placed before the other CSS rules or it won’t work at all. Consider this example:

<style type="text/css">
@import url(styles.css); /* @import comes first */
h1 {color: gray;}
</style>

Like link, there can be more than one @import statement in a document. Unlike link, however, the stylesheets of every @import directive will be loaded and used; there is no way to designate alternate stylesheets with @import. So, given the following markup:

@import url(sheet2.css);
@import url(blueworld.css);
@import url(zany.css);

all three external stylesheets will be loaded, and all of their style rules will be used in the display of the document.

As with link, you can restrict imported stylesheets to one or more media by providing media descriptors after the stylesheet’s URL:

@import url(sheet2.css) all;
@import url(blueworld.css) screen;
@import url(zany.css) projection, print;

As noted in “The link Tag”, media descriptors can get quite complicated, and are explained in detail in Chapter 20, “Media-Dependent Styles”.

@import can be highly useful if you have an external stylesheet that needs to use the styles found in other external stylesheets. Since external stylesheets cannot contain any document markup, the link element can’t be used—but @import can. Therefore, you might have an external stylesheet that contains the following:

@import url(http://example.org/library/layout.css);
@import url(basic-text.css);
@import url(printer.css) print;
body {color: red;}
h1 {color: blue;}

Well, maybe not those exact styles, but hopefully you get the idea. Note the use of both absolute and relative URLs in the previous example. Either URL form can be used, just as with link.

Note also that the @import directives appear at the beginning of the stylesheet, as they did in the example document. CSS requires the @import directive to come before any other rules in a stylesheet. An @import that comes after other rules (e.g., body {color: red;}) will be ignored by conforming user agents.

HTTP Linking

There is another, far more obscure way to associate CSS with a document: you can link the two via HTTP headers.

Under Apache, this can be accomplished by adding a reference to the CSS file in a .htaccess file. For example:

Header add Link "</ui/testing.css>;rel=stylesheet;type=text/css"

This will cause supporting browsers to associate the referenced stylesheet with any documents served from under that .htaccess file. The browser will then treat it as if it were a linked stylesheet. Alternatively, and probably more efficiently, you can add an equivalent rule to the server’s httpd.conf file:

<Directory /path/to/ /public/html/directory>
Header add Link "</ui/testing.css>;rel=stylesheet;type=text/css"
</Directory>

The effect is exactly the same in supporting browsers. The only difference is in where you declare the linking.

You probably noticed the use of the term “supporting browsers.” As of late 2017, the widely used browsers that support HTTP linking of stylesheets are the Firefox family and Opera. That restricts this technique mostly to development environments based on one of those browsers. In that situation, you can use HTTP linking on the test server to mark when you’re on the development site as opposed to the public site. It’s also an interesting way to hide styles from the WebKit and Internet Explorer families, assuming you have a reason to do so.

Inline Styles

For cases where you want to just assign a few styles to one individual element, without the need for embedded or external stylesheets, employ the HTML attribute style to set an inline style:

<p style="color: gray;">The most wonderful of all breakfast foods is
the waffle—a ridged and cratered slab of home-cooked, fluffy goodness...
</p>

The style attribute can be associated with any HTML tag whatsoever, except for those tags that are found outside of body (head or title, for instance).

The syntax of a style attribute is fairly ordinary. In fact, it looks very much like the declarations found in the style container, except here the curly braces are replaced by double quotation marks. So <p style="color: maroon; background: yellow;"> will set the text color to be maroon and the background to be yellow for that paragraph only. No other part of the document will be affected by this declaration.

Note that you can only place a declaration block, not an entire stylesheet, inside an inline style attribute. Therefore, you can’t put an @import into a style attribute, nor can you include any complete rules. The only thing you can put into the value of a style attribute is what might go between the curly braces of a rule.

Use of the style attribute is not generally recommended. Indeed, it is very unlikely to appear in XML languages other than HTML. Many of the primary advantages of CSS—the ability to organize centralized styles that control an entire document’s appearance or the appearance of all documents on a web server—are negated when you place styles into a style attribute. In many ways, inline styles are not much better than the font tag, although they do have a good deal more flexibility in terms of what visual effects they can apply.

Markup

There is no markup in stylesheets. This might seem obvious, but you’d be surprised. The one exception is HTML comment markup, which is permitted inside style elements for historical reasons:

<style type="text/css"><!--
h1 {color: maroon;}
body {background: yellow;}
--></style>

That’s it.

Rule Structure

To illustrate the concept of rules in more detail, let’s break down the structure.

Each rule has two fundamental parts: the selector and the declaration block. The declaration block is composed of one or more declarations, and each declaration is a pairing of a property and a value. Every stylesheet is made up of a series of rules. Figure 1-7 shows the parts of a rule.

Figure 1-7. The structure of a rule

The selector, shown on the left side of the rule, defines which piece of the document will be affected. In Figure 1-7, h1 elements are selected. If the selector were p, then all p (paragraph) elements would be selected.

The right side of the rule contains the declaration block, which is made up of one or more declarations. Each declaration is a combination of a CSS property and a value of that property. In Figure 1-7, the declaration block contains two declarations. The first states that this rule will cause parts of the document to have a color of red, and the second states that part of the document will have a background of yellow. So, all of the h1 elements in the document (defined by the selector) will be styled in red text with a yellow background.

Vendor prefixing

Sometimes you’ll see pieces of CSS with dashes and labels in front of them, like this: -o-border-image. These are called vendor prefixes, and are a way for browser vendors to mark properties, values, or other bits of CSS as being experimental or proprietary (or both). As of late 2016, there were a few vendor prefixes in the wild, with the most common being shown in Table 1-1.

As Table 1-1 implies, the generally accepted format of a vendor prefix is a dash, a label, and a dash, although a few prefixes erroneously omit the first dash.

The uses and abuses of vendor prefixes are long, tortuous, and beyond the scope of this book. Suffice to say that they started out as a way for vendors to test out new features, thus helping speed interoperability without worrying about being locked into legacy behaviors that were incompatible with other browsers. This avoided a whole class of problems that nearly strangled CSS in its infancy. Unfortunately, prefixed properties were then publicly deployed by web authors and ended up causing a whole new class of problems.

As of late 2016, vendor prefixes are a dwindling breed, with old prefixed properties and values being slowly removed from browser implementations. It’s entirely possible that you’ll never write prefixed CSS, but you may encounter it in the wild, or inherit it in a legacy codebase.

Whitespace Handling

CSS is basically insensitive to whitespace between rules, and largely insensitive to whitespace within rules, although there are a few exceptions.

In general, CSS treats whitespace just like HTML does: any sequence of whitespace characters is collapsed to a single space for parsing purposes. Thus, you can format the hypothetical rainbow rule in the following ways:

rainbow: infrared  red  orange  yellow  green  blue  indigo  violet  ultraviolet;
rainbow:
   infrared  red  orange  yellow  green  blue  indigo  violet  ultraviolet;
rainbow:
   infrared
   red
   orange
   yellow
   green
   blue
   indigo
   violet
   ultraviolet
   ;

…as well as any other separation patterns you can think up. The only restriction is that the separating characters be whitespace: an empty space, a tab, or a newline, alone or in combination, as many as you like.

Similarly, you can format series of rules with whitespace in any fashion you like. These are just five of an effectively infinite number of possibilities:

html{color:black;}
body {background: white;}
p {
  color: gray;}
h2 {
     color : silver ;
   }
ol
   {
      color
         :
      silver
         ;
}

As you can see from the first rule, whitespace can be largely omitted. Indeed, this is usually the case with minified CSS, which is CSS that’s had every last possible bit of extraneous whitespace removed. The rules after the first two use progressively more extravagant amounts of whitespace until, in the last rule, pretty much everything that can be separated onto its own line has been.

All of these approaches are valid, so you should pick the formatting that makes the most sense—that is, is easiest to read—in your eyes, and stick with it.

There are some places where the presence of whitespace is actually required. The most common example is when separating a list of keywords in a value, as in the hypothetical rainbow examples. Those must always be whitespace-separated.

CSS Comments

CSS does allow for comments. These are very similar to C/C++ comments in that they are surrounded by /* and */:

/* This is a CSS1 comment */

Comments can span multiple lines, just as in C++:

/* This is a CSS1 comment, and it
can be several lines long without
any problem whatsoever. */

It’s important to remember that CSS comments cannot be nested. So, for example, this would not be correct:

/* This is a comment, in which we find
 another comment, which is WRONG
   /* Another comment */
 and back to the first comment */

Unfortunately, there is no “rest of the line” comment pattern such as // or # (the latter of which is reserved for ID selectors anyway). The only comment pattern in CSS is /* */. Therefore, if you wish to place comments on the same line as markup, then you need to be careful about how you place them. For example, this is the correct way to do it:

h1 {color: gray;}   /* This CSS comment is several lines */
h2 {color: silver;} /* long, but since it is alongside */
p {color: white;}   /* actual styles, each line needs to */
pre {color: gray;}  /* be wrapped in comment markers. */

Given this example, if each line isn’t marked off, then most of the stylesheet will become part of the comment and thus will not work:

h1 {color: gray;}   /* This CSS comment is several lines
h2 {color: silver;}  long, but since it is not wrapped
p {color: white;}    in comment markers, the last three
pre {color: gray;}   styles are part of the comment. */

In this example, only the first rule (h1 {color: gray;}) will be applied to the document. The rest of the rules, as part of the comment, are ignored by the browser’s rendering engine.

Usage

Media queries can be employed in the following places:

• The media attribute of a link element

• The media attribute of a style element

• The media descriptor portion of an @import declaration

• The media descriptor portion of an @media declaration

Queries can range from simple media types to complicated combinations of media types and features.

Simple Media Queries

Let’s look at some simple media blocks before covering all of the possibilities of media queries. Suppose we want some differing styles for situations where the styles are shown in a projection setting, such as a slide show. Here are two very simple bits of CSS:

h1 {color: maroon;}
@media projection {
   body {background: yellow;}
}

In this example, h1 elements will be colored maroon in all media, but the body element will get a yellow background only in a projection medium.

You can have as many @media blocks as you like in a given stylesheet, each with its own set of media descriptors (see later in this chapter for details). You could even encapsulate all of your rules in an @media block if you chose, like this:

@media all {
   h1 {color: maroon;}
   body {background: yellow;}
}

However, since this is exactly the same as if you stripped off the first and last line shown, there isn’t a whole lot of point to doing so.

The place where we saw projection and all in those examples is where media queries are set. These queries rely on a combination of terms that describe the type of media to be considered, as well as descriptions of the media’s parameters (e.g., resolution or display height), to determine when blocks of CSS should be applied.

Media Types

The most basic form of media queries are media types, which first appeared in CSS2. These are simple labels for different kinds of media:

all

Use in all presentational media.

print

Use when printing the document for sighted users and also when displaying a print preview of the document.

screen

Use when presenting the document in a screen medium like a desktop computer monitor. All web browsers running on such systems are screen-medium user agents.

Multiple media types can be specified using a comma-separated list. The following four examples are all equivalent ways of applying a stylesheet (or a block of rules) in both screen and print media:

<link type="text/css" href="frobozz.css" media="screen, print">
<style type="text/css" media="screen, print">...</style>

@import url(frobozz.css) screen, print;
@media screen, print {...}

Things get interesting when you add feature-specific descriptors, such as values that describe the resolution or color depth of a given medium, to these media types.

Media Descriptors

The placement of media queries will be very familiar to any author who has ever set a media type on a link element or an @import declaration. Here are two essentially equivalent ways of applying an external stylesheet when rendering the document on a color printer:

<link href="print-color.css" type="text/css"
   media="print and (color)" rel="stylesheet">

@import url(print-color.css) print and (color);

Anywhere a media type can be used, a media query can be used. This means that, following on the examples of the previous section, it is possible to list more than one query in a comma-separated list:

<link href="print-color.css" type="text/css"
   media="print and (color), screen and (min-color: 8)" rel="stylesheet">

@import url(print-color.css) print and (color), screen and (min-color: 8);

In any situation where even one of the media queries evaluates to “true,” the associated stylesheet is applied. Thus, given the previous @import, print-color.css will be applied if rendering to a color printer or to a sufficiently colorful screen environment. If printing on a black-and-white printer, both queries will evaluate to “false”, and print-color.css will not be applied to the document. The same holds true in any screen medium, and so on.

Each media descriptor is composed of a media type and one or more listed media features, with each media feature descriptor enclosed in parentheses. If no media type is provided, then it is assumed to be all, which makes the following two examples equivalent:

@media all and (min-resolution: 96dpi) {...}

@media (min-resolution: 96dpi) {...}

Generally speaking, a media feature descriptor is formatted like a property-value pair in CSS. There are a few differences, most notably that some features can be specified without an accompanying value. Thus, for example, any color-based medium will be matched using (color), whereas any color medium using a 16-bit color depth is matched using (color: 16). In effect, the use of a descriptor without a value is a true/false test for that descriptor: (color) means “is this medium in color?”

Multiple feature descriptors can be linked with the and logical keyword. In fact, there are two logical keywords in media queries:

and

Links together two or more media features in such a way that all of them must be true for the query to be true. For example, (color) and (orientation: landscape) and (min-device-width: 800px) means that all three conditions must be satisfied: if the media environment has color, is in landscape orientation, and the device’s display is at least 800 pixels wide, then the stylesheet is used.

not

Negates the entire query such that if all of the conditions are true, then the stylesheet is not applied. For example, not (color) and (orientation: landscape) and (min-device-width: 800px) means that if the three conditions are satisfied, the statement is negated. Thus, if the media environment has color, is in landscape orientation, and the device’s display is at least 800 pixels wide, then the stylesheet is not used. In all other cases, it will be used.

Note that the not keyword can only be used at the beginning of a media query. It is not legal to write something like (color) and not (min-device-width: 800px). In such cases, the query will be ignored. Note also that browsers too old to understand media queries will always skip a stylesheet whose media descriptor starts with not.

There is no OR keyword for use in media queries. Instead, the commas that separate a list of queries serve the function of an OR—screen, print means “apply if the media is screen or print.” Instead of screen and (max-color: 2) or (monochrome), which is invalid and thus ignored, you should write screen and (max-color: 2), screen and (monochrome).

There is one more keyword, only, which is designed to create deliberate backward incompatibility (yes, really):

only

Used to hide a stylesheet from browsers too old to understand media queries. For example, to apply a stylesheet in all media, but only in those browsers that understand media queries, you write something like @import url(new.css) only all. In browsers that do understand media queries, the only keyword is ignored and the stylesheet is applied. In browsers that do not understand media queries, the only keyword creates an apparent media type of only all, which is not valid. Thus, the stylesheet is not applied in such browsers. Note that the only keyword can only be used at the beginning of a media query.

Media Feature Descriptors and Value Types

So far we’ve seen a number of media feature descriptors in the examples, but not a complete list. Following is a list of all possible descriptors (current as of late 2017):

• width

• min-width

• max-width

• device-width

• min-device-width

• max-device-width

• height

• min-height

• max-height

• device-height

• min-device-height

• max-device-height

• aspect-ratio

• min-aspect-ratio

• max-aspect-ratio

• device-aspect-ratio

• min-device-aspect-ratio

• max-device-aspect-ratio

• color

• min-color

• max-color

• color-index

• min-color-index

• max-color-index

• monochrome

• min-monochrome

• max-monochrome

• resolution

• min-resolution

• max-resolution

• orientation

• scan

• grid

In addition, two new value types were added:

• <ratio>

• <resolution>

A complete description of these descriptors and values, and how to use them, can be found in Chapter 20.

Element Selectors

An element selector is most often an HTML element, but not always. For example, if a CSS file contains styles for an XML document, the element selectors might look something like this:

quote {color: gray;}
bib {color: red;}
booktitle {color: purple;}
myElement {color: red;}

In other words, the elements of the document serve as the most basic selectors. In XML, a selector could be anything, since XML allows for the creation of new markup languages that can have just about anything as an element name. If you’re styling an HTML document, on the other hand, the selector will generally be one of the many HTML elements such as p, h3, em, a, or even html itself. For example:

html {color: black;}
h1 {color: gray;}
h2 {color: silver;}

The results of this stylesheet are shown in Figure 2-1.

Figure 2-1. Simple styling of a simple document

Once you’ve globally applied styles directly to elements, you can shift those styles from one element to another. Let’s say you decide that the paragraph text, not the h1 elements, in Figure 2-1 should be gray. No problem. Just change the h1 selector to p:

html {color: black;}
p {color: gray;}
h2 {color: silver;}

The results are shown in Figure 2-2.

Figure 2-2. Moving a style from one element to another

Declarations and Keywords

The declaration block contains one or more declarations. A declaration is always formatted as a property followed by a colon and then a value followed by a semicolon. The colon and semicolon can be followed by zero or more spaces. In nearly all cases, a value is either a single keyword or a space-separated list of one or more keywords that are permitted for that property. If you use an incorrect property or value in a declaration, the whole rule will be ignored. Thus, the following two declarations would fail:

brain-size: 2cm;     /* unknown property 'brain-size' */
color: ultraviolet;  /* unknown value 'ultraviolet' */

In an instance where you can use more than one keyword for a property’s value, the keywords are usually separated by spaces, with some cases requiring slashes (/) or commas. Not every property can accept multiple keywords, but many, such as the font property, can. Let’s say you want to define medium-sized Helvetica for paragraph text, as illustrated in Figure 2-3.

Figure 2-3. The results of a property value with multiple keywords

The rule would read as follows:

p {font: medium Helvetica;}

Note the space between medium and Helvetica, each of which is a keyword (the first is the font’s size and the second is the actual font name). The space allows the user agent to distinguish between the two keywords and apply them correctly. The semicolon indicates that the declaration has been concluded.

These space-separated words are referred to as keywords because, taken together, they form the value of the property in question. For instance, consider the following fictional rule:

rainbow: red orange yellow green blue indigo violet;

There is no such property as rainbow, but the example is useful for illustrative purposes. The value of rainbow is red orange yellow green blue indigo violet, and the seven keywords add up to a single, unique value. We can redefine the value for rainbow as follows:

rainbow: infrared red orange yellow green blue indigo violet ultraviolet;

Now we have a new value for rainbow composed of nine keywords instead of seven. Although the two values look mostly the same, they are as unique and different as zero and one. This may seem an abstract point, but it’s critical to understanding some of the subtler effects of specificity and the cascade (covered later in this book).

As we’ve seen, CSS keywords are usually separated by spaces. In CSS2.1 there was one exception: in the CSS property font, there is exactly one place where a forward slash (/) could be used to separate two specific keywords. Here’s an example:

h2 {font: large/150% sans-serif;}

The slash separates the keywords that set the element’s font size and line height. This is the only place the slash is allowed to appear in the font declaration. All of the other keywords allowed for font are separated by spaces.

The slash has since worked its way into a number of other properties’ values. These include, but may not always be limited to the following:

• background

• border-image

• border-radius

• grid

• grid-area

• grid-column

• grid-row

• grid-template

• mask-border

There are also some keywords that are separated by commas. When declaring multiple values, such as multiple background images, transition properties, and shadows, the declarations are separated with commas. Additionally, parameters in functions, such as linear gradients and transforms, are comma separated, as the following example shows:

.box {box-shadow: inset -1px -1px white,
                  3px 3px 3px rgba(0,0,0,0.2);
      background-image: url(myimage.png),
          linear-gradient(180deg, #FFF 0%, #000 100%);
      transform: translate(100px, 200px);
}
a:hover {transition: color, background-color 200ms ease-in 50ms;}

Those are the basics of simple declarations, but they can get much more complex. The next section begins to show you just how powerful CSS can be.

Grouping Selectors

Let’s say you want both h2 elements and paragraphs to have gray text. The easiest way to accomplish this is to use the following declaration:

h2, p {color: gray;}

By placing the h2 and p selectors on the left side of the rule and separating them with a comma, you’ve defined a rule where the style on the right (color: gray;) applies to the elements referenced by both selectors. The comma tells the browser that there are two different selectors involved in the rule. Leaving out the comma would give the rule a completely different meaning, which we’ll explore in “Descendant Selectors”.

There are really no limits to how many selectors you can group together. For example, if you want to display a large number of elements in gray, you might use something like the following rule:

body, table, th, td, h1, h2, h3, h4, p, pre, strong, em, b, i {color: gray;}

Grouping allows an author to drastically compact certain types of style assignments, which makes for a shorter stylesheet. The following alternatives produce exactly the same result, but it’s pretty obvious which one is easier to type:

h1 {color: purple;}
h2 {color: purple;}
h3 {color: purple;}
h4 {color: purple;}
h5 {color: purple;}
h6 {color: purple;}

h1, h2, h3, h4, h5, h6 {color: purple;}

Grouping allows for some interesting choices. For example, all of the groups of rules in the following example are equivalent—each merely shows a different way of grouping both selectors and declarations:

/* group 1 */
h1 {color: silver; background: white;}
h2 {color: silver; background: gray;}
h3 {color: white; background: gray;}
h4 {color: silver; background: white;}
b {color: gray; background: white;}

/* group 2 */
h1, h2, h4 {color: silver;}
h2, h3 {background: gray;}
h1, h4, b {background: white;}
h3 {color: white;}
b {color: gray;}

/* group 3 */
h1, h4 {color: silver; background: white;}
h2 {color: silver;}
h3 {color: white;}
h2, h3 {background: gray;}
b {color: gray; background: white;}

Any of these will yield the result shown in Figure 2-4. (These styles use grouped declarations, which are explained in “Grouping Declarations”.)

Figure 2-4. The result of equivalent stylesheets

* {color: red;}

Grouping Declarations

Since you can group selectors together into a single rule, it follows that you can also group declarations. Assuming that you want all h1 elements to appear in purple, 18-pixel-high Helvetica text on an aqua background (and you don’t mind blinding your readers), you could write your styles like this:

h1 {font: 18px Helvetica;}
h1 {color: purple;}
h1 {background: aqua;}

But this method is inefficient—imagine creating such a list for an element that will carry 10 or 15 styles! Instead, you can group your declarations together:

h1 {font: 18px Helvetica; color: purple; background: aqua;}

This will have exactly the same effect as the three-line stylesheet just shown.

Note that using semicolons at the end of each declaration is crucial when you’re grouping them. Browsers ignore whitespace in stylesheets, so the user agent must rely on correct syntax to parse the stylesheet. You can fearlessly format styles like the following:

h1 {
  font: 18px Helvetica;
  color: purple;
  background: aqua;
}

You can also minimize your CSS, removing all non-required spaces.

h1{font:18px Helvetica;color:purple;background:aqua;}

Ignoring whitespace, the last three are treated equally by the server, but the second one is most human readable, and the recommended method of marking up your CSS during development. (You might choose to minimize your CSS for network-performance reasons, but this is usually handled by a server-side script, caching network, or other service.)

If the semicolon is omitted on the second statement, the user agent will interpret the stylesheet as follows:

h1 {
  font: 18px Helvetica;
  color: purple background: aqua;
}

Because background: is not a valid value for color, and because color can be given only one keyword, a user agent will ignore the color declaration (including the background: aqua part) entirely. You might think the browser would at least render h1s as purple text without an aqua background, but not so. Instead, they will be the default color (which is usually black) with a transparent background (which is also a default). The declaration font: 18px Helvetica will still take effect since it was correctly terminated with a semicolon.

As with selector grouping, declaration grouping is a convenient way to keep your stylesheets short, expressive, and easy to maintain.

Grouping Everything

You now know that you can group selectors and you can group declarations. By combining both kinds of grouping in single rules, you can define very complex styles using only a few statements. Now, what if you want to assign some complex styles to all the headings in a document, and you want the same styles to be applied to all of them? Here’s how to do it:

h1, h2, h3, h4, h5, h6 {color: gray; background: white; padding: 0.5em;
  border: 1px solid black; font-family: Charcoal, sans-serif;}

Here we’ve grouped the selectors, so the styles on the right side of the rule will be applied to all the headings listed; grouping the declarations means that all of the listed styles will be applied to the selectors on the left side of the rule. The result of this rule is shown in Figure 2-5.

Figure 2-5. Grouping both selectors and rules

This approach is preferable to the drawn-out alternative, which would begin with something like this:

h1 {color: gray;}
h2 {color: gray;}
h3 {color: gray;}
h4 {color: gray;}
h5 {color: gray;}
h6 {color: gray;}
h1 {background: white;}
h2 {background: white;}
h3 {background: white;}

and continue for many lines. You can write out your styles the long way, but I wouldn’t recommend it—editing them would be as tedious as using style attributes everywhere!

It’s possible to add even more expression to selectors and to apply styles in a way that cuts across elements in favor of types of information. To get something so powerful, you’ll have to do a little work in return, but it’s well worth it.

New Elements in Old Browsers

With updates to HTML, such as the HTML5 specification, new elements have come into being. Some browsers predate these newer elements, and so don’t recognize them. Versions of Internet Explorer prior to IE9, for example, did not support selecting elements they did not understand. The solution was to create the element in the DOM, thereby informing the browser that said element exists.

For example, IE8 does not recognize the <main> element. The following JavaScript line informs IE8 of main’s existence:

document.createElement('main');

By running that line of code, older versions of Internet Explorer will recognize the existence of the element, allowing it to be selected and styled.

Class Selectors

The most common way to apply styles without worrying about the elements involved is to use class selectors. Before you can use them, however, you need to modify your actual document markup so that the class selectors will work. Enter the class attribute:

<p class="warning">When handling plutonium, care must be taken to avoid
the formation of a critical mass.</p>
<p>With plutonium, <span class="warning">the possibility of implosion is
very real, and must be avoided at all costs</span>. This can be accomplished
by keeping the various masses separate.</p>

To associate the styles of a class selector with an element, you must assign a class attribute the appropriate value. In the previous code block, a class value of warning was assigned to two elements: the first paragraph and the span element in the second paragraph.

All you need now is a way to apply styles to these classed elements. In HTML documents, you can use a compact notation where the name of a class is preceded by a period (.) and can be joined with an element selector:

.warning {font-weight: bold;}

When combined with the example markup shown earlier, this simple rule has the effect shown in Figure 2-6. That is, the declaration font-weight: bold will be applied to every element (thanks to the presence of the implicit universal selector) that carries a class attribute with a value of warning.

Figure 2-6. Using a class selector

As you can see, the class selector works by directly referencing a value that will be found in the class attribute of an element. This reference is always preceded by a period (.), which marks it as a class selector. The period helps keep the class selector separate from anything with which it might be combined—such as an element selector. For example, you may want boldface text only when an entire paragraph is a warning:

p.warning {font-weight: bold;}

The selector now matches any p elements that have a class attribute containing the word warning, but no other elements of any kind, classed or otherwise. Since the span element is not a paragraph, the rule’s selector doesn’t match it, and it won’t be displayed using boldfaced text.

If you did want to assign different styles to the span element, you could use the selector span.warning:

p.warning {font-weight: bold;}
span.warning {font-style: italic;}

In this case, the warning paragraph is boldfaced, while the warning span is italicized. Each rule applies only to a specific type of element/class combination, so it does not leak over to other elements.

Another option is to use a combination of a general class selector and an element-specific class selector to make the styles even more useful, as in the following markup:

.warning {font-style: italic;}
span.warning {font-weight: bold;}

The results are shown in Figure 2-7.

Figure 2-7. Using generic and specific selectors to combine styles

In this situation, any warning text will be italicized, but only the text within a span element with a class of warning will be both boldfaced and italicized.

Notice the format of the general class selector in the previous example: it’s a class name preceded by a period without any element name, and no universal selector. In cases where you only want to select all elements that share a class name, you can omit the universal selector from a class selector without any ill effects.

Multiple Classes

In the previous section, we dealt with class values that contained a single word. In HTML, it’s possible to have a space-separated list of words in a single class value. For example, if you want to mark a particular element as being both urgent and a warning, you could write:

<p class="urgent warning">When handling plutonium, care must be taken to
avoid the formation of a critical mass.</p>
<p>With plutonium, <span class="warning">the possibility of implosion is
very real, and must be avoided at all costs</span>. This can be accomplished
by keeping the various masses separate.</p>

The order of the words doesn’t matter; warning urgent would also suffice and would yield precisely the same results no matter how the CSS class attribute is written.

Now let’s say you want all elements with a class of warning to be boldfaced, those with a class of urgent to be italic, and those elements with both values to have a silver background. This would be written as follows:

.warning {font-weight: bold;}
.urgent {font-style: italic;}
.warning.urgent {background: silver;}

By chaining two class selectors together, you can select only those elements that have both class names, in any order. As you can see, the HTML source contains class="urgent warning" but the CSS selector is written .warning.urgent. Regardless, the rule will still cause the “When handling plutonium . . . ” paragraph to have a silver background, as illustrated in Figure 2-8. This happens because the order the words are written in doesn’t matter. (This is not to say the order of classes is always irrelevant, but we’ll get to that later in the book.)

Figure 2-8. Selecting elements with multiple class names

If a multiple class selector contains a name that is not in the space-separated list, then the match will fail. Consider the following rule:

p.warning.help {background: red;}

As you would expect, the selector will match only those p elements with a class containing the words warning and help. Therefore, it will not match a p element with just the words warning and urgent in its class attribute. It would, however, match the following:

<p class="urgent warning help">Help me!</p>

ID Selectors

In some ways, ID selectors are similar to class selectors, but there are a few crucial differences. First, ID selectors are preceded by an octothorpe (#)—also known as a pound sign (in the US), hash sign, hash mark, or tic-tac-toe board—instead of a period. Thus, you might see a rule like this one:

*#first-para {font-weight: bold;}

This rule produces boldfaced text in any element whose id attribute has a value of first-para.

The second difference is that instead of referencing values of the class attribute, ID selectors refer, unsurprisingly, to values found in id attributes. Here’s an example of an ID selector in action:

*#lead-para {font-weight: bold;}

<p id="lead-para">This paragraph will be boldfaced.</p>
<p>This paragraph will NOT be bold.</p>

Note that the value lead-para could have been assigned to any element within the document. In this particular case, it is applied to the first paragraph, but we could have applied it just as easily to the second or third paragraph. Or an unordered list. Or anything.

As with class selectors, it is possible to omit the universal selector from an ID selector. In the previous example, we could also have written:

#lead-para {font-weight: bold;}

The effect of this selector would be the same.

Another similarity between classes and IDs is that IDs can be selected independently of an element. There may be circumstances in which you know that a certain ID value will appear in a document, but you don’t know the element on which it will appear (as in the plutonium-handling warnings), so you’ll want to declare standalone ID selectors. For example, you may know that in any given document, there will be an element with an ID value of mostImportant. You don’t know whether that most important thing will be a paragraph, a short phrase, a list item, or a section heading. You know only that it will exist in each document, occur in an arbitrary element, and appear no more than once. In that case, you would write a rule like this:

#mostImportant {color: red; background: yellow;}

This rule would match any of the following elements (which, as noted before, should not appear together in the same document because they all have the same ID value):

<h1 id="mostImportant">This is important!</h1>
<em id="mostImportant">This is important!</em>
<ul id="mostImportant">This is important!</ul>

Deciding Between Class and ID

You may assign classes to any number of elements, as demonstrated earlier; the class name warning was applied to both a p and a span element, and it could have been applied to many more elements. IDs, on the other hand, should be used once, and only once, within an HTML document. Therefore, if you have an element with an id value of lead-para, no other element in that document should have an id value of lead-para.

Unlike class selectors, ID selectors can’t be combined with other IDs, since ID attributes do not permit a space-separated list of words.

Another difference between class and id names is that IDs carry more weight when you’re trying to determine which styles should be applied to a given element. This will be explained in greater detail in the next chapter.

Also note that class and ID selectors may be case-sensitive, depending on the document language. HTML defines class and ID values to be case-sensitive, so the capitalization of your class and ID values must match that found in your documents. Thus, in the following pairing of CSS and HTML, the element’s text will not be boldfaced:

p.criticalInfo {font-weight: bold;}

<p class="criticalinfo">Don't look down.</p>

Because of the change in case for the letter i, the selector will not match the element shown.

On a purely syntactical level, the dot-class notation (e.g., .warning) is not guaranteed to work for XML documents. As of this writing, the dot-class notation works in HTML, SVG, and MathML, and it may well be permitted in future languages, but it’s up to each language’s specification to decide that. The hash-ID notation (e.g., #lead) will work in any document language that has an attribute that enforces uniqueness within a document. Uniqueness can be enforced with an attribute called id, or indeed anything else, as long as the attribute’s contents are defined to be unique within the document.

Simple Attribute Selectors

If you want to select elements that have a certain attribute, regardless of that attribute’s value, you can use a simple attribute selector. For example, to select all h1 elements that have a class attribute with any value and make their text silver, write:

h1[class] {color: silver;}

So, given the following markup:

<h1 class="hoopla">Hello</h1>
<h1>Serenity</h1>
<h1 class="fancy">Fooling</h1>

you get the result shown in Figure 2-9.

Figure 2-9. Selecting elements based on their attributes

This strategy is very useful in XML documents, as XML languages tend to have element and attribute names that are specific to their purpose. Consider an XML language that is used to describe planets of the solar system (we’ll call it PlanetML). If you want to select all pml-planet elements with a moons attribute and make them boldface, thus calling attention to any planet that has moons, you would write:

pml-planet[moons] {font-weight: bold;}

This would cause the text of the second and third elements in the following markup fragment to be boldfaced, but not the first:

<pml-planet>Venus</pml-planet>
<pml-planet moons="1">Earth</pml-planet>
<pml-planet moons="2">Mars</pml-planet>

In HTML documents, you can use this feature in a number of creative ways. For example, you could style all images that have an alt attribute, thus highlighting those images that are correctly formed:

img[alt] {border: 3px solid red;}

(This particular example is generally useful more for diagnostic purposes—that is, determining whether images are indeed correctly marked up—than for design purposes.)

If you wanted to boldface any element that includes title information, which most browsers display as a “tool tip” when a cursor hovers over the element, you could write:

*[title] {font-weight: bold;}

Similarly, you could style only those anchors (a elements) that have an href attribute, thus applying the styles to any hyperlink but not to any placeholder anchors.

It is also possible to select based on the presence of more than one attribute. You do this by chaining the attribute selectors together. For example, to boldface the text of any HTML hyperlink that has both an href and a title attribute, you would write:

a[href][title] {font-weight: bold;}

This would boldface the first link in the following markup, but not the second or third:

<a href="http://www.w3.org/" title="W3C Home">W3C</a><br />
<a href="http://www.webstandards.org">Standards Info</a><br />
<a title="Not a link">dead.letter</a>

Selection Based on Exact Attribute Value

You can further narrow the selection process to encompass only those elements whose attributes are a certain value. For example, let’s say you want to boldface any hyperlink that points to a certain document on the web server. This would look something like:

a[href="http://www.css-discuss.org/about.html"] {font-weight: bold;}

This will boldface the text of any a element that has an href attribute with exactly the value http://www.css-discuss.org/about.html. Any change at all, even dropping the www. part or changing to a secure protocol with https, will prevent a match.

Any attribute and value combination can be specified for any element. However, if that exact combination does not appear in the document, then the selector won’t match anything. Again, XML languages can benefit from this approach to styling. Let’s return to our PlanetML example. Suppose you want to select only those planet elements that have a value of 1 for the attribute moons:

planet[moons="1"] {font-weight: bold;}

This would boldface the text of the second element in the following markup fragment, but not the first or third:

<planet>Venus</planet>
<planet moons="1">Earth</planet>
<planet moons="2">Mars</planet>

As with attribute selection, you can chain together multiple attribute-value selectors to select a single document. For example, to double the size of the text of any HTML hyperlink that has both an href with a value of http://www.w3.org/ and a title attribute with a value of W3C Home, you would write:

a[href="http://www.w3.org/"][title="W3C Home"] {font-size: 200%;}

This would double the text size of the first link in the following markup, but not the second or third:

<a href="http://www.w3.org/" title="W3C Home">W3C</a><br />
<a href="http://www.webstandards.org"
  title="Web Standards Organization">Standards Info</a><br />
<a href="http://www.example.org/" title="W3C Home">dead.link</a>

The results are shown in Figure 2-10.

Figure 2-10. Selecting elements based on attributes and their values

Again, this format requires an exact match for the attribute’s value. Matching becomes an issue when the selector form encounters values that can in turn contain a space-separated list of values (e.g., the HTML attribute class). For example, consider the following markup fragment:

<planet type="barren rocky">Mercury</planet>

The only way to match this element based on its exact attribute value is to write:

planet[type="barren rocky"] {font-weight: bold;}

If you were to write planet[type="barren"], the rule would not match the example markup and thus would fail. This is true even for the class attribute in HTML. Consider the following:

<p class="urgent warning">When handling plutonium, care must be taken to
avoid the formation of a critical mass.</p>

To select this element based on its exact attribute value, you would have to write:

p[class="urgent warning"] {font-weight: bold;}

This is not equivalent to the dot-class notation covered earlier, as we will see in the next section. Instead, it selects any p element whose class attribute has exactly the value "urgent warning", with the words in that order and a single space between them. It’s effectively an exact string match.

Also, be aware that ID selectors and attribute selectors that target the id attribute are not precisely the same. In other words, there is a subtle but crucial difference between h1#page-title and h1[id="page-title"]. This difference is explained in “Specificity”.

Selection Based on Partial Attribute Values

Odds are that you’ll want to select elements based on portions of their attribute values, rather than the full value. For such situations, CSS actually offers a variety of options for matching substrings in an attribute’s value. These are summarized in Table 2-1.

The last of these attribute selectors that match on a partial subset of an element’s attribute value is actually easier to show than it is to describe. Consider the following rule:

*[lang|="en"] {color: white;}

This rule will select any element whose lang attribute is equal to en or begins with en-. Therefore, the first three elements in the following example markup would be selected, but the last two would not:

<h1 lang="en">Hello!</h1>
<p lang="en-us">Greetings!</p>
<div lang="en-au">G'day!</div>
<p lang="fr">Bonjour!</p>
<h4 lang="cy-en">Jrooana!</h4>

In general, the form [att|="val"] can be used for any attribute and its values. Let’s say you have a series of figures in an HTML document, each of which has a filename like figure-1.gif and figure-3.jpg. You can match all of these images using the following selector:

img[src|="figure"] {border: 1px solid gray;}

Or, if you’re creating a CSS framework or pattern library, instead of creating redundant classes like "btn btn-small btn-arrow btn-active", you can declare "btn-small-arrow-active", and target the class of elements with:

*[class|="btn"] { border-radius: 5px;}

<button class="btn-small-arrow-active">Click Me</button>

The most common use for this type of attribute selector is to match language values, as demonstrated in an upcoming section, “The :lang Pseudo-Class”.

Matching one word in a space-separated list

For any attribute that accepts a space-separated list of words, it is possible to select elements based on the presence of any one of those words. The classic example in HTML is the class attribute, which can accept one or more words as its value. Consider our usual example text:

<p class="urgent warning">When handling plutonium, care must be taken to
avoid the formation of a critical mass.</p>

Let’s say you want to select elements whose class attribute contains the word warning. You can do this with an attribute selector:

p[class~="warning"] {font-weight: bold;}

Note the presence of the tilde (~) in the selector. It is the key to selection based on the presence of a space-separated word within the attribute’s value. If you omit the tilde, you would have an exact value-matching attribute selector, as discussed in the previous section.

This selector construct is equivalent to the dot-class notation discussed in “Deciding Between Class and ID”. Thus, p.warning and p[class~="warning"] are equivalent when applied to HTML documents. Here’s an example that is an HTML version of the “PlanetML” markup seen earlier:

<span class="barren rocky">Mercury</span>
<span class="cloudy barren">Venus</span>
<span class="life-bearing cloudy">Earth</span>

To italicize all elements with the word barren in their class attribute, you write:

span[class~="barren"] {font-style: italic;}

This rule’s selector will match the first two elements in the example markup and thus italicize their text, as shown in Figure 2-11. This is the same result we would expect from writing span.barren {font-style: italic;}.

Figure 2-11. Selecting elements based on portions of attribute values

So why bother with the tilde-equals attribute selector in HTML? Because it can be used for any attribute, not just class. For example, you might have a document that contains a number of images, only some of which are figures. You can use a partial-match value attribute selector aimed at the title text to select only those figures:

img[title~="Figure"] {border: 1px solid gray;}

This rule selects any image whose title text contains the word Figure. Therefore, as long as all your figures have title text that looks something like “Figure 4. A bald-headed elder statesman,” this rule will match those images. For that matter, the selector img[title~="Figure"] will also match a title attribute with the value “How to Figure Out Who’s in Charge.” Any image that does not have a title attribute, or whose title value doesn’t contain the word “Figure,” won’t be matched.

Matching a substring within an attribute value

Sometimes you want to select elements based on a portion of their attribute values, but the values in question aren’t space-separated lists of words. In these cases, you can use the form [att*="val"] to match substrings that appear anywhere inside the attribute values. For example, the following CSS matches any span element whose class attribute contains the substring cloud, so both “cloudy” planets are matched, as shown in Figure 2-12:

span[class*="cloud"] {font-style: italic;}

<span class="barren rocky">Mercury</span>
<span class="cloudy barren">Venus</span>
<span class="life-bearing cloudy">Earth</span>

Figure 2-12. Selecting elements based on substrings within attribute values

As you can imagine, there are many useful applications for this particular capability. For example, suppose you wanted to specially style any links to the O’Reilly website. Instead of classing them all and writing styles based on that class, you could instead write the following rule:

a[href*="oreilly.com"] {font-weight: bold;}

You aren’t confined to the class and href attributes. Any attribute is up for grabs here: title, alt, src, id…if the attribute has a value, you can style based on a substring within that value. The following rule draws attention to any image with the string “space” in its source URL:

img[src*="space"] {border: 5px solid red;}

Similarly, the following rule draws attention to input elements that have a title tells the user what to, and any other input whose title contains the substring “format” in its title:

input[title*="format"] {background-color: #dedede;}

<input type="tel"
    title="Telephone number should be formatted as XXX-XXX-XXXX"
    pattern="\d{3}\-\d{3}\-\d{4}">

A common use for the general substring attribute selector is to match a section of a class in pattern library class names. Elaborating on the last example, we can target any class name that starts with "btn" followed by a dash, and that contains the substring “arrow” preceded by a dash:

*[class|="btn"][class*="-arrow"]:after { content: "▼";}

<button class="btn-small-arrow-active">Click Me</button>

The matches are exact: if you include whitespace in your selector, then whitespace must also be present in an attribute’s value. The attribute names and values must be case-sensitive only if the underlying document language requires case sensitivity. Class names, titles, URLs, and ID values are all case-sensitive, but HTML attribute keyterm values, such as input types, are not:

input[type="CHeckBoX"] {margin-right: 10px;}

<input type="checkbox" name="rightmargin" value="10px">

Matching a substring at the beginning of an attribute value

In cases where you want to select elements based on a substring at the beginning of an attribute value, then the attribute selector pattern [att^="val"] is what you’re seeking. This can be particularly useful in a situation where you want to style types of links differently, as illustrated in Figure 2-13.

a[href^="https:"] {font-weight: bold;}
a[href^="mailto:"] {font-style: italic;}

Figure 2-13. Selecting elements based on substrings that begin attribute values

Another use case is when you want to style all images in an article that are also figures, as in the figures you see throughout this text. Assuming that the alt text of each figure begins with text in the pattern “Figure 5”—which is an entirely reasonable assumption in this case—then you can select only those images as follows:

img[alt^="Figure"] {border: 2px solid gray;  display: block; margin: 2em auto;}

The potential drawback here is that any img element whose alt starts with “Figure” will be selected, whether or not it’s meant to be an illustrative figure. The likeliness of that occurring depends on the document in question.

Another use case is selecting all of the calendar events that occur on Mondays. In this case, let’s assume all of the events have a title attribute containing a date in the format “Monday, March 5th, 2012.” Selecting them all is a simple matter of [title^="Monday"].

Matching a substring at the end of an attribute value

The mirror image of beginning-substring matching is ending-substring matching, which is accomplished using the [att$="val"] pattern. A very common use for this capability is to style links based on the kind of resource they target, such as separate styles for PDF documents, as illustrated in Figure 2-14.

a[href$=".pdf"] {font-weight: bold;}

Figure 2-14. Selecting elements based on substrings that end attribute values

Similarly, you could (for whatever reason) select images based on their image format:

img[src$=".gif"] {...}
img[src$=".jpg"] {...}
img[src$=".png"] {...}

To continue the calendar example from the previous section, it would be possible to select all of the events occurring within a given year using a selector like [title$="2015"].

Note

You may have noticed that I’ve quoted all the attribute values in the attribute selectors. Quoting is required if the value includes any special characters, begins with a dash or digit, or is otherwise invalid as an identifier and needs to be quoted as a string. To be safe, I recommend always quoting attribute values in attribute selectors, even though it is only required to makes strings out of invalid identifiers.

The Case Insensitivity Identifier

CSS Selectors level 4 introduces a case-insensitivity option to attribute selectors. Including an i before the closing bracket will allow the selector to match attribute values case-insensitively, regardless of document language rules.

For example, suppose you want to select all links to PDF documents, but you don’t know if they’ll end in .pdf, .PDF, or even .Pdf. Here’s how:

a[href$='.PDF' i]

Adding that humble little i means the selector will match any a element whose href attribute’s value ends in .pdf, regardless of the capitalization of the letters P, D, and F.

This case-insensitivity option is available for all attribute selectors we’ve covered. Note, however, that this only applies to the values in the attribute selectors. It does not enforce case insensitivity on the attribute names themselves. Thus, in a case-sensitive language, planet[type*="rock" i] will match all of the following:

<planet type="barren rocky">Mercury</planet>
<planet type="cloudy ROCKY">Venus</planet>
<planet type="life-bearing Rock">Earth</planet>

It will not match the following element, because the attribute TYPE isn’t matched by type:

<planet TYPE="dusty rock">Mars</planet>

Again, that’s in languages that enforce case sensitivity in the element and attribute syntax. XHTML was one such. In languages that are case-insensitive, like HTML5, this isn’t an issue.

Understanding the Parent-Child Relationship

To understand the relationship between selectors and documents, we need to once again examine how documents are structured. Consider this very simple HTML document:

<html>
<head>
 <base href="http://www.meerkat.web/">
 <title>Meerkat Central</title>
</head>
<body>
 <h1>Meerkat <em>Central</em></h1>
 <p>
 Welcome to Meerkat <em>Central</em>, the <strong>best meerkat web site
 on <a href="inet.html">the <em>entire</em> Internet</a></strong>!</p>
 <ul>
  <li>We offer:
   <ul>
    <li><strong>Detailed information</strong> on how to adopt a meerkat</li>
    <li>Tips for living with a meerkat</li>
    <li><em>Fun</em> things to do with a meerkat, including:
     <ol>
      <li>Playing fetch</li>
      <li>Digging for food</li>
      <li>Hide and seek</li>
     </ol>
    </li>
   </ul>
  </li>
  <li>...and so much more!</li>
 </ul>
 <p>
 Questions? <a href="mailto:suricate@meerkat.web">Contact us!</a>
 </p>
</body>
</html>

Much of the power of CSS is based on the parent-child relationship of elements. HTML documents (actually, most structured documents of any kind) are based on a hierarchy of elements, which is visible in the “tree” view of the document (see Figure 2-15). In this hierarchy, each element fits somewhere into the overall structure of the document. Every element in the document is either the parent or the child of another element, and it’s often both.

Figure 2-15. A document tree structure

An element is said to be the parent of another element if it appears directly above that element in the document hierarchy. For example, in Figure 2-15, the first p element is parent to the em and strong elements, while strong is parent to an anchor (a) element, which is itself parent to another em element. Conversely, an element is the child of another element if it is directly beneath the other element. Thus, the anchor element in Figure 2-15 is a child of the strong element, which is in turn child to the p element, which is itself child to the body, and so on.

The terms “parent” and “child” are specific applications of the terms ancestor and descendant. There is a difference between them: in the tree view, if an element is exactly one level above or below another, then they have a parent-child relationship. If the path from one element to another is traced through two or more levels, the elements have an ancestor-descendant relationship, but not a parent-child relationship. (A child is also a descendant, and a parent is also an ancestor.) In Figure 2-15, the first ul element is parent to two li elements, but the first ul is also the ancestor of every element descended from its li element, all the way down to the most deeply nested li elements.

Also, in Figure 2-15, there is an anchor that is a child of strong, but also a descendant of p, body, and html elements. The body element is an ancestor of everything that the browser will display by default, and the html element is ancestor to the entire document. For this reason, in an HTML or XHTML document, the html element is also called the root element.

Descendant Selectors

The first benefit of understanding this model is the ability to define descendant selectors (also known as contextual selectors). Defining descendant selectors is the act of creating rules that operate in certain structural circumstances but not others. As an example, let’s say you want to style only those em elements that are descended from h1 elements. You could put a class attribute on every em element found within an h1, but that’s almost as time-consuming as using the font tag. It’s far more efficient to declare rules that match only em elements that are found inside h1 elements.

To do so, write the following:

h1 em {color: gray;}

This rule will make gray any text in an em element that is the descendant of an h1 element. Other em text, such as that found in a paragraph or a block quote, will not be selected by this rule. Figure 2-16 makes this clear.

Figure 2-16. Selecting an element based on its context

In a descendant selector, the selector side of a rule is composed of two or more space-separated selectors. The space between the selectors is an example of a combinator. Each space combinator can be translated as “found within,” “which is part of,” or “that is a descendant of,” but only if you read the selector right to left. Thus, h1 em can be translated as, “Any em element that is a descendant of an h1 element.” (To read the selector left to right, you might phrase it something like, “Any h1 that contains an em will have the following styles applied to the em.”)

You aren’t limited to two selectors. For example:

ul ol ul em {color: gray;}

In this case, as Figure 2-17 shows, any emphasized text that is part of an unordered list that is part of an ordered list that is itself part of an unordered list (yes, this is correct) will be gray. This is obviously a very specific selection criterion.

Figure 2-17. A very specific descendant selector

Descendant selectors can be extremely powerful. They make possible what could never be done in HTML—at least not without oodles of font tags. Let’s consider a common example. Assume you have a document with a sidebar and a main area. The sidebar has a blue background, the main area has a white background, and both areas include lists of links. You can’t set all links to be blue because they’d be impossible to read in the sidebar.

The solution: descendant selectors. In this case, you give the element that contains your sidebar a class of sidebar and enclose the main area in a main element. Then, you write styles like this:

.sidebar {background: blue;}
main {background: white;}
.sidebar a:link {color: white;}
main a:link {color: blue;}

Figure 2-18 shows the result.

Figure 2-18. Using descendant selectors to apply different styles to the same type of element

Here’s another example: let’s say that you want gray to be the text color of any b (boldface) element that is part of a blockquote and for any bold text that is found in a normal paragraph:

blockquote b, p b {color: gray;}

The result is that the text within b elements that are descended from paragraphs or block quotes will be gray.

One overlooked aspect of descendant selectors is that the degree of separation between two elements can be practically infinite. For example, if you write ul em, that syntax will select any em element descended from a ul element, no matter how deeply nested the em may be. Thus, ul em would select the em element in the following markup:

<ul>
  <li>List item 1
    <ol>
      <li>List item 1-1</li>
      <li>List item 1-2</li>
      <li>List item 1-3
        <ol>
          <li>List item 1-3-1</li>
          <li>List item <em>1-3-2</em></li>
          <li>List item 1-3-3</li>
        </ol>
      </li>
      <li>List item 1-4</li>
    </ol>
  </li>
</ul>

A more subtle aspect of descendant selectors is that they have no notion of element proximity. In other words, the closeness of two elements within the document tree has no bearing on whether a rule applies or not. This is important when it comes to specificity (which we’ll cover later on) and when considering rules that might appear to cancel each other out.

For example, consider the following (which contains a selector type we’ll discuss in the upcoming section, “The Negation Pseudo-Class”):

div:not(.help) span {color: gray;}
div.help span {color: red;}

<div class="help">
   <div class="aside">
      This text contains <span>a span element</span> within.
   </div>
</div>

What the CSS says, in effect, is “any span inside a div that doesn’t have a class containing the word help should be gray” in the first rule, and “any span inside a div whose class contains the word help” in the second rule. In the given markup fragment, both rules apply to the span shown.

Because the two rules have equal weight and the “red” rule is written last, it wins out and the span is red. The fact that the div class="aside" is “closer to” the span than the div class="help" is irrelevant. Again: descendant selectors have no notion of element proximity. Both rules match, only one color can be applied, and due to the way CSS works, red is the winner here. (We’ll discuss why in the next chapter.)

Selecting Children

In some cases, you don’t want to select an arbitrarily descended element. Rather, you want to narrow your range to select an element that is a child of another element. You might, for example, want to select a strong element only if it is a child (as opposed to any level of descendant) of an h1 element. To do this, you use the child combinator, which is the greater-than symbol (>):

h1 > strong {color: red;}

This rule will make red the strong element shown in the first h1, but not the second:

<h1>This is <strong>very</strong> important.</h1>
<h1>This is <em>really <strong>very</strong></em> important.</h1>

Read right to left, the selector h1 > strong translates as, “Selects any strong element that is a direct child of an h1 element.” The child combinator can be optionally surrounded by whitespace. Thus, h1 > strong, h1> strong, and h1>strong are all equivalent. You can use or omit whitespace as you wish.

When viewing the document as a tree structure, it’s easy to see that a child selector restricts its matches to elements that are directly connected in the tree. Figure 2-19 shows part of a document tree.

Figure 2-19. A document tree fragment

In this tree fragment, you can pick out parent-child relationships. For example, the a element is parent to the strong, but it is child to the p element. You could match elements in this fragment with the selectors p > a and a > strong, but not p > strong, since the strong is a descendant of the p but not its child.

You can also combine descendant and child combinations in the same selector. Thus, table.summary td > p will select any p element that is a child of a td element that is itself descended from a table element that has a class attribute containing the word summary.

Selecting Adjacent Sibling Elements

Let’s say you want to style the paragraph immediately after a heading, or give a special margin to a list that immediately follows a paragraph. To select an element that immediately follows another element with the same parent, you use the adjacent-sibling combinator, represented as a plus symbol (+). As with the child combinator, the symbol can be surrounded by whitespace, or not, at the author’s discretion.

To remove the top margin from a paragraph immediately following an h1 element, write:

h1 + p {margin-top: 0;}

The selector is read as, “Selects any p element that immediately follows an h1 element that shares a parent with the p element.”

To visualize how this selector works, it is easiest to once again consider a fragment of a document tree, shown in Figure 2-20.

Figure 2-20. Another document tree fragment

In this fragment, a pair of lists descends from a div element, one ordered and the other not, each containing three list items. Each list is an adjacent sibling, and the list items themselves are also adjacent siblings. However, the list items from the first list are not siblings of the second, since the two sets of list items do not share the same parent element. (At best, they’re cousins, and CSS has no cousin selector.)

Remember that you can select the second of two adjacent siblings only with a single combinator. Thus, if you write li + li {font-weight: bold;}, only the second and third items in each list will be boldfaced. The first list items will be unaffected, as illustrated in Figure 2-21.

Figure 2-21. Selecting adjacent siblings

To work properly, CSS requires that the two elements appear in “source order.” In our example, an ol element is followed by a ul element. This allows us to select the second element with ol + ul, but we cannot select the first using the same syntax. For ul + ol to match, an ordered list must immediately follow an unordered list.

Keep in mind that text content between two elements does not prevent the adjacent-sibling combinator from working. Consider this markup fragment, whose tree view would be the same as that shown in Figure 2-19:

<div>
  <ol>
    <li>List item 1</li>
    <li>List item 1</li>
    <li>List item 1</li>
  </ol>
  This is some text that is part of the 'div'.
  <ul>
    <li>A list item</li>
    <li>Another list item</li>
    <li>Yet another list item</li>
  </ul>
</div>

Even though there is text between the two lists, we can still match the second list with the selector ol + ul. That’s because the intervening text is not contained with a sibling element, but is instead part of the parent div. If we wrapped that text in a paragraph element, it would then prevent ol + ul from matching the second list. Instead, we might have to write something like ol + p + ul.

As the following example illustrates, the adjacent-sibling combinator can be used in conjunction with other combinators:

html > body table + ul{margin-top: 1.5em;}

The selector translates as, “Selects any ul element that immediately follows a sibling table element that is descended from a body element that is itself a child of an html element.”

As with all combinators, you can place the adjacent-sibling combinator in a more complex setting, such as div#content h1 + div ol. That selector is read as, “Selects any ol element that is descended from a div when the div is the adjacent sibling of an h1 which is itself descended from a div whose id attribute has a value of content.”

Selecting Following Siblings

Selectors Level 3 introduced a new sibling combinator called the general sibling combinator. This lets you select any element that follows another element when both elements share the same parent, represented using the tilde (~) combinator.

As an example, to italicize any ol that follows an h2 and also shares a parent with the h2, you’d write h2 ~ol {font-style: italic;}. The two elements do not have to be adjacent siblings, although they can be adjacent and still match this rule. The result of applying this rule to the following markup is shown in Figure 2-22:

<div>
  <h2>Subheadings</h2>
  <p>It is the case that not every heading can be a main heading.  Some headings
  must be subheadings.  Examples include:</p>
  <ol>
    <li>Headings that are less important</li>
    <li>Headings that are subsidiary to more important headlines</li>
    <li>Headings that like to be dominated</li>
  </ol>
  <p>Let's restate that for the record:</p>
  <ol>
    <li>Headings that are less important</li>
    <li>Headings that are subsidiary to more important headlines</li>
    <li>Headings that like to be dominated</li>
  </ol>
</div>

As you can see, both ordered lists are italicized. That’s because both of them are ol elements that follow an h2 with which they share a parent (the div).

Figure 2-22. Selecting following siblings

Combining Pseudo-Classes

Before we start, a word about chaining. CSS makes it possible to combine (“chain”) pseudo-classes together. For example, you can make unvisited links red when they’re hovered and visited links maroon when they’re hovered:

a:link:hover {color: red;}
a:visited:hover {color: maroon;}

The order you specify doesn’t actually matter; you could also write a:hover:link to the same effect as a:link:hover. It’s also possible to assign separate hover styles to unvisited and visited links that are in another language—for example, German:

a:link:hover:lang(de) {color: gray;}
a:visited:hover:lang(de) {color: silver;}

Be careful not to combine mutually exclusive pseudo-classes. For example, a link cannot be both visited and unvisited, so a:link:visited doesn’t make any sense and will never match anything.

Structural Pseudo-Classes

The majority of pseudo-classes are structural in nature; that is, they refer to the markup structure of the document. Most of them depend on patterns within the markup, such as choosing every third paragraph, but others allow you to address specific types of elements. All pseudo-classes, without exception, are a word preceded by a single colon (:), and they can appear anywhere in a selector.

Before we get started, there’s an aspect of pseudo-classes that needs to be made explicit here: pseudo-classes always refer to the element to which they’re attached, and no other. Seems like a weirdly obvious thing to say, right? The reason to make it explicit is that for a few of the structural pseudo-classes, it’s a common error to think they are descriptors that refer to descendant elements.

To illustrate this, I’d like to share a personal anecdote. When my first child was born in 2003, I announced it online (like you do). A number of people responded with congratulations and CSS jokes, chief among them the selector #ericmeyer:first-child. The problem there is that selector would select me, not my daughter, and only if I were the first child of my parents (which, as it happens, I am). To properly select my first child, that selector would need to be #ericmeyer > :first-child.

The confusion is understandable, which is why I’m addressing it here. Reminders will be found throughout the following sections. Just always keep in mind that the effect of pseudo-classes is to apply a sort of a “phantom class” to the element to which they’re attached, and you should be OK.

Selecting the root element

This is the quintessence of structural simplicity: the pseudo-class :root selects the root element of the document. In HTML, this is always the html element. The real benefit of this selector is found when writing stylesheets for XML languages, where the root element may be different in every language—for example, in RSS 2.0 it’s the rss element—or even when you have more than one possible root element within a single language (though not a single document!).

Here’s an example of styling the root element in HTML, as illustrated in Figure 2-23:

:root {border: 10px dotted gray;}
body {border: 10px solid black;}

Figure 2-23. Styling the root element

In HTML documents, you can always select the html element directly, without having to use the :root pseudo-class. There is a difference between the two selectors in terms of specificity, which we’ll cover in Chapter 3.

<p></p>
<p> </p>
<p>
</p>
<p><!—-a comment--></p>

<img src="salmon.png" alt="North Pacific Salmon">
<br>
<input type="number" min="-1" max="1" step=".01"/>
<textarea></textarea>

Selecting unique children

If you’ve ever wanted to select all the images that are wrapped by a hyperlink element, the :only-child pseudo-class is for you. It selects elements when they are the only child element of another element. So let’s say you want to add a border to any image that’s the only child of another element. You’d write:

img:only-child {border: 1px solid black;}

This would match any image that meets those criteria. Therefore, if you had a paragraph which contained an image and no other child elements, the image would be selected regardless of all the text surrounding it. If what you’re really after is images that are sole children and found inside hyperlinks, then you just modify the selector like so (which is illustrated in Figure 2-24):

a[href] img:only-child {border: 2px solid black;}

<a href="http://w3.org/"><img src="w3.png" alt="W3C"></a>
<a href="http://w3.org/"><img src="w3.png" alt=""> The W3C</a>
<a href="http://w3.org/"><img src="w3.png" alt=""> <em>The W3C</em></a>

Figure 2-24. Selecting images that are only children inside links

There are two things to remember about :only-child. The first is that you always apply it to the element you want to be an only child, not to the parent element, as explained earlier. And that brings up the second thing to remember, which is that when you use :only-child in a descendant selector, you aren’t restricting the elements listed to a parent-child relationship.

To go back to the hyperlinked-image example, a[href] img:only-child matches any image that is an only child and is descended from an a element, not is a child of an a element. To match, the element image must be the only child of its direct parent, and a descendant of a link, but that parent can itself be a descendant of that link. Therefore, all three of the images here would be matched, as shown in Figure 2-25:

a[href] img:only-child {border: 5px solid black;}

<a href="http://w3.org/"><img src="w3.png" alt="W3C"></a>
<a href="http://w3.org/"><span><img src="w3.png" alt="W3C"></span></a>
<a href="http://w3.org/">A link to <span>the <img src="w3.png" alt="">
   web</span> site</a>

Figure 2-25. Selecting images that are only children inside links

In each case, the image is the only child element of its parent, and it is also descended from an a element. Thus, all three images are matched by the rule shown. If you wanted to restrict the rule so that it matched images that were the only children of a elements, then you’d just add the child combinator to yield a[href] > img:only-child. With that change, only the first of the three images shown in Figure 2-25 would be matched.

That’s all great, but what if you want to match images that are the only images inside hyperlinks, but there are other elements in there with them? Consider the following:

<a href="http://w3.org/"><b>•</b><img src="w3.png" alt="W3C"></a>

In this case, we have an a element that has two children: b and img. That image, no longer being the only child of its parent (the hyperlink), can never be matched using :only-child. However, it can be matched using :only-of-type. This is illustrated in Figure 2-26:

a[href] img:only-of-type {border: 5px solid black;}

<a href="http://w3.org/"><b>•</b><img src="w3.png" alt="W3C"></a>
<a href="http://w3.org/"><span><b>•</b><img src="w3.png" alt="W3C"></span></a>

Figure 2-26. Selecting images that are the only sibling of their type

The difference is that :only-of-type will match any element that is the only of its type among all its siblings, whereas :only-child will only match if an element has no siblings at all.

This can be very useful in cases such as selecting images within paragraphs without having to worry about the presence of hyperlinks or other inline elements:

p > img:only-of-type {float: right; margin: 20px;}

As long as there aren’t multiple images that are children of the same paragraph, then the image will be floated. You could also use this pseudo-class to apply extra styles to an h2 when it’s the only one in a section of a document, like this:

section > h2 {margin: 1em 0 0.33em; font-size: 1.8rem; border-bottom: 1px solid
   gray;}
section > h2:only-of-type {font-size: 2.4rem;}

Given those rules, any section that has only one child h2 will have it appear larger than usual. If there are two or more h2 children to a section, neither of them will be larger than the other. The presence of other children—whether they are other heading levels, paragraphs, tables, paragraphs, lists, and so on—will not interfere with matching.

There’s one more thing to make clear, which is that :only-of-type refers to elements and nothing else. Consider the following:

p.unique:only-of-type {color: red;}

<div>
  <p class="unique">This paragraph has a 'unique' class.</p>
  <p>This paragraph doesn't have a class at all.</p>
</div>

In this case, neither of the paragraphs will be selected. Why not? Because there are two paragraphs that are descendants of the div, so neither of them can be the only one of their type.

The class name is irrelevant here. We’re fooled into thinking that “type” is a generic description, because of how we parse language. Type, in the way :only-of-type means it, refers only to the element type. Thus, p.unique:only-of-type means “select any p element whose class attribute contains the word unique when the p element is the only p element among its siblings.” It does not mean “select any p element whose class attribute contains the word unique when it’s the only sibling paragraph to meet that criterion.”

Selecting first and last children

It’s pretty common to want to apply special styling to the first or last child of an element. A common example is styling a bunch of navigation links in a tab bar, and wanting to put some special visual touches on the first or last tab (or both). In the past, this was done by applying special classes to those elements. Now we have pseudo-classes to carry the load for us.

The pseudo-class :first-child is used to select elements that are the first children of other elements. Consider the following markup:

<div>
  <p>These are the necessary steps:</p>
  <ul>
    <li>Insert key</li>
    <li>Turn key <strong>clockwise</strong></li>
    <li>Push accelerator</li>
  </ul>
  <p>
    Do <em>not</em> push the brake at the same time as the accelerator.
  </p>
</div>

In this example, the elements that are first children are the first p, the first li, and the strong and em elements, which are all the first children of their respective parents. Given the following two rules:

p:first-child {font-weight: bold;}
li:first-child {text-transform: uppercase;}

we get the result shown in Figure 2-27.

Figure 2-27. Styling first children

The first rule boldfaces any p element that is the first child of another element. The second rule uppercases any li element that is the first child of another element (which, in HTML, must be either an ol or ul element).

As has been mentioned, the most common error is assuming that a selector like p:first-child will select the first child of a p element. Remember the nature of pseudo-classes, which is to attach a sort of phantom class to the element associated with the pseudo-class. If you were to add actual classes to the markup, it would look like this:

<div>
  <p class="first-child">These are the necessary steps:</p>
  <ul>
    <li class="first-child">Insert key</li>
    <li>Turn key <strong class="first-child">clockwise</strong></li>
    <li>Push accelerator</li>
  </ul>
  <p>
    Do <em class="first-child">not</em> push the brake at the same time as the
  accelerator.
  </p>
</div>

Therefore, if you want to select those em elements that are the first child of another element, you write em:first-child.

The mirror image of :first-child is :last-child. If we take the previous example and just change the pseudo-classes, we get the result shown in Figure 2-28.

p:last-child {font-weight: bold;}
li:last-child {text-transform: uppercase;}

<div>
  <p>These are the necessary steps:</p>
  <ul>
    <li>Insert key</li>
    <li>Turn key <strong>clockwise</strong></li>
    <li>Push accelerator</li>
  </ul>
  <p>
    Do <em>not</em> push the brake at the same time as the accelerator.
  </p>
</div>

Figure 2-28. Styling last children

The first rule boldfaces any p element that is the last child of another element. The second rule uppercases any li element that is the last child of another element. If you wanted to select the em element inside that last paragraph, you could use the selector p:last-child em, which selects any em element that descends from a p element that is itself the last child of another element.

Interestingly, you can combine these two pseudo-classes to create a version of :only-child. The following two rules will select the same elements:

p:only-child {color: red;}
p:first-child:last-child {background-color: red;}

Either way, we get paragraphs with red foreground and background colors (not a good idea, clearly).

Selecting first and last of a type

In a manner similar to selecting the first and last children of an element, you can select the first or last of a type of element within another element. This permits things like selecting the first table inside a given element, regardless of whatever elements come before it.

table:first-of-type {border-top: 2px solid gray;}

Note that this does not apply to the entire document; that is, the rule shown will not select the first table in the document and skip all the others. It will instead select the first table element within each element that contains one, and skip any sibling table elements that come after the first. Thus, given the document structure shown in Figure 2-29, the circled nodes are the ones that are selected.

Figure 2-29. Selecting first-of-type tables

Within the context of tables, a useful way to select the first data cell within a row regardless of whether a header cell comes before it in the row is as follows:

td:first-of-type {border-left: 1px solid red;}

That would select the first data cell in each of the following table rows:

<tr>
  <th scope="row">Count</th><td>7</td><td>6</td><td>11</td>
</tr>
<tr>
  <td>Q</td><td>X</td><td>-</td>
</tr>

Compare that to the effects of td:first-child, which would select the first td element in the second row, but not in the first row.

The flip side is :last-of-type, which selects the last instance of a given type from amongst its sibling elements. In a way, it’s just like :first-of-type except you start with the last element in a group of siblings and walk backward toward the first element until you reach an instance of the type. Given the document structure shown in Figure 2-30, the circled nodes are the ones selected by table:last-of-type.

Figure 2-30. Selecting last-of-type tables

As was noted with :only-of-type, remember that you are selecting elements of a type from among their sibling elements; thus, every set of siblings is considered separately. In other words, you are not selecting the first (or last) of all the elements of a type within the entire document as a single group. Each set of elements that share a parent is its own group, and you can select the first (or last) of a type within each group.

Similar to what was noted in the previous section, you can combine these two pseudo-classes to create a version of :only-of-type. The following two rules will select the same elements:

table:only-of-type{color: red;}
table:first-of-type:last-of-type {background: red;}

Selecting every nth child

If you can select elements that are the first, last, or only children of other elements, how about every third child? All even children? Only the ninth child? Rather than define a literally infinite number of named pseudo-classes, CSS has the :nth-child() pseudo-class. By filling integers or even simple algebraic expressions into the parentheses, you can select any arbitrarily numbered child element you like.

Let’s start with the :nth-child() equivalent of :first-child, which is :nth-child(1). In the following example, the selected elements will be the first paragraph and the first list item.

p:nth-child(1) {font-weight: bold;}
li:nth-child(1) {text-transform: uppercase;}

<div>
  <p>These are the necessary steps:</p>
  <ul>
    <li>Insert key</li>
    <li>Turn key <strong>clockwise</strong></li>
    <li>Push accelerator</li>
  </ul>
  <p>
    Do <em>not</em> push the brake at the same time as the accelerator.
  </p>
</div>

If we change the numbers from 1 to 2, however, then no paragraphs will be selected, and the middle (or second) list item will be selected, as illustrated in Figure 2-31:

p:nth-child(2) {font-weight: bold;}
li:nth-child(2) {text-transform: uppercase;}

Figure 2-31. Styling second children

You can insert any integer you choose; if you have a use case for selecting any ordered list that is the 93rd child element of its parent, then ol:nth-child(93) is ready to serve. This will match the 93rd child of any parent as long as that child is an ordered list. (This does not mean the 93rd ordered list among its siblings; see the next section for that.)

More powerfully, you can use simple algebraic expressions in the form a n + b or a n − b to define recurring instances, where a and b are integers and n is present as itself. Furthermore, the + b or − b part is optional and thus can be dropped if it isn’t needed.

Let’s suppose we want to select every third list item in an unordered list, starting with the first. The following makes that possible, selecting the first and fourth items, as shown in Figure 2-32.

ul > li:nth-child(3n + 1) {text-transform: uppercase;}

Figure 2-32. Styling every third list item

The way this works is that n represents the series 0, 1, 2, 3, 4, and on into infinity. The browser then solves for 3 n + 1, yielding 1, 4, 7, 10, 13, and so on. Were we to drop the +1, thus leaving us with simply 3n, the results would be 0, 3, 6, 9, 12, and so on. Since there is no zeroth list item—all element counting starts with one, to the likely chagrin of array-slingers everywhere—the first list item selected by this expression would be the third list item in the list.

Given that element counting starts with one, it’s a minor trick to deduce that :nth-child(2n) will select even-numbered children, and either :nth-child(2n+1) or :nth-child(2n-1) will select odd-numbered children. You can commit that to memory, or you can use the two special keywords that :nth-child() accepts: even and odd. Want to highlight every other row of a table, starting with the first? Here’s how you do it, with the results shown in Figure 2-33:

tr:nth-child(odd) {background: silver;}

Figure 2-33. Styling every other table row

Anything more complex than every-other-element requires an an + b expression.

Note that when you want to use a negative number for b, you have to remove the + sign or else the selector will fail entirely. Of the following two rules, only the first will do anything. The second will be dropped by the parser and ignored:

tr:nth-child(4n - 2) {background: silver;}
tr:nth-child(3n + −2) {background: red;}

If you want to select every row starting with the ninth, you can use either of the following. They are similar in that they will select all rows starting with the ninth, but the latter one has greater specificity, which we discuss in Chapter 3:

tr:nth-child(n + 9) {background: silver;}
tr:nth-child(8) ~ tr {background: silver;}

As you might expect, there is a corresponding pseudo-class in :nth-last-child(). This lets you do the same thing as :nth-child(), except with :nth-last-child() you start from the last element in a list of siblings and count backward toward the beginning. If you’re intent on highlighting every other table row and making sure the very last row is one of the rows in the highlighting pattern, either one of these will work for you:

tr:nth-last-child(odd) {background: silver;}
tr:nth-last-child(2n+1) {background: silver;} /* equivalent */

If the DOM is updated to add or remove table rows, there is no need to add or remove classes. By using structural selectors, these selectors will always match the odd rows of the updated DOM.

Any element can be matched using both :nth-child() and :nth-last-child() if it fits the criteria. Consider these rules, the results of which are shown in Figure 2-34:

li:nth-child(3n + 3) {border-left: 5px solid black;}
li:nth-last-child(4n - 1) {border-right: 5px solid black; background: silver;}

Figure 2-34. Combining patterns of :nth-child() and :nth-last-child()

It’s also the case that you can string these two pseudo-classes together as :nth-child(1):nth-last-child(1), thus creating a more verbose restatement of :only-child. There’s no real reason to do so other than to create a selector with a higher specificity, but the option is there.

You can use CSS to determine how many list items are in a list, and style them accordingly:

li:only-child {width: 100%;}
li:nth-child(1):nth-last-child(2),
li:nth-child(2):nth-last-child(1) {width: 50%;}
li:nth-child(1):nth-last-child(3),
li:nth-child(1):nth-last-child(3) ~ li {width: 33.33%;}
li:nth-child(1):nth-last-child(4),
li:nth-child(1):nth-last-child(4) ~ li {width: 25%;}

In these examples, if a list item is the only list item, then the width is 100%. If a list item is the first item and also the second-from-the-last item, that means there are two items, and the width is 50%. If an item is the first item and also the third from the last item, then we make it, and the two sibling list items following it, 33% wide. Similarly, if a list item is the first item and also the fourth from the last item, it means that there are exactly four items, so we make it, and its three siblings, 25% of the width.

Selecting every nth of a type

In what’s probably become a familiar pattern, the :nth-child() and :nth-last-child() pseudo-classes have analogues in :nth-of-type() and :nth-last-of-type(). You can, for example, select every other hyperlink that’s a child of any given paragraph, starting with the second, using p > a:nth-of-type(even). This will ignore all other elements (spans, strongs, etc.) and consider only the links, as demonstrated in Figure 2-35:

p > a:nth-of-type(even) {background: blue; color: white;}

Figure 2-35. Selecting the even-numbered links

If you want to work from the last hyperlink backward, then you’d use p > a:nth-last-of-type(even).

As before, these select elements of a type from among their sibling elements, not from among all the elements of a type within the entire document as a single group. Each element has its own list of siblings, and selections happen within each group.

As you might expect, you can string these two together as :nth-of-type(1):nth-last-of-type(1) to restate :only-of-type, only with higher specificity. (We will explain specificity in Chapter 3, I promise.)

Dynamic Pseudo-Classes

Beyond the structural pseudo-classes, there are a set of pseudo-classes that relate to structure but can change based on changes made to the page after it’s been rendered. In other words, the styles are applied to pieces of a document based on something in addition to the structure of the document, and in a way that cannot be precisely deduced simply by studying the document’s markup.

It may sound like we’re applying styles at random, but not so. Instead, we’re applying styles based on somewhat ephemeral conditions that can’t be predicted in advance. Nevertheless, the circumstances under which the styles will appear are, in fact, well-defined. Think of it this way: during a sporting event, whenever the home team scores, the crowd will cheer. You don’t know exactly when during a game the team will score, but when it does, the crowd will cheer, just as predicted. The fact that you can’t predict the exact moment of the cheer doesn’t make it any less expected.

Consider the anchor element (a), which (in HTML and related languages) establishes a link from one document to another. Anchors are always anchors, but some anchors refer to pages that have already been visited, while others refer to pages that have yet to be visited. You can’t tell the difference by simply looking at the HTML markup, because in the markup, all anchors look the same. The only way to tell which links have been visited is by comparing the links in a document to the user’s browser history. So there are actually two basic types of links: visited and unvisited.

a {color: blue;}
a:visited {color: red;}

<a>4. The Lives of Meerkats</a>

a:link {color: blue;}    /* unvisited links are blue */
a:visited {color: red;}   /* visited links are red */

<a href="/about.html">My About page</a>
<a href="https://www.site.net/" class="external">An external site</a>

a.external:link, a[href^="http"]:link { color: slateblue;}
a.external:visited, a[href^="http"]:visited  {color: maroon;}

a#footer-copyright:link{background: yellow;}
a#footer-copyright:visited {background: gray;}

User action pseudo-classes

CSS defines a few pseudo-classes that can change a document’s appearance based on actions taken by the user. These dynamic pseudo-classes have traditionally been used to style hyperlinks, but the possibilities are much wider. Table 2-3 describes these pseudo-classes.

Table 2-3. User action pseudo-classes

Name	Description
:focus	Refers to any element that currently has the input focus—i.e., can accept keyboard input or be activated in some way.
:hover	Refers to any element over which the mouse pointer is placed—e.g., a hyperlink over which the mouse pointer is hovering.
:active	Refers to any element that has been activated by user input—e.g., a hyperlink on which a user clicks during the time the mouse button is held down.

Elements that can become :active include links, buttons, menu items, and any element with a tabindex value. These elements and all other interactive elements, including form controls and elements that are content-editable, can also receive focus.

As with :link and :visited, these pseudo-classes are most familiar in the context of hyperlinks. Many web pages have styles that look like this:

a:link {color: navy;}
a:visited {color: gray;}
a:focus {color: orange;}
a:hover {color: red;}
a:active {color: yellow;}

Note

The order of the pseudo-classes is more important than it might seem at first. The usual recommendation is “link-visited-hover-active,” although this has been modified to “link-visited-focus-hover-active.” The next chapter explains why this particular ordering is important and discusses several reasons you might choose to change or even ignore the recommended ordering.

Notice that the dynamic pseudo-classes can be applied to any element, which is good since it’s often useful to apply dynamic styles to elements that aren’t links. For example, using this markup:

input:focus {background: silver; font-weight: bold;}

you could highlight a form element that is ready to accept keyboard input, as shown in Figure 2-36.

Figure 2-36. Highlighting a form element that has focus

You can also perform some rather odd feats by applying dynamic pseudo-classes to arbitrary elements. You might decide to give users a “highlight” effect by way of the following:

body *:hover {background: yellow;}

This rule will cause any element that’s descended from the body element to display a yellow background when it’s in a hover state. Headings, paragraphs, lists, tables, images, and anything else found inside the body will be changed to have a yellow background. You could also change the font, put a border around the element being hovered, or alter anything else the browser will allow.

Warning

While you can style elements with :focus any way you like, do not remove all styling from focused elements. Differentiating which element currently has focus is vital for accessibility, especially for those navigating your site or application with a keyboard.

Real-world issues with dynamic styling

Dynamic pseudo-classes present some interesting issues and peculiarities. For example, it’s possible to set visited and unvisited links to one font size and make hovered links a larger size, as shown in Figure 2-37:

a:link, a:visited {font-size: 13px;}
a:hover, a:active {font-size: 20px;}

Figure 2-37. Changing layout with dynamic pseudo-classes

As you can see, the user agent increases the size of the anchor while the mouse pointer hovers over it; or, thanks to the :active setting, when a user touches it on a touch screen. A user agent that supports this behavior must redraw the document while an anchor is in hover state, which could force a reflow of all the content that follows the link.

UI-State Pseudo-Classes

Closely related to the dynamic pseudo-classes are the user-interface (UI) state pseudo-classes, which are summarized in Table 2-4. These pseudo-classes allow for styling based on the current state of user-interface elements like checkboxes.

Although the state of a UI element can certainly be changed by user action—for example, a user checking or unchecking a checkbox—UI-state pseudo-classes are not classified as purely dynamic because they can also be affected by the document structure or DOM scripting.

Enabled and disabled UI elements

Thanks to both DOM scripting and HTML5, it is possible to mark a user-interface element (or group of user interface elements) as being disabled. A disabled element is displayed, but cannot be selected, activated, or otherwise interacted with by the user. Authors can set an element to be disabled either through DOM scripting, or (in HTML5) by adding a disabled attribute to the element’s markup.

Any element that hasn’t been disabled is by definition enabled. You can style these two states using the :enabled and :disabled pseudo-classes. It’s much more common to style disabled elements and leave enabled elements alone, but both have their uses, as illustrated in Figure 2-38:

:enabled {font-weight: bold;}
:disabled {opacity: 0.5;}

Figure 2-38. Styling enabled and disabled UI elements

Check states

In addition to being enabled or disabled, certain UI elements can be checked or unchecked—in HTML, the input types “checkbox” and “radio” fit this definition. Selectors level 3 offers a :checked pseudo-class to handle elements in that state, though curiously it omits an :unchecked. There is also the :indeterminate pseudo-class, which matches any checkable UI element that is neither checked nor unchecked. These states are illustrated in Figure 2-39:

:checked {background: silver;}
:indeterminate {border: red;}

In addition, you can use the negation pseudo-class, which is covered later, to select checkboxes which are not checked with input[type="checkbox"]:not(:checked). Only radio buttons and checkboxes can be checked. All other elements, and these two when not checked, are :not(:checked).

Figure 2-39. Styling checked and indeterminate UI elements

Although checkable elements are unchecked by default, it’s possible for a HTML author to toggle them on by adding the checked attribute to an element’s markup. An author can also use DOM scripting to flip an element’s checked state to checked or unchecked, whichever they prefer.

There is a third state, “indeterminate.” As of late 2017, this state can only be set through DOM scripting or by the user agent itself; there is no markup-level method to set elements to an indeterminate state. The purpose of allowing an indeterminate state is to visually indicate that the element needs to be checked (or unchecked) by the user. However, note that this is purely a visual effect: it does not affect the underlying state of the UI element, which is either checked or unchecked, depending on document markup and the effects of any DOM scripting.

Although the previous examples show styled radio buttons, remember that direct styling of radio buttons and checkboxes with CSS is actually very limited. However, that shouldn’t limit your use of the selected-option pseudo-classes. As an example, you can style the labels associated with your checkboxes and radio buttons using a combination of :checked and the adjacent sibling combinator:

input[type="checkbox"]:checked + label {
  color: red;
  font-style: italic;
}

<input id="chbx" type="checkbox"> <label for="chbx">I am a label</label>

[type="checkbox"]:default + label { font-style: italic; }

<input type="checkbox" id="chbx" checked name="foo" value="bar">
<label for="chbx">This was checked on page load</label>

input:required { border: 1px solid #f00;}
input:optional { border: 1px solid #ccc;}

<input type="email" placeholder="enter an email address" required>
<input type="email" placeholder="optional email address">
<input type="email" placeholder="optional email address" required="false">

input[required] { border: 1px solid #f00;}
input:not([required]) { border: 1px solid #ccc;}

Validity pseudo-classes

The :valid pseudo-class refers to a user input that meets all of its data validity requirements. The :invalid pseudo-class, on the other hand, refers to a user input that does not meet all of its data validity requirements.

The validity pseudo-classes :valid and :invalid only apply to elements having the capacity for data validity requirements: a div will never match either selector, but an input could match either, depending on the current state of the interface.

Here’s an example where an image is dropped into the background of any email input which has focus, with one image being used when the input is invalid and another used when the input is valid, as illustrated in Figure 2-40:

input[type="email"]:focus {
  background-position: 100% 50%;
  background-repeat: no-repeat;
}
input[type="email"]:focus:invalid {
  background-image: url(warning.jpg);
}
input[type="email"]:focus:valid {
  background-image: url(checkmark.jpg);
}

<input type="email">

Figure 2-40. Styling valid and invalid UI elements

Warning

These pseudo-class states are dependent on what the user agent reports to its own style system, and so may not act as you might expect. For example, in late 2017, an empty email input matched :valid in multiple user agents, despite the fact a null input is not a valid email address. Until these validation routines improve, it is best to treat the validity pseudo-classes with caution.

input[type="number"]:focus {
  background-position: 100% 50%;
  background-repeat: no-repeat;
}
input[type="number"]:focus:out-of-range {
  background-image: url(warning.jpg);
}
input[type="number"]:focus:in-range {
  background-image: url(checkmark.jpg);
}

<input id="nickels" type="number" min="0" max="1000" />

input[type="number"]:invalid {color: red;}
input[type="number"]:in-range {font-weight: bold;}

<input id="by-tens" type="number" min="0" max="1000" step="10" value="23" />

textarea:read-only {opacity: 0.75;}
pre:read-write:hover {border: 1px dashed green;}

<textarea disabled></textarea>
<pre contenteditable>Type your own code!</pre>

The :target Pseudo-Class

When a URL includes a fragment identifier, the piece of the document at which it points is called (in CSS) the target. Thus, you can uniquely style any element that is the target of a URL fragment identifier with the :target pseudo-class.

Even if you’re unfamiliar with the term “fragment identifier,” you’ve probably seen them in action. Consider this URL:

http://www.w3.org/TR/css3-selectors/#target-pseudo

The target-pseudo portion of the URL is the fragment identifier, which is marked by the # symbol. If the referenced page (http://www.w3.org/TR/css3-selectors/) has an element with an ID of target-pseudo, then that element becomes the target of the fragment identifier.

Thanks to :target, you can highlight any targeted element within a document, or you can devise different styles for various types of elements that might be targeted—say, one style for targeted headings, another for targeted tables, and so on. Figure 2-41 shows an example of :target in action:

*:target {border-left: 5px solid gray; background: yellow url(target.png)
    top right no-repeat;}

Figure 2-41. Styling a fragment identifier target

:target styles will not be applied in two circumstances:

1. If the page is accessed via a URL that does not have a fragment identifier

2. If the page is accessed via a URL that has a fragment identifier, but the identifier does not match any elements within the document

More interestingly, though, what happens if multiple elements within a document can be matched by the fragment identifier—for example, if the author erroneously included three separate instances of <div id="target-pseudo"> in the same document?

The short answer is that CSS doesn’t have or need rules to cover this case, because all CSS is concerned with is styling targets. Whether the browser picks just one of the three elements to be the target or designates all three as co-equal targets, :target styles should be applied to anything that is a valid target.

The :lang Pseudo-Class

For situations where you want to select an element based on its language, you can use the :lang() pseudo-class. In terms of its matching patterns, the :lang() pseudo-class is similar to the |= attribute selector. For example, to italicize elements whose content is written in French, you could write either of the following:

*:lang(fr) {font-style: italic;}
*[lang|="fr"] {font-style: italic;}

The primary difference between the pseudo-class selector and the attribute selector is that language information can be derived from a number of sources, some of which are outside the element itself. For the attribute selector, the element must have the attribute present to match. The :lang pseudo-class, on the other hand, matches descendants of an element with the language declaration. As Selectors Level 3 states:

In HTML, the language is determined by a combination of the lang attribute, and possibly information from the meta elements and the protocol (such as HTTP headers). XML uses an attribute called xml:lang, and there may be other document language-specific methods for determining the language.

The pseudo-class will operate on all of that information, whereas the attribute selector can only work if there is a lang attribute present in the element’s markup. Therefore, the pseudo-class is more robust than the attribute selector and is probably a better choice in most cases where language-specific styling is needed.

The Negation Pseudo-Class

Every selector we’ve covered thus far has had one thing in common: they’re all positive selectors. In other words, they are used to identify the things that should be selected, thus excluding by implication all the things that don’t match and are thus not selected.

For those times when you want to invert this formulation and select elements based on what they are not, Selectors Level 3 introduced the negation pseudo-class, :not(). It’s not quite like any other selector, fittingly enough, and it does have some restrictions on its use, but let’s start with an example.

Let’s suppose you want to apply a style to every list item that doesn’t have a class of moreinfo, as illustrated in Figure 2-42. That used to be very difficult, and in certain cases impossible, to make happen. If we wanted all the list items to be italic except those with the class .moreinfo, we used to declare all the links as italic, generally having to target the ul with a class, then normalize back based on the class, making sure the override came last in the source order, and had equal or higher specificity. Now we can declare:

li:not(.moreinfo) {font-style: italic;}

Figure 2-42. Styling list items that don’t have a certain class

The way :not() works is that you attach it to an element, and then in the parentheses you fill in a simple selector. A simple selector, according to the W3C, is:

either a type selector, universal selector, attribute selector, class selector, ID selector, or pseudo-class.

Basically, a simple selector is a selector with no ancestral-descendant relationship.

Note the “either” there: you can only use one of those inside :not(). You can’t group them and you can’t combine them using combinators, which means you can’t use a descendant selector, because the space separating elements in a descendant selector is a combinator. Those restrictions may (indeed most likely will) be lifted in the future, but we can still do quite a lot even within the given constraints.

For example, let’s flip around the previous example and select all elements with a class of moreinfo that are not list items. This is illustrated in Figure 2-43:

.moreinfo:not(li) {font-style: italic;}

Figure 2-43. Styling elements with a certain class that aren’t list items

Translated into English, the selector would say, “Select all elements with a class whose value contains the word moreinfo as long as they are not li elements.” Similarly, the translation of li:not(.moreinfo) would be “Select all li elements as long as they do not have a class whose value contains the word moreinfo.”

Technically, you can put a universal selector into the parentheses, but there’s very little point. After all, p:not(*) would mean “Select any p element as long as it isn’t any element,” and there’s no such thing as an element that is not an element. Very similar to that would be p:not(p), which would also select nothing. It’s also possible to write things like p:not(div), which will select any p element that is not a div element—in other words, all of them. Again, there is very little reason to do so.

You can also use the negation pseudo-class at any point in a more complex selector. Thus, to select all tables that are not children of a section element, you would write *:not(section) > table. Similarly, to select table header cells that are not part of the table header, you’d write something like table *:not(thead) > tr > th, with a result like that shown in Figure 2-44.

Figure 2-44. Styling header cells outside the table’s head area

What you cannot do is nest negation pseudo-classes; thus, p:not(:not(p)) is invalid and will be ignored. It’s also, logically, the equivalent of just writing p, so there’s no point anyway. Furthermore, you cannot reference pseudo-elements (which we’ll cover shortly) inside the parentheses, since they are not simple selectors.

On the other hand, it’s possible to chain negations together to create a sort of “and also not this” effect. For example, you might want to select all elements with a class of link that are neither list items nor paragraphs:

*.link:not(li):not(p) {font-style: italic;}

That translates to “Select all elements with a class whose value contains the word link as long as they are neither li nor p elements.”

One thing to watch out for is that you can have situations where rules combine in unexpected ways, mostly because we’re not used to thinking of selection in the negative. Consider this test case:

div:not(.one) p {font-weight: normal;}
div.one p {font-weight: bold;}

<div class="one">
   <div class="two">
      <p>I'm a paragraph!</p>
   </div>
</div>

The paragraph will be boldfaced, not normal-weight. This is because both rules match: the p element is descended from a div whose class does not contain the word one (<div class="two">), but it is also descended from a div whose class contains the word one. Both rules match, and so both apply. Since there is a conflict, the cascade is used to resolve the conflict, and the second rule wins. The structural arrangement of the markup, with the div.two being “closer” to the paragraph than div.one, is irrelevant.

Styling the First Letter

The ::first-letter pseudo-element styles the first letter, or a leading punctuation character and the first letter (if the text starts with punctuation), of any non-inline element. This rule causes the first letter of every paragraph to be colored red:

p::first-letter {color: red;}

The ::first-letter pseudo-element is most commonly used to create an “initial cap” or “drop cap” typographic effect. You could make the first letter of each p twice as big as the rest of the heading, though you may want to only apply this styling to the first letter of the first paragraph:

p:first-of-type::first-letter {font-size: 200%;}

The result of this rule is illustrated in Figure 2-45.

Figure 2-45. The ::first-letter pseudo-element in action

This rule effectively causes the user agent to style a fictional, or “faux” element, that encloses the first letter of each p. It would look something like this:

<p><p-first-letter>T</p-first-letter>his is a p element, with a styled first
    letter</h2>

The ::first-letter styles are applied only to the contents of the fictional element shown in the example. This <p-first-letter> element does not appear in the document source, nor even in the DOM tree. Instead, its existence is constructed on the fly by the user agent and is used to apply the ::first-letter style(s) to the appropriate bit of text. In other words, <p-first-letter> is a pseudo-element. Remember, you don’t have to add any new tags. The user agent styles the first letter for you as if you had encased it in a styled element.

The first letter is defined as the first typographic letter unit of the originating element, if it is not preceded by other content, like an image. The specifications use “letter unit” because some languages have letters made up of more than character, like “oe” in Norse. Punctuation that precedes or follows the first letter unit, even if there are several such symbols, are included in the ::first-letter pseudo-element.

Styling the First Line

Similarly, ::first-line can be used to affect the first line of text in an element. For example, you could make the first line of each paragraph in a document large and purple:

p::first-line {
  font-size: 150%;
  color: purple;
}

In Figure 2-46, the style is applied to the first displayed line of text in each paragraph. This is true no matter how wide or narrow the display region is. If the first line contains only the first five words of the paragraph, then only those five words will be big and purple. If the first line contains the first 30 words of the element, then all 30 will be big and purple.

Figure 2-46. The ::first-line pseudo-element in action

Because the text from “This” to “only” should be big and purple, the user agent employs a fictional markup that looks something like this:

<p>
<p-first-line>This is a paragraph of text that has only</p-first-line>
one stylesheet applied to it. That style causes the first line to
be big and purple. No other line will have those styles applied.
</p>

If the first line of text were edited to include only the first seven words of the paragraph, then the fictional </p-first-line> would move back and occur just after the word “that.” If the user were to increase or decrease the font-size rendering, or expand or contract the browser window causing the width of the text to change, thereby causing the number of words on the first line to increase or decrease, the browser automatically sets only the words in the currently displayed first line to be both big and purple.

The length of the first line depends on a number of factors, including the font-size, letter spacing, width of the parent container, etc. Depending on the markup, and the length of that first line, it is possible that the end of the first line comes in the middle of a nested element. If the ::first-line breaks up a nested element, such as an em or a hyperlink, the properties attached to the ::first-line will only apply to the portion of that nested element that is displayed on the first line.

Restrictions on ::first-letter and ::first-line

The ::first-letter and ::first-line pseudo-elements currently can be applied only to block-display elements such as headings or paragraphs, and not to inline-display elements such as hyperlinks. There are also limits on the CSS properties that may be applied to ::first-line and ::first-letter. Table 2-5 gives an idea of these limitations.

Styling (or Creating) Content Before and After Elements

Let’s say you want to preface every h2 element with a pair of silver square brackets as a typographical effect:

h2::before {content: "]]"; color: silver;}

CSS lets you insert generated content, and then style it directly using the pseudo-elements ::before and ::after. Figure 2-47 illustrates an example.

Figure 2-47. Inserting content before an element

The pseudo-element is used to insert the generated content and to style it. To place content after an element, use the pseudo-element ::after. You could end your documents with an appropriate finish:

body::after {content: "The End.";}

Generated content is a separate subject, and the entire topic (including more detail on ::before and ::after) is covered more thoroughly in Chapter 15.

Declarations and Specificity

Once the specificity of a selector has been determined, the specificity value will be conferred on all of its associated declarations. Consider this rule:

h1 {color: silver; background: black;}

For specificity purposes, the user agent must treat the rule as if it were “ungrouped” into separate rules. Thus, the previous example would become:

h1 {color: silver;}
h1 {background: black;}

Both have a specificity of 0,0,0,1, and that’s the value conferred on each declaration. The same splitting-up process happens with a grouped selector as well. Given the rule:

h1, h2.section {color: silver; background: black;}

the user agent treats it if it were the following:

h1 {color: silver;}             /* 0,0,0,1 */
h1 {background: black;}         /* 0,0,0,1 */
h2.section {color: silver;}     /* 0,0,1,1 */
h2.section {background: black;} /* 0,0,1,1 */

This becomes important in situations where multiple rules match the same element and some of the declarations clash. For example, consider these rules:

h1 + p {color: black; font-style: italic;}              /* 0,0,0,2 */
p {color: gray; background: white; font-style: normal;} /* 0,0,0,1 */
*.aside {color: black; background: silver;}             /* 0,0,1,0 */

When applied to the following markup, the content will be rendered as shown in Figure 3-1:

<h1>Greetings!</h1>
<p class="aside">
It's a fine way to start a day, don't you think?
</p>
<p>
There are many ways to greet a person, but the words are not as important as
the act of greeting itself.
</p>
<h1>Salutations!</h1>
<p>
There is nothing finer than a hearty welcome from one's fellow man.
</p>
<p class="aside">
Although a thick and juicy hamburger with bacon and mushrooms runs a close second.
</p>

Figure 3-1. How different rules affect a document

In every case, the user agent determines which rules match a given element, calculates all of the associated declarations and their specificities, determines which rules win out, and then applies the winners to the element to get the styled result. These machinations must be performed on every element, selector, and declaration. Fortunately, the user agent does it all automatically. This behavior is an important component of the cascade, which we will discuss later in this chapter.

Universal Selector Specificity

The universal selector does not contribute to specificity. In other words, it has a specificity of 0,0,0,0, which is different than having no specificity (as we’ll discuss in “Inheritance”). Therefore, given the following two rules, a paragraph descended from a div will be black, but all other elements will be gray:

div p {color: black;} /* 0,0,0,2 */
* {color: gray;}      /* 0,0,0,0 */