A few common gotchas when using BEM, and how to deal with them.
A really terrific piece from Garrett on the nature of the web:
Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.
I share his concerns about the maintainability overhead introduced by new tools and frameworks:
I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.
Taking the idea of the Clock of the Long Now and applying it to a twitterbot:
Software may not be as well suited as a finely engineered clock to operate on these sorts of geological scales, but that doesn’t mean we can’t try to put some of the 10,000 year clock’s design principles to work.
The bot will almost certainly fall foul of Twitter’s API changes long before the next tweet-chime is due, but it’s still fascinating to see the clock’s principles applied to software: longevity, maintainability, transparency, evolvability, and scalability.
Software tends to stay in operation longer than we think it will when we first wrote it, and the wearing effects of entropy within it and its ecosystem often take their toll more quickly and more destructively than we could imagine. You don’t need to be thinking on a scale of 10,000 years to make applying these principles a good idea.
You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.
Marissa Christy outlines the reasons why your design system might struggle:
- The redesign isn’t prioritized
- The tech stack is changing
- Maintenance takes discipline
But she also offers advice for counteracting these forces:
- Get buy-in from the whole team
- Prioritize a lightweight re-skin on older parts of the product
- Treat a design system like any other product project: start small
- Don’t wait for others. Lead by example.
- Finally, don’t compare yourself to others on the internet
The fascinating results of Brad’s survey.
Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.
That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.
Great advice on writing sensible comments in your code.
A really great case study of a code refactor by Mina, with particular emphasis on the benefits of CSS Grid, fluid typography, and accessibility.
Here’s Zach’s style guide. But the real reason I’m linking to this is his lovely description of having a personal website that grows over time:
As my own little corner of the web unceremoniously turned ten years old this year, it’s really starting to feel more like a garden than a piece of software. I certainly enjoy tending to it. I can plant what I like and with proper care it can grow into something useful.
Oh No! Our Stylesheet Only Grows and Grows and Grows! (The Append-Only Stylesheet Problem) | CSS-Tricks
I think Chris is on to something here when he identifies one of the biggest issues with CSS growing out of control:
The developers are afraid of the CSS.
A really terrific piece by Heydon that serves as a rousing defence of the cascade in CSS. It’s set up in opposition to methodologies like BEM (and there’s plenty of back’n’forth in the comments), but the truth is that every project is different so the more approaches you have in your toolkit, the better. For many projects, something like BEM is a good idea. For others, not so much.
Funnily enough, I’ve been working something recently where I’ve been embracing the approach that Heydon describes—although, to be fair, it’s a personal project where I don’t have to think about other developers touching the HTML or CSS.
This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.
I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.
I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.
Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!
The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.
There’s a lot of really good stuff in here to mull over.
My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.
A talk from Harry on the whys and hows of refactoring CSS. He mentions the
all: initial declaration, which I don’t think I’ve come across before.
Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.
I really like the self-examination that Ian and his team at Lonely Planet are doing here. Instead of creating a framework for creating a living style guide and calling it done, they’re constantly looking at what could be done better, and revisiting earlier decisions.
I’m intrigued by the way they’ve decided to reorganise their files by component rather than by filetype.
Good advice from Chris, particularly if you’re the one who has to live with the CSS you write.
As Obi-Wan Kenobi once said, “You must do what you feel is right, of course.”
Harry has written down his ideas and recommendations for writing CSS.
The challenges of maintaining a living breathing front-end style guide for an always-evolving product (the Lonely Planet website in this case).
Mark Otto talks through the state of Github’s CSS and the processes behind updating it. There’s a nice mix of pragmatism and best practices, together with a recognition that there’s always room for improvement.