640

I don’t have time to learn React - Keith Cirkel

React is a non-transferable skill.

React proponents might claim that React will teach you modern UI, but from what I’ve seen it barely copes with modern UI. autofocus is broken, custom elements don’t work in all but the experimental version, using any “modern” features like dialog or popovers requires useEffect, and the synthetic event system teaches you so little about how DOM actually works. This isn’t modern UI, it’s UI from 2013 at its inception. I don’t have the time left in my career to pick up UI paradigms that haven’t evolved much beyond from when Barack Obama was in office.

When I mentor early career developers and they ask me what they should learn, I can’t say React, they don’t have time. I mean sure, pick up enough React to land you the inevitable job doing it, but it’s not going to level up your career.

There are different kinds of buzzwords.

Some buzzwords are useful. They take a concept that would otherwise require a sentence of explanation and package it up into a single word or phrase. Back in the day, “ajax” was a pretty good buzzword.

Some buzzwords are worse than useless. This is when a word or phrase lacks definition. You could say this buzzword in a meeting with five people, and they’d all understand five different meanings. Back in the day, “web 2.0” was a classic example of a bad buzzword—for some people it meant a business model; for others it meant rounded corners and gradients.

The worst kind of buzzwords are the ones that actively set out to obfuscate any actual meaning. “The cloud” is a classic example. It sounds cooler than saying “a server in Virginia”, but it also sounds like the exact opposite of what it actually is. Great for marketing. Terrible for understanding.

“AI” is definitely not a good buzzword. But I can’t quite decide if it’s merely a bad buzzword like “web 2.0” or a truly terrible buzzword like “the cloud”.

The biggest problem with the phrase “AI” is that there’s a name collision.

For years, the term “AI” has been used in science-fiction. HAL 9000. Skynet. Examples of artificial general intelligence.

Now the term “AI” is also used to describe large language models. But there is no connection between this use of the term “AI” and the science fictional usage.

This leads to the ludicrous situation of otherwise-rational people wanted to discuss the dangers of “AI”, but instead of talking about the rampant exploitation and energy usage endemic to current large language models, they want to spend the time talking about the sci-fi scenarios of runaway “AI”.

To understand how ridiculous this is, I’d like you to imagine if we had started using a different buzzword in another setting…

Suppose that when ride-sharing companies like Uber and Lyft were starting out, they had decided to label their services as Time Travel. From a marketing point of view, it even makes sense—they get you from point A to point B lickety-split.

Now imagine if otherwise-sensible people began to sound the alarm about the potential harms of Time Travel. Given the explosive growth we’ve seen in this sector, sooner or later they’ll be able to get you to point B before you’ve even left point A. There could be terrible consequences from that—we’ve all seen the sci-fi scenarios where this happens.

Meanwhile the actual present-day harms of ride-sharing services around worker exploitation would be relegated to the sidelines. Clearly that isn’t as important as the existential threat posed by Time Travel.

It sounds ludicrous, right? It defies common sense. Just because a vehicle can get you somewhere fast today doesn’t mean it’s inevitably going to be able to break the laws of physics any day now, simply because it’s called Time Travel.

And yet that is exactly the nonsense we’re being fed about large language models. We call them “AI”, we look at how much they can do today, and we draw a straight line to what we know of “AI” in our science fiction.

This ridiculous situation could’ve been avoided if we had settled on a more accurate buzzword like “applied statistics” instead of “AI”.

It’s almost as if the labelling of the current technologies was more about marketing than accuracy.

New CSS that can actually be used in 2024 | Thomasorus

Logical properties, container queries, :has, :is, :where, min(), max(), clamp(), nesting, cascade layers, subgrid, and more.

Help us choose the final syntax for Masonry in CSS | WebKit

I really like the way that the thinking here is tied back to Bert Bos’s original design principles for CSS.

This is a deep dive into the future of CSS layout—make a cup of tea and settle in for some good nerdiness!

Living In A Lucid Dream

I love the way that Claire L. Evans writes.

First Impressions of the Pixel 9 Pro | Whatever

At this point, it really does seem like “AI” is “bullshit you don’t need or is done better in other ways, but we’ve just spent literally billions on this so we really need you to use it, even though it’s nowhere as good as what we were already doing,” and everything else is just unsexy functionality that makes what you do marginally easier or better. I’m sorry we live in a world where enshittification is being marketed as The Hot And Sexy Thing, but just because we’re in that world, doesn’t mean you have to accept it.

The goal isn’t to write less code | Go Make Things

The goal isn’t to write less code.

It’s to ship less code to users. Better code. Faster code. More resilient code.

THIS!

Sooooo many front-end developers don’t grasp this fundamental principle: it’s not about you!

Frostapalooza – Chris Coyier

The show itself was an unbelievable outpouring of energy and love. I couldn’t help but imagine if anyone in the audience had decided to go on a lark, not knowing anything about it. I would think they would have been pretty damn impressed. This wasn’t just a couple of nerds poking around at instruments (except me), these were some serious musicians giving it their all.

Generative AI Is Not Going To Build Your Engineering Team For You - Stack Overflow

People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.

