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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.