In March I attended Web Day Out – a one-day event all about what you can do in web browsers today. It was hosted by Clearleft at the Brighton Dome Studio.
It was a brilliant day featuring a diverse line-up, friendly hosting and opportunities to mingle with likeminded souls. At this time when software engineers are navigating a bewildering explosion of AI-related tools and opinions, it was refreshing to change gears and focus on the craft of web development.
We were treated to eight talks spanning:
- exciting modern web features and APIs via HTML, CSS and JavaScript;
- front-end performance and reliability; and
- planning new web feature adoption using Baseline.
Here are my highlights.
Jemima Abu – I can’t believe it’s not JavaScript
You might have noticed that newer browser-native web features provide more interactivity. Until recently we had to create sliding menus, tooltips, modal dialogues (etc) from scratch or reach for third party libraries. Not only was this resource-intensive and repetitious, it also left users reliant on us and our dependencies to correctly implement complex accessibility considerations. Now, modern web features solve many of these longstanding challenges.
Jemima demonstrated creative possibilities for using the Popover API, and the <details> and <dialog> elements. There was also a great section on using CSS Anchor Positioning for smart, adaptive positioning of popovers beside their trigger elements.
At FreeAgent we’ve begun our journey of adding these tools into our design system and applications by introducing dialog, but we have plenty more opportunities to explore. I’m excited at the prospect of us creating leaner solutions that serve users better.
Rachel Andrew – A pragmatic guide to browser support
Baseline has been a useful aid to the industry by offering a sensible, data-driven heuristic for evaluating web feature readiness in browsers. And it’s really handy that we are shown Baseline statuses on MDN and caniuse pages, and in our various dev tools.
Not all features are the same
One of Rachel’s key messages was that Baseline is intended to remove most of the unnecessary thinking rather than to be considered as a hard line.
A newly-available feature that you plan to use only to enhance the user experience rather than to provide core functionality is fine to use now.
For more impactful features or more important purposes, often you can start with a perfectly workable fallback then safely enhance within a feature query. This is how the web has always worked and Baseline doesn’t change that.
Planning for known Baseline dates
I loved the section where Rachel explained that Baseline allows us to “see into the future”. In cases where we’d like to use an emergent feature for core functionality but it is not yet “widely available”, we don’t need to mindlessly hope for its status to change or write off the idea. Instead we can plan and schedule our use of the feature by understanding the fixed durations of Baseline stages. The time for a feature to transition from newly available to widely available is always the same, so we actually know in advance when it will be marked widely available.
For example, when we’re considering using an exciting newly available web feature, we might observe that in, say, 3 months time it will reach widely available status. So rather than writing it off as a non-starter we can instead consider how that timeline fits with our project release date or the urgency of the work.
I feel that in many cases this could help us make smarter decisions which favour lean, browser-native solutions over expensive and temporary DIY solutions.
My baseline is not your baseline
I enjoyed the idea of choosing a “Baseline year” that better represents your audience statistics than the standard “Widely available for the general public” heuristic. Your audience data might reveal that you can be less conservative and use a baseline year like “Baseline 2024”, which means “we’re comfortable using every feature that became newly available in 2024 or earlier”.
Harry Roberts – Build for the web, build on the web, build with the web
Renowned web performance consultant Harry – whose clientele includes Shopify, Google and the BBC – explained that he’s routinely called in to help companies “get out of the mud” when their performance has degraded due to severe overcomplexity. He suggests that adding extra layers of work for the browser can never be faster than it doing less. He also laments that clients waste years of effort sinking time into framework upgrades and rebuilding existing web features from scratch.
To get them back on track, Roberts steers them away from volatile ecosystem trends and back toward native capabilities, often reminding them: “there’s a spec for that; there’s a standard for that; we can do that in the browser already”.
His core advice to businesses is to iterate quickly on a slow-moving platform. Embracing the web’s innate reliability and forward-compatibility offers a long-term guarantee that is ultimately just good business.
I loved Harry’s message, and his passion. My feeling is that at FreeAgent, generally we share the mindset of iterating quickly on a slow moving platform but there is an opportunity for us to stay closer to the web and its curve.
Richard Rutter – What’s new in web typography
Richard is a real expert in this field – in fact he wrote the book on Web Typography. I went to the Ampersand Web Typography conference he ran in 2018 at the dawn of variable fonts and a time of real promise for type on the web, so I was interested to hear what had progressed since.
In short, we now have greater control over font loading behaviour plus a variety of new CSS properties offering typographic refinement. At FreeAgent we use custom webfonts so there may be opportunities for us to improve performance, legibility and reading experience for our users.
A lot of this stuff is subtle – nerdy, even – but in Richard’s words:
These are details which raise mediocrity to excellence. It’s about care, attention and craft.
Jake Archibald – Customisable Select and the friends we made along the way
In Jake from Firefox’s witty talk, he told us how there has been a desire for authors to be able to customise the select element’s appearance and content since the early days of the web. And because we’ve lacked that ability, <select> has been voted the form control element most manually recreated by developers, and the source of most frustration.
Excitingly, Customisable Select is finally here – already shipped in Chrome, and being actively worked on by the other browser manufacturers. And the element follows core web principles by offering native progressive enhancement. A customisable select will fall back to a “classic” select in non-supporting browsers rather than breaking – which I love.
Jake explained how surprisingly difficult it was for standards folks and browser manufacturers to introduce a customisable select element due to several key gaps. They have succeeded largely through years of collaborative work introducing independent subfeatures that have wider value, then bringing those together. These other features include:
- The Popover API and Invoker Commands API
- The Top Layer
- CSS Anchor Positioning
At FreeAgent, we have some UI patterns which currently use DIY menus where they would ideally use a select. The customisable select will unlock the ability for us to make these lean, reliable and accessible, and I can’t wait to work with it.
I thoroughly enjoyed the inaugural Web Day Out. And I imagine that anyone interested in modern web standards, native browser capabilities and creating lightweight, accessible user interfaces would love it too. If it returns in 2027, I heartily recommend going.