A classic example of the holy grail of web performance and robustness—start with regular HTML sent from the server, enhance once it’s in the browser …if the browser is capable of it. In this case, it’s using JavaScript (React) on both the server and the browser.
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.
This is an interesting thought from Scott: using Shadow DOM in HTML web components but only as a way of providing sort-of user-agent styles:
providing some default, low-specificity styles for our slotted light-dom HTML elements while allowing them to be easily overridden.
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!
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.
If a browser feature can be used as a progressive enhancement, you don’t have to wait for all browsers to support it.
A little fix for Safari.
Baldur Bjarnason has written my mind.