Here’s the video of the talk I gave at the Web Stories conference back in February.
I click the link. The page loads fast. I navigate the surprisingly sparse yet clear form inputs. And complete the whole thing in less than thirty seconds.
Oh, how I wish this experience weren’t remarkable!
Simple forms with clear labels. Little to no branding being shoved down my throat. No array of colors, big logos, or overly-customized UI components.
Getting a tattoo. brb
I remember discussing this with Tantek years ago:
There are a few elements who need to be placed inside of another specific element in order to function properly.
If I recall, he was considering writing “HTML: The Good Parts”.
Anyway, I can relate to what Eric is saying here about web components. My take is that web components give developers a power that previous only browser makers had. That’s very liberating, but it should come with a commensurate weight of responsibility. I fear that we will see this power wielded without sufficient responsibility.
Receive one email a day for 30 days, each featuring at least one HTML element.
Right up my alley!
An excellent explainer from Trys and James of their supersmart Utopia approach:
Utopia encourages the curation of a system small enough to be held in short-term memory, rather than one so sprawling it must be constantly referred to.
Six years old. Still very astute. Still very true.
Good to see Google, Mozilla, and Apple collaborating on fixing cross-browser CSS compatability issues:
- position: sticky
You can track progress here.
Given the widespread browser support for
prefers-reduced-motion now, this approach makes a lot of sense.
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.
And, no, you don’t need to
npm install any of these. Try “vendoring” them instead (that’s copying and pasting to you and me).
I agree with this approach.
What’s important is that you test it with real users… and stop using hover menus.
This is terrific! Jeremy shows how you can implement a fairly straightforward service worker for performance gains, but then really kicks it up a notch with a recipe for turning a regular website into a speedy single page app without framework bloat.
Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:
Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.
So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.
I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.
For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.
I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.