- Basic functionality should work on any device that can access the web.
- Extras and flourishes are treated as progressive enhancements for modern devices.
- The UI can look different and even clunky on older devices and browsers, as long as it doesn’t break rule #1.
I really like the idea of unifying some layout values in CSS. If you’ve got any feedback, please chip in!
I’ve been banging on for a while now about how much I’d like a declarative option for the Web Share API. I was thinking that the type attribute on the button element would be a good candidate for this (there’s prior art in the way we extended the type attribute on the input element for HTML5).
I wrote about the reason for a share button type as well as creating a polyfill. I also wrote about how this idea would work for other button types: fullscreen, print, copy to clipboard, that sort of thing.
Since then, I’ve been very interested in the idea of “invokers” being pursued by the Open UI group. Rather than extending the type attribute, they’ve been looking at adding a new attribute. Initially it was called invoketarget (so something like button invoketarget="share").
Things have been rolling along and invoketarget has now become the command attribute (there’s also a new commandfor attribute that you can point to an element with an ID). Here’s a list of potential values for the command attribute on a button element.
Right now they’re focusing on providing declarative options for launching dialogs and other popovers. That’s already shipping.
The next step is to use command and commandfor for controlling audio and video, as well as some form controls. I very much approve! I love the idea of being able to build and style a fully-featured media player without any JavaScript.
I’m hoping that after that we’ll see the command attribute get expanded to cover JavaScript APIs that require a user interaction. These seem like the ideal candidates:
button command="share"button command="fullscreen"button command="print"button command="copy"button command="install"There’s also scope for declarative options for navigating the browser’s history stack:
button command="back"button command="forward"button command="refresh"Whatever happens next, I’m very glad to see that so much thinking is being applied to declarative solutions for common interface patterns.
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.
And by LLMS I mean: (L)ots of (L)ittle ht(M)l page(S).
I really like this approach: using separate pages instead of in-page interactions. I remember Simon talking about how great this works, and that was a few years back, before we had view transitions.
I build separate, small HTML pages for each “interaction” I want, then I let CSS transitions take over and I get something that feels better than its JS counterpart for way less work.
This describes how I like to work too.
Rich suggests another reason why the UX of websites on mobile is so shit these days:
The path to installing a native app is well trodden. We search the App Store (or ironically follow a link from a website), hit ‘Get’ and the app is downloaded to our phone’s home screen, ready to use any time with a simple tap.
A PWA can also live on your home screen, nicely indistinguishable from a native app. But the journey to getting a PWA – or indeed any web app – onto your home screen remains convoluted to say the least. This is the lack of equivalence I’m driving at. I wonder if the mobile web experience would suck as badly if web apps could be installed just as easily as native apps?
Here’s a post outlining all the great things you can do in mobile web browsers today: Your App Should Have Been A Website (And Probably Your Game Too):
Today’s browsers are powerhouses. Notifications? Check. Offline mode? Check. Secure payments? Yep, they’ve got that too. And with technologies like WebAssembly and WebGPU, web games are catching up to native-level performance. In some cases, they’re already there.
This is all true. But this post from John Gruber is equally true: One Bit of Anecdata That the Web Is Languishing Vis-à-Vis Native Mobile Apps:
I won’t hold up this one experience as a sign that the web is dying, but it sure seems to be languishing, especially for mobile devices.
As John points out, the problems aren’t technical:
There’s absolutely no reason the mobile web experience shouldn’t be fast, reliable, well-designed, and keep you logged in. If one of the two should suck, it should be the app that sucks and the website that works well. You shouldn’t be expected to carry around a bundle of software from your utility company in your pocket. But it’s the other way around.
He’s right. It makes no sense, but this is the reality.
Ten or fifteen years ago, the gap between the web and native apps on mobile was entirely technical. There were certain things that you just couldn’t do in web browsers. That’s no longer the case now. The web caught up quite a while back.
But the experience of using websites on a mobile device is awful. Never mind the terrible performance penalties incurred by unnecessary frameworks and libraries like React and its ilk, there’s the constant game of whack-a-mole with banners and overlays. What’s just about bearable in a large desktop viewport becomes intolerable on a small screen.
This is not a technical problem. This doesn’t get solved by web standards. This is a cultural problem.
First of all, there’s the business culture. If your business model depends on tracking people or pushing newsletter sign-ups, then it’s inevitable that your website will be shite on mobile.
Mind you, if your business model depends on tracking people, you’re more likely to try push people to download your native app. Like Cory Doctorow says:
50% of web users are running ad-blockers. 0% of app users are running ad-blockers, because adding a blocker to an app requires that you first remove its encryption, and that’s a felony (Jay Freeman calls this ‘felony contempt of business-model’).
Matt May brings up the same point in his guide, How to grey-rock Meta:
Remove Meta apps from your devices and use only the mobile web versions. Mobile apps have greater access to your personal data, provided the app requests those privileges, and Facebook and Instagram in particular (more so than WhatsApp, another Meta property) request the vast majority of those privileges. This includes precise GPS data on where you are, whether or not you are using the app.
Ironically, it’s the strength of the web—and web browsers—that has led to such shitty mobile web experiences. The pretty decent security model on the web means that sites have to pester you.
Part of the reason why you don’t see the same egregious over-use of pop-ups and overlays in native apps is that they aren’t needed. If you’ve installed the app, you’re already being tracked.
But when I describe the dreadful UX of most websites on mobile as a cultural problem, I don’t just mean business culture.
Us, the people who make websites, designers and developers, we’re responsible for this too.
For all our talk of mobile-first design for the last fifteen years, we never really meant it, did we? Sure, we use media queries and other responsive techniques, but all we’ve really done is make sure that a terrible experience fits on the screen.
As developers, I’m sure we can tell ourselves all sorts of fairy tales about why it’s perfectly justified to make users on mobile networks download React, Tailwind, and megabytes more of third-party code.
As designers, I’m sure we can tell ourselves all sorts of fairy tales about why intrusive pop-ups and overlays are the responsibility of some other department (as though users make any sort of distinction).
Worst of all, we’ve spent the last fifteen years teaching users that if they want a good experience on their mobile device, they should look in an app store, not on the web.
Ask anyone about their experience of using websites on their mobile device. They’ll tell you plenty of stories of how badly it sucks.
It doesn’t matter that the web is the perfect medium for just-in-time delivery of information. It doesn’t matter that web browsers can now do just about everything that native apps can do.
In many ways, I wish this were a technical problem. At least then we could lobby for some technical advancement that would fix this situation.
But this is not a technical problem. This is a people problem. Specifically, the people who make websites.
We fucked up. Badly. And I don’t see any signs that things are going to change anytime soon.
But hey, websites on desktop are just great!
A handy one-pager for front-end web developers:
Here are ways to keep track of what you can use, of what’s new in web browsers, and ways you can influence the development of the platform by making your voice heard.
Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.
With the release of a new Salter Cane album I figured it was high time to update the design of the band’s website.
Here’s the old version for reference. As you can see, there’s a connection there in some of the design language. Even so, I decided to start completely from scratch.
I opened up a text editor and started writing HTML by hand. Same for the CSS. No templates. No build tools. No pipeline. Nothing. It was a blast!
And lest you think that sounds like a wasteful way of working, I pretty much had the website done in half a day.
Partly that’s because you can do so much with so little in CSS these days. Custom properties for colours, spacing, and fluid typography (thanks to Utopia). Logical properties. View transitions. None of this takes much time at all.
Because I was using custom properties, it was a breeze to add a dark mode with prefers-color-scheme. I think I might like the dark version more than the default.
The final stylesheet is pretty short. I didn’t bother with any resets. Browsers are pretty consistent with their default styles nowadays. As long as you’ve got some sensible settings on your body element, the cascade will take care of a lot.
There’s one little CSS trick I think is pretty clever…
The background image is this image. As you can see, it’s a rectangle that’s wider than it is tall. But the web pages are rectangles that are taller than they are wide.
So how I should I position the background image? Centred? Anchored to the top? Anchored to the bottom?
If you open up the website in Chrome (or Safari Technical Preview), you’ll see that the background image is anchored to the top. But if you scroll down you’ll see that the background image is now anchored to the bottom. The background position has changed somehow.
This isn’t just on the home page. On any page, no matter how tall it is, the background image is anchored to the top when the top of the document is in the viewport, and it’s anchored to the bottom when you reach the bottom of the document.
In the past, this kind of thing might’ve been possible with some clever JavaScript that measured the height of the document and updated the background position every time a scroll event is triggered.
But I didn’t need any JavaScript. This is a scroll-driven animation made with just a few lines of CSS.
@keyframes parallax {
from {
background-position: top center;
}
to {
background-position: bottom center;
}
}
@media (prefers-reduced-motion: no-preference) {
html {
animation: parallax auto ease;
animation-timeline: scroll();
}
}
}
This works as a nice bit of progressive enhancement: by default the background image stays anchored to the top of the viewport, which is fine.
Once the site was ready, I spent a bit more time sweating some details, like the responsive images on the home page.
But the biggest performance challenge wasn’t something I had direct control over. There’s a Spotify embed on the home page. Ain’t no party like a third party.
I could put loading="lazy" on the iframe but in this case, it’s pretty close to the top of document so it’s still going to start loading at the same time as some of my first-party assets.
I decided to try a little JavaScript library called “lazysizes”. Normally this would ring alarm bells for me: solving a problem with third-party code by adding …more third-party code. But in this case, it really did the trick. The library is loading asynchronously (so it doesn’t interfere with the more important assets) and only then does it start populating the iframe.
This made a huge difference. The core web vitals went from being abysmal to being perfect.
I’m pretty pleased with how the new website turned out.
- Springy easing with
linear()- Typed custom properties
- View transitions for page navigation
- Transition animation for
dialogandpopover- Transition animation for
details- Animated adaptive gradient text
If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.
Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).
- Opt into web platform features incrementally
- Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
- Write code that leans into the browser, not away from it
I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.
Some interesting experiments in web typography here.
Remember when every company rushed to make an app? Airlines, restaurants, even your local coffee shop. Back then, it made some sense. Browsers weren’t as powerful, and apps had unique features like notifications and offline access. But fast-forward to today, and browsers can do all that. Yet businesses still push native apps as if it’s 2010, and we’re left downloading apps for things that should just work on the web.
This is all factually correct, but alas as Cory Doctorow points out, you can’t install an ad-blocker in a native app. To you and me, that’s a bug. To short-sighted businesses, it’s a feature.
(When I say “ad-blocker”, I mean “tracking-blocker”.)
- Violates User Expectations
- Causes Motion Sickness
- Reduces Accessibility for Disabled Users
- Inconsistent Performance Across Devices
- Impairs Usability for Power Users
- Increases Page Load Times
- Breaks Native Browser Features
- Makes Scroll Position Unclear
- Adds Maintenance Overhead
- Disrespects the User’s Control
I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.
Logical properties, container queries, :has, :is, :where, min(), max(), clamp(), nesting, cascade layers, subgrid, and more.
UX London isn’t the only event from Clearleft coming your way in 2025. There’s a brand new spin-off event dedicated to user research happening in February. It’s called Research By The Sea.
I’m not curating this one, though I will be hosting it. The curation is being carried out most excellently by Benjamin, who has written more about how he’s doing it:
We’ve invited some of the best thinkers and doers from from in the research space to explore how researchers might respond to today’s most gnarly and pressing problems. They’ll challenge current perspectives, tools, practices and thinking styles, and provide practical steps for getting started today to shape a better tomorrow.
If that sounds like your cup of tea, you should put February 27th 2025 in your calendar and grab yourself a ticket.
Although I’m not involved in curating the line-up for the event, I offered Benjamin my swor… my web dev skillz. I made the website for Research By The Sea and I really enjoyed doing it!
These one-day events are a great chance to have a bit of fun with the website. I wrote about how enjoyable it was making the website for this year’s Patterns Day:
I felt like I was truly designing in the browser. Adjusting spacing, playing around with layout, and all that squishy stuff. Some of the best results came from happy accidents—the way that certain elements behaved at certain screen sizes would lead me into little experiments that yielded interesting results.
I took the same approach with Research By The Sea. I had a design language to work with, based on UX London, but with more of a playful, brighter feel. The idea was that the website (and the event) should feel connected to UX London, while also being its own thing.
I kept the typography of the UX London site more or less intact. The page structure is also very similar. That was my foundation. From there I was free to explore some other directions.
I took the opportunity to explore some new features of CSS. But before I talk about the newer stuff, I want to mention the bits of CSS that I don’t consider new. These are the things that are just the way things are done ‘round here.
Custom properties. They’ve been around for years now, and they’re such a life-saver, especially on a project like this where I’m messing around with type, colour, and spacing. Even on a small site like this, it’s still worth having a section at the start where you define your custom properties.
Logical properties. Again, they’ve been around for years. At this point I’ve trained my brain to use them by default. Now when I see a left, right, width or height in a style sheet, it looks like a bug to me.
Fluid type. It’s kind of a natural extension of responsive design to me. If a website’s typography doesn’t adjust to my viewport, it feels slightly broken. On this project I used Utopia because I wanted different type scales as the viewport increased. On other projects I’ve just used on clamp declaration on the body element, which can also get the job done.
Okay, so those are the things that feel standard to me. So what could I play around with that was new?
View transitions. So easy! Just point to an element on two different pages and say “Hey, do a magic move!” You can see this in action with the logo as you move from the homepage to, say, the venue page. I’ve also added view transitions to the speaker headshots on the homepage so that when you click through to their full page, you get a nice swoosh.
Unless, like me, you’re using Firefox. In that case, you won’t see any view transitions. That’s okay. They are very much an enhancement. Speaking of which…
Scroll-driven animations. You’ll only get these in Chromium browsers right now, but again, they’re an enhancement. I’ve got multiple background images—a bunch of cute SVG shapes. I’m using scroll-driven animations to change the background positions and sizes as you scroll. It’s a bit silly, but hopefully kind of cute.
You might be wondering how I calculated the movements of each background image. Good question. I basically just messed around with the values. I had fun! But imagine what an actually-skilled interaction designer could do.
That brings up an interesting observation about both view transitions and scroll-driven animations: Figma will not help you here. You need to be in a web browser with dev tools popped open. You’ve got to roll up your sleeves get your hands into the machine. I know that sounds intimidating, but it’s also surprisingly enjoyable and empowering.
Oh, and I made sure to wrap both the view transitions and the scroll-driven animations in a prefers-reduced-motion: no-preference @media query.
I’m pleased with how the website turned out. It feels fun. More importantly, it feels fast. There is zero JavaScript. That’s the main reason why it’s very, very performant (and accessible).
Smooth transitions across pages; smooth animations as you scroll: it’s great what you can do with just HTML and CSS.