To BEM or not to BEM : Stephanie Rewis

“Though nothing is perfect, I really appreciate the way BEM’s structure makes it easy to tell at a glance exactly how selectors relate to each other.”


Date: 16 November 2016

Q. Hi Stephanie

the first time I have met you is at Industry Conf, a few months ago. I admire the work that you and your team have done in Salesforce, building the Lightning Design System. Since then I have chased you to make this interview, and finally here you are :)

Let’s start from you: you are Principal UI Developer of the team responsible for the CSS framework in the Salesforce Lightning Design System (SLDS). I can’t think to something more interesting and challenging — professionally, for someone that works in the front end I mean — than that. Styleguides, Pattern Libraries and Design System are the hot new thing in that special middle ground between the front end development and design. What’s your role, what is your daily job?

A. When I was hired at Salesforce, the Design Systems team had just gotten approval to add the CSS Framework to the existing Design System. My role was to architect and build that framework. It quickly became apparent that, with the rapidity that our execs were embracing what we were doing, we were going to need a bigger team.

My daily job still includes building components and checking other team member PRs, but what seems to take exceedingly more time lately is working with teams that are adopting the framework internally. There are always challenges and I enjoy helping to solve those so we can be more efficient, and the framework can be more easily adopted.

I also do a good bit of answering questions (my team has a bi-weekly advisory board) and providing support.

Q. Do you still find time to code? Or it’s all about meeting, supervising, organising other people’s work?

A. I do still find time to code. But definitely less than I did initially — though that’s not so much because I’m organizing other people, but more about being involved with other teams we integrate with.

Though our team is small, it’s a very smooth-running team. People are very self-motivated and hard-working. None of us need much supervision — we collaborate and support each other very well.

Q. How is your team composed? How many people work with you?

A. As I said, we have a very small team that actually builds the framework. It was initially Brandon and I who worked on it full-time, and Jina was half-time framework and half-time design and patterns. We just hired Isha about three months ago.

Interestingly, we have 3 women and 1 man — somewhat unusual from what I understand.

We monitor consistency in patterns as well. We recently split our two designers onto a sister team under a creative director.

We also have a sister team that runs the infrastructure, systems, testing, and our integration with other internal systems.

The Accessibility team is also now under our larger umbrella which has been a fantastic move so that we can integrate with them even more tightly.

Also under our umbrella is a team that does rapid prototyping and testing of the patterns and new components before they’re built.

I believe the large overall team is roughly around 21 people now.

Q. As you know, this project is called To BEM or not to BEM. What is your relation with BEM? You chose to use it for the CSS framework in SLDS, right?

Yes, I did make the BEM choice. I had used it at the startup I worked at previously. Though nothing is perfect, I really appreciate the way BEM’s structure makes it easy to tell at a glance exactly how selectors relate to each other. And while “we BEM”, we have made a couple modifications and taken a few liberties. We’ve also made a few mistakes.

Q. Usually when someone builds a CSS framework, is to use it on its own product/project. In your case, your framework has been built to be used and consumed by an heterogeneous user base, internal and external to Salesforce. How does this factor played in the decision to adopt BEM as naming convention?

A. Because we have an huge number of consumers of our framework — both internal and external — it was important to me that A) naming was understandable and B) specificity was kept as low as possible to avoid the !important trump card being used. That means many times you will put a class where you might generally write a descendant selector. It pays off though.

Q. Alla Kholmatova in her article on A List Apart suggests to name component based on their “high-level function”, so what is their ultimate scope and not simply their name in the context of use. Also suggests to name things collaboratively, at team level. Quoting her:

“if an object in the interface doesn’t have a name — a name that makes sense to your team, and is known and used by people on your team — then it doesn’t exist as a concrete, actionable module to work with.”

A few weeks ago you tweeted (oh, I loved that tweet!):

“OMG! I’m experiencing an extreme BEM-blockage. Naming is SO hard.”

How do your team(s) name things?

A. Naming IS hard. Even after you’ve named a module, sometimes deciding how much of the component is unique and how much is smaller, reusable micropatterns can bring us to debate.

Clarity is our number one principal, so we do try to name things in a way that makes sense to us as well as developers.

However, within our ecosystem (CRM), there are some interesting, unique names for things. And to be honest, we’ve definitely got some oddly named components due to the names internal teams wanted. Also, sometimes over time, components become more similar. Yet we’ve initially built them as unique components. We have a bit of regrouping and clarification to do.

We’re in the midst of a spike now where we’re working on the metadata for the framework, creating a new taxonomy and imagining new ways to define and describe things. This will create an API of sorts — so that we can create our IA in a variety of more useful ways.

Q. Who decides what name to give to an element or a component? Is a collaborative effort, or you are the final judge? Or you always use the Cap Watkins Sliding Scale? (I remember you mentioned it at Industry Conf)