The present wave of generative AI tools has done a lot to help us generate lots of code, very fast. The easy parts are becoming even easier, at a truly remarkable pace. But it has not done a thing to aid in the work of managing, understanding, or operating that code. If anything, it has only made the hard jobs harder.

Home-Cooked Software and Barefoot Developers

A very thought-provoking presentation from Maggie on how software development might be democratised.

The deskilling of web dev is harming the product but, more importantly, it’s damaging our health – this is why burnout happens – Baldur Bjarnason

A depressing but accurate description of the economics of web development.

RFC: Initial CSS Level Categorization · CSS-Next/css-next · Discussion #92

A proposal to retroactively classify additions to CSS in order to put more meat on the bones of the term “modern CSS”.

• Download the slides
• Watch the video

I want to talk to you today about declarative design. But before I get to that I want to talk to you about music.

I want to talk about two different approaches to musical composition. I want to compare and contrast.

Classical

On the one hand, I’ll take this man as an example. This is Wolfgang Amadeus Mozart, a classical composer. He’s got this amazing music in his head and he can get that down onto sheet music which is very specific, very accurate. You can note down what notes to play, how long to play each note for each instrument, even some instructions on how to play the music.

So very accurate, very specific. That’s one approach to to musical composition.

Jazz

The other approach is very different and I’m going to use this man as an example. This is Miles Davis, from the jazz side of things. And his approach to composition was very different to Mozart.

Take something like his classic album, Kind Of Blue. He comes into the studio with sketches, with maybe some scales and no rehearsal for the musicians. And what resulted was absolutely amazing!

Like So What?, the opening track. That’s where the instructions were literally “Let’s do 16 bars in D Dorian then another eight bars and D flat Dorian and go back to D Dorian eight bars.” That’s as much structure as there is. And what comes out is absolutely amazing.

So these are two different approaches to musical composition: the classical and the jazz approach. Very different styles.

I think there’s a corresponding kind of split that you can see in the world of programming. You can divide programming into two different categories as well.

Imperative programming

On the one hand you’ve got imperative programming. Most programming languages are imperative programming languages. This is where you describe step-by-step what the computer should do. You give it clear instructions. Very specific. This makes it very powerful. It makes it general purpose. Maybe hard to learn because there’s a lot you have to understand before you can write those instructions.

Classic pseudo-code for an imperative language would be something like this. These step-by-step instructions:

• create an array of stuff,
• loop through each item,
• check to see if a condition is true,
• return the result.

You’ve got arrays and loops and ifs and else’s and returns: all the classic bits that go into general purpose imperative programming languages.

Declarative programming

The other category of programming language is declarative programming. This is where you don’t give step-by-step instructions to the computer. Instead you describe the outcome you want and you leave the implementation details to the to the language. You don’t describe the specific steps.

These are often domain-specific. They’re usually not general purpose languages and they’re probably less powerful than imperative languages. But on the other hand they may be easier to learn because you don’t have to get into all the the nitty-gritty that you do with an imperative programming language.

A classic example of a declarative programming language would be something like Structured Query Language or SQL. You describe what you want. You leave the details to the database. So you write something practically in English here:

select items from table where condition is true

Now it might be that under the hood the programming language is going to create an array of items, loop through each one, check if the condition is true and return the result but you don’t need to care about that. You don’t have to write those specific instructions. You describe the outcome you want.

Those are the two categories of programming language: imperative and declarative.

With that in mind let’s turn our attention to the medium where I work and I’m sure a lot of you do as well, which is the World Wide Web.

The World Wide Web

Let’s go back to the the birth of the World Wide Web, which is thanks to this gentleman. This is Sir Tim Berners-Lee working at CERN in the 1980s. He’s trying to solve the problem that there’s just so much information and how to manage it. So he writes this memo, this proposal. Information Management: A Proposal.

Terrible title, riddled with typos, incomprehensible diagrams and yet his supervisor Mike Sendall must have seen some some promise in it because he scrolled across the top:

vague but exciting.

This was March 1989. Tim Berners-Lee gets to go ahead to do that information management project which turns into the World Wide Web.

Now Tim Berners-Lee had some ideas about how to approach programming in general but also information management. He’s got design principles.

The principle of least power

For example, one of the principles he wants to adhere to is the principle of least power. The principle of least power states that:

for any given purpose, choose the least powerful language

…which sounds really counterintuitive. Why on Earth would I choose a less powerful language to accomplish what I want to do?

But this goes back to the declarative/imperative split, because the less powerful language may also be easier to learn, maybe more robust, less fragile.

HTML

He certainly puts that into practice when he creates HTML which is very much a declarative language. The classic case of a declarative language. It’s domain-specific. It’s for the web only.

Interestingly it’s fault-tolerant. By that I mean if you write some HTML and you make a mistake or you just type out an element that doesn’t even exist, the browser doesn’t throw an error . It doesn’t refuse to render any of the HTML that comes after that mistake. It just ignores what it doesn’t understand and carries on.

That actually turns out to be very powerful and I think maybe it’s only possible because HTML is a is a declarative language.

CSS

A couple of years later we get the next language on the web which is CSS. This is also a declarative language. It is also fault tolerant. If you’re writing CSS and you give the browser something it doesn’t understand it doesn’t choke on it. It just ignores it and carries on processing the style sheet. Again that’s very powerful.

