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.
I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.
Anselm isn’t talking about becoming a CSS wizard, but simply having an understanding of what CSS can do. I have had similar experiences to this:
In the past years I had various situations where TypeScript developers (they called themselves) approached me and asked whether I could help them out with CSS. I expected to solve a complex problem but for me — knowing CSS very well — it was always a simple, straightforward solution or code snippet.
Let’s face it, “full stack” usually means “JavaScript”—HTML and CSS aren’t considered worthy of consideration. Their loss.
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
Technology doesn’t have to be terrible. Here’s an absolutely wonderful use of an e-ink display:
I made as much use of vanilla HTML and CSS as possible. I used a small amount of JavaScript but no framework or other libraries.
Having fun with view transitions and scroll-driven animations.
It’s almost as though humans prefer to use post-hoc justifications rather than being rational actors.
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.