When I first started learning CSS, I found that getting to grips with the syntax (the set of rules and structures that comprise a programming language) was simple because there are rules that explain how the code should be written. However, I found it was much more difficult to learn how to keep my CSS organized and maintainable, and even more difficult to clean up the disorganized CSS I’d written without a clear vision. I wrote this book with the hope that I could help others by sharing everything I learned through trial and error; I wish this book had existed when I was just starting out.
While I hope that anybody writing CSS will benefit from reading this book, it’s aimed primarily at people who have cobbled together a working user interface but lack either the experience or the vision to understand how their code fits together in the bigger picture. The intended reader understands how to write CSS syntax, but might not necessarily grasp why some things work the way they do. They might also not know how to better architect their code into a piece of software that is easier to maintain, extend, and collaborate on.
My goal in writing this book is to make some of the subtler aspects of CSS more approachable to readers that are just starting out. I also aim to shed some light on why CSS can be difficult to write and test and why spending time refactoring CSS is a worthwhile endeavor.
Topics we’ll cover include:
What refactoring is, why it’s beneficial, and how it relates to software architecture
Commonly misunderstood aspects of CSS including the cascade, selector specificity, and the box model
How to write better CSS by making informed decisions and being consistent
How to maintain well-written CSS with coding standards and pattern libraries
How to test CSS
How to organize CSS
Strategies for refactoring CSS
Ways to measure success when refactoring
Reading this book will provide the knowledge necessary to take immediate action to start working toward a better CSS codebase that should also be more maintainable when working with a team. While doing so, readers are encouraged to revisit chapters that apply to concepts they’re currently making use of.
This book focuses on explaining concepts that are not necessarily technical in nature. As such, there are a lot of topics that are not covered in this book. These include:
Knowledge of available CSS properties is necessary for writing CSS, but they will not be covered in this book. While there may be recommendations for which properties to use from time to time, these properties are better learned by consulting a book like CSS: The Definitive Guide by Eric Meyer or CSS Cookbook by Christopher Schmitt (both from O’Reilly), or any number of reputable websites like the Mozilla Developer Network.
HTML and CSS are used in tandem to build user interfaces, and one can influence the other. Strategies for decoupling CSS from HTML will be discussed, but the pros and cons of how to write and structure HTML will not.
Frontend performance is an important aspect of building any website, and it’s an extremely interesting topic. Since this book is only about refactoring CSS, though, this topic will only be covered very briefly—it is far too broad a topic, since it encompasses a variety of other subjects. Steve Souders has written some great books about performance, and Paul Irish, Nicole Sullivan, and Stoyan Stefanov have done a lot of great work on the topic as well. Google also provides a number of guidelines and tools that can be very beneficial to frontend performance.
CSS frameworks change frequently and impose their own rules on implementation, so they won’t be covered in this book. However, after reading this book I hope that you will be able to look at the source code of any given framework and draw your own conclusions about its implementation.
There are a ton of web browsers out there, but I’ll only be discussing the major players—Microsoft Edge (formerly Internet Explorer), Safari, Chrome, and Firefox, as well as their mobile counterparts—because they comprise the majority of the market share.
Although the intended audience for this book has some knowledge about CSS, some nomenclature might not be familiar, so various terms will be defined throughout the book. At an even more basic level:
In Example P-1 the web browser is instructed to style all paragraphs such that they have blue text set at 16 px (pixels).
p is the selector that tells the browser which elements to style. Everything from the left curly brace up to and including the right curly brace is the declaration block. The declaration block contains two declarations; the first assigns the value
#1200FF to the
color property and the second assigns the value
16px to the
font-size property. The passage of code in its entirety is the ruleset. For your convenience, the anatomy of a ruleset is illustrated in Figure P-1.
The companion website to this book, http://www.cssrefactoringbook.com, contains:
Examples from this book
Occasional blog posts
Links to great articles, presentations, and other resources
Errata and corrections
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 Refactoring by Steve Lindstrom (O’Reilly). Copyright 2017 Steve Lindstrom, 978-1-491-90642-2.”
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at email@example.com.
The following typographical conventions are used in this book:
Indicates new terms, URLs, email addresses, filenames, and file extensions.
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.
This element signifies a tip or suggestion.
This element signifies a general note.
This element indicates a warning or caution.
Safari (formerly Safari Books Online) is membership-based training and reference platform for enterprise, government, educators, and individuals.
Members have access to thousands of books, training videos, Learning Paths, interactive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.
For more information, please visit http://oreilly.com/safari.
Please address comments and questions concerning this book to the publisher:
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-refactoring.
To comment or ask technical questions about this book, send email to firstname.lastname@example.org.
For more information about our books, courses, conferences, and news, 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
Writing this book was a truly humbling experience.
One night on a whim I sent a short proposal to O’Reilly Media in the form of a terse email that included some bullet points for ideas I had for this book. I panicked after the email was sent, and promptly stopped thinking about it because I didn’t expect to hear back anyway.
When I did hear back from O’Reilly and it was good news I was even more afraid that I was in over my head, but Simon St. Laurent, Brian MacDonald, and Meg Foley were fantastic to work with. I owe a tremendous amount of gratitude to my editor Meg Foley in particular, because she was so understanding and encouraging despite the fact that I missed every single deadline that I had. I’ve said it before and I’ll say it again—sorry Meg!
This book is full of techniques, strategies, and ideas that have come from lots of different places over the years. I can’t claim ownership of the majority of the concepts in this book, so first and foremost I’d like to thank all of the people that have come before me and figured all of this stuff out. I think the web development community is one of the best to be a part of because there are so many smart people that are willing to share their ideas with everyone. I can only hope that I’ve done some good by compiling all of these ideas in one place.
Writing a book is much more difficult than I had ever imagined because it’s time-consuming, lonely work, but fortunately I’m surrounded by great people all day at work. Whenever I felt like throwing in the towel writing this book, I would look to Andy Denmark’s amazing work ethic for inspiration. Thor Denmark also helped me keep my head above water by showing me how to maintain a great attitude through both the good times and the bad. Nate Racklyeft and Josh Hudner read a very early version of this book and provided tremendous feedback that made it a thousand times better than it would have been otherwise. Finally, Erin Wallace provided valuable feedback as someone who deals with similar concepts of organization, process, and subtlety in the design world and was able to help me refine my writing to be easier to understand. All of these people keep me on my toes on a daily basis and push me to be better than I was the day before, and for that I’m eternally grateful.
I also owe a great deal of thanks to Christopher Schmitt for reviewing the contents of this book. When I found out that he was reviewing my work I knew that his name sounded familiar, and sure enough two of his books were sitting on my bookshelf. Your notes helped me immensely and your books were invaluable when I was first getting started. Thanks so much for taking the time out of your day to help a complete stranger. I’d love to repay the favor some day!
This acknowledgments section wouldn’t be complete if I didn’t also thank my family for making me the person I am today. My parents always encouraged me to read and I still try to read more than I watch TV. At an early age my dad gave me my first O’Reilly book (I think it was a book about C), and I attribute my career choice in large part to his encouragement and career. My mom and brother have also been major sources of inspiration and encouragement, and I can’t possibly thank you enough.
Finally, I owe a lot of thanks to coffee. I love you, coffee <3.