But you might be thinking, “Hang on— CSS? Declarative? No no no, surely when I’m writing CSS I’m telling the computer exactly what to do? I’m telling the computer exactly how to style things.”

No. You’re not. It’s worth remembering with CSS you’re not telling the browser to do anything you’re making suggestions. Eric Meyer once said that every line of CSS is a suggestion to the browser. I think that’s worth bearing in mind.

Cascading HTML Style Sheets

Now CSS did not come from Tim Berners-Lee. The original proposal came from Håkon Wium Lie in an email in 1994. The original proposal was called Cascading HTML Style Sheets and he puts forward some ideas for how this could look.

h1.font.size = 24pt 100%
h2.font.size = 20pt 40%

This isn’t what we ended up with. You can see the syntax isn’t like the CSS today but you can kind of make sense of it. You can kind of understand what’s going on. I see this is setting the font size of all the H1s to 24 points and all the H2s to 20 points.

But hang on. What’s going on here with these percentages? 100? 40?

Well, what the percentages indicate is this early idea called influence in CSS where you as the author would basically specify how much do you care about this particular style. Like 100, I really want the H1s to be 24 points. But 40, I don’t care so much.

Influence

The idea was that that there were these competing concerns. There’s you, the author of the style sheet, the person making the website. There’s the browser itself which will have opinions in the user agent style sheets about how things should be styled. And really importantly, the user. The user should also have a say.

And this was the default in early browsers. You would have user style sheets—not user agent style sheets—user style sheets so the user could specify how they wanted things.

The idea with influence was that the browser would somehow hand-wavingly figure out exactly the right number to come up with. It obviously didn’t work. And we don’t have user style sheets anymore in any of the major browsers, which is a real shame. You can install browser extensions to do the same thing so it’s a bit of a power user feature, although if anyone’s played around with The Arc browser they’ve kind of got a similar thing. They call it boosts but it’s basically like user style sheets.

Preference queries

I do see almost a little bit of resurgence of this idea of influence though coming back into CSS. I see it in media queries level five where we have the so-called preference queries, where now the user can at least specify their preference, usually at the operating system level. Like I prefer reduced motion. I prefer reduced data. I prefer a dark color scheme.

Now it’s not quite the same as influence because it’s it’s up to us as developers to honor those preferences. But I like it because it’s again getting back to not thinking of CSS about giving precise instructions but it turns it into more of a dialogue with the user. Instead of the designer dictating their wishes upon all the users, it’s more like a conversation.

“What do you want? What do you care about?”

“Well, here’s what I care about. Let’s come to some kind of agreement.”

I like that. I think that’s good. I want to see more of that kind of dialogue happen on the web rather than just us dictating to users.

JavaScript

There’s one final language on the web. That’s JavaScript. That came along a few years later.

This is not a declarative language. This is an imperative language which makes it more powerful. You can do a lot more with JavaScript.

But JavaScript is not fault tolerant. In other words if you do make a mistake in your JavaScript or give the browser something it doesn’t understand it will stop at that point it will not parse any further. So it’s less resilient than HTML or CSS.

So this is what we have on the front end of the web. These three languages: HTML, CSS ,and JavaScript. Two declarative and fault-tolerant languages. One imperative language that isn’t fault tolerant.

Fault tolerance

I fell into a trap of thinking for a while “Oh, all declarative languages are fault-tolerant.” I guess I was seeing causation where there’s just correlation. That’s not true. You can absolutely make a declarative language that is not fault-tolerant.

In fact XML is a perfect example. The parsing instructions for XML say “if you see a mistake, stop: do not render anything; just quit right then.”

So not all declarative languages are fault tolerant. But I think we’re lucky on the web that the two we have are fault tolerant. I think that makes the web more accessible to people.

I think it would be very hard to make a fault-tolerant imperative language. It would be impossible to debug an imperative language if it just ignored what it didn’t understand and carried on.

This is kind of how I like to approach building on the web, in this order:

1. the foundations of HTML for the structure,
2. I’ll layer on my suggestions for styling with CSS and then, if I need to,
3. I’ll reach for JavaScript to do the more powerful behavioral stuff.

Mindset

So in programming we’ve got these two approaches, these two categories of programming languages: imperative and declarative. But I think more importantly what we have is two different mindsets, two ways of approaching how you solve a problem: an imperative way and a declarative way. And the kind of mindset you have will probably influence the kind of languages you prefer, the kind of languages you gravitate towards.

Let’s take a a problem we’re trying to solve on on the web where we want to make a component, a button component.

How will we go about making this button component? Because a nice thing on the web is there’s no one way of doing things. You can do things however you like.

One approach would be a very imperative way. We reach straight for JavaScript. We’d have the bare minimum HTML, just a div or something. Throw in a bunch of event handlers to handle those clicks. Don’t forget you got to handle keyboard support as well. Got to make sure it’s accessible too so you’ll need to put in some ARIA roles and all that stuff.

So that’s one way to do it.

Or just use a freaking button element.

This would be the declarative approach.

So which approach would you go for?

Now I know what I would do. Mostly because I’m just lazy. I don’t want to have to do all this when I can do this. I’m absolutely going to reach for the declarative approach, which kind of reflects my general approach with client-side JavaScript on the web which is:

