This looks interesting. On the hand, it’s yet another proprietary creation by one browser vendor (boo!), but on the other hand it’s a declarative API with no JavaScript required (yay!).
Even if this particular feature doesn’t work out, I hope that this is the start of a trend for declarative access to browser features.
It’s very exciting to see the support for popovers—I’ve got a use-case I’m looking forward to playing around with.
Although there’s currently a bug in Safari on iOS (which means there’s a bug in every browser on iOS because …well, you know).
Robin describes his experience of using a design system, having previously been one of the people making and enforcing a design system:
However it’s only now as a product designer that I realize just how much I want the design system to carefully guide me instead of brute-forcing its decisions onto my work. I want to fall into the loving embrace of the system because I don’t wanna have to think about hex values or button sizes or box shadows. I don’t want to rethink padding and margins or rethink the grid each time I design a page.
But by golly if a design system says “no” to me then I will do my very best to blow it up.
Here’s a taste of what Rich will be delivering at Patterns Day on Thursday—can’t wait!
This is an interesting idea from Scott—a templating language that doesn’t just replace variables with values, but keeps the original variable names in there too.
Not sure how I feel about using data- attributes for this though; as far as I know, they’re intended to be site-specific, not for cross-site solutions like this.
This is a really interesting proposal, and I have thoughts.
I suspect most people on opposing sides of the Tailwind debate actually complete agree on Tailwind itself. I don’t think we disagree on atomic CSS, or utility classes; I think our contention comes from the valuations we made long before we ever chose our tools. Where one of us sees a selling point, the other sees a flaw.
This is very much in line with what I’ve been talking about in my presentation on declarative design.
As Jeremy Keith put it so well: where it comes to styling, Builders want imperative programming; they want to specify what they want, where they want, how they want it. No surprises.
Crafters instead want declarative programming; they understand how to wield the power of creating rules of governance within a complex system, and wish to use that power, rather than micromanaging the browser.
Bruce raises an interesting question with media playing in popovers—shouldn’t the media pause when the popover is closed? I agree with Bruce that this is a common use case that should be covered declaratively.
Oliver asked me some questions about my upcoming talk at Pixel Pioneers in Bristol in June. Here are my answers.
Here’s the video of the talk I gave at Monday’s meet-up here in Brighton—it’s a very condensed version of my longer conference talk on declarative design.
I feel like we need a name for this era, when CSS started getting real good.
I think this is what I’ve been calling declarative design.
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 like to think of CSS as a conditional design language.
Yes! This is exactly what I’m talking about with declarative design!
Read on for some fantastic examples. And also, Ahmad makes a comparison between CSS and Figma, pointing out that the conditional, declarative possibilities currently aren’t available in graphic design tools.
James describes his process for designing fluid grid layouts, which very much involves working with the grain of the web but against the grain of our design tools:
In 2022 our design tools are still based around fixed-size artboards, while we’re trying to design products which scale gracefully to suit any screen.
If, like me, you despair at the tech stacking and JavaScriptification of everything, shut that out and pay attention to those who understand the material of the web, its inherent resilience and efficiency. We’re lucky that principled voices still advocate for simple and inclusive methods because building with efficiency and a lightness of touch makes the work feel meaningful and, sometimes, fun.
I wrote a while back about descriptive and prescriptive design systems—and a follow-up post—but I didn’t realise there was such a thing as descriptive and prescriptive engineering.
Jim shares his thoughts on my recent post about declarative design systems. He picks up on the way I described a declarative design systems as “a predefined set of boundary conditions that can be used to generate components”:
I like this definition of a design system: a set of boundaries. It’s about saying “don’t go there” rather than “you can only go here”. This embraces the idea of constraints as the mother of invention: it opens the door to creativity while keeping things bounded.
This is really interesting. I hadn’t thought too much about the connection between design engineering and declarative design before now, but Jim’s post makes the overlap very clear indeed.
Some interesting thoughts from Tim here. What if CSS could “displace” design decisions from one area to another?
For example, a flexible line spacing value in one container could influence margins that surround the text block. That change in spaciousness may mean that nearby headings need size or spacing adjustments to stay feeling connected.
This feels like the complete opposite way that most people approach design systems—modular, componentised, and discrete—but very in-line with the way that CSS has been designed—interconnected, relational and cascading.
To complement her talk at Beyond Tellerrand, Stephanie goes through some of the powerful CSS features that enable intrinsic web design. These are all great tools for the declarative design approach I was talking about: