The CSS Holy War & How To Think Beyond Dogma
In which we look at the state of CSS and how dogma impedes progress.
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 …
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.”
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
60% ownership, and this stylesheet styled
20px 40%, the two values would be combined based on their ownership percentage to get some value around
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).
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
DOGMATISM — the expression of an opinion or belief as if it were a fact : positiveness in assertion of opinion especially when unwarranted or arrogant
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.
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:
“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.
Selection of Hatfield articles:
- CSS in Not Broken by Kieth J. Grant
- CSS If Fine, It’s Just Really Hard by Jordan Scales
- In Defense of CSS by Liam Campbell
Selection of McCoy articles:
- CSS is Broken by Sergio Zamarro
- CSS Sucks by Shaun Bent
- Is CSS Condemned to Suck Forever? by Vincent Navetat
- CSS Is Broken: My Dime-a-Dozen Opinion by Jeremy Wagner