Choosing a CSS methodology or framework has never been more difficult than it is now. Whether starting a new project or recognizing a need for change in an existing codebase, there are just no quick answers. This is because CSS is living in a unique place during a special time in the evolution of the web.

The landscape of CSS solutions is more diverse now than it ever has been. Perhaps you’re seeking regulations and guidelines without strict enforcement. CSS methodologies were made for you! But do you chose SMACSS, MaintainableCSS, BEM, OOCSS, CSS Guidelines, ITCSS, eCSS, AtomicCSS? Or maybe a combination of methodologies would work better than any one in particular (BEMITCSS anyone?).

Intimidated by the sheer amount of methodologies? Or maybe you prefer your CSS to be opinionated and come with widgets? Frameworks to the rescue! Some frameworks simply implement a methodology or combination of methodologies. The framework inuit.css created by CSSWizardry for example implements the OOCSS methodology and intentionally “does not provide you with UI and design out of the box, instead, it provides you with a solid architectural baseline upon which to complete your own work.”

Rather have all the bells and whistles? There’s always the venerable Bootstrap, incredibly popular for good reason. Lest we forget the versatile Foundation by ZURB. Or one of the many Material Design implementations, like Materialize, MUI, Material-UI (React specific), or Angular Material (Angular specific). There’s also Bulma, Skeleton, Tachyons, Neat …

Or maybe you’re fancy and component based and you’re looking for a more modular solution. Thanks to a number of pioneering developers, especially in the React community, clever use of Javascript is being used to solve CSS problems in exciting new ways. The two incarnations of this trend are CSS Modules and CSS-in-JS. CSS Modules require extra tooling and knowledge (primarily PostCSS), and CSS-in-JS has its own ecosystem of implementations, many of the React specific. Facebook engineer Michele Bertoli maintains a repo comparing React specific implementations which lists 57 different projects at the time of this writing.

What’s worse, there is a heated and sometimes anger filled debate happening between two camps in the CSS argument, not unlike the Hatfields vs. the McCoys in American folklore. Our CSS Hatfields prefer CSS as it is, and our CSS McCoys prefer Javascript enhanced CSS. (Further reading on each camp is provided at the end of this article.)

The Hatfields believe that CSS is by and large working just fine. The Hatfields accuses the McCoy developers of not understanding and properly using their toolset. The Hatfields see no need for the unholy witchcraft of Javascript to be meddling in the affairs of CSS. “If only they’d learn to use the cascade correctly!” the Hatfields shout.

The McCoys argue we have a CSS spec that is out dated for its current uses. The McCoys believes writing CSS by hand is antiquated and error prone and are frustrated by “leaking” styles and unintended side effects. “If only they’d use our new technology to scope styles!” the McCoys shout back.

Before diligently researching the current state of CSS, it seemed like providing a high level overview of predominant methodologies and frameworks would be a manageable task, one that I could research and write in a few hours. The truth however is that this topic is sprawling, unwieldy, and ignites passionate debate.

But why? And how did we get here? By taking a step back and looking at a very brief history of where Cascading Style Sheets come from, we can get a better context for the contentious topic at hand.

Learning from the Past

On October 10th, 1994, scientist Håkon Wium Lie while working at CERN published the first draft of what would become CSS, a mere three days before Netscape was announced to the public. [W3’s History of CSS] According to the W3 there were around 10 competing specs attempting to serve the same purpose as CSS, but CSS was different because “[i]t took into account that on the Web, the style of a document couldn’t be designed by either the author or the reader on their own, but that their wishes had to be combined, or cascaded, in some way; and, in fact, not just the reader’s and the author’s wishes, but also the capabilities of the display device and the browser.”

Håkon Wium Lie, 1995 (W3’s Brief History of CSS)

Lie’s first implementation of the CSS spec included the concept of user/author influence. During the first demonstration of the spec in November of ’94 “a fictitious screen shot showed a slider with the label user on one side and author on the other. By adjusting the slider, the user could change the mix of his own preferences and those of the author.” [W3’s History of CSS] This was a visual representation of the concept CSS was trying to instill. The original attempt was via explicit percentages for each style. As described by Zack Bloom in The Languages that were Almost CSS, “if a previous stylesheet had defined the h2 font size as 30pt , with 60% ownership, and this stylesheet styled h2 s as 20px 40% , the two values would be combined based on their ownership percentage to get some value around 26pt .”

