There’s a broader point here about declarative design:
Setting very specific values may feel like you’re in more control, but you’re actually rescinding control by introducing fragility in the form of overly-specific CSS.
I’m subscribed to a lot of blogs in my RSS reader. I follow some people because what they write about is very different to what I know about. But I also follow lots of people who have similar interests and ideas to me. So I’m not exactly in an echo chamber, but I do have the reverb turned up pretty high.
Sometimes these people post thoughts that are eerily similar to what I’ve been thinking about. Ethan has been known to do this. Get out of my head, Marcotte!
But even if Ethan wasn’t some sort of telepath, he’d still be in my RSS reader. We’re friends. Lots of the people in my RSS reader are my friends. When I read their words, I can hear their voices.
Then there are the people I’ve never met. Like Desirée García, Piper Haywood, or Jim Nielsen. Never met them, don’t know them, but damn, do I enjoy reading their blogs. Last year alone, I ended up linking to Jim’s posts ten different times.
Or Baldur Bjarnason. I can’t remember when I first came across his writing, but it really, really resonates with me. I probably owe him royalties for the amount of times I’ve cited his post Over-engineering is under-engineering.
His latest post is postively Marcottian in how it exposes what’s been fermenting in my own mind. But because he writes clearly, it really helps clarify my own thinking. It’s often been said that you should write to figure out what you think, and I can absolutely relate to that. But here’s a case where somebody else’s writing really helps to solidify my own thoughts.
Which type of novelty-seeking web developer are you?
It starts with some existentialist stock-taking. I can relate, what with the whole five decades thing. But then it turns the existential questioning to the World Wide Web itself, or rather, the people building the web.
In a way, it’s like taking the question of the great divide (front of the front end and back of the front end), and then turning it 45 degrees to reveal an entirely hidden dimension.
In examining the nature of the web, he hits on the litmus of how you view encapsulation:
I mention this first as it’s the aspect of the web that modern web developers hate the most without even giving it a label. Single-Page-Apps and GraphQL are both efforts to eradicate the encapsulation that’s baked into the foundation of every layer of the web.
Most modern devs are trying to get rid of it but it’s one of the web’s most strategic advantages.
I hadn’t thought of this before.
By default, if you don’t go against the grain of the web, each HTTP endpoint is encapsulated from each other.
Moreover, all of this can happen really fast if you aren’t going overboard with your CSS and JS.
He finishes with a look at another of the web’s most powerful features: distribution. In between are the things that make the web webby: hypertext and flexibility (The Dao of the Web).
It’s the idea that the web isn’t a single fixed thing but a fluid multitude whose shape is dictated by its surroundings.
This resonates with me because it highlights two different ways of viewing the web.
On the one hand, you can see the web purely as a distribution channel. In the past you might have been distributing a Flash movie. These days you might be distributing a single page app. Either way, the web is there as a low-friction way of getting your creation in front of other people.
The other way of building for the web is to go with the web’s grain, embracing flexibility and playing to the strengths of the medium through progressive enhancement. This is the distinction I was getting at when I talked about something being not just on the web, but of the web.
With that mindset, Baldur then takes us through some of the technologies that he’s excited about, like SvelteKit and Hotwire. I think it’s the same mindset that got me excited about service workers. As Baldur says:
They are helping the web become better at being its own thing.
That’s my tagline right there.
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.
This post absolutely nails what’s special about CSS …and why supersmart programmers might have trouble wrapping their head around it:
Other programming languages often work in controlled environments, like servers. They expect certain conditions to be true at all times, and can therefore be understood as concrete instructions as to how a program should execute.
CSS on the other hand works in a place that can never be fully controlled, so it has to be flexible by default.
Max goes on to encapsulate years of valuable CSS learnings into some short and snappy pieces of advices:
No matter what your level of CSS knowledge, this post has something for you—highly recommended!
This is a really good explanation of the difference between context-aware layouts—that we’ve had up until now—and content-aware layouts, which are now possible with CSS grid:
With the
min-content,max-contentandautokeywords, we can size grid tracks based on their content. I think this is very cool. If we manage to embrace as much of the web’s flexibility as we can, we can get the most out of these tools, and let CSS help us with designing for the unknown.
CSS Grid is easy to use but difficult to learn. It’s a more intuitive paradigm than any other CSS layout technique, but it’s completely different from its predecessors.
Some great advice here on how to approach CSS grid:
- Use names, not numbers
- Use fr as your flexible unit
- Don’t use a grid system
A well-written (and beautifully designed) article on the nature of the web, and what that means for those of us who build upon it. Matthias builds on the idea of material honestly and concludes that designing through prototypes—rather than making pictures of websites—results in a truer product.
A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.
The slides from Yesenia’s talk on scenario-driven design.
Whenever you plan or design a system, you need to build in your own ashtrays—a codified way of dealing with the inevitability of somebody doing the wrong thing. Think of what your ideal scenario is—how do you want people to use whatever you’re building—and then try to identify any aspects of it which may be overly opinionated, prescriptive, or restrictive. Then try to preempt how people might try to avoid or circumvent these rules, and work back from there until you can design a safe middle-ground into your framework that can accept these deviations in the safest, least destructive way possible.
Words of wisdom from Scott on the clash of brand guidelines and the flexible nature of the web:
One thing I am pretty sure of though, is that having a fast, accessible, user-friendly site can reflect incredibly well on a company, and I’d love to see more guidelines and expectations that prioritize these aspects of a service as branding requirements in addition to the usual visual details.
Cameron has put all the materials from his four-part series together in one handy spot.