I almost missed this great post by Una Kravets on the upcoming changes to the <select> element where soon we’ll be able to customize it to our heart’s content without the need to hack things together. Una shows how we’ll be able to do that soon with just this little bit of CSS:

select,
::picker(select) {
	appearance: base-select;
}

A few visual changes are made by default which is weird and interesting, but the most important thing is that now under the hood we have access to style the popover when we click that <select>. This is rad as hell and I can’t wait for this to land in browsers.

This is a neat detail, too:

The new customizable <select> uses functionality from popover and anchor positioning. It's built with these two underlying technologies. This means that the drop-down option list within a select acts as a popover which is anchored to the trigger button that opens the select.

Richard Rutter made a cool new CSS reset:

The idea is to set sensible typographic defaults for use on prose (a column of text), making particular use of the font features provided by OpenType. The main principle is that it can be used as starting point for all projects, so doesn’t include design-specific aspects such as font choice, type scale or layout (including how you might like to set the line-length).

Within the styles is mildly opinionated best practice, which will help set suitable styles should you forget.

There’s a lot of smart, sensible defaults and make sure to take a gander at the full stylesheet. But there’s little things like this:

.centered {
  text-align: center;
  text-wrap: balance;
}

Just good type helper classes, with a handy reminder to use text-wrap: balance to boot.

Michelle Barker wrote this nifty piece about blockquotes but then at the end talks about why it’s so important to learn HTML:

Conversely, it’s pretty easy to write bad HTML, because for most developers there are no consequences. If you write some bad Javascript, your application will probably crash and you or your users will get a horrible error message. It’s like a flashing light above your head telling the world you’ve done something bad. At the very least you’ll feel like a prize chump. HTML fails silently. Write bad HTML and maybe it means someone who doesn’t browse the web in exactly the same way as you do doesn’t get access to the information they need. But maybe you still get your pay rise and bonus.

Chase McCoy:

You might be aware of a visual effect related to HDR videos if you’ve ever scrolled Instagram on your iPhone—the pixels displaying the HDR content display in full brightness, while the rest of the screen is slightly dimmed.

[...] The illustrations for Digital Divinity make use of this effect in a brilliant (literally) way by masking a pure white, HDR video such that parts of the illustration glow with an ethereal brightness. For devices that support displaying HDR content brighter than the rest of the screen, the effect is stunning.

This is a surreal effect from Digital Divinity and Chase made a really neat demo of this technique with the original Star Wars poster where the lightsaber appears to be tearing a hole straight through my screen.

Doug Parker made some interesting notes about the unexpected behavior of whitespace:

Why exactly does HTML work this way? Why did we make this language so complicated?

I think the core problem here is that all whitespace in HTML is ambiguous. Specifically, it is ambiguous with regard to the developer's intent. For any given space, did the developer mean for it to be displayed to the user or did they just want to keep their code under the line length limit? It's impossible for the browser to know.

To address this, the designers of HTML tried to come up with a set of rules which would roughly map the HTML code they wanted to write to the rendered output they wanted to create. So you, as a developer, have a UI in your head and write out the HTML to display it, and usually the whitespace "just works".

The unpredictability of whitespace causes all sorts of problems as Doug notes: code formatting bugs, accidental line breaks, etc. and there’s been so, so many times that I’ve had to fight whitespace that often I’ve just hacked things together until it works right or let it act out and be wrong and weird.

Doug mentions that although we can’t easily change this behavior of HTML without breaking changes, he recommends adding a new entity to help: &ncsp;.

I love this post Adam Stoddard on building a color and theming system for his website because it outlines all the hidden and oft-ignored complexities behind great UI engineering. Adam writes:

What does an ideal CSS color system look like? My answer to this question has evolved along the way, but here’s what I think, today:

• Composable, cascading themes - You should be able to set different themes at the page-level, section-level, and component-level, and have them cascade down until a different theme is applied.
• Light & dark mode for all themes - Color themes shouldn’t be in addition to light and dark mode, every theme includes light and dark mode support.
• Expressive - It should be easy to change opacity, use tints and shades, etc. within the context of your system. No having to go off system just because you need to add transparency.
• Micromanagement-free - You should never even have to think about working with specific hues at the component level. In other words, adding a new theme shouldn’t mean touching every component.
• Small set of properties - You should be able to worth with a small set of properties that you can further modify vs. maintaining an extensive list of semantic colors. Easier to work with, and easier to make new themes.
• Good DX - It should feel good to work with. Flexible, straightforward, reads intuitively, forgiving, consistent, etc.

