You Better Use Inline Styles, If You Know What’s Good For You

There are a lot of good reasons to use any of these tools. There is no silver bullet, no “right choice.” Some projects will benefit from a specific toolset. Some teams will be more comfortable or more productive with one approach or another. When I see articles saying “please don’t use inline styles,” I think to myself: *fart noises*. When I see articles saying “CSS is dead, use inline styles,” I think to myself: *fart noises*.

There’s a secret about inline styles, and it goes like this: the biggest benefits are doable with plain old CSS. I’m talking specifically about specificity equalization and scoping, which I consider to be the best features. With diligence, you can ensure that most of your styles are applied with equal specificity by using class selectors whenever possible. You can avoid naming collisions by carefully managing class names, maybe with a pattern like BEM.

Inline styling introduces a constraint that enforces this style of authorship: no more selectors. That’s the key difference, really. Using CSS for the same result requires diligence, and inline styling changes the toolset so that it’s the only option. In my experience, solutions requiring diligence are more difficult at scale and break down more quickly than those that are enforced through tooling constraints. CSS Modules provides a nice middle ground by enforcing unique class names through build-level tooling. The actual result is effectively the same no matter which path you take.

The other major benefit of inline styling is computed styles. This is a neat trick, and one that most applications probably don’t need. They’ve gotten along this far without it, after all. Nontrivial computed styles are impossible with CSS, and I don’t expect that to change. That’s not to say that computed styles aren’t useful. The team at Formidable is doing great work with them in Victory, a new React data visualization library. Data visualization is an excellent use case for the technique. I expect that novel and interesting approaches to user interface design based on computed styling will emerge over time. The Grid is a promising early example.

Just Tell Me What To Do

The styling mechanism you should choose will probably depend on your project and your team. If you’re writing a React application, don’t want to deal with specificity or scoping, and don’t need server-rendered media queries¹, or if you want to do a lot of style computation, inline styles are a good option. Maybe try a library like Radium or react-style to help with some of the pain points. If you want some similar benefits but don’t want to abandon CSS, try CSS Modules. The tooling there is only viable for Webpack and Browserify projects so far (I think), but the technique revolves around a specification rather than a particular tool, so support for other languages and ecosystems is coming. If you don’t mind the global nature of CSS (or like it, even!), use your favorite preprocessor. If you want scoped styles on a standards track, check out web component styling through the Shadow DOM. There are options, is that I’m saying.

My advice? Pick the tools that will make you happy and productive. Don’t be precious about your decisions— rethink them when things change. Mentally replace all hype and FUD with fart noises. Don’t let anybody tell you what to do.