A. We discuss it. Both with the teams that are requesting the component/pattern and amongst ourselves. And I am not a dictator.

LOL I love collaboration. We are stronger together. When we can’t agree via discussion, we absolutely use Cap Watkins sliding scale. It’s magical if you use it honestly.

Q. “Naming things” — especially in a context of a strict naming convention like BEM — has also an impact on how you decide to structure — or modularize — your components. How do you avoid name clashing? Every time you have to find a new name, and be sure is not conflicting (and will not conflict in the future) with other class names, other components, blocks, etc.

A. You’re right. And as the framework grows, this becomes more tricky. We look at a component and build by starting with the micropatterns or atoms. If something is a small, reusable pattern, then we build it separate from the component that houses it.

Sometimes, a small reusable component, like tiles, are included in a larger experience component. But the naming of the tiles doesn’t need to contain the name of the parent component — though sometimes they may require a modifier class.

As far as clashing, we tend to group similar components which helps us to see what exists pretty easily.

Q. How do you avoid the classic bikeshedding discussions? (they happen in every team)

Great question. I’m not sure we totally avoid them, but we’re a pretty pragmatic, and very busy team. Usually one of us speaks up and says, “Does this really matter in the larger scheme of things?” We don’t really have a methodology around it (though we might apply the sliding scale if we don’t agree).

Q. How do you do code reviews, in your team? There is someone — you? — that is the gatekeeper of the naming conventions and strategies? With so many components I imagine someone needs to know all the possible names and classes, to avoid clashes and collisions.

A. Since Brandon Ferrua and I started out doing most of the code, we kept each other in check. We reviewed each other’s PRs. Gave each other a sanity check. My feeling is, if you okay all my PRs, you’re clearly not looking at them close enough. Challenge me!

As the team has grown, we try to have two of us look at each PR, unless it’s something super simple. People review differently and see things differently — the more the merrier, to catch little discrepancies.

Q. In a discussion on the Design System channel on Slack you mentioned having problems integrating BEM classes into XML-type environments? Can you explain what is the problem you are facing? And did you find yet a solution?

A. This has been a frustration. We have been using the common BEM notation of .block.block__element.block--modifier. In XML, you can't have a double dash inside a comment. Our internal system compiles XML prior to runtime, so the XML parser we use won’t compile with comments.

On Twitter, Mauro Alvarez suggested the ignore directive. We tested that, and while we can make it work, it means that developers have to learn to comment in a non-standard way. So we're weighing our options.

Q. Looking at the organisation of the files and UI components in the CSS codebase, I see that the files that compose a single UI element (e.g. buttons or forms or tabs) are collected under a flavors folder. Why? What is the meaning of that folder?

A. A flavor was, at the time we started, an internal naming convention for a variation of a component. We used it, and it’s in our folder structure, but we don’t surface it anywhere. That folder creates the “variations” of a component, and we also currently show “states” of a component as well since we are an agnostic, UI-only framework. States are our way of showing JS interactions.

Q. Don’t you think that this organisation of your components can lead to an excessive fragmentation and scattering of files — I have counted more than 150 Sass files — and therefore also to an unnecessary complexity and a steeper learning curve (and more difficult adoption)?

A. As you might guess, the system has been through a variety of permutations over the past 18 months. We’re always looking at better ways to do things.

As I mentioned before, we’re working on the metadata and taxonomy. We may flatten our file system out a bit with that project as well.

That said, I actually find it easier to identify where to find CSS when it’s kept with its component or variation. Compiling isn’t a big deal since we don’t compile at runtime. In fact, we pre-compile our React prior to runtime as well and serve static pages.

Q. I have seen that in your codebase in some places you are using the “evil” nesting of selectors to build the Block-Element-Modifier name stucture of BEM:

.#{$css-prefix}page-header {

&__title {

}
}

and in other places you are explicitly writing the full BEM selector.

I know for sure that Kaelig doesn’t like it (here and here). It’s hard to search/grep, I agree with him, and personally I think is also hard to read. Are you getting rid of them or did Kaelig simply surrender?

A. Hahah! Kaelig, surrender? You surely do not know Kaelig well then. ;)

But seriously, we had already begun down this path when Kaelig joined the team. However, due to tooling our dev ops teams is building, we are finding it to be problematic. And searching for a selector in a large code base can be nightmarish.

As it is with @extends, “just because you can doesn’t mean you should”. We will probably be unnesting for human and machine readability in the big project we’re currently working on.

Q. A “stinging” question: why do you decided to use this syntax .#{$css-prefix} without the dash after? Every time I see it my eyes cry... :)

A. That prefix will be gone shortly in light of the plain .slds- namespace in front of each class.

