This looks like a really interesting proposal for allowing developers more control over styling inputs. Based on the work being done the customisable select element, it starts with a declaration of appearance: base.
And by LLMS I mean: (L)ots of (L)ittle ht(M)l page(S).
I really like this approach: using separate pages instead of in-page interactions. I remember Simon talking about how great this works, and that was a few years back, before we had view transitions.
I build separate, small HTML pages for each “interaction” I want, then I let CSS transitions take over and I get something that feels better than its JS counterpart for way less work.
This is a great little helper in understanding anchor positioning in CSS.
This describes how I like to work too.
If you like the prospect of an old man ranting at clouds, this is for you.
- Springy easing with
linear()- Typed custom properties
- View transitions for page navigation
- Transition animation for
dialogandpopover- Transition animation for
details- Animated adaptive gradient text
Some interesting experiments in web typography here.
It’s great to see the evolution of HTML happening in response to real use-cases—the turbo-charging of the select element just gets better and better!
CSS wants you to build a system with it. It wants styles to build up, not flatten down.
Truth!
Anselm isn’t talking about becoming a CSS wizard, but simply having an understanding of what CSS can do. I have had similar experiences to this:
In the past years I had various situations where TypeScript developers (they called themselves) approached me and asked whether I could help them out with CSS. I expected to solve a complex problem but for me — knowing CSS very well — it was always a simple, straightforward solution or code snippet.
Let’s face it, “full stack” usually means “JavaScript”—HTML and CSS aren’t considered worthy of consideration. Their loss.
Technology doesn’t have to be terrible. Here’s an absolutely wonderful use of an e-ink display:
I made as much use of vanilla HTML and CSS as possible. I used a small amount of JavaScript but no framework or other libraries.
This makes sense:
Wrap everything in your CSS reset with a
@layerrule.When you place any styles inside a layer, these styles automatically have lower priority compared to all unlayered styles on the page. Think of it like an
!unimportantblock. You don’t need to worry about specificity or order of stylesheets at all.
Logical properties, container queries, :has, :is, :where, min(), max(), clamp(), nesting, cascade layers, subgrid, and more.
I like the approach here: logical properties and sensible default type and spacing.
I really like the way that the thinking here is tied back to Bert Bos’s original design principles for CSS.
This is a deep dive into the future of CSS layout—make a cup of tea and settle in for some good nerdiness!
Trys describes exactly the situation where you really do need to use the Shadow DOM in a web component—as opposed to just sticking to HTML web components—, and that’s when the component is going to be distributed and you have no idea where:
This component needed to be incredibly portable, looking great on any third-party website, in any position, at any viewport, with any amount of content. It had to be a “hyper-responsive” component.
Picture me holding Trys back and telling him, “Leave it alone, mate, it’s not worth it!”
Oh, how I wish that every team building for the web would use this sensible approach!
Every problem at every company I’ve ever worked at eventually boils down to “please dear god can we just hire people who know how to write HTML and CSS.”