It’s official: hash bang URLs are an anti-pattern, and if you want your content indexed by Google, use progressive enhancement:
Since the assumptions for our 2009 proposal are no longer valid, we recommend following the principles of progressive enhancement.
- 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.
This is very nice HTML web component by Miriam, progressively enhancing an ordered list of audio elements.
This is a great history of the idea of progressive enhancement:
It is an idea that has been lasting and enduring for two decades, and will continue.
So what are the advantages of the Custom Elements API if you’re not going to use the Shadow DOM alongside it?
- Obvious Markup
- Instantiation is More Consistent
- They’re Progressive Enhancement Friendly
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.
Having fun with view transitions and scroll-driven animations.
Here’s Clearleft’s approach to browser support. You can use it too (it’s CC-licensed).
Here’s how I interpret the top-level guidance in the Web Content Accessibility Guidelines.
A performance boost in Chrome.
If a browser feature can be used as a progressive enhancement, you don’t have to wait for all browsers to support it.