JavaScript should only do what only JavaScript can do.

That means if there’s a way of doing it in HTML or CSS, do it in HTML or CSS. Only reach for JavaScript when you when you absolutely need to.

(This is client-side Javascript I’m talking about here. When you’re doing something on a server do what you want. It’s a different environment. I’m talking about in the browser on the World Wide Web.)

Okay, so I know how I would do it. But I’m trying to understand why would anybody do this? Why would anybody reach for JavaScript immediately and do the over-engineered version?

I don’t want to just think “Oh, they don’t know what they’re doing!” That doesn’t feel right. I want to understand the mindset that’s going on.

I’m going to reach for a button element because I get so much for free. I get some styling for free but I can change it. I get interactivity for free. I get the keyboard support for free. It’s accessible by default. So if the browser gives you all the styling and behavior for free, why would you invent everything from scratch and reject that?

I think it’s about control.

Control

This goes back to that mindset. I think if you have this imperative mindset then control is probably a priority. You want to understand exactly how things work in precise step-by-step instructions. I feel like people with this imperative mindset, they’re probably coming from a computer science background where you’re used to specifying everything very precisely. And if that’s your attitude then those free stylings and behavior you get from the browser, those aren’t features— they’re bugs.

Because, well, what if there’s some unintended side effects? If you haven’t written it yourself how do you know how it’s going to behave in every situation? You don’t. Whereas if you invent everything from scratch it feels like you’ve got total control.

Declarative approaches can feel like giving up control: I’m going to leave the details to the web browser, I’m going to trust that the web browser handles the keyboard support and accessibility.

But I feel like this control comes at a cost. I’m not sure you really gain control. I think you get the feeling of control. But it always involves making assumptions, whereas a declarative mindset is about avoiding assumptions.

Assumptions

Let me illustrate what I mean. To illustrate this I’m going to use a declarative language but show you how the mindset could still be imperative.

Let’s say we’ve got a button and we want to style it so we’re going to use CSS, a declarative language. I might write some CSS like this:

button {
  font-size: 16px;
  padding-left: 16px;
}

Absolutely nothing wrong with the CSS. Font size 16 pixels, padding left 16 pixels, on a button. That’s fine.

But is that what I really mean?

When I say font-size: 16px do I really mean the default browser font size? (which is 16 pixels most of the time)

I could be more intentional about this. When I say 16 pixels what I mean is the default browser font size: one rem.

button {
  font-size: 1rem;
  padding-left: 1rem;
}

Now if the user changes their default font size my button will change accordingly. I’ve removed that assumption that the default browser font size is always going to be 16 pixels.

Actually when I say padding-left is one rem, do I really mean padding -*left*? Or do I mean the padding at the start of the text?

If that’s what I mean then I can say that. I can say padding-inline-start is one rem.

button {
  font-size: 1rem;
  padding-inline-start: 1rem;
}

Now inline-start is the same as left if it’s a left-to-right language like English. But I’m making an assumption that it’s going to be presented in a left-to-right language like English when I use padding-left.

This is again removing that assumption. I might not have any plans to translate my website myself, but users can translate my website. It’s more of that that two-way conversation with the user. If they want to do that, let’s allow them to do that. So again I’ve removed an assumption there.

But if I want to really get into a conversation with the user and how they come to me to look at this website I could start to adjust the font size to be relative to their browser width by using the the viewport width unit here: vw.

button {
  font-size: calc(0.5rem + 0.666vw);
  padding-inline-start: 1rem;
}

I throw it into a calc with a bit of rem. The reason I’m doing this is that if you just use viewport width then the font size can’t respond to changing. So mixing it up with a relative unit like this keeps it accessible; people can change their their font size.

But the point here is that the text in the button now could change depending on the browser width. I could do that with media queries but then you’d be jumping at these different break points. This keeps it fluid the whole time.

But maybe I’ve gone too far here. Because maybe at small sizes it’s going to get way too small and at large screen sizes is going to get way too big. That’s okay. I can put guard rails in place.

button {
  font-size: clamp(
    1rem,
    0.5rem + 0.666vw,
    1.5rem
  );
  padding-inline-start: 1rem;
}

We’ve got this clamp function in CSS. In the middle I’ve got the same declaration I had before( but I don’t even need to use calc when I use clamp) but what I’ve got on either side is like a minimum and a maximum: don’t ever go below one rem and don’t ever go above 1.5 rems. Let it flow in between those.

Now the truth is I probably wouldn’t do this on a button element. I’d probably want my whole interface to to respond like this. So I’d probably do it on the body and say let the font size adjust. It’s going to be relative to the the viewport but it’s never going to be lower than that it’s never going to be higher than that. And then you end up with an interface that just scales fluidly with font size.

Now I’ve kind of given up a lot of control here. Because if you were to ask me “What is the font size when the screen width is 1024 pixels wide?”my answer would be “I don’t know …but I know it’ll look good.”

I know that everything will be in proportion and I know it will never get too small and it’ll never get too big.

In a way I’m giving up control so that I can have more of that dialogue with the user, more of that conversation.

Utopia

This idea of fluid typography—and fluid spacing as well—is what’s at the heart of a project called Utopia I highly encourage you to check out utopia.fyi

