Container Queries and Typography
I feel like we need a name for this era, when CSS started getting real good.
I think this is what I’ve been calling declarative design.
I feel like we need a name for this era, when CSS started getting real good.
I think this is what I’ve been calling declarative design.
Like a little mini Utopia:
Handy little tool for calculating viewport-based clamped values.
Over the past 10 years or so, we’ve slowly but very surely transitioned to a state where frameworks are the norm, and I think it’s a problem.
I concur.
Use the frameworks and libraries that make sense for you to deliver the best UX possible. But also learn the web platform from the ground up. Take time to understand how web browsers work and render webpages. Learn HTML, CSS, JavaScript. And keep an eye, if you can, on the new things.
Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)
queries to break to layouts that allow for more real estate as it becomes available.- If your site doesn’t work without JavaScript, your site doesn’t work.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.
Now Michelle asks:
Suppose we want to stop using Tailwind one day?
Turns out it’s a bit of a roach motel, much like most JavaScript frameworks: you can get in but you can’t easily get out.
So whenever possible, the safest, and most future-proof bet is to use the native features of the web platform.
Wise words:
Myself, I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.
To paraphrase Michael Pollan:
Write CSS, not too much, mostly vanilla.
There’s a broader point here about declarative design:
Setting very specific values may feel like you’re in more control, but you’re actually rescinding control by introducing fragility in the form of overly-specific CSS.
I like to think of CSS as a conditional design language.
Yes! This is exactly what I’m talking about with declarative design!
Read on for some fantastic examples. And also, Ahmad makes a comparison between CSS and Figma, pointing out that the conditional, declarative possibilities currently aren’t available in graphic design tools.
I did not know about box-decoration-break
—sounds like a game-changer for text effects that wrap onto multiple lines.
Styling a list of nested details
elements to create a beautiful lokking tree view, all in CSS, all nicely accessible.
Hear, hear!
If you have even a passing knowledge of CSS, I encourage you to experiment with its possibilities.
All twelve are out, and all twelve are excellent deep dives into exciting web technologies landing in browsers now.
A collection of stylesheets that don’t use class selectors. Think of them as alternatives to default user-agent stylesheets.
This is a superb explanation of flexbox—the interactive widgets sprinkled throughout are such a great aid to learning!
In order to thoroughly attend to every pertinent aspect of the spec, fantasai asked us each to read one sentence aloud to the group. At which point we were all asked whether we thought the sentence made sense, and to speak up if we didn’t understand any of it or if it wasn’t clear.
Rich documents the excellent and fascinating process used in a recent W3C workshop (though what he describes is the very opposite of groupthink, so don’t let the title mislead you):
I’d never come across the person-by-person, sentence-by-sentence approach before. I found it particularly effective as a way of engaging a group of people, ensuring collective understanding, and gathering structured feedback on a shared document.
Reminder:
em
andrem
work with the user’s font size;px
completely overrides it.
What happens if the ‘pace layers’ get out of sync?
A very thoughtful post by Miriam on how tools can adversely affect the pace of progress in the world of web standards.
When tools intervene between you and your access to the web platform, proceed with caution. Ask not only: How well does it work? But also: How well does it fail? Not only: What features do they provide? But also: What features do they prevent?
Here’s a remarkably in-depth timeline of the web’s finest programming language, from before it existed to today’s thriving ecosystem. And the timeline is repsonsive too—lovely!
A good ol’ rant by Vasilis on our design tools for the web.
I think this might be the most excited I’ve been in quite some time about an update to browser support, which probably says a lot about my priorities:
Support for the
avoid
value of the CSS fragmentation propertiesbreak-before
,break-after
, andbreak-inside
when printing.
Finally!