The day we started to allow email clients to be full-blown web browsers (but without the protections of browsers) was the day we lost — time, security, privacy, and effectiveness. Now we spend all our time fighting with the materials of an email (i.e. color and layout) rather than refining its substance (i.e. story and language).
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
Some thoughts—and kind words—prompted by my recent talk, In And Out Of Style.
I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.
Robin adds a long-zoom perspective on my recent post:
This is exactly the pattern of usage I’ve been advocating for with web components—instead of creating a custom element from scratch, wrap an existing HTML element and use the custom element to turbo-charge it, like Zach is doing:
By enhancing native HTML instead of replacing it, we can provide a solid baseline experience, and add progressive enhancement as the cherry on top.
A cautionary tale on why you should keep your dependencies to a minimum and simplify your build process (if you even need one):
If it’s not link rot that gets you then it’s this heat death of the universe problem with entropy setting in slowly over time. And the only way to really defend against it is to build things progressively, to make sure that you’re not tied to one dependency or another. That complex build process? That’s a dependency. Your third party link to some third party font service that depends on their servers running forever? Another dependency.
This is a really excellent four-part series on web performance that really dives into the technical details and asks all the right questions:
Addy takes a deep dive into making sure your images are performant. There’s a lot to cover here—that’s why I ended up splitting it in two for the responsive design course: one module on responsive images and one on the
I can’t remember the last time that a website made me smile like this.
You had me at “beautifully resilient apps with progressive enhancement”.
This is a great clear walkthrough of enhancing a form submission. A lot of this seems like first principles to me, but if you’ve only ever built single page apps, then thinking about a server-submission process first might well be revelatory.
Excellent advice from Jeremy who wants us to build fast, reliable, resilient websites …even if the technologies involved in doing that don’t feel exciting.
Central to that endeavor is recognizing that the browser gives you a ton of stuff for free. Relying on those freebies requires a willingness to not
I’m glad that Heydon has answered this question once and for all.
I’m sure that’ll be the end of it now.
It’s great to see browsers working together to collectively implement a range of much-needed features.
These scores represent how browser engines are doing in 15 focus areas and 3 joint investigation efforts.
Here’s a great explanation of progressive enhancement, complete with practical examples and myth-busting. Pass it ‘round!
If you care about quality engineering, you want as much fault tolerance in the things you build as possible.
The headline is a little misleading because if you follow this advice, your multi-page apps will be much much faster than single page apps, especially when you include that initial page load of a single page app.
Here’s a quick high-level summary of what I do…
That’s an excellent recipe for success right there!
This is how a web component should be designed! Zach has made a custom element that wraps around an existing HTML element, turbocharging its powers. That’s the way to think about web components—as a progressive enhancement.
Prompted by the rhetorical question at the end of my post Today, the distant future, Jim casts his gaze into a crystal ball. I like what he sees.
However, I also think it’s possible—and dare I predict—to say we are peaking in our divergence and are now facing a convergence back towards building with the grain of the web and its native primitives.
Why do I say that? In our quest for progress, we explored so far beyond the standards-based platform that we came to appreciate the modesty of the approach “use the platform”.
He also makes one prediction that lies within his control:
This blog post will still be accessible via its originally published URL in 2036.
I’d recommend going in the order HTML, CSS, JS. That way, you can build something in HTML, add CSS to it as you learn it, and finally soup it up with your new-found JS knowledge.
Excellent advice for anyone new to web develoment.
This is a wonderful piece by Bram. Half history lesson, and half practical advice for building resilient websites today:
By embracing what the web platform gives us — instead of trying to fight against it — we can build better websites.
Keep it simple. Apply the Rule of Least Power. Build with progressive enhancement in mind.