Sure! Solid is a front end framework and a styleguide. It provides a single responsability class framework for us to rapidly style UI in a unified BuzzFeed style. It also includes simple “components” which use a BEM like naming convention.

Solid was initially conceived by Amaury Moulron as an OOCSS based style guide that would unite BuzzFeed’s visual style. Cap Watkins joined, and presented us with the idea of an atomic style guide after he was blown away by Brent Jackson’s work on basscss. He cobbled together a team of designers within BuzzFeed to develop Solid, along with myself and Amaury. The project is currently maintained by myself, Emily Brick, John Niedermeyer, Allison Chefec, and Lindsey Maretta.

Solid is currently being used by every BuzzFeed team working on the web. Initially I thought using an Atomic class based framework as a style guide was a terrible idea, but I changed my mind.

I wrote a medium post about that journey: “How I Learned to Stop Worrying and Love the Atomic Class”

The BEM and atomic parts work independently of each other in Solid. If we had more BEM components it would make sense for us to make a whole new library for them! But one of the benefits of managing a library for use within the company is that we can provide just enough functionality to serve our needs, even if there's a conceptual incongruity.

I do think that atomic classes can work well in a BEM based system though.

The benefit of Atomic classes is that they are composable, easy to use, and standardized. The drawback is they wreck DOM readability. When you have elements that rely on each other hierarchically that information has to be conveyed somewhere. BEM serves this purpose well.

Though I think it's important to note that when you have a component based architecture - using react components for example - a lot of semantic information is built into how components are named and organized. And I think in that context single responsability classes work really well.

Solid is definitely simple by design. Our practice is that we want our designers to be comfortable writing front end code, and comfortable extending Solid when necessary. Our CMS definitely has different needs than our web application. So if our CMS team needed tighter spacing and more form controls we encourage them to develop custom atomic classes to do so.

Shared components are great, and what Financial Times has done with Origami is amazing. We simply don't have the need or resources for a framework that complex. We have many internal projects working on many different stacks and we don't have a front end infrastructure team to work on cross-team components.

Right now at BuzzFeed we are trying to structure our teams to be more independent. We want our CMS to be optimized for formatting content, and our site to be optimized for displaying that content. This was a pragmatic choice. Will be serving our content to an infinite variety of screen dimensions and sizes. We can never guarantee a 1:1 relationship between our CMS preview and what winds up displaying on the site.

So we're trying to embrace that.

That said with encapsulation there will always be duplication. We are experimenting with a shared component library and figuring out to what extend that could be useful to us. But so far Solid has produced many of the same visual benefits without a lot of developer overhead.

BuzzFeed dev has around 60 developers working on a variety of internal tools, ad tools, and applications. We have somewhere in the neighborhood of 20 active projects using Solid right now. These range in complexity from simple internal dashboards to the BuzzFeed CMS. We have more projects that are no longer in development which benefited from Solid a great deal.

The solid team consists of four designers, each from a different group (our higher level org structure), and myself. We also have point people in every team using Solid that we keep abreast of all changes in Solid. We call them “Solid Scouts”. I send a lot of update emails to them with dumb gifs. This stuff gets dry quickly if you don’t find ways to keep it fun.

Great question! In my experience you're lucky to have someone who cares about CSS naming conventions. I think when it comes to naming conventions in general the most important thing is having one. The second most important thing is that everyone agree on that convention. The semantic stability of the convention is important, but it's nothing compared to those first two.

In Solid when we make concessions it's generally to write classes that "feel" right. This is nebulous but it belies Solid's roots as a design-led framework. But no matter what bizarre naming conventions we've developed the most important thing is that we have heavily documented them.

We don't impose any CSS naming structure on any of our teams. I have preached BEM, and I think it's a good solution to a lot of CSS semantic issues. But I think having a well documented naming scheme is more important than having a perfect one, and being dogmatic doesn't help anyone.

Everyone has their own interpretation of BEM, and arguing about it gets silly fast.

I think for me the most common mistake with BEM is assuming you have to create massive chains of child sibling classes.

I think if you're creating these your real problem is you are writing your front end code in a totally un-modular fashion. So if you wind up with header__content__logo__subtitle it’s probably time to break your UI down into more independent bits.

We have made a couple of sweeping, ambitious, sometimes stupid changes to Solid. It’s really been a learning process! We are able to do this for two reasons:

First, Solid is a versioned node package. Giving our teams the ability to choose when to update the library has been a boon. We can update without the fear of immediately breaking our applications, and make ourselves available to aid in updating if need be.

Second, we over communicate every change in Solid. We go through great pains to make sure everyone using Solid internally knows what changes are in the pipeline. We do this with emails, slack updates, and our online docs. We give internal talks about Solid. We give workshops. We’re probably a little annoying honestly. But the result is we have a passionate internal user base who will tell us if we’re fucking up. Without that Solid never would have worked. I cannot stress that enough.

Creating a style framework instead of a style guide was a bit of a strange move, but it has worked very well for us. I think the reason for this is that we didn’t set out to create an all-encompassing framework. We were just trying to make a tool that worked well with our design process. Once we released it we saw huge internal adoption. It was simply easier to use than to avoid. That let Solid become the backbone of our web design process.

I think it's tempting to try and create a styleguide, show it off, and try and convince your team to use it. I’ve done that before! But I think if you focus on the tooling that makes sense for your team you will find a better Solution. At least that’s what worked for us.

I think Atomic CSS will gain traction because it works so well in component based front end architectures, and yes it keeps CSS weight down. That said it is a hell of a dependency, and is nowhere near as rigid as an OOCSS based class system. This is a pro for us, since we trust our designers to use the library efficiently.

CSS does gain weight over time but compared to other assets it is comparatively small. It's the complexity that can make CSS a nightmare. If you want to stop your CSS from evolving into nightmare spaghetti you'll need some kind of convention to combat implicit dependencies and bloat.

If your designers are coding, or your coders are designing, I think you'll find a lot to like with an Atomic CSS based system. Otherwise for the love of god please choose SOME convention and stick to it. CSS is declarative. It should be stupid. It should be easy. It's our job to keep it that way.

Great, it's been a pleasure. Hope we do get to meet in real life!