CSS Concerns

These days, I often find myself hearing people say “we use BEM” or “we use SMACSS” and the question that often comes to mind is “how exactly do you use them?”

Coming up with a catchy name for a development approach is a double-edged sword. On one hand, they are a convenient way to convey a lot of information really quickly. If someone says that they use BEM, I can make some quick assumptions. On the other hand, people are people and often interpret the details differently. The devil is in the details.

Like Ajax and RWD, BEM and SMACSS and OOCSS have, to some degree, become overloaded terms and it’s hard to tease out what someone really means when they say they use these techniques. Long gone are the days when people actually transmit XML in an Ajax call. People create fixed width designs for three viewports under the banner of Responsive Web Design. Likewise, people use atomic classes with a BEM naming convention. (And don’t get me started on naming conventions!)

In reality, what I’ve found is that I have specific concerns that I want to address and that I use particular techniques to address those concerns. People don’t often think consciously about these concerns. I know I often don’t. But it can be useful to understand the priorities on a project and what techniques you choose to address those priorities.

My Concerns (when developing with CSS)

My concerns when it comes to architecting an application often are:

  1. Consistency: How can I maintain consistency in my design and development?
  2. Clarity: How can I make it easier for people to understand what I’ve developed?
  3. Efficiency: How can I speed up development?
  4. Change: How can I make it easier to make changes?
  5. UX: How can I improve the user experience?

The Salesforce Lightning Design System talks about their design principles. Salesforce lists these in order of priority. It’s useful to articulate your priorities as they help you make decisions during the design and development process.

Obviously, when it comes to CSS architecture, I have opinions. The way I chose to solve those problems was by using the concepts I laid out in SMACSS. I’ve never explicitly mapped the concepts to the concerns I’ve listed above but I can see how the concepts address those concerns and why the concepts were important to me.


I care about consistency within a given page and I care about consistency across an entire site. I believe that a consistent experience is easier for users to understand, thus creating a better user experience.


When I talk of clarity, I mean of how easy is it for other developers (or future me) to understand the work I’ve done. Can a new team member ramp up quickly? Can a developer building out a new interface do so without stumbling their way through it or missing critical steps?


Being able to build new features or redesign existing ones easily in an established system is important. If teams ignore parts of the app or take months to refactor things because of poor design or infrastructure then everything else suffers—users, employees, and employers are sad because it takes longer to get features out the door.


Change ties into both efficiency and consistency.

When it comes to growth within a design system, I believe it important to be able to maintain that consistency as designs change.

It’s also important to be able to roll out design changes quickly. If it takes a large team weeks or months to roll out a new design then this pulls them away from working on new features. In some orgs, I’ve seen global design changes take a back seat to new feature development, further exacerbating the situation. New features either take on new design elements, breaking away from site consistency, or they continue to stay with an old design, increasing the amount of work required to roll out a new design.

User Experience

Lastly, how will the user experience be affected by any of the above? For example, if I improve a widget experience for those using screen readers, I want to be able to easily roll out the change to that widget across the site.

How do I address performance in all the ways that it can affect the user experience? How does a consistent design affect the user experience? Is it worthwhile to replace native controls with custom ones?

The One True Way to Build a Site

You might think I subscribe to the idea that SMACSS is the only way that a site can and should be built. As I mention early on in the book, however, is that when it comes to web development, the answer is almost always “it depends”.

Consider what’s important to you on your project—make sure the team agrees—and then build guidelines on how best to meet your goals.

It’s also important to recognize that these issues aren’t just CSS issues. They are HTML and JavaScript and backend issues, too. They all need to work together to serve these concerns.

Published March 03, 2017
Categorized as HTML and CSS
Short URL: https://snook.ca/s/1099