CSS first.

[michelle]

We've all heard the stories. First, your amazing web application is built, some beautiful CSS is written for it, and not a pixel is out of place. After launch, out of nowhere, features start needing to be added and your CSS is the first to unravel. Developers for whom CSS is an afterthought start building on the project, and CSS is the final boss before they can ship their feature. Vague class names start popping up all over the place, there's 15 different re-stylings of .hide and .hidden across 14 different files, and CSS rules (.page .subpage div span .red:hover { color: red; }) suddenly stop having meaning. Then things start breaking. It starts off with an innocent margin change in one file when styling one page of your app that breaks 5 other pages. Then it's a span that gets styled for one component but ends up affecting 10 other components. And finally it becomes a self-perpetuating cycle that makes everyone on your team grimace when CSS is even mentioned. This was the status quo at Stripe.

So let's start over. Let's start with CSS first this time, and focus on making it a great developer experience. In this talk, I will introduce how we're using rework at Stripe, and how building and selecting simple rework plugins helps us write and maintain testable, component-based CSS that's pleasing for everyone to work with.