Progressive enhancement is a design and development principle where we build in layers which automatically turn themselves on based on the browser’s capabilities.
The idea of progressive enhancement is that everyone gets the perfect experience for them, rather than a pre-determined “perfect” experience from a design and development team.
This proposal is exactly what I was asking for!
C’mon browsers, let’s make this happen!
Photoshop in the browser? That needs JS.
But the reality is, most of what we build is either static HTML or mostly just forms and page reloads. We can build the web that way by default, and progressively enhance a more Ajaxy experience on top of it.
The result is an app that’s faster to load, faster to run, and less prone to breaking… without much additional work for your developers.
We’re all tired of: write some code, come back to it in six months, try to make it do more, and find the whole project is broken until you upgrade everything.
Progressive enhancement allows you to do the opposite: write some code, come back to it in six months, and it’s doing more than the day you wrote it!
So many of the problems and challenges of working with Web Components just fall away when you ditch the shadow DOM and use them as a light wrapper for progressive enhancement.
Some lovely HTML web components—perfect for progressive enhancement!
This is a great thought exercise in progressive enhancement …that Scott then turns into a real exercise!
I somehow missed this when it came out in January but Amber just pointed me to it—an interview with Chris about HTML web components, available for your huffduffing pleasure.
Here’s a nice HTML web component that uses structured data in the markup to populate a Leaflet map.
Personally I’d probably use microformats rather than microdata, but the princple is the same: progressive enhancement from plain old HTML to an interactive map.
It’s a shame that the newest Safari release is overshadowed by Apple’s shenanigans and subsequent U-turn because there’s some great stuff in there.
I really like what they’re doing with web apps added to the dock:
Safari adds support for the
shortcutsmanifest member on macOS Sonoma. This gives you a mechanism in the manifest file for defining custom menu commands that will appear in the File menu and the Dock context menu.
Hallelujah! Apple have backed down on their petulant plan to sabatoge homescreen apps.
I’m very grateful to the Open Web Advocacy group for standing up to this bullying.
This is a really lovely little HTML web component from Jason. It does just one thing—wires up a trigger button to toggle-able content, taking care of all the ARIA for you behind the scenes.
This is exactly what it looks like: a single-fingered salute to the web and web developers.
Read Alex’s thorough explanation of the current situation and then sign this open letter.
Cupertino’s not just trying to vandalise PWAs and critical re-engagement features for Safari; it’s working to prevent any browser from ever offering them on iOS. If Apple succeeds in the next two weeks, it will cement a future in which the mobile web will never be permitted to grow beyond marketing pages for native apps.
Also, remember this and don’t fall for it:
Apple apparently hopes it can convince users to blame regulators for its own choices.
Isn’t this a lovely little HTML web component? All it does is hook up a button element with an audio or video element: exactly the kind of discrete drudge work that’s good to automate away.
When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.
I don’t like to assume the worst and assign vindictitive motives to people, but what Apple is doing here is hard to read as anything other than petulant and nasty …and really, really bad for users.
If you’ve ever made a progressive web app, please fill in this survey.
In the same vein as that last link, Chris says what we’re all thinking:
Most of what we build is links from one page to another, and
formsubmissions that send data from the browser to the server.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
Scott has written a perfect description of HTML web components:
They are custom elements that
- are not empty, and instead contain functional HTML from the start,
- receive some amount of progressive enhancement using the Web Components JavaScript lifecycle, and
- do not rely on that JavaScript to run for their basic content or functionality.
Web Push on iOS is nearing its one year anniversary. It’s still mostly useless.
Sad, but true. And here’s why:
On iOS, for a website to be able to ask the user to grant the push notification permission, it needs to be installed to the home screen.
No other browser on any of the other platforms requires you to install a website for it to be able to send push notifications.
Apple is within their rights to withhold Web Push to installed apps. One could argue it’s not even an unreasonable policy - if Apple made installing a web app at least moderately straightforward. As it is, they have buried it and hidden important functionality behind it.
I really, really hope that the Safari team are reading this.