Bruce raises an interesting question with media playing in popovers—shouldn’t the media pause when the popover is closed? I agree with Bruce that this is a common use case that should be covered declaratively.
Gosh! And I thought I had strong opinions about markup!
A great reminder of just how much you can do with modern markup and styles when it comes to form validation. The :user-invalid and :user-valid pseudo-classes are particularly handy!
I enjoyed this self-documenting journey of exploration.
This is a handy guideline to remember, even if there exceptions:
When a keyboard user follows a link, their focus should be taken to the new place; when a keyboard user presses a button, focus should remain on that button.
This is a great step-by-step guide to HTML by Estelle.
It gives me warm fuzzies to see an indie web building block like rel="me" getting coverage like this.
A demonstration of how even reinventing a relatively simple wheel takes way more effort than it’s worth when you could just use what the brower gives you for free.
Can you feel the energy?
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
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
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.
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.
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 picture element.
I’m glad that Heydon has answered this question once and for all.
I’m sure that’ll be the end of it now.
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.
I really like the progressive enhancement approach that this little library uses—it’s basically the Hijax approach I was talking about back in the days of Bulletproof Ajax but all wrapped up into a neat package that you can use entirely via HTML attributes.
A neat little tool when you need a reminder about what elements can go in other elements.
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 button element.