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-valid pseudo-classes are particularly handy!
I enjoyed this self-documenting journey of exploration.
On day 1 of your class about behaviour change in a science course, you learn that behaviour change is not a simple matter of information in, behaviour out. Human behaviour, and changing it, is big and complex.
Meanwhile, on your marketing courses, which I have had the misfortune to attend, the model of changing behaviour is pretty much this: information in, behaviour out.
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.
Good writing advice from Matt.
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
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.
At its very core, the rules of the web are different than those of “real” markets. The idea that ownership fundamentally means that nobody else can have the same thing you have just doesn’t apply here. This is a world where anything can easily be copied a million times and distributed around the globe in a second. If that were possible in the real world, we’d call it Utopia.