Progressive enhancement brings everyone in - The History of the Web
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.
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.
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.
This proposal is exactly what I was asking for!
C’mon browsers, let’s make this happen!
It’s kind of ridiculous that this functionality doesn’t exist yet.
Here’s how I interpret the top-level guidance in the Web Content Accessibility Guidelines.
A little fix for Safari.
Baldur Bjarnason has written my mind.
Reframing the principle of least power.