A few common gotchas when using BEM, and how to deal with them.
Friday, March 15th, 2019
Saturday, August 11th, 2018
I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
Tuesday, July 10th, 2018
Components and concerns
But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:
This echoes a point made previously in a slidedeck by Cristiano Rastelli.
Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?
In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:
Your starting point should always be well-structured markup.
This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.
That’s basically an application of starting with the rule of least power.
In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:
We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”
There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.
My point is this:
- Separating structure, presentation, and behaviour is a good idea.
- Separating an interface into components is a good idea.
Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.
Monday, May 7th, 2018
Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!
This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)
Tuesday, August 29th, 2017
Adam Wathan wrote an article recently called CSS Utility Classes and “Separation of Concerns”. In it, he documents his journey through different ways of thinking about CSS. A lot of it is really familiar.
Phase 1: “Semantic” CSS
Ah, yes! If you’ve been in the game for a while then this will be familiar to you. The days when we used to strive to keep our class names to a minimum and use names that described the content. But, as Adam points out:
My markup wasn’t concerned with styling decisions, but my CSS was very concerned with my markup structure.
Phase 2: Decoupling styles from structure
This is the work pioneered by Nicole with OOCSS, and followed later by methodologies like BEM and SMACSS.
This felt like a huge improvement to me. My markup was still “semantic” and didn’t contain any styling decisions, and now my CSS felt decoupled from my markup structure, with the added bonus of avoiding unnecessary selector specificity.
But then Adam talks about the issues when you have two visually similar components that are semantically very different. He shows a few possible solutions and asks this excellent question:
For the project you’re working on, what would be more valuable: restyleable HTML, or reusable CSS?
For many projects reusable CSS is the goal. But not all projects. On the Code For America project, the HTML needed to be as clean as possible, even if that meant more brittle CSS.
Phase 3: Content-agnostic CSS components
Naming things is hard:
The more a component does, or the more specific a component is, the harder it is to reuse.
Adam offers some good advice on naming things for maximum reusability. It’s all good stuff, and this would be the point at which I would stop. At this point there’s a nice balance between reusability, readability, and semantic meaning.
But Adam goes further…
Phase 4: Content-agnostic components + utility classes
Okay. The occasional utility class (for alignment and clearing) can be very handy. This is definitely the point to stop though, right?
Phase 5: Utility-first CSS
Oh God, no!
Once this clicked for me, it wasn’t long before I had built out a whole suite of utility classes for common visual tweaks I needed, things like:
- Text sizes, colors, and weights
- Border colors, widths, and positions
- Background colors
- Flexbox utilities
- Padding and margin helpers
If one drink feels good, then ten drinks must be better, right?
At this point there is no benefit to even having an external stylesheet. You may as well use inline styles. Ah, but Adam has anticipated this and counters with this difference between inline styles and having utility classes for everything:
You can’t just pick any value want; you have to choose from a curated list.
Right. But that isn’t a technical solution, it’s a cultural one. You could just as easily have a curated list of allowed inline style properties and values. If you are in an environment where people won’t simply create a new utility class every time they want to style something, then you are also in an environment where people won’t create new inline style combinations every time they want to style something.
I think Adam has hit on something important here, but it’s not about utility classes. His suggestion of “utility-first CSS” will only work if the vocabulary is strictly adhered to. For that to work, everyone touching the code needs to understand the system and respect the boundaries of it. That understanding and respect is far, far more important than any particular way of structuring HTML and CSS. No technical solution can replace that sort of agreement …not even slapping
!important on every declaration to make them
I very much appreciate the efforts that people have put into coming up with great naming systems and methodologies, even the ones I don’t necessarily agree with. They’re all aiming to make that overlap of HTML and CSS less painful. But the really hard problem is where people overlap.
The older I get, the more every problem in tech seems to be a matter of getting humans to work together effectively, and not tech itself.— Laurie Voss (@seldo) August 23, 2017
Tuesday, June 27th, 2017
Progressing the web
Frances has written up some of the history behind her minting of the term “progressive web app”. She points out that accuracy is secondary to marketing:
I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer.
Personally, I think “progressive web app” is a pretty good phrase—two out of three words in it are spot on. I really like the word “progressive”, with its echoes of progressive enhancement. I really, really like the word “web”. But, yeah, I’m one of those smart-asses who points out that the “app” part isn’t great.
That’s not just me being a pedant (or, it’s not only me being a pedant). I’ve seen people who were genuinely put off investigating the technologies behind progressive web apps because of the naming.
The name is one of the reasons I didn’t look into PWAs 6 months ago. Can we change the name itself? 😎— Julian Gaviria (@juliangav) March 24, 2017
Here’s an article with the spot-on title Progressive Web Apps — The Next Step In Responsive Web Design:
Late last week, Smashing Magazine, one of the largest and most influential online publications for web design, posted on Facebook that their website was “now running as a Progressive Web App.”
Honestly, I didn’t think much of it. Progressive Web Apps are for the hardcore web application developers creating the next online cloud-based Photoshop (complicated stuff), right? I scrolled on and went about my day.
And here’s someone feeling the cognitive dissonance of turning a website into a progressive web app, even though that’s exactly the right thing to do:
My personal website is a collection of static HTML files and is also a progressive web app. Transforming it into a progressive web app felt a bit weird in the beginning because it’s not an actual application but I wanted to be one of the cool kids, and PWAs still offer a lot of additional improvements.
Still, it could well be that these are the exceptions and that most people are not being discouraged by the “app” phrasing. I certainly hope that there aren’t more people out there thinking “well, progressive web apps aren’t for me because I’m building a content site.”
In short, the name might not be perfect but it’s pretty damn good.
What I find more troubling is the grouping of unrelated technologies under the “progressive web app” banner. If Google devrel events were anything to go by, you’d be forgiven for thinking that progressive web apps have something to do with AMP or Polymer (they don’t). One of the great things about progressive web apps is that they are agnostic to tech stacks. Still, I totally get why Googlers would want to use the opportunity to point to their other projects.
Far more troubling is the entanglement of the term “progressive web app” with the architectural choice of “single page app”. I’m not the only one who’s worried about this.
I’ve seen too many devs assume PWA is a subset of SPA. We need to improve our messaging— Jake Archibald (@jaffathecake) June 4, 2016
Here’s the most egregious example: an article on Hacker Noon called Before You Build a PWA You Need a SPA.
No! Not true! Literally any website can be a progressive web app:
Alas, I think that many of the initial poster-children for progressive web apps gave the impression that you had to make a completely separate app/site at a different URL. It was like a return to the bad old days of
m. sites for mobile. The Washington Post’s progressive web app (currently offline) went so far as to turn away traffic from the “wrong” browsers. This is despite the fact that the very first item in the list of criteria for a progressive web app is:
Responsive: to fit any form factor
Now, I absolutely understand that the immediate priority is to demonstrate that a progressive web app can compete with a native mobile app in terms of features (and trounce it in terms of installation friction). But I’m worried that in our rush to match what native apps can do, we may end up ditching the very features that make the web a universally-accessible medium. Killing URLs simply because native apps don’t have URLs is a classic example of throwing the baby out with the bath water:
Up until now I’ve been a big fan of Progressive Web Apps. I understood them to be combining the best of the web (responsiveness, linkability) with the best of native (installable, connectivity independent). Now I see that balance shifting towards the native end of the scale at the expense of the web’s best features. I’d love to see that balance restored with a little less emphasis on the “Apps” and a little more emphasis on the “Web.” Now that would be progressive.
If the goal of the web is just to compete with native, then we’ve set the bar way too low.
So if you’ve been wary of investing the technologies behind progressive web apps because you’re “just” building a website, please try to see past the name. As Frances says:
It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname.
Literally any website can—and should—be a progressive web app. Don’t let anyone tell you otherwise.
I was at an event last year where I heard Chris Heilmann say that you shouldn’t make your blog into a progressive web app. I couldn’t believe what I was hearing. He repeats that message in this video chat:
When somebody, for example, turns their blog into a PWA, I don’t see the point. I don’t want to have that icon on my homepage. This doesn’t make any sense to me.
Excuse me!? Just because you don’t want to have someone’s icon on your home screen, that person shouldn’t be using state-of-the-art technologies!? Excuse my French, but Fuck. That. Shit!
Our imaginations have become so limited by what native mobile apps currently do that we can’t see past merely imitating the status quo like a sad cargo cult.
I don’t want the web to equal native; I want the web to surpass it. I, for one, would prefer a reality where my home screen isn’t filled with the icons of startups and companies that have fulfilled the criteria of the gatekeepers. But a home screen filled with the faces of people who didn’t have to ask anyone’s permission to publish? That’s what I want!
Like Frances says:
Remember, this is for everyone.
Monday, June 26th, 2017
AMP is a symptom that someone, somewhere, thinks the web is failing so badly (so slow, so unresponsive) for a portion of the world that they want to take all the content and package it back up in a sterile, un-webby, branded box. That makes me so sad. PWAs, to me, are a potential treatment.
Thursday, June 22nd, 2017
Breaking down programming tasks into smaller chunks …and naming things.
I’ll take a piece of paper and write the function names I’m going to implement. Or I’ll do it directly in my code editor, with real functions or comments.
It allows you to focus on one problem at a time. When you’re writing those function names, you are thinking about what the code should be doing. When you’re implementing the functions, you are thinking about how the code should do it.
Sunday, June 18th, 2017
A great one-page intro to microformats (h-card in particular), complete with a parser that exports JSON. Bookmark this for future reference.
Monday, March 20th, 2017
Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are:
Tuesday, January 3rd, 2017
I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
Thursday, November 10th, 2016
The video of Charlotte’s excellent pattern library talk that she presented yesterday in Berlin.
Monday, October 10th, 2016
Here’s an epic brain dump by Vitaly on the challenges of putting together a pattern library and then maintaining it.
Sacrificing consistency for usability is fine. A slightly open-ended, inconsistent but heavily used pattern library is better than a perfectly consistent pattern library that is never used.
Monday, September 26th, 2016
The Museum of Wi-Fi exists to preserve these vestiges of our neighbourhood battlefields.
Some are brilliantly smart, some are just purely gross. They all belong in the museum.
Thursday, May 26th, 2016
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.
Wednesday, March 2nd, 2016
There is one truism that has been constant throughout my career on the web, and it’s this: naming things is hard.
Trent talks about the strategies out there for naming things. He makes specific mention of Atomic Design, which as Brad is always at pains to point out, is just one way of naming things: atoms, molecules, organisms, etc.
In some situations, having that pre-made vocabulary is perfect. In other situations, I’ve seen it cause all sorts of problems. It all depends on the project and the people.
Personally, I like the vocabulary to emerge from the domain knowledge of the people on the project. Building a newspaper website? Use journalism-related terms. Making a website about bicycles? Use bike-related terms.
Monday, February 8th, 2016
We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.
Wednesday, January 6th, 2016
A really terrific article from Dan on building pattern libraries. In summary:
- Naming things is hard,
- Separation of content and presentation is A Good Thing.
There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:
When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.
(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)
Friday, July 3rd, 2015
Smart thinking from Harry here on a common issue when it comes to naming and styling. As he points out, the solution is not technical, but lies in how you form your mental model:
The design issue here is solved by subtly inverting the problem.
Saturday, May 30th, 2015
100 words 069
I made mention already of an exercise that myself and Charlotte came up with to help developers to think in terms of granular components: using a humble pair of scissors to cut up screenshots or mockups into their constituent parts.
Recently we repeated and added to this exercise. Once the groups of components are gathered together—buttons, form elements, icons, whatever—we go through each group. Everyone writes on a post-it what name they would give this component—button, formField, icon, etc. Then everyone slaps down their post-it notes at the same time. See any overlap? That’s your class name.