Looking back from our vantage point this idea seems inherently doomed to fail, and it isn’t surprising that it didn’t end up as part of the specification, but it does point to Lie’s understanding of the need for allowing multiple definitions for the same style to coincide with a sane and coherent way to meld the two together. From this understanding evolved selector specificity, which applies largely arbitrary number values to each element and selector to guarantee stability despite potential conflicts.

In understanding how a technology came to be, it is important to grasp two things: (1) what existing problem does the technology attempt to solve, and (2) why did the currently prevailing technology win out over the competition? In the case of CSS and its competitors in 1994: (1) there was no way to style documents on the web, and (2) CSS won the day because it methodically took into account and addressed the needs of the time (recognizing that author and designer are inextricably linked on the web, adapting to the device displaying the content, recognizing the need for an elegant system to combine multiple sheets with conflicting styles).

How Rules Beget Dogma

A few definitions for clarity:

rule (objective): description of what is possible in a given context.

specification (objective): a collection of related rules for a given context.

guideline (subjective): suggestions to facilitate effectiveness and efficiency in a given context.

methodology (subjective): collection of related rules and guidelines.

dogma (subjective as objective): guideline or collection of rules and guidelines sold as specification.

Rules describe what we can do, guidelines suggest what might be helpful to do. We group related rules (e.g. selector specificity) into specifications (e.g. Cascading Style Sheets). When time is spent with a specification, we gain experience that helps us create guidelines (e.g. avoid overuse of !important in your style sheets) that we can share with each other, so we can avoid repeating our mistakes and increase our productivity. With some creativity, we combine established rules with learned guidelines to create coherent methodologies (e.g. BEM, SMACC, or eCSS) which allow us to work within an emergent system of ideas greater than the sum of their parts.

When guidelines or methodologies become popular wide reaching enough, they tend to take on the miasma of dogma. Dogma is what happens when guidelines and methodologies (subjective) masquerade as rules and specifications (objective).

Image by Chris Coyier. Used with permission.

Dogma Prevents Forward Momentum

DOGMA — a :something held as an established opinion; especially :a definite authoritative tenet b :a code of such tenets c :a point of view or tenet put forth as authoritative without adequate grounds

— Merriam-Webster Dictionary

DOGMATISM — the expression of an opinion or belief as if it were a fact : positiveness in assertion of opinion especially when unwarranted or arrogant

— Merriam-Webster Dictionary

Dogma is not in its own right a bad thing; sometimes a dogma has earned its right to the throne through the thoughtful adoption of a set of rules. We must however guard against the fundamental problem presented by dogma — they are by their nature held to be incontrovertibly true. We forget the original goal the dogma set out to assist with, and the goal becomes replaced by a mass of agreed upon opinions. We can no longer see the forest for the trees.

In the wise words of ESLint creator Nicholas C. Zakas made in a tweet way back in 2013:

Dogmas encourage us to adhere to rules at the cost of creating new ones, especially ideas that speak against the prevailing dogma of the day. Great minds are reduced to scoffing at suggestions that attempt to forge a new path. The larger community becomes embroiled in a heated debate more closely resembling a shouting match than a mature discourse. In the words of Galileo,

To apply oneself to great inventions, starting from the smallest beginnings, is no task for ordinary minds; to divine that wonderful arts lie hid behind trivial and childish things is a conception for superhuman talents. — [“Galileo on Critical Thinking and the Folly of Believing Our Preconceptions,” Brain Pickings]

Mark Dalgleish, creator of CSS Modules echoes the same concern in a tweet from earlier this year:

Chris Coyier, creator of CSS-Tricks and CodePen, closes his thoughtful article My Increasing Wariness of Dogma with practical advise on the matter:

“It’s certainly wordier to avoid dogma when you’re trying to make a point. But it’s more honest. It’s more clear. It’s showing empathy for people out there doing things different. It makes it easier for others to empathize with you.”

Let’s all tap into our superhuman talents and judge ideas based upon how well they solve the problems we are presented with as developers. Let’s share new ideas clearly. More importantly, let’s review and discuss ideas from within the community with empathy. Just as CSS rose to prominence by focusing on solving the problem it was created to solve, so too will we find success by focusing on the goal of problem solving instead of defending established rule sets.