Full disclosure: Utopia started life at Clearleft, the agency I work at. It’s the work of Trys Mudford and James Gilyead.

It’s kind of like clamp on steroids. You set the boundary conditions. In this case it’s what type scale you want to use. And that type scale is probably going to be different for small screens than large screens. So you might say for small screens I want my type scale to be 1.2. That’s the the ratio. But on the large screen I want a larger type scale: 1.3.

So you specify those those edges and then you let the browser figure it out. It does the calculations. Figures it out for you.

I like this diagram that James put together for it where it shows I designed the minimum and the maximum and then maths figured out the in-between. Handing over those controls.

I think it’s this great use of machines and humans working together, doing what they’re best at. Because you got the human defining the boundary conditions, doing the design. And then handing over to the machine to do the calculations, to do the maths, which is what machines are good at.

You know when Steve Jobs described computers as a bicycle for the mind? I wonder can CSS be a bicycle for design? Where it’s amplifying design. You set the boundary conditions and then the browser does all the in-between.

Because CSS now is full of these functions that that work like this, where you give it the edges, you give it the boundary conditions and then it figures out the specifics. It does the calculations. It does the maths for you.

calc()
clamp()
min() and max()
fit-content
min-content and max-content
repeat()
minmax()

Intrinsic web design

This all opens up whole new ways of designing for the web that some people have been exploring. Jen Simmons in particular. She calls this intrinsic web design. She’s got a YouTube channel called Layout Land. It’s well worth checking out.

Watching her talks on this but I feel like it’s kind of got the same mindset that the Utopia project has: defined boundary conditions; let the browser figure out the specifics.

Be the browser’s mentor, not its micromanager

Every-Layout.dev is a project from Heydon Pickering and Andy Bell. It’s a book with various designs you can you can implement. Well worth checking out. I feel like the same mindset is there as well.

Even if you don’t buy the book it’s worth going to the website and reading the thinking behind it. If you go to the axioms there’s a quote there that says:

Instead of thinking of designing for the web as creating visual artifacts, think of it as writing programs for generating visual artifacts.

Declarative programs I would say.

Andy Bell,one of the guys behind that,he also built this website for a conference talk that’s called Build Excellent Websites. The talk was called “Be the browser’s mentor, not its micromanager”. Chef’s kiss! I think that is exactly what I’m trying to get at here:

Give the browser some solid rules and hints then let it make the right decisions for the people that visit it.

That’s exactly what I’m getting at!

Declarative design

So I feel like there’s something here. There’s this kind of declarative approach to design I’m trying to put my finger on and feel like they all share a mindset, a declarative mindset.

Now am I then saying that the the declarative approach is inherently better than the imperative approach?

The answer to that question is …it depends

…which is a bullshit answer. Anytime someone gives you this answer to a question you must follow up with the question, “it depends on what?”

Culture

In this case, whether the declarative approach is inherently better than an imperative approach depends on …culture, for one thing. The culture of the organization that’s producing the website, the culture of the organization that’s shipping.

Companies have different cultures which manifest in different ways, like management: how a company does management.

I think you could you could divide management into two categories like you can do with programming languages. There is a very imperative school of management where it’s all about measurements, it’s all about those performance reports, it’s all about metrics, time tracking. Maybe they install software on your machine to track how long you’ve been working. It’s all about measuring those outputs.

That’s one approach to management. Then there’s a more declarative approach, where you just care about the work getting done and you don’t care how people do it. So if they want to work from home, let them work from home. If they want to work strange hours, let them work strange hours. What do you care as long as the work gets done? This is more about giving people autonomy and trust

Now I know which approach I prefer and I would say at Clearleft we’ve definitely got a declarative approach. We give people lots of autonomy and trust.

That’s not always necessarily a good thing. If someone’s coming from an imperative background and on the first day of work is told “hey you’re a designer, you solve the problem; we’re not going to tell you what to do” people can really flounder if they’re not used to that level of autonomy and trust.

So again I’m not saying one is is right or wrong. I know which place I’d rather work at but I’m not saying one is is right and the other is wrong.

So companies have different cultures. There’s no one-size-fits-all way of thinking that will work for all company cultures.

Culture is one of those things that’s usually implicit and it’s unspoken. It’s rarely made explicit. It can be made explicit and one of the ways I think you can make a company culture explicit is through design systems.

Design systems

I know when normally we think of design systems we’re thinking of component libraries. We’re thinking of interface elements gathered together. To me that’s not what the design system is. My favorite definition of design systems comes from Jina Anne who knows a lot about design systems and she said that design systems are “the way we do things around here.”

I think focusing on those those components is maybe focusing on the the artifacts.

It will come as no surprise to you that I think you can kind of divide design systems into two categories. What are those categories? Imperative and declarative.

Before I look at how we divide design systems into imperative and declarative design systems I’m going to take a step back and talk about how we think about thinking.

I’m going to get meta here. And I don’t mean just on the web I mean how we approach problem solving as human beings.

Analytical thinking

I think there are two different ways historically to approach thinking and problem solving. One is analytical thinking. This isn’t new. This goes back centuries. This is what Emmanuel Kant was talking about in his critique of pure reason.

