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.
With the release of a new Salter Cane album I figured it was high time to update the design of the band’s website.
Here’s the old version for reference. As you can see, there’s a connection there in some of the design language. Even so, I decided to start completely from scratch.
I opened up a text editor and started writing HTML by hand. Same for the CSS. No templates. No build tools. No pipeline. Nothing. It was a blast!
And lest you think that sounds like a wasteful way of working, I pretty much had the website done in half a day.
Partly that’s because you can do so much with so little in CSS these days. Custom properties for colours, spacing, and fluid typography (thanks to Utopia). Logical properties. View transitions. None of this takes much time at all.
Because I was using custom properties, it was a breeze to add a dark mode with prefers-color-scheme. I think I might like the dark version more than the default.
The final stylesheet is pretty short. I didn’t bother with any resets. Browsers are pretty consistent with their default styles nowadays. As long as you’ve got some sensible settings on your body element, the cascade will take care of a lot.
There’s one little CSS trick I think is pretty clever…
The background image is this image. As you can see, it’s a rectangle that’s wider than it is tall. But the web pages are rectangles that are taller than they are wide.
So how I should I position the background image? Centred? Anchored to the top? Anchored to the bottom?
If you open up the website in Chrome (or Safari Technical Preview), you’ll see that the background image is anchored to the top. But if you scroll down you’ll see that the background image is now anchored to the bottom. The background position has changed somehow.
This isn’t just on the home page. On any page, no matter how tall it is, the background image is anchored to the top when the top of the document is in the viewport, and it’s anchored to the bottom when you reach the bottom of the document.
In the past, this kind of thing might’ve been possible with some clever JavaScript that measured the height of the document and updated the background position every time a scroll event is triggered.
But I didn’t need any JavaScript. This is a scroll-driven animation made with just a few lines of CSS.
@keyframes parallax {
from {
background-position: top center;
}
to {
background-position: bottom center;
}
}
@media (prefers-reduced-motion: no-preference) {
html {
animation: parallax auto ease;
animation-timeline: scroll();
}
}
}
This works as a nice bit of progressive enhancement: by default the background image stays anchored to the top of the viewport, which is fine.
Once the site was ready, I spent a bit more time sweating some details, like the responsive images on the home page.
But the biggest performance challenge wasn’t something I had direct control over. There’s a Spotify embed on the home page. Ain’t no party like a third party.
I could put loading="lazy" on the iframe but in this case, it’s pretty close to the top of document so it’s still going to start loading at the same time as some of my first-party assets.
I decided to try a little JavaScript library called “lazysizes”. Normally this would ring alarm bells for me: solving a problem with third-party code by adding …more third-party code. But in this case, it really did the trick. The library is loading asynchronously (so it doesn’t interfere with the more important assets) and only then does it start populating the iframe.
This made a huge difference. The core web vitals went from being abysmal to being perfect.
I’m pretty pleased with how the new website turned out.
- 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!
I like the approach here: logical properties and sensible default type and spacing.
I’m very glad to see that work has moved away from a separate selectmenu element to instead enhancing the existing select element—I could never see an upgrade path for selectmenu, but now there are plenty of opportunities for progressive enhancement.
Laying out sheet music with CSS grid—sounds extreme until you see it abstracted into a web component.
We need fluid and responsive music rendering for the web!
Those HTML web components I made for date inputs are very simple. All they do is slightly extend the behaviour of the existing input elements.
This would be the ideal use-case for the is attribute:
<input is="input-date-future" type="date">
Alas, Apple have gone on record to say that they will never ship support for customized built-in elements.
So instead we have to make HTML web components by wrapping existing elements in new custom elements:
<input-date-future>
<input type="date">
<input-date-future>
The end result is the same. Mostly.
Because there’s now an additional element in the DOM, there could be unexpected styling implications. Like, suppose the original element was direct child of a flex or grid container. Now that will no longer be true.
So something I’ve started doing with HTML web components like these is adding something like this inside the connectedCallback method:
connectedCallback() {
this.style.display = 'contents';
…
}
This tells the browser that, as far as styling is concerned, there’s nothing to see here. Move along.
Or you could (and probably should) do it in your stylesheet instead:
input-date-future {
display: contents;
}
Just to be clear, you should only use display: contents if your HTML web component is augmenting what’s within it. If you add any behaviours or styling to the custom element itself, then don’t add this style declaration.
It’s a bit of a hack to work around the lack of universal support for the is attribute, but it’ll do.
This is a great thought exercise in progressive enhancement …that Scott then turns into a real exercise!
I love it when I come across some bit of CSS I’ve never heard of before.
Take this article on the text-emphasis property.
“The what property?”, I hear you ask. That was my reaction too. But look, it’s totally a thing.
Or take this article by David Bushell called CSS Button Styles You Might Not Know.
Sure enough, halfway through the article David starts talking about styling the button in an input type="file” using the ::file-selector-button pseudo-element:
All modern browsers support it. I had no idea myself until recently.
Then I remembered that I’ve got a file upload input in the form I use for posting my notes here on adactio.com (in case I want to add a photo). I immediately opened up my style sheet, eager to use this new-to-me bit of CSS.
I found the bit where I style buttons and this is the selector I saw:
button,
input[type="submit"],
::file-selector-button
Huh. I guess I did know about that pseudo-element after all. Clearly the knowledge exited my brain shortly afterwards.
There’s that tautological cryptic saying, “You don’t know what you don’t know.” But I don’t even know what I do know!
Adam makes a very good point here: the term “vertical rhythm” is quite chauvanistic, unconciously defaulting to top-to-bottom writing modes; the term “logical rhythm” is more universal (and scalable).
Heydon does a very good job of explaining why throwing away the power of selectors makes no sense.
Utility-first detractors complain a lot about how verbose this is and, consequently, how ugly. And it is indeed. But you’d forgive it that if it actually solved a problem, which it doesn’t. It is unequivocally an inferior way of making things which are alike look alike, as you should. It is and can only be useful for reproducing inconsistent design, wherein all those repeated values would instead differ.
He’s also right on the nose in explaining why something as awful at Tailwind could get so popular:
But CSS isn’t new, it’s only good. And in this backwards, bullshit-optimized economy of garbage and nonsense, good isn’t bad enough.
I remember Jon telling me this lovely story when we first met in person. I love the idea that we had already met in a style sheet.
I also love the idea of hosting your own little internet archive—that Bill Oddie site still looks pretty great to me!
It’s a lot like an embarrassing family photo, but I’m owning it!
With classes, we can send CSS static values but with custom properties we can send dynamic ones, which is a major shift in the way we can style state. This is something that has been true for some time—and is extremely well supported—but sometimes it takes solving a small real-world problem to make you appreciate the value of it.
I think we still haven’t come to fully appreciate the superpower of custom properties: dynamic values that are shared between CSS and JavaScript.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
I love how straightforward these bits of CSS are—time to rip out some of those old complicated hacks and workarounds!
The main reason I’m so hot on Light DOM is that I find the styling story of Web Components using Shadow DOM annoying.
This is an excellent step-by-step walkthrough by Tess of creating a web component, with real thought given to what should be in the HTML (which will act as a fallback) and what’s better generated in the Shadow DOM (like buttons for interactivity).
This perfectly mirrors something Chris was saying in a recent episode of the Shop Talk Show:
I think of the image comparison one. That’s a classic example in Web component. What’s inside is just two IMG tags. That’s it. When it fails, you don’t want a weird div with little arrows on it being rendered on the page. That’s not doing anything because it has failed to load the JavaScript.