SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.
Use modern server rendering. Use actual pages. Animate with CSS. Preload with intent. Ship less JavaScript.
Hannah runs through the details of making a grid-aware website:
The design adjusts between “low”, “moderate”, and “high” based on the quantity of fossil fuels on your local energy grid.
I like this idea, but I really think it needs to be on by default, rather than being opt-in.
And I’m really intrigued by the idea of a grid-aware browser!
This is a really thoughtful look at the evolution of CSS and the ever-present need to balance power with learnability.
Grrr…
Chrome, Edge and Firefox updates usually reach 95% of users within three months. But Safari updates are tied to a new release of the underlying operating system, so they take around 19 months to reach the same usage, and some updates may even need a new device.
This is so shameful. And glad as I am to see new features landing in Safari, as long as they hobble updates like this it’s all just pissing in the wind.
An excellent appraisal of the importance of the rule of least power.
The joy came flooding back to me! It turns out browser APIs are really good now.
It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree
Nice to see Clearleft’s browser support policy get a shoutout from Rachel during her Google IO talk.
Why single-page apps are just not worth it:
Here’s the problem: your team almost certainly doesn’t have what it takes to out-engineer the browser. The browser will continuously improve the experience of plain HTML, at no cost to you, using a rendering engine that is orders of magnitude more efficient than JavaScript.
Meanwhile, the browser marches on, improving the UX of every website that uses basic HTML semantics. For instance: browsers often don’t repaint full pages anymore.
A great talk by Matthias on what you can do with web standards today!
This is an interesting proposal for a declarative way of triggering permission dialogs, although it seems to overlap with the work being done on invokers (command and commandfor).
What really disgusts me is to see Google referring to this element as though it’s a done deal. It’s not. It’s a proposal …a proposal that Apple rejects and Mozilla rejects.
Words matter. Call your proposal a proposal, Google.
Update: They fixed it!
I should be using the lh and rlh units more enough—they’re supported across the board!
Everything you ever wanted to know about text-wrap: pretty in CSS.
- 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?