With analytical thinking you understand how something works by breaking it down into its constituent parts. This is what underpins the scientific method. It’s really, really useful for things that work exactly the same way everywhere in the universe: chemistry and physics and mathematics. I would say it’s probably not so great when you’re dealing with messy unpredictable things like human beings but analytical thinking has served us very, very well in our civilization.

Sytems thinking

On the other hand you’ve got systems thinking, which is almost the opposite of analytical thinking, where you understand the parts by looking at how they all work together as a whole.

To be very crude about it, analytical thinking is about zooming in and systems thinking is about zooming out.

So with that in mind let’s look at design systems.

Well the word “system” is right there in the title so surely what we’re talking about here is systems thinking, right?

Surprisingly most design systems to me seem to exhibit very analytical thinking: breaking things down into their constituent parts. Maybe you do an interface inventory; break things down into components, atoms, molecules.

It doesn’t have to be that way.

Let’s go back to our friend the button. Let’s say we’ve got our design system with a bunch of different button styles and you want to document this. That’ss what a design system for, right? Documenting the different styles you have.

You can see these buttons have different background colours and different borders and one approach would be to document those colours. You put those in the design system. Maybe there’s nice tokens, right? And then when someone needs that information they go to the design system and they pluck out the colours. Done.

That’s one way of doing it. That’s a very imperative, very precise way of doing it.

The other way is to pull back and say “what’s the commonality across all these buttons?” And then you could come up with that rule, that boundary condition. which would be:

the border colour should be 10% lighter than the background colour.

You could convert this to CSS now using custom properties. We’re even gonna have a color-mix function in CSS.

But you see how this is a very different approach to just specifying what the final colours are.

So am I saying that when it comes to design systems a declarative approach is always better than an imperative approach?

I’m saying it depends.

“It depends on what?” you ask.

It depends on your team. It depends on their background and their mindset.

Teams

In a way it doesn’t matter whether you have a declarative or imperative mindset. What matters is what’s the mindset of the team working on this? That should dictate the approach you take.

When I hear someone say “design systems stifle creativity” what I’m hearing is “I’m a declarative designer and the design system is being very imperative, it’s fencing me in.”

But if you’re from an imperative background, “I need to know the color of the border for this button!” And if the design system says “well, you should make the border 10% lighter than the background,” that’s not useful—“Just give me the colors!” That’s the mindset I’ve got: “don’t make me think; just give me the data!”

I was I was talking about composers and I was comparing Mozart and Miles Davis. But let’s also compare their teams.

Classical musicians, they’re trying to sight read. It’s like a superpower they have. Whereas jazz musicians are trained to improvise. That’s their superpower.

With classical musicians, they could play a whole new piece of music without ever having heard it just from sight, which is absolutely amazing. But if Miles Davis had tried to record Kind Of Blue with a bunch of classical musicians I think it would have turned out very, very differently.

And then there’s the process, the design process.

The design process

I struggle with the design process on the web. I assume everyone does.

Jason Grigby has been blogging about this on the Cloud Four blog. The very first post in the series is Traditional Website process is Fundamentally Broken. I think we’d share that frustration.

He shows the traditional sort of very waterfall-y process that happens a lot, where particularly you’ve got this handover stage. The design all happens on this side of the handover and the development all happens on that side of the handover.

I think we can all agree that’s not good. That’s not going to lead to a great result.

He proposes something more like this, that goes backwards and forwards in time and also intertwingling design and development. And that’s that’s clearly better.

I still think there’s an issue here. Right here in the middle. Static mock-ups. Very precise, high-fidelity pictures of how something should look before you start actually building the thing.

Tools

Our tools tools influence us. They can’t help but do that.

We shape our tools and then our tools shape us.

Look at the tools we use for designing on the web. It used to be Photoshop and then it was Sketch. Now it’s Figma. Whatever it is, they’re very precise high-fidelity pixel-perfect tools. They’re very imperative. So we take imperative approach and then we try to translate it into a declarative language like CSS which is supposed to be about setting boundary conditions, leaving the browser to figure out the details.

There’s a mismatch there. So what’s the alternative?

We could jump straight to CSS, designing in the browser. Is that the answer? I’m not sure.

I like I like the phrase that Dan Mall uses which isn’t designing in the browser but deciding in the browser. He’s kind of talking about sign off . Instead of having something done in a mock-up and that’s what gets signed off, that’s the ideal we want and then you go to the browser. Instead do as much as you want in the in the design tool but that’s not the sign-off. You get it into the browser and at some point in the browser you go “Yes, that’s what we want” Sign off on that.

Now it’s already been translated into the the language of the browser so there isn’t going to be that disappointment with the traditional design process: the designer is disappointed because the end result doesn’t look like what they designed; the developer is disappointed because the designer did all this without consulting them; the client is disappointed; everybody is disappointed.

So I like the idea of deciding in the browser. But your approach to taking things into the browser sooner—maybe even designing in the browser—will depend entirely on your attitude to CSS.

If you’re from an imperative mindset you might think:

CSS is broken and I want my tools to work around the way that CSS has been designed.