Adam then walks step by step how we could go about doing that whilst listing the cons to his approach. One thing I really like about this system is how Adam uses the new light-dark() function that I’d totally forgotten about. Super neat stuff.

How have I never heard of the animation-composition property before? I just spotted it over on Manuel Matuzović’s blog:

CSS animations can be composited in three ways: replace, add, and accumulate. The animation-composition property allows you to switch between them.

Huh! So you can effectively add, replace, or combine animations together which is something I’ve never thought about before! I had never even thought much about the default behavior too, which replaces an animation on an element, so that in the CSS below the .element will only move 100px...

.element {
  animation: move 2s infinite;
  transform: translateX(10px);
}

@keyframes move {
  to {
    transform: translateX(100px);
  }
}

But what if you wanted these properties to stack, so that you have 100 + 10 here? That’s what animation-composition is for and you can use it like this:

.element {
  animation: move 2s infinite;
  transform: translateX(10px);
  animation-composition: add;
}

@keyframes move {
	to {
		transform: translateX(100px);
	}
}

Huh! Very neat indeed!

The funny thing is that when I saw this property this morning my first thought was: why on earth do we need this? I couldn’t imagine scenarios where this would help me out of tricky problems or help me with animation work (which, admittedly, is very rare for me). And then later in the afternoon I was working with an engineer and realized that we could use this animation-composition stuff without writing a bunch of complicated JavaScript!

Oh and make sure to check out Bramus’ post combining multiple animation effects, too.

This is your daily reminder that Wakamai Fondue is an invaluable resource when dealing with font files. A lot of the time I’ll buy a font and the PDF specimen won’t tell me how to use a feature with CSS! It’s annoying!

Thankfully the open beta has a host of improvements when it comes to variable fonts too, so first you upload your font and then tweak the optical size, weight, width, or turn on stylistic sets, fractions, and countless other OpenType goodies. It’ll then spit out the CSS that you need, like this:

.element {
  font-feature-settings: "c2sc" 1, "dnom" 1, "frac" 1, "lnum" 1, "smcp" 1, "ss01" 1, "ss03" 1, "ss05" 1;
  font-variation-settings: "opsz" 48, "wght" 300, "wdth" 100, "ital" 1;
}

Alex Russell has written a fantastic series of posts on the “JavaScript-industrial-complex” where he explores how the current state of web performance has become unacceptable and how dire the situation has become:

We are not getting better UX for the escalating capital and operational costs. Instead, the results are getting worse for folks on the margins. JavaScript-driven frontend complexity hasn't just driven out the CSS and semantic-markup experts that used to deliver usable experiences for everyone, it is now a magnifier of inequality.

Each post is endlessly quote-worthy because so much of it matches my experience working on big, slow web apps which, for the most part, have ignored the lessons of progressive enhancement. Why are websites like this? Why are they embarrassing?

Well, Alex makes this great point:

Unacceptable performance is the consequence of a chain of failures to put the user first. Breaking the chain usually requires just one insistent advocate.

He then takes this one step further and argues that the biggest threat to the web is the JavaScript-ification of it; bloated, slow websites make an argument against the web ‘platform’ as a whole and might even threaten its future existence. Why not download an app if the website is obviously going to suck?

And so, to save the web, we must first care for the user—and then make our websites fast as hell.

Here’s a fantastic trick with background-attachment: fixed from Kevin Powell:

Huh! Also, doing a quick search for other cool things you can do with this trick, I found that Geoff already made a collection of use cases for fixed backgrounds in CSS years ago that’s worth checking out, too.

The other day I wanted to make a CSS animation where an object would rotate around a circle so this was the first thing I tried:

@keyframes circle {
  0%{
    transform: rotate(0deg);
  } 100% {
    transform: rotate(360deg);
  }
}

See the Pen Untitled by Robin Rendle (@robinrendle) on CodePen.