The reason it was done dynamically initially is, the name of our framework was changed more than once by marketing. Rather than grep the codebase to change the namespace, we made it dynamic to change in a single place. (The syntax is from one of our sister teams.) Now that things have been settled for over a year, we’re simplifying and making it more readable.

Q. Let’s get back to BEM: in the codebase on Github I have seen some classes like:

.#{$css-prefix}tabs--default__item
.#{$css-prefix}tabs--default__link

I don’t think is correct from the BEM perspective. Or is it “allowed”?

A. Remember when I said we still contain some mistakes? Sometimes you build things, and then the rules about the component change (or you learn more).

Tabs were initially built in another way, with a few descendant selectors which I warned about above. Later, we found they needed to be nested and we had some styles competing. We made the decision to break them out and put classes on all the parts. The mistake though is not about .slds-tabs--default__link as much as the problem that there is no base .slds-tabs component. So we have two variations and no base. Womp womp!

Stuff happens. Perfection is unattainable. And sometimes you have to live with a poor decision because it’s “in the wild” already.

We have some other “strange BEM”, purposely created, which due to our syntax change we’ll now need to update. Sometimes a component will have an optional container. We don’t want to put the base, block component class name on that container. However, that container will only be used on that component.

Originally, Brandon and I experimented with a lot of possible characters we could use. But nearly all of them had to be escaped — which looks pretty gross in your CSS. We chose to go with a single underscore to denote a container. For example: .slds-component_container. We felt it was clear at a glance that this class was an optional container class for a specific component.

Q. I see that in the repo on Github there are a lot of React files (typically index.react.jsx). As far as I understand they are used to build the documentation and for testing purposes. Are you already considering the migration to CSS Modules?

A. Yes, those React files are what we build our documentation site from — including the variety of states. We are not yet considering CSS Modules. We’re a huge system and I don’t feel it’s ready for prime time yet. Maybe in a couple of years.

Q. Looks like — at least to me — that the new “hot thing” in Design Systems are the “tokens”, the visual design atoms (or quarks?) of the systems. Simplifying, they are a list of variables, typically in JSON, that store the basic visual design attributes of the system and can be then cascade down to all platforms. Bootstrap was a precursor, then?

A. Tokens are simply stored values — maybe subatomic particles. LOL For us, they originated from Aura, the system we use to build product from. They had been using tokens to store strings of all kinds. Several years ago, we started using them as “design tokens”. The team then built a tool called Theo (open source) that uses JSON to output the values to a large number of formats. Bootstrap seems to be surfacing Less (or Sass) variables, but we export about 7 or 8 different formats.

Q. Out of curiosity: from your LinkedIn I see you “Created the 32 CSS Layouts included in Dreamweaver CS3 and updated for Dreamweaver CS5”. Wow! What layouts techniques did you use? Tables, Floated divs, Flexbox, CSS Grids?

A. Well, since this was back in 2005 or 2006, there was no flexbox or grid layout. They were built to be modern (for that era), with pure CSS layout techniques, so no tables.

Yes, floating divs were involved. As I recall, options included 2 or 3 columns, optional headers and footers, and they were either fixed width, fluid (responsive %), elastic (em units), hybrid (fixed sides, fluid middle) or absolutely positioned. (I fought the positioned ones, but I didn’t win.)

They were meant to give people who were not CSS experts a quick way to get started and learn how to use CSS for layout. They had no design — just structure and shades of gray.

I commented the heck out of everything as a teaching tool (though once you got used to them, you could choose the non-commented version). It was a fun project.

Q. A last silly question :) what made you decide to call a catamaran “border-radius”?

A. Since our plan is to circumnavigate the globe on a catamaran, we liked the play on words (since border-radius can make a full circle like the globe). We toyed with float:left or float:right. We definitely ruled out float:none though.

Since we spoke, we’ve purchased Amritha, the 40ft catamaran we’ll be circumnavigating on later, and border-radius has a new family.

Q. Well, what can I say: you’re an all-round developer :)

Thank you so much Stephanie for the interview: it took a while, but it was definitely worth the wait!


Stephanie Rewis is Principal UI Developer at Salesforce where she leads the team responsible for the CSS framework in the Lightning Design System.

She has been a front-end developer, passionate about web standards and accessibility, for over 16 years.

Well known speaker and book author, she has worked with a wide spectrum of clients including Under Armour, Newsweek, MLB, New York Magazine, Adobe, Disney’s ‘TRON’, and a lively bunch of startups.

When not fighting specificity wars, she and her husband escape on their catamaran, border-radius.

Links: medium // twitter // github


This is the seventh of a series of ten interviews, originally published at www.didoo.net/to-bem-or-not-to-bem.

Like what you read? Give Cristiano Rastelli a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.