Hiding elements that require JavaScript without JavaScript :: dade
This is clever: putting CSS inside a noscript
element to hide anything that requires JavaScript.
Riffing on an offhand comment I made about progressive enhancement being a form of “technical credit”, Chris dives deep into what exactly that means. There’s some really great thinking here.
With such a wide array of both expected and unexpected properties of the current technological revolution, building our systems in such a way to both be resilient to potential failures and benefit from unanticipated events surely is a no-brainer.
This is clever: putting CSS inside a noscript
element to hide anything that requires JavaScript.
- 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
How I switched to high-resolution maps on The Session without degrading performance.
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).
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.