We write quite a lot of CSS at Sparkbox, and we try to write a fair bit about what we are doing and learning in regards to CSS. Like so many things in the web industry, change is constant and persistent. Each time we write an article, it captures a moment, a mere snapshot of where we are, or were, in our journey of web making. This is my meager attempt to pull back a bit and compile our knowledge and opinions of CSS into a larger picture of where we are in this journey.
Sass
First things first, we use Sass to help us write our CSS. A firm comprehension of writing CSS is certainly needed before diving into any CSS pre-, or post-, processors. Sass can simplify writing and even help ease repetitive tasks. We primarily use the C-based implementation of Sass, libSass, to handle compiling our stylesheets via the Grunt or Gulp task. While in the past we have used libraries like Compass or Bourbon to handle vendor prefixes, lately we’ve relied more and more on PostCSS’s Autoprefixer to add in the necessary prefixes. This allows us to focus on writing CSS without keeping track of when a library’s mixin is required.
Knowing how to structure Sass is important, a topic that Marshall Norman shared in his post “Sass Packing.” We use partials to keep our files concise and easy to navigate, which are all compiled together into the final stylesheet(s). Diving deeper into the structure, property order within a selector matters, and with Sass, two key features should almost always come before any CSS properties are declared: mixins and extends. These features are priorities since there are times we may need to override styles found within those mixins and extends.
.selector-name {
@extend .other-selector;
@include mixin-one(value);
background-color: #038;
font-size: 1.25em;
}
Media Queries
Most of our media queries are written using a mixin we wrote called SB-Media. This mixin allows us to output two CSS files from the same set of partials; one CSS file is for browsers that support media queries, and the other is for the browsers that do not, which is pretty much IE8 down. Ethan Muller is one of the masterminds behind this mixin, and he wrote about how the SB-Media mixin was conceived and how we implement this approach.
We nest media queries within selectors. Organizationally, this is quite helpful as it keeps all the styles for an element together and easier to find and adjust. Ben Callahan goes into detail of this approach to media queries in his article, “There Is No Breakpoint.” Please note, Ben’s article was written a few months before Ethan’s article on SB-Media; Ben’s article uses an older iteration of the mixin.
Naming Things
Regardless of what it is, naming things is hard. Creating class names is often the hardest part of writing CSS. This is a topic of discussion on each project at Sparkbox. We haven’t figured out an absolute solution for every project—naming things is often debated and questioned internally. Ethan wrote a fantastic post addressing this issue, aptly titled, “Naming CSS Stuff Is Really Hard.” Our general solution to naming things is documentation and refactoring. We document our naming conventions and patterns in the project’s README file on GitHub, which helps communicate to everyone involved in the project, both present and future. But it is important to keep names fluid so they can change as needed, which requires refactoring. Nathan Rambeck wrote about keeping a project nimble by making CSS refactoring a regular part of development.
Accessibility
Accessibility is often a concern of ours, but this year, we have been especially attuned to understanding how we make websites that meet the needs of all. Concerning how CSS plays into good accessibility practices, Marshall tackles the implications of hiding elements, and Daniel Flynn targets accessible content with attribute selectors.
Automated Visual Testing
Most of our projects at Sparkbox involve multiple teams that are all contributing to a repository in GitHub. With so many hands involved with the code, we try to set up safeguards by requiring work to be done in feature branches, not master, and to have another developer review and merge Pull Requests. Even with such precautionary measures in place, sometimes bugs not clearly evident in the code get through. To help alert us to visual issues, Adam Simpson and Rob Tarr have introduced Wraith into our workflow. With Wraith, we can automate visual testing of styles and be alerted to discrepancies with Slack integration. Each time there is a visual difference between the current deploy and the previous, Wraith lets us know.
Responsive Grid Systems
Responsive grid systems have been a topic of discussion for quite a while at Sparkbox. Use cases, individual preference, and project needs all weighing in at some point or another, picking a singular grid system isn’t possible. Ethan dives into the nitty gritty of responsive grid systems, to help find the right approach for your needs.
Looking Ahead
This article is a snapshot of the current moment at Sparkbox. In our pursuit of a Web built right, my coworkers and I will likely do our best to make the content outdated as soon as possible—moving on to the next thing that allows us to write CSS that is more performant, more accessible, and more comprehensive. Something that makes the Web a more beautiful and inclusive place. Something that helps us teach others to pursue approaches of creating to that end.
