Can you feel the energy?
Tuesday, August 30th, 2022
Tuesday, August 16th, 2022
My talk, Building, was about the metaphors we use to talk about the work we do on the web. So I’m interested in this analysis of the metaphors used to talk about markup:
- Data is documents, processing data is clerking
- Data is trees, processing data is forestry
- Data is buildings, processing data is construction
- Data is a place, processing data is a journey
- Data is a fluid, processing data is plumbing
- Data is a textile, processing data is weaving
- Data is music, processing data is performing
Wednesday, July 27th, 2022
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
Thursday, May 12th, 2022
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.
Friday, April 22nd, 2022
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.
Tuesday, April 12th, 2022
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
Wednesday, March 9th, 2022
I feel like it’s high time I revived some interest in my proposal for
button type="share". Last I left it, I was gathering use cases and they seem to suggest that the most common use case for the Web Share API is sharing the URL of the current page.
If you want to catch up on the history of this proposal, here’s what I’ve previously written:
A good example is the Constraint Validation API. For the most common use cases, the
required attribute and
A bad example is the Geolocation API. The most common use case is getting the user’s current location. But there’s no
input type="geolocation" (or
I’ve been thinking about how a lot of recently-proposed APIs end up having to deal with what Chrome devrel’s been calling the “user gesture/activation budget”, and wondering if that’s a good indicator of when something should have been HTML in the first place.
I think he’s onto something here!
button type could be minted?
The Web Share API is a classic example. You can’t invoke the API after an event like the page loading. You have to invoke the API after a user-initiated event like, oh, I don’t know …clicking on a button!
The Fullscreen API has the same restriction. You can’t make the browser go fullscreen unless you’re responding to user gesture, like a click. So why not have
button type="fullscreen" in HTML to encapsulate that? And again, the fallback in non-supporting browsers is predictable—it behaves like a regular button—so this is trivial to polyfill. I should probably whip up a polyfill to demonstrate this.
button type value.
The only potential flaw in this thinking is that some APIs that require a user gesture might also require a secure context (either being served over HTTPS or
localhost). But as far as I know, HTML has never had the concept of features being restricted by context. An element is either supported or it isn’t.
That said, there is some prior art here. If you use
input type="password" in a non-secure context—like a page being served over HTTP—the browser updates the interface to provide scary warnings. Perhaps browsers could do something similar for any new
Monday, March 7th, 2022
I’m glad that Heydon has answered this question once and for all.
I’m sure that’ll be the end of it now.
Thursday, February 10th, 2022
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.
Wednesday, November 17th, 2021
Saturday, October 23rd, 2021
A neat little tool when you need a reminder about what elements can go in other elements.
Wednesday, October 20th, 2021
Do you need a button for your next project but you’re not sure about the right markup? Don’t worry, The Button Cheat Sheet™️ has got you covered.
Spoiler alert: it’s the
Monday, September 20th, 2021
On the surface this is about the pros and cons of minting a new HTML
search element to replace
div role="search" but there’s a deeper point which is that, while ARIA exists to the plug the gaps in HTML, the long-term goal is to have no gaps.
ARIA is not meant to replace HTML. If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies.
Tuesday, July 6th, 2021
Personally, I’m not convinced that a new element is needed but I’m open to the suggestion.
I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.
Sunday, June 6th, 2021
A great introduction to structuring your content well:
Sunday, May 16th, 2021
The point of this post is to show how nicely container queries can play with web components, but I want to also point out how nice the design of the web component is here: instead of just using an empty custom element, Max uses progressive enhancement to elevate the markup within the custom element.
Tuesday, May 11th, 2021
The more I consume content in reading apps, the more I am reminded of the importance and the power of progressive enhancement as a strategy to create resilient and malleable experiences that work for everyone, regardless of how they choose to consume our content.
Top stuff from Sara here!
We have a tendency to always make an assumption about how our readers are reading our content—probably in the browser, with our fancy styles applied to it. But if we make a habit out of thinking about the Web in layers and CSS as an enhancement on top of the content layer, then we can start optimizing and enhancing our users’ reading experiences regardless of their context.
Thinking about the different ways in which users access the Web only shines light on the importance of a progressively enhanced approach to building for the Web. The more we think about the Web in layers and try to improve the experience of one layer before moving to the next, the more resilient experiences we can create. That’s what the essence of progressive enhancement is about.
Monday, April 19th, 2021
This is a great HTML boilerplate, with an explanation of every line.