Which is fair enough if you’re coming from that imperative mindset. I totally understand why you’d think that way. And there are tools to help you. This is pretty much what Tailwind does. Or CSS-in-JS. Treat the C in CSS as a bug and and work around. In that situation maybe you do want to stick to designing as much as possible in an imperative tool like Figma.

But if your mindset is more declarative you may think:

CSS is awesome and I want my tools to amplify the way that CSS has been designed.

Then, yeah, go check out Utopia, go check out those other websites I was talking about. Because that’s what they do. They go with the flow of CSS.

I’ve been saying “it depends”. It depends on your team. It depends on the culture of your company. You have to choose the approach that works best foryou and and your team. But to finish I want to point out one more thing that it depends on.

The medium

Choosing a declarative or an imperative approach to design also depends on the medium. The medium that you’re working in.

Now if you’re working in a medium that’s very precise like print or native apps, mobile or operating system specific apps for desktop, then you do actually have a lot of control. So an imperative approach might make a lot more sense. Those assumptions are maybe justified because you’ve got such a tightly controlled environment. So in that situation, yeah, go for it— be like Mozart; take the imperative approach.

But I don’t think that maps very well to the World Wide Web.

I think on the World Wide Web you want to be more Miles. You want to be more declarative.

We’ve tried them the past on the World Wide Web to shoehorn in an imperative mindset, to say “Well, let’s say things are really defined—let’s make assumptions about, you know, how wide everybody’s screen is.”

I’m showing my age here but when I started making websites, the assumption was everybody’s screen is 640 pixels wide. Later on it was 800 pixels wide. 1024.

Then mobile phones came along and everybody shat the bed because they didn’t know what they were supposed to do.

You understand why designers were doing this. It was to try and feel that sense of control. But it was always an illusion of control. It was a consensual hallucination to say “Yes, everybody’s screen is 800 pixels wide.” It doesn’t match with the reality, the messy beautiful reality of the World Wide Web.

To paraphrase the senator from Alderaan:

The more you tighten your grip, the more the World Wide Web slips through your fingers.

People have been talking about this for a long time. There’s an article called A Dao of Web Design by John Alsopp. It was published in 2000. 23 years ago it still holds up today. I recommend going back and reading it.

It was all about rejecting assumptions. Assumptions about devices. Assumptions about browsers. Assumptions about networks. Assumptions about people.

Look, you don’t have control over how people access the web. And that’s okay. That’s that’s not a bad thing.

Ten years after John published A Dao Of Web Design on A List Apart, Ethan Marcotte published Responsive Web Design on A List Apart. And the first thing he does in this article is he quotes John Allsopp’s A Dao Of Web Design. He was building on top of it. It was the same approach, the same mindset that was behind responsive web design.

That was 2010. And now, are we in a new era? Is it time for the next phase? A new era of declarative design maybe?

That’s up to you.

CSS is an incredibly powerful tool now. So let’s use it. Let’s lean into the the fluid, ever-changing nature of the World Wide Web.

It is a very very exciting time for design on the web right now and I can’t wait to see what you build.

An alternative proposal for CSS masonry  |  Blog  |  Chrome for Developers

Rachel responds to Jen’s recent post with the counter-argument; why masonry should be separate from grid.

I’m not entirely convinced. We heard performance issues as a reason why we could never have container queries or :has, but here we are. And the syntax for a separate masonry spec borrows so heavily from grid that it smells of redundancy.

Custom Element Naming | BitWorking

More thoughts on naming web components.

I’ve been deep-diving into HTML web components over the past few weeks. I decided to refactor the JavaScript on The Session to use custom elements wherever it made sense.

I really enjoyed doing this, even though the end result for users is exactly the same as before. This was one of those refactors that was for me, and also for future me. The front-end codebase looks a lot more understandable and therefore maintainable.

Most of the JavaScript on The Session is good ol’ DOM scripting. Listen for events; when an event happens, make some update to some element. It’s the kind of stuff we might have used jQuery for in the past.

Chris invoked Betteridge’s law of headlines recently by asking Will Web Components replace React and Vue? I agree with his assessment. The reactivity you get with full-on frameworks isn’t something that web components offer. But I do think web components can replace jQuery and other approaches to scripting the DOM.

I’ve written about my preferred way to do DOM scripting: element.target.closest. One of the advantages to that approach is that even if the DOM gets updated—perhaps via Ajax—the event listening will still work.

Well, this is exactly the kind of thing that custom elements take care of for you. The connectedCallback method gets fired whenever an instance of the custom element is added to the document, regardless of whether that’s in the initial page load or later in an Ajax update.

So my client-side scripting style has updated over time:

1. Adding event handlers directly to elements.
2. Adding event handlers to the document and using event.target.closest.
3. Wrapping elements in a web component that handles the event listening.

None of these progressions were particularly ground-breaking or allowed me to do anything I couldn’t do previously. But each progression improved the resilience and maintainability of my code.

Like Chris, I’m using web components to progressively enhance what’s already in the markup. In fact, looking at the code that Chris is sharing, I think we may be writing some very similar web components!

A few patterns have emerged for me…

Naming custom elements

Naming things is famously hard. Every time you make a new custom element you have to give it a name that includes a hyphen. I settled on the convention of using the first part of the name to echo the element being enhanced.

