CSS: The Definitive Guide, 4th Edition

Preface

If you are a web designer or document author interested in sophisticated page styling, improved accessibility, and saving time and effort, this book is for you. All you really need to know before starting the book is HTML 4.0. The better you know HTML, the better prepared you’ll be, but it is not a requirement. You will need to know very little else to follow this book.

This fourth edition of the book was finished in mid-2017 and does its best to reflect the state of CSS at that time. The assumption is that anything covered in detail either had wide browser support at the time of writing or was known to be coming soon after publication. CSS features which were still being developed, or were known to have support dropping soon, are not covered here.

Conventions Used in This Book

The following typographical conventions are used in this book (but make sure to read through the subsection “Value Syntax Conventions” to see how some of these are modified):

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.

Tip

This element signifies a tip or suggestion.

Note

This element signifies a general note.

Warning

This element indicates a warning or caution.

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

Using Code Examples

Whenever you come across an icon that looks like , it means there is an associated code example. Live examples are available at https://meyerweb.github.io/csstdg4figs/. If you are reading this book on a device with an internet connection, you can click the icon to go directly to a live version of the code example referenced.

Supplemental material—in the form of the HTML, CSS, and image files that were used to produce nearly all of the figures in this book—is available for download at https://github.com/meyerweb/csstdg4figs. Please be sure to read the repository’s README.md file for any notes regarding the contents of the repository.

This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “CSS: The Definitive Guide by Eric A. Meyer and Estelle Weyl (O’Reilly). Copyright 2018 Eric Meyer, Estelle Weyl, 978-1-449-39319-9.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [e-mail].

O’Reilly Online Learning

Note

For almost 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.

Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway North
• Sebastopol, CA 95472
• 800-998-9938 (in the United States or Canada)
• 707-829-0515 (international or local)
• 707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/css-the-definitive-guide-4e.

To comment or ask technical questions about this book, send email to [e-mail].

For news and more information about our books and courses, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

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