Gah! That’s not the right kind of rotation I wanted.

What I really needed was for the whole object to be locked in place and rotate around the center. So I tried again, but this time I added a translate in there:

@keyframes circle {
  0%{
    transform: rotate(0deg) translate(-10px);
  }
  100%{
    transform: rotate(360deg) translate(-10px);
  }
}

See the Pen Rotate Circle 1 by Robin Rendle (@robinrendle) on CodePen.

Okay, that’s got the position I want where the image rotates around a center – but how do I prevent that rotation of the image itself? WELL, I found kirupa’s post about animating items around a point but all those items show the same side to the center as they rotate. So sadly that didn’t help me.

After fiddling with things and playing around, and I cannot tell you how I managed to get here dear reader, but this CSS eventually worked for me:

@keyframes circle {
  0%{
    transform: rotate(0deg) translate(-10px) rotate(0deg);
  }
  100%{
    transform: rotate(360deg) translate(-10px) rotate(-360deg);
  }
}

See the Pen Rotate Circle 2 by Robin Rendle (@robinrendle) on CodePen.

That’s the precise effect I was lookin’ for!

This doesn’t have much to do with CSS, but this new feature by Framer called Fetch caught my eye:

The reason why I mention this is because it shows a snapshot of what the future of web design tools might be: they’re not just going to allow you to draw pixels on a canvas, but allow you to build real, interactive software that pings a database.

That’s exciting to me! As a designer by day, I want to make better prototypes of my designs and using real data helps sell my ideas. But it also makes me a little fearful for the future of front-end development? I would see something like this as a prototyping tool, ready to give to a talented UI engineer to build properly once I’m finished with it, but I fear that folks will see this and think of ditching front-end developers altogether.

After all these years of using CSS Grid and I still feel like I haven’t grokked everything that it’s capable of. Ahmad Shadeed’s latest interactive tutorial is a great reminder of that where he’s written about named grid areas and explains the following bit of CSS:

.layout {
  grid-template-columns:  [full-start] 1fr
                          [content-start] 2fr
                          [content-end] 1fr [full-end];
}

So what Ahmad has done here is defined and named specific areas of a grid and then he can use them elsewhere in his CSS like this:

.layout-item {
  grid-column: content-start / content-end;
}

Smart stuff.

I’m not sure how I fell of the bandwagon of Manuel Matuzović’s excellent 100 days of CSS...

It’s time to get me up to speed with modern CSS. There’s so much new in CSS that I know too little about. To change that I’ve started #100DaysOfMoreOrLessModernCSS. Why more or less modern CSS? Because some topics will be about cutting-edge features, while other stuff has been around for quite a while already, but I just have little to no experience with it.

That’s from the latest post all about this syntax I’d never seen before:

li:nth-child(even of :not([hidden])) {
  background-color: aqua;
}

The idea is to filter all of the even list elements that aren’t hidden. That is extremely useful and good to know!

I think my favorite line of CSS has finally been usurped! For maybe a decade my favorite line was this bad boy:

.element {
	display: grid;
	place-items: center;
}

Pure, simple, perfect. Throw some viewport units in on top and you now have Megazord-like super powers to take control of the browser canvas like you never could before.

Now though, my favorite line is this:

@view-transition {
	navigation: auto;
}

As Dave Rupert wrote a while back, this is the easiest way to add view transitions to your website today. And I’ve already added them here and on my blog whilst I figure out how exactly pages should animate in and out without making everyone sick of it.

Honestly, if this was the new default animation between pages on the internet then I’d be chuffed to bits. It feels a bit more app-like, a bit more polished and less janky then the clunky page switching of the past.

But but but!

Eric Portis warns us that this is all more complicated than it seems and when we add view transitions we need to test the heck out of them because they break incremental loading:

I worry that giving developers tools to explicitly block render – with or without View Transitions – is going to make experiencing the web on slow connections and cheap devices much worse.

[...] We need tuned timeouts that ensure that the long tail of slow devices/connections don’t wait for View Transitions if they would excessively delay first paint.

So: I am very excited about my favorite new line of CSS but we have to tread lightly with this stuff because it could end up hurting folks more than it helps.