If I’m adding an enhancement to a button element, I’ll wrap it in a custom element that starts with button-. I’ve now got custom elements like button-geolocate, button-confirm, button-clipboard and so on.

Likewise if the custom element is enhancing a link, it will begin with a-. If it’s enhancing a form, it will begin with form-.

The name of the custom element tells me how it’s expected to be used. If I find myself wrapping a div with button-geolocate I shouldn’t be surprised when it doesn’t work.

Naming attributes

You can use any attributes you want on a web component. You made up the name of the custom element and you can make up the names of the attributes too.

I’m a little nervous about this. What if HTML ends up with a new global attribute in the future that clashes with something I’ve invented? It’s unlikely but it still makes me wary.

So I use data- attributes. I’ve already got a hyphen in the name of my custom element, so it makes sense to have hyphens in my attributes too. And by using data- attributes, the browser gives me automatic reflection of the value in the dataset property.

Instead of getting a value with this.getAttribute('maximum') I get to use this.dataset.maximum. Nice and neat.

The single responsibility principle

My favourite web components aren’t all-singing, all-dancing powerhouses. Rather they do one thing, often a very simple thing.

Here are some examples:

• Jason’s aria-collapsable for toggling the display of one element when you click on another.
• David’s play-button for adding a play button to an audio or video element.
• Chris’s ajax-form for sending a form via Ajax instead of a full page refresh.
• Jim’s user-avatar for adding a tooltip to an image.
• Zach’s table-saw for making tables responsive.

All of those are HTML web components in that they extend your existing markup rather than JavaScript web components that are used to replace HTML. All of those are also unambitious by design. They each do one thing and one thing only.

But what if my web component needs to do two things?

I make two web components.

The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.

What if you’ve got some text that you want to be a level-three heading and also a link? You don’t bemoan the lack of an element that does both things. You wrap an a element in an h3 element.

The same goes for custom elements. If I find myself adding multiple behaviours to a single custom element, I stop and ask myself if this should be multiple custom elements instead.

Take some of those button- elements I mentioned earlier. One of them copies text to the clipboard, button-clipboard. Another throws up a confirmation dialog to complete an action, button-confirm. Suppose I want users to confirm when they’re copying something to their clipboard (not a realistic example, I admit). I don’t have to create a new hybrid web component. Instead I wrap the button in the two existing custom elements.

Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes. And it has the added benefit of stopping my code getting too complex and hard to understand.

Communicating across components

Okay, so I’ve broken all of my behavioural enhancements down into single-responsibility web components. But what if one web component needs to have awareness of something that happens in another web component?

Here’s an example from The Session: the results page when you search for sessions in London.

There’s a map. That’s one web component. There’s a list of locations. That’s another web component. There are links for traversing backwards and forwards through the locations via Ajax. Those links are in web components too.

I want the map to update when the list of locations changes. Where should that logic live? How do I get the list of locations to communicate with the map?

Events!

When a list of locations is added to the document, it emits a custom event that bubbles all the way up. In fact, that’s all this component does.

You can call the event anything you want. It could be a newLocations event. That event is dispatched in the connectedCallback of the component.

Meanwhile in the map component, an event listener listens for any newLocations events on the document. When that event handler is triggered, the map updates.

The web component that lists locations has no idea that there’s a map on the same page. It doesn’t need to. It just needs to dispatch its event, no questions asked.

There’s nothing specific to web components here. Event-driven programming is a tried and tested approach. It’s just a little easier to do thanks to the connectedCallback method.

I’m documenting all this here as a snapshot of my current thinking on HTML web components when it comes to:

• naming custom elements,
• naming attributes,
• the single responsibility principle, and
• communicating across components.

I may well end up changing my approach again in the future. For now though, these ideas are serving me well.

Help us invent CSS Grid Level 3, aka “Masonry” layout | WebKit

This is a wonderful in-depth article by Jen, with lots of great demos.

She makes a very strong case for masonry layouts being part of the grid spec (I’m convinced!). If you have strong feelings one way or the other, get involved

This is a little follow-up to my post about web components for date inputs.

If you try the demo on iOS it doesn’t work. There’s nothing stopping you selecting any date.

That’s nothing to do with the web components. It turns out that Safari on iOS doesn’t support min and max on date inputs. This is also true of any other browser on iOS because they’re all just Safari in a trenchcoat …for now.

I was surprised — input type="date" has been around for a long time now. I mean, it’s not the end of the world. You’d have to do validation on inputted dates on the server anyway, but it sure would be nice for the user experience of filling in forms.

Alas, it doesn’t look like this is something on the interop radar.

What really surprised me was looking at Can I Use. That shows Safari on iOS as fully supporting date inputs.

Maybe it’s just semantic nitpickery on my part but I would consider that the lack of support for the min and max attributes means that date inputs are partially supported.

Can I Use gets its data from here. I guess I need to study the governance rules and try to figure out how to submit a pull request to update the currently incorrect information.

The quiet, pervasive devaluation of frontend - Josh Collinsworth blog

It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.

In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?

Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.

I worry our Copilot is leaving some passengers behind - Josh Collinsworth blog

Products of all kinds are required to ensure misuse is discouraged, at a minimum, if not difficult or impossible. I don’t see why LLMs should be any different.