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.
Some thoughts on CSS, media queries, and fluid type prompted by Utopia:
We say CSS is “declarative”, but the more and more I write breakpoints to accommodate all the different ways a design can change across the viewport spectrum, the more I feel like I’m writing imperative code. At what quantity does a set of declarative rules begin to look like imperative instructions?
In contrast, one of the principles of Utopia is to be declarative and “describe what is to be done rather than command how to do it”. This approach declares a set of rules such that you could pick any viewport width and, using a formula, derive what the type size and spacing would be at that size.
There’s a lot here that ties in with what I was talking about at New Adventures around the rule of least power in technology choice.
I’m not sure if I agree with describing CSS as being state-based. The example that illustrates this—a
:hover style—feels like an exception rather than a typical example of CSS.
Jon introduces a new tool with a very interesting observation: up until now, all our graphic design tools have been imperative rather than declarative…
With our current tools we’re telling the computer how to design the vision we have in our head (by tapping on our input devices for every element on the screen); in our future tools we will tell our computers what we want to see, and let them figure out how to move elements around to get there.