So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”
I was supposed to be in Cork over the weekend.
Not only was it high time I paid my mother a visit, but the Cork Folk Festival was happening too. So I booked some relatively cheap plane tickets for myself and Jessica back in August and noted down the days in my calendar.
We didn’t end up getting our flight. This time it wasn’t because I messed up the flight times. We made it to Gatwick airport in plenty of time. That’s when we saw that our flight was delayed.
See, Storm Amy was moving in. We were hoping to get into Cork before the storm hit, but now with the flight delayed, that wasn’t likely. In fact, it was more likely that the flight would just get more and more delayed and possibly even get diverted.
To start with, we settled in at the airport, prepared to spend an hour or two more than we had planned. But, sure enough, the delays kept piling up. It was time to make decision; wait it out in the hopes that we’d eventually make a very bumpy landing in Cork, or cut our losses and run.
I quickly looked up flights for the next couple of weekends and spotted some cheap ones a fortnight away. I booked them and then called my mother to tell her we wouldn’t be showing up that night, but we’d see her in a couple of weeks.
Alright then, time to go home.
Wait a minute …how exactly are we supposed to leave the airport other than on an airplane?
It turns out there’s a process called “decontrolling”. You need to find someone from the airline (or in our case, a third-party contractor operating on the airline’s behalf) who has the security privileges to walk you back out. But you still need to go through passport control …even though you never left the building.
Luckily we didn’t have any checked luggage or it would’ve gotten complicated. As it was, it was just weird. It was all very City And The City.
That flight we abandoned did finally take off …six hours late. By that time we were back home on the sofa eating pizza and listening to the wind gusting outside. I think we made the right choice.
I don’t think it’s controversial to suggest that LLMs haven’t measured up to any of the lofty promises made by their vendors. But in more concrete terms, consumers dislike “AI” when it shows up in products, and it makes them actively mistrust the brands that employ it. In other words, we’re some three years into the hype cycle, and LLMs haven’t met any markers of success we’d apply to, well, literally any other technology.
Marcin has outdone himself this time. Not only has he created an exhaustive history of the settings controls in Apple interfaces, he’s gone and made them all interactive!
While it’s easy to be blown away by the detail of the interactive elements here, it’s also worth taking a moment to appreciate just how good the writing is too.
Bravo!
There’s a new proposal for giving developers more control over styling form controls. I like it.
It’s clearly based on the fantastic work being done by the Open UI group on the select element. The proposal suggests that authors can opt-in to the new styling possibilities by declaring:
appearance: base;
So basically the developer is saying “I know what I’m doing—I’m taking the controls.” But browsers can continue to ship their default form styles. No existing content will break.
The idea is that once the developer has opted in, they can then style a number of pseudo-elements.
This proposal would apply to pretty much all the form controls you can think of: all the input types, along with select, progress, meter, buttons and more.
But there’s one element more that I wish were on the list:
legend
I know, technically it’s not a form control but legend and fieldset are only ever used within forms.
The legend element is notoriously annoying to style. So a lot of people just don’t bother using it, which is a real shame. It’s like we’re punishing people for doing the right thing.
Wouldn’t it be great if you, as a developer, had the option of saying “I know what I’m doing—I’m taking the controls”:
legend {
appearance: base;
}
Imagine if that nuked the browser’s weird default styles, effectively turning the element into a span or div as far as styling is concerned. Then you could style it however you wanted. But crucially, if browsers shipped this, no existing content would break.
The shitty styling situation for legend (and its parent fieldset) is one of those long-standing annoyances that seems to have fallen down the back of the sofa of browser vendors. No one’s going to spend time working on it when there are more important newer features to ship. That’s why I’d love to see it sneak in to this new proposal for styling form controls.
I was in Amsterdam last week. Just like last year I was there to help out Vasilis’s students with a form-based assignment:
They’re given a PDF inheritance-tax form and told to convert it for the web.
Yes, all the excitement of taxes combined with the thrilling world of web forms.
(Side note: this time they were told to style it using the design system from the Dutch railway because the tax office was getting worried that they were making phishing sites.)
I saw a lot of the same challenges again. I saw how students wished they could specify a past date or a future date in a date picker without using JavaScript. And I saw them lamenting the time they spent styling legends that worked across all browsers.
Right now, Mason Freed has an open issue on the new proposal with his suggestion to add some more elements to consider. Both legend and fieldset are included. That gets a thumbs-up from me.
This looks like a really interesting proposal for allowing developers more control over styling inputs. Based on the work being done the customisable select element, it starts with a declaration of appearance: base.
I see the personal website as being an antidote to the corporate, centralised web. Yeah, sure, it’s probably hosted on someone else’s computer – but it’s a piece of the web that belongs to you. If your host goes down, you can just move it somewhere else, because it’s just HTML.
Sure, it’s not going to fix democracy, or topple the online pillars of capitalism; but it’s making a political statement nonetheless. It says “I want to carve my own space on the web, away from the corporations”. I think this is a radical act. It was when I originally said this in 2022, and I mean it even more today.
I’m not a fan of Nicholas Carr and his moral panics, but this is an excellent dive into some historical media theory.
What Innis saw is that some media are particularly good at transporting information across space, while others are particularly good at transporting it through time. Some are space-biased while others are time-biased. Each medium’s temporal or spatial emphasis stems from its material qualities. Time-biased media tend to be heavy and durable. They last a long time, but they are not easy to move around. Think of a gravestone carved out of granite or marble. Its message can remain legible for centuries, but only those who visit the cemetery are able to read it. Space-biased media tend to be lightweight and portable. They’re easy to carry, but they decay or degrade quickly. Think of a newspaper printed on cheap, thin stock. It can be distributed in the morning to a large, widely dispersed readership, but by evening it’s in the trash.
Every UI control you roll yourself is a liability. You have to design it, test it, ship it, document it, debug it, maintain it — the list goes on.
It makes you wonder why we insist on rolling (or styling) our own common UI controls so often. Perhaps we’d be better off asking: What are the fewest amount of components we have to build to deliver value to our users?
I’m very glad to see that work has moved away from a separate selectmenu element to instead enhancing the existing select element—I could never see an upgrade path for selectmenu, but now there are plenty of opportunities for progressive enhancement.
I really, really like Paul’s idea of splitting up the indie web principles into one opinionated nerdy list of dev principles, and a separate shorter list of core principles for everyone:
- Own your identity An independent web presence starts with an online identity you own and control. The most reliable way to do this today is by having your own domain name.
- Own your content You should retain control of the things you make, and not be subject to third-parties preventing access to it, deleting it or disappearing entirely. The best way to do this is by publishing content on your own website.
- Have fun! When the web took off in the 90’s people began designing personal sites with garish backgrounds and animated GIFs. It may have been ugly but it was fun. Let’s keep the web weird and interesting.
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.
Claire L. Evans has written a beautiful piece on the difference between growth and scalability:
Life is nonhierarchical, and it shirks top-down control. But scalability relies on hierarchy, on the isolation of elements stripped of history and context. It is predicated on the assumption that nature is little more than a raw material to be processed and commodified until it is spent. This is, of course, unsustainable — at any scale.
- Good design works for everyone
- Good design makes things obvious
- Good design puts users in control
- Good design is lightweight
This is a terrific talk by Jack on how to deal with the tooling involved in modern front-end development:
- Maintaining control,
- Dependency awareness,
- Lean on browser primitives,
- Have an exit strategy.
Modern computing is far too rigid. Applications can only function in preset ways determined by some far away team. Software is trapped in hermetically sealed silos and is rewritten many times over rather than recomposed.
This community catalogs and experiments with malleable software and systems that reset the balance of power via several essential principles…
I’ll be adding those principles to my collection.
In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:
In each case you could use native HTML elements:
button,select, andinput type="date".Or you could use divs with a whole bunch of JavaScript and ARIA.
In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.
In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.
Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.
Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.
But there’s one more component: a button.
Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.
Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.
I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.
I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.
When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).
But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.
I get it. I don’t agree. But I get it.
If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.
But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.
Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.
At the risk of grossly oversimplifying things, I propose that the core of the debate can be summed up by these truisms:
- The best SPA is better than the best MPA.
- The average SPA is worse than the average MPA.
I’ve got the same hunch as Nolan:
There’s a feeling in the air. A zeitgeist. SPAs are no longer the cool kids they once were 10 years ago.
And I think he’s right to frame the appeal of single page apps in terms of control (even if that control comes at the expense of performance and first-load user experience).
I feel like in the past few years there’s been a number of web design approaches that share a similar mindset. Intrinsic web design by Jen; Every Layout by Andy and Heydon; Utopia by Trys and James.
To some extent, their strengths lie in technological advances in CSS: flexbox, grid, calc, and so on. But more importantly, they share an approach. They all focus on creating the right inputs rather than trying to control every possible output. Leave the final calculations for those outputs to the browser—that’s what computers are good at.
As Andy puts it:
Be the browser’s mentor, not its micromanager.
Reflecting on Utopia’s approach, Jim Nielsen wrote:
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.
Declarative! Maybe that’s the word I’ve been looking for to describe the commonalities between Utopia, Every Layout, and intrinsic web design.
So if declarative design is a thing, does that also mean imperative design is also a thing? And what might the tools and technologies for imperative design look like?
I think that Tailwind might be a good example of an imperative design tool. It’s only about the specific outputs. Systematic thinking is actively discouraged; instead you say exactly what you want the final pixels on the screen to be.
I’m not saying that declarative tools—like Utopia—are right and that imperative tools—like Tailwind—are wrong. As always, it depends. In this case, it depends on the mindset you have.
If you agree with this statement, you should probably use an imperative design tool:
CSS is broken and I want my tools to work around the way CSS has been designed.
But if you agree with this statement, you should probably use a declarative design tool:
CSS is awesome and I want my tools to amplify the way that CSS had been designed.
If you agree with the first statement but you then try using a declarative tool like Utopia or Every Layout, you will probably have a bad time. You’ll probably hate it. You may declare the tool to be “bad”.
Likewise if you agree with the second statement but you then try using an imperative tool like Tailwind, you will probably have a bad time. You’ll probably hate it. You may declare the tool to be “bad”.
It all depends on whether the philosophy behind the tool matches your own philosophy. If those philosophies match up, then using the tool will be productive and that tool will act as an amplifier—a bicycle for the mind. But if the philosophy of the tool doesn’t match your own philosophy, then you will be fighting the tool at every step—it will slow you down.
Knowing that this spectrum exists between declarative tools and imperative tools can help you when you’re evaluating technology. You can assess whether a web design tool is being marketed on the premise that CSS is broken or on the premise that CSS is awesome.
I wonder whether your path into web design and development might also factor into which end of the spectrum you’d identify with. Like, if your background is in declarative languages like HTML and CSS, maybe intrisic web design really resonates. But if your background is in imperative languages like JavaScript, perhaps Tailwind makes more sense to you.
Again, there’s no right or wrong here. This is about matching the right tool to the right mindset.
Personally, the declarative design approach fits me like a glove. It feels like it’s in the tradition of John’s A Dao Of Web Design or Ethan’s Responsive Web Design—ways of working with the grain of the web.