utilitybend

Putting my money where my mouth is: a redesign built on progressive enhancement

Brecht De Ruyte — Wed, 04 Mar 2026 00:00:00 GMT

If you’ve been reading my articles or attended one of my talks, you probably know that I’m quite the fan of progressive enhancement. I’ve written about why you should be using new CSS features today, I’ve done conference demos showing off @supports and feature detection, and I’ve been trying to advocate the idea that we can use new CSS features without waiting for full browser support ever since I read Andy Clarke’s “Hardboiled web design” in 2010. So when I looked at my own blog and realized it wasn’t exactly living up to that message… well, it was time to do something about it.

It started out as a “just a quick typography fix” and turned into a full redesign (as it goes with side projects, nothing ever stays small). I wanted to share some of the things I did, some of the features I used, and how progressive enhancement plays into all of it. The CSS isn’t perfect (yet), it’s a side project after all and I will keep tinkering with it, but I had a lot of fun building this.

It started with typography

This one was on top of my list for quite some time. The font pairing on the old site just didn’t feel right anymore. The hierarchy was a bit off, and the reading experience could be better. I decided to go with Young Serif for headings, it has this warm character without being overly decorative. Inter for body text because it reads beautifully on screens, and I kept Source Code Pro for code blocks because the only thing I did love on the previous version was the code blocks.

Beyond just swapping fonts, I also reworked the entire type scale. Once again, it uses fluid sizing with clamp(), so the typography scales smoothly between viewport sizes without breakpoints:

--s-font-size-base: clamp(1rem, 0.46vw + 0.91rem, 1.31rem);
--s-line-height-base: clamp(1.625rem, 0.74vw + 1.48rem, 2.13rem);
--s-font-size-h1: clamp(1.3125rem, 3.15vw + 0.68rem, 3.44rem);

I also rethought the color palette while I was at it. The new design uses a warm cream base for light mode insted of being just “harsh” and a deep indigo for dark mode, built on oklch and color-mix() to keep things perceptually consistent across both themes.

But there was this other thing that was bugging me…

From SCSS to plain CSS, and organizing the project

I dropped SCSS entirely. The whole codebase is now plain CSS with native nesting. No Sass compilation, but I did rely on postCSS for the very basic things such as imports and minification. I wrote an article years ago wondering whether it was time to stop pre-processing CSS, and I believe this time was the right time.

For the architecture, I went with CSS cascade layers following a sort of “atomic design” approach:

@layer vendor, tokens, reset, base, atoms, molecules, organisms, pages, utilities;

I chose to load vendors first (don’t have many of those to begin with except for Prism). Makes it easier to override them if needed.

Each layer has its own set of files. One decision I’m quite happy with is putting some progressive enhancement features in their own dedicated files (for now). Things like corner-shapes.css and view-transitions.css each have their own file, which gives me a clear overview of what’s enhanced and makes it easy to manage or remove things if needed. It’s a small thing, but it helped a lot while the updates keeps growing (and believe me, they did).

Corner-shape: squircles and scoops

I have to admit, this one brings a smile to my face every time I look at it. If you’ve read my end-of-year article on corner-shape, you know I’m a fan. The corner-shape property lets you control how border-radius curves are drawn, giving you squircles instead of the standard circular arcs.

The entire implementation lives behind @supports, which makes it progressive enhancement in its purest form. If your browser supports it, you get those smooth curves. If not, you still get regular border-radius and you’re none the wiser:

@supports (corner-shape: squircle) {
    .intro-text {
        corner-shape: squircle;
    }

    .home-latest .article-preview {
        corner-shape: squircle;
    }

    pre[class*="language-"] {
        corner-shape: squircle;
    }

    .nav-category,
    .related,
    .comments {
        corner-shape: squircle;
    }
}

One thing worth mentioning: when corner-shape is supported, the existing border-radius values often look too subtle because the squircle curves are smoother by nature. So I bump up the radius primitives inside the @supports block to compensate. It’s not the most elegant solution, but it does the job. Yes, a purist would say I shouldn’t change a primitive…

My favorite part though, is the button hover effect. When you hover a button, the corner-shape transitions from round to round round round scoop, giving the bottom-left corner a playful inward curve:

.btn:not(.btn-link) {
    corner-shape: round;
    transition: corner-shape 0.24s ease, border-radius 0.24s ease;

    &:is(:hover, :focus-visible) {
        corner-shape: round round round scoop;
    }
}

Cross-document view transitions were the feature I was most excited to add. The foundation is surprisingly simple:

@view-transition {
    navigation: auto;
}

That gives you a basic crossfade between pages. But I wanted a bit more control. The header and footer are persistent elements, so they get animation: none (no need for them to animate). The main content fades, and the interesting bit is what happens with article previews.

Each article preview’s image, title, lead text, and date get a view-transition-class. When you click an article from the homepage, those elements morph into their corresponding positions on the article page. The image smoothly scales and repositions, the title flows to its new location. It creates this continuity that makes the site feel a bit more cohesive:

.article-preview-image {
    view-transition-class: post-image;
}

.article-preview-header h2 {
    view-transition-class: post-title;
}

.article-body > figure:first-child {
    view-transition-class: post-image;
}

.article-header h1 {
    view-transition-class: post-title;
}

I also added direction-aware transitions using :active-view-transition-type(). Going deeper into the site (clicking an article) slides the content to the left. Going back slides it to the right. Navigating between pages at the same level does a subtle crossfade:

:active-view-transition-type(forward) {
    &::view-transition-old(page-content) {
        animation: 0.25s cubic-bezier(0.4, 0, 1, 1) both vt-slide-out-left;
    }
    &::view-transition-new(page-content) {
        animation: 0.3s 0.05s cubic-bezier(0, 0, 0.2, 1) both vt-slide-in-right;
    }
}

:active-view-transition-type(back) {
    &::view-transition-old(page-content) {
        animation: 0.25s cubic-bezier(0.4, 0, 1, 1) both vt-slide-out-right;
    }
    &::view-transition-new(page-content) {
        animation: 0.3s 0.05s cubic-bezier(0, 0, 0.2, 1) both vt-slide-in-left;
    }
}

And of course, all of this respects prefers-reduced-motion. If a user has that preference set, every transition duration drops to essentially zero. Progressive enhancement goes both ways: enhance for those who want it, back off for those who don’t.

One more thing on view transitions: each article preview and its corresponding article page share data-vt attributes on matching elements (title, image, date, lead text). Instead of writing a unique view-transition-name for every single article in CSS, I used the enhanced attr() to pull the transition name straight from the HTML:

[data-vt] {
    view-transition-name: attr(data-vt type(<custom-ident>));
}

This is the enhanced version of attr(), not the old string-only one we’ve had forever. It can now resolve to typed CSS values like <custom-ident>, <color>, <length>, and more. This is part of interop 2026, which means browser support should be solid by the end of 2026. I decided to use this for a couple of updates because of this reason.

The orbs: @property meets scroll-driven animations

The old homepage had these colorful orb-like blobs in the background. They used a mix-blend-mode which used to have a “wow factor” when I first created this website, It also used scroll-driven-animations to make them move but that was already an updates as I used GSAP before that. I liked the vibe of those orbs, they gave the page some personality. But they were static and felt a bit dated (and I really wanted a hue shift somewhere…).

I wanted to keep the same idea but make them feel alive. If you haven’t played with @property yet, I’ve written about it in depth and used it for animating clip-paths on scroll. The magic is that it lets you register custom properties with a type, which means CSS can actually interpolate them. You can’t normally transition a hue value inside an oklch() color, but if you register a custom property as a <number>, suddenly you can:

@property --atm-hue-1 {
    syntax: "<number>";
    inherits: false;
    initial-value: 30;
}

@property --atm-opacity-1 {
    syntax: "<number>";
    inherits: false;
    initial-value: 0.28;
}

If you are wondering, the atm stands for atmoSPHERE, get it? get it? ok… moving on…

The blobs themselves are ::before and ::after pseudo-elements with organic border-radius values, colored with oklch using those registered properties:

.homepage-sections::before {
    width: 50vw;
    height: 50vw;
    border-radius: 62% 38% 46% 54% / 60% 44% 56% 40%;
    background: oklch(85% 0.08 var(--atm-hue-1));
    opacity: var(--atm-opacity-1);
    filter: blur(clamp(60px, 8vw, 120px));
}

When scroll-driven animations are supported, those properties animate as you scroll down the page. The hue shifts, the opacity pulses, the blobs drift across the screen. It’s subtle, but it makes the homepage feel like it’s breathing:

@supports (animation-timeline: scroll()) {
    .homepage-sections::before {
        animation: atm-light-1 linear forwards;
        animation-timeline: scroll(root);
    }
}

It took a bit of time to get it the way I wanted it, especially in the light theme I had to tinker quite a lot to keep the sort of “elegance” in the cream coor scheme.

I used the same @property approach for the buttons. The gradient angle and color stops are registered custom properties, so hovering a button smoothly transitions the gradient direction and colors instead of just snapping between states. I wrote about building a smart button system with custom properties before, and this takes that idea a step further.

I hated my old navigation, it was boring as hell so I really enjoy this one. The desktop navigation has a pill-shaped highlight that sits on the active page link. When you hover over a different nav item, the pill smoothly slides over to it. When you stop hovering, it slides back. No JavaScript involved, and it degrades perfectly to a simple static highlight.

The trick combines two features I’ve written about quite a bit: :has() (which I genuinely believe we’ve only scratched the surface of) and anchor positioning.

Let’s look at how it works. The active nav link gets an anchor-name. When another link is hovered, :has() detects this and moves the anchor name to the hovered link instead. A ::before pseudo-element on the nav list is positioned using position-anchor, so it follows wherever the anchor goes:

@supports (anchor-name: --a) {
    .nav-desktop .nav-link {
        &:not(:has(.nav-link:hover)).active {
            anchor-name: --nav-pill;
        }

        &:is(:hover, :focus-visible) {
            anchor-name: --nav-pill;
        }
    }

    .nav-desktop .nav-list:has(.nav-link:hover)
        .nav-link.active:not(:hover) {
        anchor-name: none;
    }

    .nav-desktop .nav-list::before {
        position-anchor: --nav-pill;
        inset: anchor(top) anchor(right) anchor(bottom) anchor(left);
        border-radius: 100vw;
        background: var(--s-color-highlight);
        content: "";
        transition: 0.2s;
    }
}

Everything sits behind @supports (anchor-name: --a). Without it, you simply get a static background color on the active link. Perfectly functional, just without the sliding animation.

On mobile, the navigation uses the Popover API with @starting-style for a smooth slide-in animation. I wrote about both popovers and @starting-style before, and it’s really satisfying to see them work together for something as common as a mobile menu.

Scroll-state queries, the progress bar, and CSS carousels

If you’ve been following along, you might have read my articles on scroll-state queries when they first landed and the more recent update with scrolled and scrollable states. I’m using them in a few places on this site now, and I have to say, it feels great to use your own articles as reference material for the things you’re building.

The header

The header uses scroll-state queries in two ways. First, when it’s stuck to the top, it gets a more pronounced shadow:

@supports (container-type: scroll-state) {
    .header-container {
        container-type: scroll-state;
    }

    @container scroll-state(stuck: top) {
        .header {
            box-shadow: 0 2px 12px rgb(58 52 42 / 0.1),
                        0 4px 24px rgb(58 52 42 / 0.06);
        }
    }
}

Second, the header hides when you scroll down and reappears when you scroll back up. The scrolled: top and scrolled: bottom states handle it without any Intersection Observer or scroll event listeners:

@container scroll-state(scrolled: top) {
    .header-container {
        translate: 0 0;
    }
}

@container scroll-state(scrolled: bottom) {
    .header-container {
        translate: 0 calc(-100% + var(--s-progress-height));
    }
}

The article progress bar

That var(--s-progress-height) in the translate? That’s the article reading progress bar peeking through at the bottom of the header. When you’re reading an article, there’s a thin gradient bar that grows from left to right as you scroll. Both the bar height and the translate offset share the same semantic token, so they stay in sync. It uses :has(.article-body) so it only shows up on pages that actually have an article, and animation-timeline: scroll(root) to tie the progress to the scroll position:

@supports (animation-timeline: scroll()) {
    body:has(.article-body) .header::after {
        position: absolute;
        width: 100%;
        height: var(--s-progress-height);
        inset-block-end: 0;
        transform-origin: left;
        scale: 0 1;
        background: linear-gradient(
            90deg,
            var(--s-color-brand-primary),
            var(--s-color-brand-primary-muted)
        );
        content: "";
        animation: progress-grow linear both;
        animation-timeline: scroll(root);
    }

    @keyframes progress-grow {
        to {
            scale: 1 1;
        }
    }
}

It’s a nice little detail. Browsers that don’t support animation-timeline simply don’t show it. No harm done.

CSS carousels with scroll markers and scroll buttons

One of the new features I’ve been most excited about is CSS-only carousels. I’m using the ::scroll-button() pseudo-element in two places on the homepage: the photo reel and the new Bluesky feed.

I know there are accessibility concerns with these carousels, but It’s not making my content inaccessible, it might just not be the best practice. My website, my choice, and I’m ok with this (for this usecase).

The Bluesky feed is a new addition to the homepage that shows my latest posts in a horizontally scrollable strip of cards. Both the feed and the photo reel share the same carousel CSS, which I put in a single scroll-carousel.css file. The scroll buttons are positioned using anchor positioning (another great use case for it), and scroll-state queries handle showing and hiding the gradients based on whether there’s content to scroll to:

@supports (container-type: scroll-state) {
    .bluesky-feed,
    .photo-reel-carousel {
        container-type: scroll-state;
    }

    @container scroll-state(scrollable: left) {
        .scroll-fade-start {
            opacity: 1;
        }
    }

    @container scroll-state(scrollable: right) {
        .scroll-fade-end {
            opacity: 1;
        }
    }
}

Without support for scroll-marker-group, the carousels still work as basic horizontal scroll containers with scroll-snap. You can still swipe through them, you just don’t get the nice prev/next buttons and dot indicators. Progressive enhancement doing its thing.

The table of contents

The article table of contents uses scroll-target-group: auto combined with :target-current to automatically highlight the section you’re currently reading. And when anchor positioning is also supported, that highlight becomes an animated indicator bar that smoothly slides between items:

@supports (scroll-target-group: auto) {
    .article-toc ol {
        scroll-target-group: auto;
    }

    .article-toc a:target-current {
        border-inline-start-color: var(--s-color-brand-primary);
        color: var(--s-color-brand-primary);
    }
}

The TOC list itself uses @container scroll-state(scrollable: top) and scrollable: bottom to show fade gradients when there’s more content to scroll to. Small detail, but it helps with those longer articles where the TOC overflows. To be honest, this one might be a bit on the edge, I decided to keep the TOC in every browser even if they don’t have an active state. I might get back on that later on.

The photography corner

One thing I really wanted with this redesign is to give photography a more prominent place on the site. I’ve always loved taking pictures, and I hope to actually maintain this part a bit more in the upcoming years.

The old homepage had a single hero image tucked away at the bottom. The new version has a horizontal photo reel right on the homepage, built with the same CSS carousel approach: scroll-snap, and ::scroll-button() for navigation. There’s also a dedicated photography page with a proper grid layout, infinite scroll, and a lightbox. It finally feels like it has a proper home. The lightbox uses a native <dialog> element and I will be updating that grid from the moment we have grid-lanes in CSS. It’s actually the only JS-heavy part of this website at the moment.

Same HTML, different paint job

Something I’m quite happy about with this redesign: the HTML barely changed. The whole thing was primarily a CSS effort. The existing markup stayed intact, and all these new visual features, view transitions, corner shapes, scroll-driven animations, sticky header tricks, were layered on top of what was already there.

That’s the whole point of progressive enhancement, isn’t it? You don’t rip out your DOM to add a squircle. The data-vt attributes for view transitions are one of the few HTML additions, and even those are just a handful of data attributes on elements that already existed.

This approach also made the move to container queries a lot smoother. Same components, same markup, just a different type of query. Which brings me to…

Slowly moving to container queries

One last thing worth mentioning: I’m gradually replacing media queries with container queries where it makes sense. I’ve been writing about container queries since 2021, so it was about time I used them more on my own site.

The homepage article cards, for example, switch from a stacked layout to a side-by-side layout based on the container width, not the viewport:

.home-hero-articles .home-articles {
    container-type: inline-size;
}

.article-preview {
    @container (min-width: 630px) {
        display: grid;
        grid-template-columns: 110px 1fr;
        align-items: center;
    }
}

I haven’t migrated everything yet, but slowly, query by query, it’s getting there. The nice thing about container queries is that the same component just works, whether it’s in a full-width layout or squeezed into a sidebar.

Other things

I also updated my code examples just a bit, more especially the frame by just giving it a header (I just used a multi-background image for that). I changed some of the badges so that the CSS category reflects the CSS logo color. Removed X from the share options, and updated the about page a bit. While i was updating the about page I decided to make my company logo work with scroll-triggered animations. this is now in the latest chrome so it suddenly worked (I added it in Canary).

This is going to be a lot of fun: seing more browsers get these capabilities!

Wrapping up

So… sorry for the amount of self-linking articles in this one, but I wanted to show that it is due to my own writing and experimenting with these features that I was able to build this improvement. All these things, small demos had to be done to actually understand how they work and how to use them. Call it selfish, but this article is a reminder to myself that all these little things can make me create better experiences.

Every feature I added follows the same pattern: the basics works everywhere, and browsers that support newer things get something extra on top. No polyfills, no JavaScript workarounds, no “please use Chrome” disclaimer.

It’s not perfect yet, but it’s a start (as in, good enough to ship). I’m happy I did this.

Progressive enhancement isn’t just about fallbacks. It’s about layering experiences. Start with something solid, then add on top. The squircle corners, the view transition morphing, the sliding nav pill, the scroll-state header, the reading progress bar, the CSS carousels… none of these are essential for reading the content. But together, they make the experience feel a bit more alive, a bit more intentional (and fun!).

I had a lot of fun building this, and I hope it inspires you to try something similar on your own projects. Pick one feature, wrap it in @supports, and see what happens. You might get hooked.

Oh and just for fun, here’s what this site looked like in an even earlier life. This was the Tailwind version. Redesigning it was also the reason I never wanted to use Tailwind again.

I hope you enjoyed this little look in my brain (and love the little updates).

CSS Animation Triggers: Playing animations on scroll without scrubbing. It's a match!

Brecht De Ruyte — Thu, 12 Feb 2026 00:00:00 GMT

I love scroll animations. In the past few years, I’ve written a blogpost on Valentine’s Day that has something to do with scroll, from scroll-driven animations to carousels. This year I’m releasing it two days prior, but I am really excited about a new feature, and I’m happy that I can do something “scroll” again for 2026 with a new kid: CSS scroll-triggered animations.

I’ve been having a lot of joy experimenting with this feature. It is currently available in Chrome Canary with the experimental web platform features flag enabled. In this (edit: long) article, I’d like to go over the basics as well of giving you some insights on a big demo I created (once again… it started small, really…). I promise that I did my best to make this article as complete as possible, but I am thinking of creating a workshop out of this in the future. Feel free to contact me if you’d like this sort of thing.

This article should cover most things scroll-trigger related, as well as some hot tips to keep your sanity when entering the depths with scroll animations.

For those who just want the demo… here it is, or watch the video if your browser doesn’t have the support. For those who like to learn about this juicy feature (and some hot tips), read on!

See the Pen The Tinkerer (scroll driven/trigger animation demo) by utilitybend (@utilitybend) on CodePen.

Your browser does not support the video tag.

(The demo also has a secret message. Can you spot it? Let me know on the socials! 😀)

The difference between scroll-driven and scroll-triggered

I thought I’d at least put a little section in here to explain the difference with a simple example. Imagine you have a text element that should fade in when it enters the viewport.

With scroll-driven animations, the opacity would be tied directly to scroll position. Scroll down a bit? 30% opacity. Scroll more? 60% opacity. The animation literally scrubs frame by frame based on where you are in the scroll.

/* Scroll-driven: opacity tied to scroll position */
.text {
  animation: fade-in linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

This works great for things like parallax backgrounds or progress indicators. But in a lot of cases, such as a text fading in, it feels… off. The text sort of “oozes” into existence rather than appearing with a nice, smooth transition. It’s just not snappy, and snappy can be really good.

With scroll-triggered animations, the scroll position only determines when the animation starts. Once triggered, the animation plays at its normal duration and easing, just like any other CSS animation would.

/* Scroll-triggered: plays normally when triggered */
.text {
  animation: fade-in 0.6s ease-out both;
  animation-trigger: --my-trigger play-forwards play-backwards;
}

There are always exceptions, and “it depends” is probably the biggest phrase in webdevelopment, but for a simple rule of thumb, I find this true for these kids of animations:

Use scroll-driven for continuous effects, use triggers for discrete transitions.

Here is a little demo to illustrate the difference:

See the Pen Scroll-Driven vs Scroll-Triggered animations by utilitybend (@utilitybend) on CodePen.

Creating a first scroll-trigger

Let’s do the basic example. No tricks, no cleverness. One trigger, one animation. Here’s the HTML:

<section class="scene">
  <div class="trigger"></div>
  <div class="box">I animate when the trigger is in view.</div>
</section>

The .trigger is just an invisible element positioned inside the section. It’s the thing we’ll “watch” for visibility. The .box is what actually animates.

Now the CSS. Two new properties, and that’s it:

Step 1: Define the trigger on the trigger element

.trigger {
  position: absolute;
  inset: 30% 0;
  timeline-trigger: --my-trigger view() contain / cover;
}

What’s inside this new timeline-trigger property?

--my-trigger: a name for this trigger (dashed ident, just like custom properties)
view(): the timeline source. This creates a view timeline based on the element’s position
contain / cover: the enter range / exit range

Step 2: Connect the animation to the trigger

.box {
  animation: fade-in 0.5s ease-out both;
  animation-trigger: --my-trigger play-forwards play-backwards;
}

What’s inside this new animation-trigger property?:

--my-trigger: which trigger to listen to
play-forwards: what to do when the trigger activates (enter action)
play-backwards: what to do when it deactivates (exit action)

That’s it. No intersectionObserver, no JavaScript event listeners, no threshold calculations that never feel quite right.

Don’t worry about the ranges and actions, we’ll get to these in a minute.

But in general, this is it for the first demo. When the trigger element becomes fully visible in the viewport (contain), the animation plays forward. When it starts to leave (cover), it plays in reverse. You can see this working in the “hello trigger” demo.

See the Pen Basic trigger example: CSS Scroll-triggered animations by utilitybend (@utilitybend) on CodePen.

Enter and exit ranges: controlling the timing

I always found the naming of those enter and exit ranges confusing. I usually rely on visiting scroll-driven-animations.style when I need them. For those wondering, this is also why I still write: as my blog and Codepen have served me well as my own little snippets lab. And actually writing about it makes me remember it better.

The range is where you fine-tune the trigger’s firing. The syntax is enter-range / exit-range, separated by a slash.

The keywords

cover: from the first pixel entering the viewport to the last pixel leaving
contain: only while the element is fully visible
entry: while the element is entering (first pixel to become fully visible)
exit: while the element is exiting (fully visible to the last pixel)

You can also use percentages within those ranges for fine control:

Here’s a little example

/* active from first pixel in to last pixel out */
timeline-trigger: --trigger view() cover / cover;

/* activates and deactivates at the same boundary */
timeline-trigger: --trigger view() contain / contain;

/* fires halfway through entry, releases halfway through exit */
timeline-trigger: --trigger view() entry 50% / exit 50%;

In short… contain / cover means the animation plays when the trigger is fully in view, and only reverses once it starts leaving the viewport. That’s a pretty big active window, which I use most of the time. On the other hand, contain / contain is much tighter; in that case, the trigger deactivates as soon as the element isn’t fully contained anymore, which is great for when you want snappy behavior.

If you need to use longhands (If you’d want to vary just the range per element while keeping the same trigger name), you can split things up:

.trigger {
  timeline-trigger-name: --my-trigger;
  timeline-trigger-source: view();
  timeline-trigger-range: contain;
  timeline-trigger-exit-range: cover;
}

I built a range demo where five identical animations use different range configurations. Same trigger, same animation, wildly different timing. Honestly, playing with these helped me understand the ranges better than reading the spec ever could. It’s not a perfect educational demo, but I had fun creating it. I think the tool by Bramus is much more educational. Still, it would be a shame not to share it:

See the Pen Scroll-triggered animations: a little bit of fun with ranges and triggers by utilitybend (@utilitybend) on CodePen.

Please don’t use this demo as your go-to; there are many other options beyond what I’m showing here. Since this is a love message to tinkering, I thought it was fun to display these ranges by triggering them.

Animation actions when using triggers

The second thing I sort of introduced in the first demo, without really explaining, are the actions inside of animation-trigger. They do a lot more than just the options play-forwards and play-backwards. There’s a whole table of actions in the CSS Animations Level 2 spec, and they give you surprisingly fine-grained control.

The syntax is always:

animation-trigger: <trigger-name> <enter-action> <exit-action>

Here’s what each action does:

play-forwards Sets playback rate to positive, then plays
play-backwards Sets playback rate to negative, then plays
play Plays the animation (at current rate)
play-once Plays the animation, but only from initial or paused state (ignores if already finished)
pause Pauses the animation (only if currently playing)
reset Sets progress back to 0 and pauses
replay Sets progress back to 0, then plays
none Does nothing

The real power is in the combinations. I’m still in the progress on creating a few more demo’s that I don’t want to reveal just yet, but here are the my first takes on which combinations I’ll likely use the most

play-forwards / play-backwards: The classic. Plays forward when triggered, reverses when the trigger deactivates.
play-forwards / none: Plays forward on enter, and does absolutely nothing on exit. The animation stays wherever it ended up. Great for one-directional reveals that shouldn’t reverse when you scroll past
play-forwards / reset: Plays forward on enter, snaps instantly back to the beginning on exit. No smooth reverse, just a hard cut. Useful when you want a clean slate every time.
play-forwards / pause: This one’s fun! But I still have to find the practical use-case. It plays forward on enter, and freezes mid-animation if you exit while it’s still playing.
play-once / none: Plays the animation exactly once. After it finishes, the trigger is effectively ignored; scroll away and back, and nothing happens. This is great for intro animations that should only run the first time. This will probably be my go-to in many cases, having nice entries and not overly bombard the user with animations
replay / none: Every time the trigger activates, the animation restarts from the beginning. Even if it was still playing. This is the “eager restart” option.

I created a little “animation actions demo” with a progress bar that fills over 2 seconds. The slow animation and tight contain / contain trigger range make it easy to scroll away mid-fill and actually see the difference between pause, reset, none, and play-backwards. I had a bunch of different tests in order to get a grasp on this and thought I should combine it in one single package… descriptions only get you so far… and a picture/demo is worth…

Note: I used custom properties here to fill the actions. I didn’t find a dedicated property for the actions, which would’ve been helpful in this case.

See the Pen Scroll-triggered animations: actions explained by utilitybend (@utilitybend) on CodePen.

Going in-depth with the scroll-trigger + scroll-driven Valentine demo

Here’s the thing I’ve come to really appreciate: combining triggers with scroll-driven animations. To be honest, it probably was my first thought: “combined, this will be awesome”. Really, think about it, these kinds of things are complementary. In the same project, you might want:

Triggers for text reveals (they should fade in with a nice ease-out, not scrub)
Scroll-driven for background visibility (fade backgrounds in and out based on scroll position)
Scroll-driven for parallax effects (layers moving at different speeds)
Triggers for SVG drawing effects (a waterfall should draw itself once triggered, not scrub)

The combination gives you the best of both worlds: precise scrollytelling for the big picture, with natural-feeling animations for the details.

So.. I started this demo with a Valentine’s Day poem, the plan was a small demo, but that went overboard really quick. I’d love to tell you about the thought behind the poem, but feel free to skip to the next section if you just want the technical info.

I’ve been going to quite a lot of conferences in 2025 and saw a lot of AI talks. There are always so many strong believers, and so many haters. I really hate both extremes in this case. The worst people on the “extreme pro end” are the ones who claim that handcrafting things is dead… It’s really not. Yes, for your typical agency work, this might become less and less needed. But there are still tinkerers, crafty people, innovative leaders. People who create beautiful experiences that can’t just come into existence by completely relying on a machine (it will make things faster and help… for sure, or they have to train their agents). People mostly buy furniture from IKEA, but that doesn’t mean there aren’t any crafty people who create beautiful tables, dressers, etc… Guess who designs these types of furniture to begin with? Some people just enjoy it, and I strongly believe that those people, the ones who tinker and enhance themselves with “the machines,” are the ones we’ll need if we want to grow in quality as well as quantity, the ones that have that extra “edge”. Tinkering leads to new knowledge, interesting features, and better ways. I applaud combining tinkering with AI, it’s fantastic. But we still need to grow in combining both, finding the right balance. So I thought… for those that also heard the comment or doubt themselves, “Is my handcrafting still worth it?”, well, this one is for you.

Ok, let’s continue with the technical part 🙂

The basic setup, fixed stuff + scroll trigger + driven

The idea is pretty straightforward: all the visual stuff (backgrounds, SVGs, illustrations) live in position: fixed layers that cover the full viewport. They don’t scroll. What does scroll is a <main> element containing the poem text. I decided to split them with <section> elements stacked vertically, creating enough height to create the scroll distance.

<!-- Fixed visual layers (don't scroll) -->
<div class="fixed-layer bg-layer bg-paper"></div>
<div class="fixed-layer centered-layer tinkerer-container">...</div>
<div class="fixed-layer bg-layer bg-mountain"></div>
<div class="fixed-layer waterfall-container">...</div>
<!-- ...more layers... -->

<!-- Scrollable poem (this is what creates the scroll) -->
<main id="poem">
  <section class="poem-section">
    <div class="section-trigger" data-trigger="--heart-trigger"></div>
    <p class="poem-text" data-trigger-ref="--heart-trigger">To you...</p>
  </section>
  <!-- ...more sections... -->
</main>

Each fixed layer fades in and out based on scroll position using animation-timeline: scroll(root). So as the user scrolls through the poem, the backgrounds cross-fade behind the text. I recently watched a musical where they did the same thing… There was a stage where the backdrops changed while the actors (the text in this metaphor) walked on and off. So next up…

Two animation systems, combined!

As I explained with my stage metaphor, I changed the backgrounds using the root scroller for that true scorllytelling experience.

.bg-mountain {
  animation: visible linear both;
  animation-timeline: scroll(root);
  animation-range: 16% 27%;
}

.heart-stroke {
  animation: heart-draw linear both;
  animation-timeline: scroll(root);
  animation-range: 0% 4%;
}

The poem text, on the other hand, uses scroll-triggered animations. Each section has a trigger element, and when that trigger enters the viewport, the text plays a text-reveal animation with a proper easing (no half opacity text anymore)

.section-trigger {
  timeline-trigger: --heart-trigger view() contain / cover;
}

.heart-text {
  animation: text-reveal 0.6s ease-out both;
  animation-trigger: --heart-trigger play-forwards play-backwards;
}

The result: backgrounds scrub smoothly with your scroll, while the text pops in. I migh’ve been geeking out a bit too much on this but I dragged that scrollbar for minutes to see the satisfying difference between the two.

Now, if you look at that last code block and imagine repeating it for all those sections… yeah, that feels like a dumb machine would write it and “it just works”, but we’re smart, so… Let’s fix that.

Scaling up: making it DRY

The demo has 11 sections, each with its own trigger. Writing a separate timeline-trigger rule for every single one is kind of painful. Let me show you how I avoided that.

So yes, I really started like this:

.trigger-heart {
  timeline-trigger: --heart-trigger view() contain / cover;
}

.trigger-cascade {
  timeline-trigger: --cascade-trigger view() contain / cover;
}

.trigger-robot {
  timeline-trigger: --robot-trigger view() contain / cover;
}
/* ... and so on for every single trigger */

This works, but it’s tedious. Every new section means a new CSS rule that’s essentially copy-paste with a different name.

The attr() one-liner

This is where the new typed attr() syntax in Chrome comes in. If you store the trigger name in a data-trigger attribute on the HTML element:

<div class="trigger" data-trigger="--heart-trigger"></div>
<div class="trigger" data-trigger="--cascade-trigger"></div>
<div class="trigger" data-trigger="--robot-trigger"></div>

…you can read it directly in CSS:

.trigger {
  timeline-trigger: attr(data-trigger type(<custom-ident>)) view() contain / cover;
}

One rule for all the triggers! The attr(data-trigger type(<custom-ident>)) tells the browser to read the attribute value and interpret it as a custom identifier, the exact type that timeline-trigger expects.

The same trick works on the animation side. Give each animated element a data-trigger-ref pointing to the trigger it should listen to:

<div class="heart-text" data-trigger-ref="--heart-trigger">...</div>

[data-trigger-ref] {
    animation: text-reveal var(--duration-normal) ease-out both;
    animation-trigger: attr(data-trigger-ref type(<custom-ident>)) play-forwards play-backwards;
}

.heart-text {
  /* custom reveal variables */
}

Add a new section? Add a trigger element in the HTML with the right data-trigger value. No CSS changes needed. I love how smart we can make this by just using some modern capabilities.

Reusable keyframes with CSS variables

While I was creating this demo, I was starting to struggle a bit with duplicate animations, so I decided to simplify the keyframes a bit. Instead of writing separate animations for “fade from left”, “fade from right”, “fade from below”, we can use variables with fallbacks in combination with custom properties:

@keyframes text-reveal {
  from {
    opacity: 0;
    translate: var(--reveal-x, 0) var(--reveal-y, 30px);
  }
  to {
    opacity: 1;
    translate: var(--end-x, 0) var(--end-y, 0);
  }
}

By default, this reveals from 30px below. But when I wanted to create an exception, I just had to update the variables:

.from-left {
  --reveal-x: -50px;
  --reveal-y: 0;
}

.from-right {
  --reveal-x: 50px;
  --reveal-y: 0;
}

One keyframe, infinite directions…

Centralizing your “scroll choreography”

Do people say choreography in this sense? I dunno, might be my daughter’s dancing lessons in my head… Anyway, this one’s a hot tip for full-page scrollytelling. When you’re using animation-range on a bunch of scroll-driven elements, those percentage ranges end up scattered across your stylesheet. I was constantly scrolling back and forth, tweaking those percentages… Until I got sick of them and decided to pull them all into a dedicated layer:

@layer scrollTimeline {
  :root {
    --range-hero: 0% 9%;
    --range-intro: 7% 18%;
    --range-feature: 16% 27%;
    --range-detail: 25% 45%;
    --range-outro: 90% 100%;
  }
}

This way, I could play around with a sort of centralized storyboard. Overlaps are visible, retiming is a single-line change; think of it as a timeline editor built into your stylesheet.

.waterfall-container {
  animation-range: var(--range-hero);
}

.robot-container {
  animation-range: var(--range-intro);
}

Debugging: visualizing your triggers

When building scroll-triggered pages, it really helps to see where your triggers are. A dashed border on the trigger element goes a long way:

.trigger {
  border: 1px dashed oklch(60% 0.1 180 / 0.3);
}

.trigger::after {
  content: "trigger zone";
  position: absolute;
  font-family: ui-monospace, monospace;
  font-size: 0.6rem;
  color: oklch(60% 0.1 180 / 0.4);
}

If you’re using the data-trigger attribute approach, you can make the label dynamic:

.trigger::after {
  content: attr(data-trigger);
}

Each trigger gets the correct label automatically. When you’re done debugging, comment it out or hide it behind a .debug class. I left it in the demo; feel free to uncomment it to see it in action.

Here is that demo once again:

See the Pen The Tinkerer (scroll driven/trigger animation demo) by utilitybend (@utilitybend) on CodePen.

Browser support

I know, I know.. This is, unfortunately, still experimental. As of writing, you need Chrome Canary with the “Experimental Web Platform features” flag enabled. The feature should arrive in Chrome 146, which might actually arrive by the end of February.

For production, you’ll want a fallback; you can add a support query for this, but in general it’s up to you… Do you want this as a progressive enhancement, or do you have the time to create an intersectionObserver fallback?

@supports not (animation-trigger: none) {
  /* Fallback styles */
}

Conclusion

Animation triggers are one of those features that feel obvious. We’ve had scroll-driven animations for a while, but the ability to use scroll position as a signal rather than a driver always felt a bit broken. I’m really happy it’s here.

The basics are simple: timeline-trigger on an element to define when it fires, animation-trigger on another element to say what should happen. But the depth is there when you need it: action pairs for fine-tuning control, longhand properties for per-element ranges, and the attr() capability really comes in handy here for scaling to dozens of triggers. I do believe an extra property to target actions individually would’ve been handy for one of my demos, but not sure if I’d miss it in a real-world situation, that part is for me to discover at a later stage.

Further reading:

Happy Valentine’s Day and happy triggering

Is it scrolled? Is it not? Let's find out with CSS @container scroll-state() queries

Brecht De Ruyte — Fri, 23 Jan 2026 00:00:00 GMT

I don’t know about you, but for me, Intersection Observer always felt like this magical thing that kind of works, but somehow I never got it to work exactly the way I wanted it. It missed control, it missed clarity. Way too many times have I been playing with margins and thresholds in that API only to notice that it didn’t always work perfectly on every screen.

If you are in the same boat as me, well, it seems that the future is bright, because @container scroll-state is here to make our lives a whole lot easier. For the sake of this article, I’m going to refer to them as just “Scroll-state queries”, ditching the container part.

There are a few updates in Chrome 144, but a few things were already available in Chrome 133, so let’s recap this first.

A Quick Recap: How Do Scroll-State Queries Work?

Before we get to the shiny new toys, let’s do a little refreshing. Scroll-state queries allow a container to query its own scroll state and style its children accordingly. You simply define a container and then use a container query to check its state. It’s beautifully simple.

.scroll-ancestor {
  container-type: scroll-state;
}

@container scroll-state(stuck: top) {
  .child-of-scroll-parent {
    /* Magic happens here! */
  }
}

This functionality landed in Chrome 133 with a trio of incredibly useful states that already solved some major headaches.

The power trio: stuck, snapped, and scrollable

As I played around during my first look at this feature (at the time still in Canary), “Is the sticky thing stuck?”, the initial implementation gave us some powerful tools.

Is it stuck?

This query answers the age-old question: “Is my position: sticky header actually stuck to the top right now?”. Before, this required tricky JavaScript. With this CSS feature, it’s trivial. In our demo, we use a wrapper to detect the state and style the header inside it, adding a background and shadow only when it’s “stuck”.

.sticky-header-wrapper {
  position: sticky;
  inset-block-start: 0;
  container-type: scroll-state;
}

@container scroll-state(stuck: top) {
  .main-header {
    background-color: var(--color-header-bg);
    box-shadow: 0 4px 15px rgba(0, 0, 0, 0.2);
  }
}

See the Pen CSS Scroll-state: Is the sticky header stuck? by utilitybend (@utilitybend) on CodePen.

Is it snapped?

For scroll-snap galleries, we often want to highlight the active item. The snapped state lets us do just that. It checks if an element within a scroll-snap container is the one currently “snapped” in the viewport. In this demo, I used this to create a zoom effect on the active image, and also changed a bit of the background color.

.horizontal-track li {
  container-type: scroll-state;
}

@container scroll-state(snapped: inline) {
  .card-content img {
    transform: scale(1.1);
    filter: sepia(0);
  }
}

See the Pen CSS Scroll-state: Is the snap item snapped? by utilitybend (@utilitybend) on CodePen.

I’m also re-entering my Pokémon demo again… I just spent way too many hours on it, not to repeat it.

See the Pen Scroll-state query to check which item is snapped with CSS, Pokemon version by utilitybend (@utilitybend) on CodePen.

Is it scrollable?

I’m sure that this one will have quite a few use cases. The scrollable state doesn’t care what the user has done; it cares about what the user can do. It asks, “Is there un-scrolled content past a certain edge?” This is perfect for showing arrows only when there’s somewhere to scroll, a task that used to require a heap of JS checking scrollLeft, scrollWidth, and clientWidth.

/* Show the LEFT arrow ONLY if there is content to scroll to on the left */
@container scroll-state(scrollable: left) {
  .scroll-arrow.left {
    opacity: 1;
  }
}
  
/* Show the RIGHT arrow ONLY if there is content to scroll to on the right */
@container scroll-state(scrollable: right) {
  .scroll-arrow.right {
    opacity: 1;
  }
}

See the Pen CSS Scroll-state: Is it scrollable? by utilitybend (@utilitybend) on CodePen.

Note: all data/horses in this table were created by using AI; anything resembling real horses or people is purely accidental. If your horse feels offended, you can always let me know, and I will remove it from this generated list. (I mean… at least I’m honest about it…)

This is a very specific use case, but you could, for example, check if a container is scrollable in general using the inline or block axis as a keyword.

The new kid: @container scroll-state(scrolled) arrives in Chrome 144!

That original trio was powerful, but one piece of the puzzle was missing: understanding the action of scrolling itself. With Chrome 144, the arrival of the scrolled state completes the picture, and it will help us with a very common pattern across the web.

The scrolled state is all about the user’s immediate action. It tracks the direction of the most recent scroll. Think of it as asking the browser, “Which way did the user just move?”

This is perfect for the classic “hidey-bar” header.

html {
  container-type: scroll-state;
}

/* If the last scroll was DOWN, hide the header */
@container scroll-state(scrolled: bottom) {
  .main-header {
    transform: translateY(-100%);
  }
}

/* If the last scroll was UP, show the header */
@container scroll-state(scrolled: top) {
  .main-header {
    transform: translateY(0);
  }
}

No more JavaScript janky headers. Yay!

See the Pen CSS Scroll-state: Has the user scrolled up or down? by utilitybend (@utilitybend) on CodePen.

The scrolled query can also be used for a one-time check. By querying scrolled: inline, we can ask, “Has this container been scrolled horizontally at all?” This is ideal for a scroll hint that should disappear after the user’s first interaction.

@container scroll-state(scrolled: inline) {
  .scroll-indicator {
    opacity: 0;
  }
}

See the Pen CSS Scroll-state: Has the user scrolled inline? by utilitybend (@utilitybend) on CodePen.

Now I know that the preference for this sort of behavior will probably be the earlier “arrow demo”, still, it’s nice to have the option. I would like to note that there is still a small Chromium bug related to this new feature, but I already filed it.

The Future is State-ful

With the arrival of scrolled, the scroll-state query family feels complete. This is a clever CSS-native toolkit for handling UI changes that were once the exclusive domain of JavaScript. That being said, these are features that people will probably only start to rely on fully when there is more browser support. Even though you can perfectly use all of them as a progressive enhancement, in my experience, clients usually want “hidey headers” or “scroll indicators” in every browser. You could do a JS fallback, but you know… time and money and time and….

Once again, I’m happy to welcome more CSS into the state-machine kingdom. These features are important for performance, UI enhancement, and yes, maybe even accessibility.

An update on customizable selects: the multiple select

Brecht De Ruyte — Thu, 15 Jan 2026 00:00:00 GMT

In this article, I’m not going to repeat the whole process of creating a customizable select, and I’m not adding this to the part of the series I wrote earlier on this great feature. But I want to take a look at the work that is being done when you add the attribute multiple to the select element.

The multiple select

Who uses this element? Let’s be honest that usage on the web is scarce. It’s not very intuitive to operate with a mouse, actually, it’s probably more intuitive with a keyboard in this case? It’s a strange element. I actually showed it to a few of my colleagues; you would be amazed at how many people don’t know that you have to hold ctrl/cmd to make a selection. In my experience, I always rely on checkboxes to create a multi-selection instead of using this dedicated element.

Making this element customizable should, in my opinion, challenge the original design, while still making sense for keyboard users and assistive technology. Different, but better, could be the way to go here.

And that is exactly what it is starting to look like at this moment. Please note that this is still under development, and many aspects are still under active discussion.

For this first demo, I created a music picker with the ’90s and blues as selected options.

This is what this element looks like at the moment:

Now, when we turn this into a customizable select with:

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

We see the following:

But more is changing than just looks,…

There are some navigational differences, for example:

When using the mouse on the original design, you had to hold ctrl/cmd while clicking to select multiple options. This now turns to a single click.

Now… personally, I am happy with that; it makes the element way more intuitive than before. Just as I did, I’d encourage you to test this with your friends by giving them a normal multiple-select and letting them select multiple options; you’ll be amazed at how many would fail on their first try.

Even more… on touch devices, it was already a “single tab”.

If you want to navigate this element with a keyboard, you also need to hold the ctrl/cmd key and use your up and down arrows to go through the selection when you want to select multiple options, and you press the spacebar to confirm it. The thing I hate about that design is that when you accidentally let go of your Ctrl key, you lose your selection and only select one item.

With the customizable select the need for holding cmd/ctrl is removed. But we do lose a few smaller keyboard functionalities:

Ctrl/cmd + a: to select them all
Ctrl/cmd + arrow: to select the one below right away.

I personally feel like this is a minor loss compared to the wins. But I’ll let you be the judge of that.

The ability to style the customizable select

This updated behavior allows us to style the customizable select like a proper selection. A thing that came directly to mind was a music genre selection. In a lot of cases, people like more than one music genre, so I was able to style this with just one select element:

Your browser does not support the video tag.

You can check out the following demo in Chrome Canary for now:

See the Pen Multiple select music selection by utilitybend (@utilitybend) on CodePen.

This is pretty much the gist of it:

<select id="genres" class="genre-select" aria-label="Select multiple music genres" multiple>
  <div class="options-grid">
    <option value="80s">
      <svg class="icon" aria-hidden="true">
        <use href="#80s"></use>
      </svg>
      <span>80s</span>
    </option>
    <!-- other options -->
  </div>
</select>

And then with the extra .options-grid we can do the following:

.options-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(min(160px, 100%), 1fr));
  gap: 20px;
  option {
    /*    Style options as a card */
    &::checkmark {
      /* style checkmark to top right */
    }
  }
}

Why this could be a win for accessibility

Apart from the questions I raised about keyboard navigation, I believe that by following the idea behind the previous demo, you can imagine this could remove a lot of the bad checkbox or button tricks in the world. Too many times have I seen places where people use checkboxes for it, and just set their checkbox to display: none; too many times have I seen it to be buttons with bad behavior, lost outlines, etc…

In this example, I didn’t change anything for the outlines. I just set the picker to a grid and styled the options as cards, and it just works…

Yes, people will always be able to break these things, and since I’m human and prone to error, I’ll probably make a bad example as well in my future career, but this does provide a solid default, and I think that’s the important thing to keep in mind here.

The size attribute on a multiple select element

You probably thought we were done here? Well, we’re not.

The size attribute on a select is a special one. It determines how many options of the select are visible by default. For the multiple select, this is by default set to 4, and if we choose to set this to one, we get a rather peculiar look:

Suddenly, the multiple select changes to a dropdown type of select with checkboxes inside. I find this a strange design choice that feels like it was bolted on due to the nature of the multiple select not being used often (I am not familiar with the history here).

Now of course this should still be supported with a customizable select. When you opt-in to the feature with CSS, you get the following result:

I really like this idea, and I’ll tell you why. With this design, we always have the checkmarks (::checkmark), same as in the “non-multiple customizable select”, the “auto-sized multiselect”, and in the “size="1" multiselect”. If there is one thing that I like about defaults, it’s consistency.

Sweet sweet consistency

Same as with the customizable select, we can now style this, and it can open up a lot of possibilities:

Your browser does not support the video tag.

You can check out the following demo in Chrome Canary:

See the Pen Multiselect Chrome Canary by utilitybend (@utilitybend) on CodePen.

This system also allows me to easily switch up the design to a multiple select without a dropdown. First of all by removing the size attribute, removing my picker animations, and setting my ::picker(select) to height: fit-content;

See the Pen Multiselect full Chrome Canary experiment by utilitybend (@utilitybend) on CodePen.

The listbox rendering mode (the fact if the select is rendered in-flow or in the page rather than with a separate button and popup by setting the size atttribute) is set to release in Chrome 145, but this is not yet for multiselect.

Future ideas with selectedcontent?

There still isn’t anything set in stone concerning the selectedcontent element in combination with these examples. If you’d ask me, I’d love to see a version where with size="1", a <selectedcontent> would hold every option instead of falling back to “2 selected, 3 selected”.

More specifically, I think it could be styled easily by wrapping your options with a <div>, and maybe using pseudo-elements to add commas or even just style them as little blocks.

<select multiple size="1">
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option><div class="wrapper">option</div></option>
  <option><div class="wrapper">option2</div></option>
  <option><div class="wrapper">option3</div></option>
</select>

selectedcontent .wrapper::after {
  content: ',';
}

Just sharing a thought here…

I opened an issue at Open UI to discuss this in the future.

Conclusion

I didn’t really go into too much detail on the styling of these demos because I have other articles for that. I’m planning on doing some more CSS-heavy demos in the (near) future. I did want to write about this feature because I’ve constantly told people in the past year that all these UI changes are a work in progress and that there is much more to come. This is just an update on something existing, but a very welcome feature.

I’d like to give a reminder as well: if you are passionate about these things, if you want to test more on the “accessibility side of things” for this feature, then this might be a good time to ease into this feature and play around with it.

With questions open, such as the selectedcontent element, I’m still very much excited to see what custom selects will be able to do in the future (even after all the demos I created for this feature).

Furthermore, for you reading this, I hope you had a wonderful time with family and/or friends to start the New Year. My best wishes for 2026!

CSS corner-shape, books, talks, and happy holidays

Brecht De Ruyte — Fri, 19 Dec 2025 00:00:00 GMT

It’s that time, “the most wonderful time of the year”, the time that we look back at the things we accomplished. It wasn’t all sunshine and rainbows; in fact, I think this year was once again an emotional rollercoaster, a year with ultimate highs, climbing on stages I never thought I would be on, but also some lows, struggles, unfinished projects, and re-invention.

Conferencing

For this end-of-year post, I’d like to keep things brief. Those who follow me around know that I’ve spoken at 13 conferences this year. I am grateful that my company allowed me to attend. Some were on weekends, some were during my holidays, but it’s been a real pleasure speaking at so many of them and connecting with so many developers. I still haven’t figured out what exactly, but it looks like I’m doing something right. From PHP and JS conferences, to a dedicated CSS day, Frontend scoped conferences, and DevFest for big and smaller communities. It’s been an honor.

Not sure if we can call it a conference (I did count it for the 13), but I am also grateful for being a panelist on the stage of Google I/O Connect with Bram.us and Rachel Andrew. It’s not every day you get to sit next to someone and talk about the web who actually taught you to work with Dreamweaver back in 2003 (yes, I read that book).

Speaking of books….

Reading

What I love about traveling is that I get to read a bit more books from time to time. I have a few recommendations. For fiction, I read “The last wish”, the book that inspired the Netflix Witcher series. I really enjoyed this, but I also played the games in the past so it was about time I read a book about it. I also read a few non-fiction books. Here are a few of them:

Atomic Habits
Think again
Bounce

But my favourite non-fiction was “Engineering Management for the rest of us”. Even tho I’m not a manager myself, this book taught me a lot, and I believe it is a must-read for anyone managing engineering teams.

Currently, I’m reading “This is for everyone”, the biography by Tim Berners-Lee. I like it a lot and hope to finish it by New Year’s.

Struggles

My biggest struggles at the moment are mostly about giving things a place… AI is evolving rapidly, and I’m sick of people shoving it down everyone’s throats. It’s not that I have something against it, it’s just that there is soooo much noise that doesn’t mean anything. I can’t hear another talk about “how cool something was made by one prompt”. I hope 2026 gets a bit more real on this topic, real usecases, real problem solving, real movement. Less cool and corporate wannabes, more quality and solutions.

And for my AI people out there who I connected with, I know it’s there, just… the noise…

I’m going to leave the AI topic for this article right here….

I did struggle a bit of writers block as well, and maybe I should let it go from time to time. Take time to absorb a bit more. I’m especially looking forward to playing around with some more CSS features aside from creating awesome select elements. Especially going to start the next year with scroll-triggered animations…

I’ve written 19 articles this year, and I’m carefully considering writing smaller ones on a more consistent basis, maybe a few more personal ones. I’m not going to write “ranting” articles; enough people are doing that already, I’m just not that kind of person. Keeping it educational, but maybe a little bit more personal.

Last year, I had a message. I don’t think it worked, so my wish is the same for all of us:

Converse, be patient, converse some more, scream later

And lastly, some lost projects… The CSS Next community group is currently on a pause. It just didn’t seem to catch on enough. I also noticed a lack of time on my hands for a project that didn’t really get enough traction. That is not due to the people there; I think everyone involved had the best interests and moved this project forward. I loved our Monday calls. I sure hope this is not completely the end, but for now, it is. Also my Oklch color picker project could use a bit of love. It’s not dead, but I’m not sure if I want to continue working on it. And I still have to fix some bugs on my little Guess who project.

I also set off this year to write better and draw better, which actually went quite well. My journaling went with ups and downs.

Still struggling with that weight… Conferencing didn’t help. But working on it (again).

Other Good things

So many good things in my life that I’m grateful for as well. My dad is currently cancer-free, my daughter went to the first grade (it’s crazy how fast these kids learn to read/write!), my parents got a really funny hyperactive Pomeranian dog (unfortunatly because we had to say goodbye to the last one). I got my golfing licence and won my first amateur game. There is a big stigma on this sport, unfortunately, but it’s not “elitist” everywhere. Seeing my daughter grow in character and develop hobbies is a great thing to witness. Not going to lie, it sure comes with its usual headaches, but that’s completely worth it.

So, next year?

Maybe a bit less conferencing, more time for my family, and figuring some things out career-wise. I’ve been an agency front-end developer for quite some time now. When projects are getting into trouble, I’m mostly the go-to nowaday but I do feel like I need to grow a bit in a different direction. I just don’t know in which direction and am not completely sure what is possible. I need to figure that out. I hope to grow in the non-purely-frontend-related tasks and do more for colleagues/developers close to me. We’ll see. This will be a big reflection I’ll have to make in the first half of 2026.

Also going to keep working on my fitness, and you know, just trying to be a good person. I will keep writing, I will keep speaking, I will keep building, I will keep learning, I will keep growing. And still be writing these articles by hand, mistakes included, because I enjoy the process, I don’t care if an AI agent writes in a better tone, grammar checks are all I need.

And for the web, well, I really hope I can get a bit more traction on this multi-thumb range slider proposal I’ve been working on.

CSS holidays card and corner-shape

Yes, this is quite enough now.

Did you hear about this new CSS feature, corner-shape? It’s inside CSS wrapped 2025, do check it out.

I do see some pixel issues depending on screen size, but I had a blast with these corner shapes to build a little holidays card out of CSS.

For example, you can easily create a star-like shape like this now:

.star {
    width: 2vmin;
    aspect-ratio: 1;
    background: #e2e8f0;
    border-radius: 50%;
    corner-shape: scoop;
}

Happy Holidays!

See the Pen Untitled by utilitybend (@utilitybend) on CodePen.

State, Logic, And Native Power: CSS Wrapped 2025

Brecht De Ruyte — Tue, 09 Dec 2025 00:00:00 GMT

Read the article at Smashing Magazine

Why Tailwind is great, why you might be missing out, and why it isn't for me

Brecht De Ruyte — Thu, 04 Dec 2025 00:00:00 GMT

People often asked me, “How do I do this in Tailwind?” or even stated that I have something against Tailwind. Nothing could be further from the truth. I think Tailwind is great. I also still believe jQuery is great, and the usage will probably stay bigger than React ever will be. We need to talk more about tooling, but on an honest level. This article is not about “syntax” or having “long classes in your HTML”. This article is about the good stuff about Tailwind, but also about the bad stuff, the things you are missing out on, and why it isn’t for me.

This is one of those articles that I’ve been thinking about for a long time. I always feel like I need to walk on eggshells to convey a clear and understandable message. That being said, I thought a long time about how to approach this topic, and I wanted to share it nonetheless. To give a bit more context, I’ve recently been working on a project using Tailwind. I see the benefits, but it really is a step down from just writing CSS.

Tailwind is a fantastic tool that is used by a multitude of companies, including the company I work for. I am not here to argue the benefits. I also believe that Tailwind is created by people who have an absolute passion for CSS, and that is a fantastic thing. I’ve also noticed that Tailwind, in some cases, has become a gateway drug for people to get more into writing CSS, which is great! It actually teaches people due to its good documentation, which also makes me wonder that we may not have enough clear “go to websites” purely for CSS documentation, or maybe they are not beginner-friendly enough, but I digress…

But it does bring me to one important selling point for Tailwind:

Clearer vs easier?

Look, CSS is a simple language; it’s not easy, but the syntax is easy to remember, and that has been the case for a long time (as in forever). So my question here is: Is Tailwind actually easier than CSS?

I believe it’s really not… It’s better documented, it might be clearer, but it’s not easier. When I’m forced to write Tailwind, I’m losing a lot of time since it is an abstraction of a language that I know by heart, for some reason, it also makes me write websites in a more old-fashioned manner, using way more breakpoints instead of just creating fluid experiences (but that might just be me not being trained enough). For me personally, Tailwind only has one huge benefit that I’ll get to later on.

And this is where a divider takes place: Creating a grid with Tailwind is easy, and breakpoints are easy; as a matter of fact, margins and paddings are easy. But CSS is so much more nowadays than your good old margins and paddings. And you can use a lot of modern features of CSS right inside of Tailwind, but here is an example that I think of.

It wasn’t that long ago that I created a full (big) website, and I had to write a total of 6 (sizing) media queries in the whole project. Because the web is fluid, we can do so much with so little. But to create a fluid grid in Tailwind, I believe that it gets rather painful on the eyes:

<div class="grid grid-cols-[repeat(auto-fit,minmax(min(250px,100%),1fr))] gap-4">
</div>

In those cases, I wonder if we aren’t just best off with writing some CSS, making it more humanly readable. But I do want to be fair in this article and state that this is subjective to me.

My real point is that when we want to create these kinds of experiences, it is still a matter of learning how CSS works. Tailwind is simple and can be hard, just as CSS is. The question for your “basic website” is not if Tailwind can do it; it probably can.

But! Welcome to the age of AI

If your design skills exist out of “basic Tailwind”, meaning, just your good old breakpoint-based classes for grids, margins, and paddings, I’ve got a newsflash for you. The average “AI chatbot” out there is really good at that as well.

So these are the questions you need to ask yourself:

Do you use Tailwind to create basic designs?
Do you think it is still sufficient if your competitor is an average Joe in his garage with the prompting machine?
Are you a person who creates fresh experiences, or is the “good old bootstrap” style enough?

Do you want to create more evolved experiences where you might need to learn a bit more about CSS in general and maybe run into limitations at some point (more on that later)? When you learned those new CSS skills, was it still worth the trade-offs of an abstraction to an already perfect language?

This is the reason why I always felt that Tailwind shouldn’t be a battle about yes and no… I think utility classes are great, but I believe the truth lies somewhere in the middle, a hybrid way to create unique experiences and make “the boring stuff” go quicker (even though I still freaking love styling buttons!).

Naming conventions, Debugging & copy pasta

This is, in my opinion, the biggest selling point of Tailwind for companies. There is one way to write classnames, and that is final; no need to discuss naming conventions, property sort orders in CSS, and all that stuff. I’ll leave it at that, but it’s a really important thing.

I don’t believe that copy-pasting is the sole benefit of Tailwind because it’s also the case in CSS. You can easily copy and paste stuff without having an idea of what is going on. But when it comes to debugging, I always found it hard to read every single class declaration in my DevTools instead of a good, nicely written CSS with multiple properties and values.

You are missing out, but maybe that’s ok

It’s not a secret that I love writing CSS, and I like to be modern, pushing boundaries, trying progressive enhancements, creating smart systems, and this is where, for me, the biggest pain point of Tailwind lies.

Features such as @starting-style, advanced color functions, ::details-content, scroll-driven animations, interpolate-size, view transitions, customizable selects, and missing out on trigonometric functions are for me a deal breaker, as I think those can help us reduce dependencies, add progressive enhancements, and create more beautiful experiences. These things can push boundaries in creativity. Note that some of these things are possible, but they really become bloated.

But that’s not all, with the new attribute capabilities in Chromium, new container queries, carousels, CSS Functions and CSS conditionals, etc, there are a lot of new things that we can do, there are also a bunch of new pseudo-elements for some of these features, and I know there might be a way for Tailwind to handle this somewhere in the future, I just feel ike it is being bolted on and maybe, it’s coming into that phase where it’s time to let go?

I’ve been in this industry for quite some time, I’ve used Bootstrap in the past, and it was also one of those things I had to let go after a while, as CSS just got a lot better. That being said, people still use Bootstrap as well, and I am not going to judge any of them. If it works for you, by all means…

I think it is purely up to you… Do you want to evolve with the language or stick to the abstraction? Maybe CSS just isn’t your thing and you want to get things styled. That is a choice that you have to make, but you already know that this is the reason why…

It isn’t for me, and that’s ok as well

I want to push the web forward, I want to push projects forward, and I love seeing the structure of my HTML clearly, as it helps me to create accessible experiences. I like to create a multibrand setup with smartly placed custom properties that do more than just color changes. I’m not afraid to use progressive enhancements, I love to know what is possible and learn the language to the best of my capabilities.

So no, it isn’t for me. Even if I knew all these classnames by heart, I’d probably still lose time instead of gaining it, because I love tinkering. I don’t like “good enough” or “close enough”. The world is evolving with AI experiences, and I want to evolve UI experiences as well, think about performance by removing dependencies, because a lot of countries with shitty internet connections are economically booming, and every bit of performance helps.

Is knowing CSS way more beneficial than just knowing Tailwind? Yes, of course, that is a no-brainer. An <insert JS framework here> developer who has a strong foundational skill in vanilla JavaScript will also have an extra edge. Knowing the foundations is so important, probably even more so in this AI era, and also, a lot of fun.

So, should you Tailwind or not

It’s your choice. I think I’ve shown the downsides clearly here without neglecting the benefits. A colleague of mine also pointed out that NativeWind might be a selling point if you want to create both desktop and mobile applications (which often use simpler design patterns).

In most cases, Tailwind will be enough, and it might just be the thing you need; And maybe it’s me, I like to go beyond “just enough”. It all depends on the direction you want to go in your “visual/UI programming” journey. When Tailwind launched, CSS had some missing features that made utility-first make sense, but let me be the one to tell you, in 2025, CSS is pretty damn cool.

5 CSS debugging features I want to see in Chrome DevTools - Holidays list

Brecht De Ruyte — Fri, 28 Nov 2025 00:00:00 GMT

I’m not going to make this a long article, but I want you to know, that I could easily come up with more features… However, these are the ones that I really could’ve used a couple of times. And who knows, maybe some of these are features already exist, and and someone will point that out for me 🙂.

1. More positioning debugging.

For this, I’m going to split it into two; one of them is a more recent capability that we will start with, and the other is long overdue:

Anchoring

Especially with anchoring being in Interop this year, I was hoping for some better anchoring tools. We already get a link from the positioned item to the anchor, but I kind of feel I need a bit more from time to time:

I want to see which position-try fallback is currently active
I want to see an icon next to the position property, indicating that the element is anchored; It might be handy to know at a glance.

General positioning

I always felt that we could get some more info for the positioned element.

For example

When I use position: absolute; within a relative container, it would be nice to get some sort of quick view to see on which container it is positioning itself to, as in some cases, the stack can get complicated.
It would also be nice if I could see a distance measurement on my website for that item (this also counts for anchoring).

2. Hide overruled styles with a simple toggle

When we only want to see the applied styles, we can look at the computed tab, we can even use the computed tab to jump back to the styles panel.

However, there have been multiple occasions when some property is being set, and I quickly want to know which class it came from. Not every codebase is equally clean, and sometimes there are a whole bunch of styles that have been overwritten by specificity.

I just want a quick toggle in my CSS panel to hide the crossed-out styles so that I can get a quick browse. Seems like an easy feature.

3. Guides, rulers, and more quick looks on my webpage

I’m just going to say it like it is. I want a LOT of features from VisBug baked into Chrome DevTools, especially the rulers, editing text, and quick overviews.

We see these things all the time in design tools, and it’s such a shame that we don’t have them by default in our “website debugging tool”.

I feel like this is such a missed opportunity to just have that baked in. While we’re at it, let’s also add some top and left rulers where we can draw lines out of, just as you would in a design tool.

This is a small bit of text for a huge feature, but I believe this is really needed!

Simply put: learn from VisBug.

4. Sticky panels

I’m going to refer to VisBug again, and I’m not sure if it’s a feature or a bug. But what I like is that when you have a panel, inspecting contrast, it gets stuck when you click.

We have soooo many panels in DevTools: colors, shadows, easing, …

Wouldn’t it be cool to just grab them and place them on your page?

5. Scroll-stuff animations panel

There is a lot of scrolling going on in CSS nowadays, from carousels, scroll-state queries, to scroll-driven animations. There is a scroll-driven animations debugger for DevTools, but even tho it is made by a Googler, it’s not a real DevTools feature.

So, can we have this in DevTools by default?

Can we add this? And maybe extend it for carousels, snaps, etc…

Who knows, I think we need this.

Bonus: Fast features and a clear focus shift towards AI

With new features coming to Chromium, I’m sometimes bummed out that the tooling is not ready yet. For example, I don’t see any pseudo-elements of the customizable select, I don’t see ::details-content, but then again, I do see pseudo-elements for carousels, it feels a bit messy, or is it just me? Sometimes I feel like the tooling should be part of the “this is stable” story, but then again, this could be a “shortage of developers” thing. I dunno, just putting that out there.

I know recent DevTools updates had a lot to do with AI features. And that’s ok, I understand it, but I feel that there is so much handy stuff that can be done here.

Sometimes I want to design in the browser, and who knows, maybe in the future, I want to ask Gemini to move this item by x pixels, so taking that quick look at current values might help as well.

This is just one developer’s opinion, but let’s not forget all the cool stuff to be done in favor of prompting mechanisms.

I welcome new AI features, but want my DevTools to be my actual toolbox, not my assistant.

Call me a geezer, but when opening DevTools, it kinda should still feel like I’m running towards my garage, get my trusty toolbox, and pick the right tool for the job, and just tinker away.

So these are just a few of those features that came to mind, and I’m sure I can think of many more, but I’m more curious to see what you would like? What is something you missed in DevTools?

A native way of having more than one thumb on a range slider in HTML

Brecht De Ruyte — Fri, 17 Oct 2025 00:00:00 GMT

The proposal: `<rangegroup>`

In this article, I’m going to summarize the current explainer. I want you to know that this is very early stage, which is exactly why it needs noise from other developers. For those who want to take a deep dive, these are the steps you can take:

Read the full explainer
Look at the prototype (using a web component)
filling out the feedback form

Note that if you have already given me feedback, I am still in the process of collecting more of it 🙂 I haven’t forgotten, and I value each bit of feedback a lot.

So now, let me summarize. What if we could combine two <input type="range" /> and each of those would become a thumb. In short, this is what that would look like in HTML:

<rangegroup>
  <legend>Temperature Range</legend>
  <label>
    Minimum Temperature
    <input type="range" name="temp-min" value="-25">
  </label>
  <label>
    Maximum Temperature
    <input type="range" name="temp-max" value="15">
  </label>
</rangegroup>

What exactly is happening here? A lot, and I’m sure with a bit of browser engineering magic that this could look different, but this starting point does make a few things clear regarding the direction of this API.

Look at the <rangegroup> as sort of a <fieldset>; this <fieldset> has a <legend> which could become the general label for your duo-thumb range slider. Giving each thumb a <label> can help screen readers to identify the intent of each thumb. In complete honesty, I haven’t tried this in every piece of software, but inside the prototype, this is working rather nicely. Which is why I also did not add “crossing” of thumbs. I’m not saying it is impossible, but when a thumb has a “minimum” label attached and is suddenly passed the “maximum”, it’s weird….

A progressive enhancement?

I would love to bring this idea to the table. Having a way where we could progressively enhance for most scenarios. By using this wrapping element there is a possibility to have two individual range sliders for browsers that don’t support <rangegroup>. So, depending on the use case, there is a chance of progressive enhancement here that I believe should at least be explored.

Why range sliders as a progressive enhancement?

Why not <input type="number" />?

I believe using <input type="range"> elements better preserves the design intent. A range input is designed for selecting an approximate value within a scale, where the user is more interested in the position along the track than a precise number. This means that using <input type="range"> as the fallback provides a more equitable, if not identical, user experience.

Min and max values

Since range inputs can have a min and max attribute, I thought it would be handy to extend capabilities by allowing constraints by the range group. This is one of those examples where progressive enhancement might not work anymore, but I don’t want to miss this opportunity at the starting point.

If a handle’s range is within the group’s range (e.g., rangegroup max="100", input max="70"): The track will render from 0 to 100, but the handle will be prevented from moving past 70. This is a desirable pattern for use cases like a seek bar for a live video stream, where the total buffer is visible but the user cannot seek into the future.
If a handle’s range exceeds the group’s range (e.g., rangegroup max="100", input max="200"): The handle’s movement will be clamped by the <rangegroup>’s bounds. The handle will not be able to exceed a value of 100. This ensures the component’s visual representation is the source of truth and prevents invalid states.

Stepbetween

It might be nice to define a boundry on how close thmbs can be against each other, this is where the stepbetween attribute would come in. It defines the minimum distance between handles in a range group.

Styling capabilities and datalist

In the current explainer, there are a few styling capabilities that I think we all want to have. My main background is in UI/UX, so I am aware that this explainer is not complete and has the focus there, but we need to start somewhere. The same pseudo-elements and classes defined in the new CSS Forms spec should be there, but there are a couple of nuances/extras.

Here is a short explanation:

::slider-thumb(*): would style the thumb, between the parentheses, a number can occur for each thumb
:slider-segment(*): This is a pseudo-class that styles a segment of the ::slider-track the first one between edge and first thumb, the second between the first and second thumb, etc…
::slider-tick: Optional tick marks along the track for value representation. (when datalist is paired.)
::slider-tick-label: Labels associated with tick marks. (when datalist is paired.)

I still have a lot of unfinished thoughts about the tick marks as well. For the moment, I’m leaning towards an idea that sort of works like CSS carousels, where the ticks would be wrapped in a ::slider-tick-group. But as I said… Still a lot to think about

What I do know is that <datalist> pairing should be supported.

More than two thumbs?

I love the idea of having the capability to add more than two thumbs, which is actually part of the foundation of this API idea. Having the chance to add more range inputs for more thumbs.

I added a few examples of how it could be used in my prototype, but this is why I need the community: Let it be heard: Do you want this? Why do you want this? Do you have examples of where you would use this?

Here is another one of my ideas: an opening hours slider:

This would result in something like this:

<rangegroup id="opening-hours-range" min="480" max="1320" list="hours-ticks" stepbetween="30">
    <legend slot="legend" class="color-purple">Opening Hours Selector</legend>
    <label>
        AM Open
        <input type="range" value="540" />
    </label>
    <label>
        AM Close
        <input type="range" value="720" />
    </label>
    <label>
        PM Open
        <input type="range" value="780" />
    </label>
    <label>
        PM Close
        <input type="range" value="1020" />
    </label>
</rangegroup>
<datalist id="hours-ticks">
    <option value="480" label="8 AM">
    <option value="540" label="9 AM">
    <!-- etc -->
    <option value="1260" label="9 PM"></option>
    <option value="1320" label="10 PM"></option>
</datalist>

rangegroup::slider-segment(1),
rangegroup::slider-segment(3),
rangegroup::slider-segment(5) {
    background-color: oklch(35% 0.02 230); /* Muted track */
}

rangegroup::slider-segment(2),
rangegroup::slider-segment(4) {
    background-color: var(--color-teal);
}

rangegroup::slider-thumb {
   background: var(--color-teal);
}

Expanding…

I thought a lot about what should be the default and what should not be. I think that if we want to see the value inside the thumbs, anchoring could be used to put the values on top of the thumb. Showing live updated values could be handled by a bit of extra JS. There are quite a lot of possibilities here.

The following examples anchor values on the slider. This is also using the same component:

There is a lot more detail on all of this that you can find in the explainer. But this article is already becoming a bit too long…

And this is why I need you

I know there are still a lot of open questions and things to be improved, which is exactly why this is so important now.

I am not a browser engineer; I am a developer creating web applications. I’m not even sure if I’m an expert on anything, really, but I do love the web. I usually ask the stupid questions, which sometimes actually is the good kind of question. I am NOT going to build this API. I haven’t got the skillset. Which is why…

I need it to be on the radar, on the radar for people who can make this happen. I need you to ask for this in your socials, write about this, anything, really… Make sure it can’t be ignored.

All I can promise you in return is that I will keep asking the stupid questions, and will be testing the API in the future, making demo’s trying to break stuff. See me as your little helper, who might not really be qualified to work on web standards, but just really cares about it.

This being picked up is the most important thing.

And if you read the explainer, you can also help by filling out this feedback form.

Thank you 🙂

Build a guessing game with the Prompt API

Brecht De Ruyte — Fri, 10 Oct 2025 00:00:00 GMT

Read the article at Chrome for Developers

Styling siblings with CSS has never been easier. Experimenting with sibling-count and sibling-index

Brecht De Ruyte — Fri, 12 Sep 2025 00:00:00 GMT

I’ve been living a lot in “select land” with my last articles, and even tho I’m still passionate about all things Open UI, I really wanted to get back to some of those newer yummy CSS features. I was building a bunch of demos already, but never had the chance to do a full write-up. So, I’m playing some catch-up because the features I’m tackling today are already available in Chromium browsers. This article is about sibling-count() and sibling-index(), and some of my first ideas for this new feature. What can we use it for? Where does it make our lives easier? Let’s get to it.

So, what is this about?

I feel like I don’t need to explain it too much:

sibling-index() returns a number representing the position of the current element relative to all its sibling elements
sibling-count() returns a number representing the total number of siblings of the element on which it is used, including itself.

That’s it, the only tricky one is that sibling-count() also counts itself. I will be going over 4 demo’s and some extras in the end. Here are some quicklinks:

Creating staggered animations using sibling-index()
Dynamic color spectrum: Give each card a different color using sibling-index() and sibling-count()
Placing items in a circle using sibling-index(), sibling-count(), and @function
Creating a casino cards fan effect using sibling-index() and sibling-count()
Further experiments, demos that didn’t make the article

Creating staggered animations using sibling-index()

One of the things that I used in past animations was setting an inline custom property with CSS to create staggered animations.

return (
    <>
        {cardData.map((card, index) => (
          <div
            key={index}
            className="card"
            style={{ '--stagger-index': index }}
          >
            <h2>{card.title}</h2>
            <p>{card.content}</p>
          </div>
        ))}
    </>
  );
}

And then I would handle my animation delay as follows:

.card {
  animation: reveal 0.6s ease-out forwards;
  animation-delay: calc(var(--stagger-index) * 100ms);
}

And this works like a charm as long as you’re looping over some cards. But imagine the situation where you suddenly have a call to action in the middle of the cards, then it gets a lot trickier. You’d have to start propagating the index to another component; it’s not necessarily the hardest thing to do, but a cleaner way is more than welcome.

This is one of those things that suddenly becomes a lot easier with sibling-index(). Instead of just trying to get our CTA inside the loop or passing down index counts in other components, we could just use CSS!

Here is pretty much the gist of it:

.card-container > * {
  animation: reveal 0.6s ease-out forwards;
  animation-delay: calc(sibling-index() * 0.1s);
}

I love a bit of ease-of-life enhancements. It’s just nice to clean up the code a bit.

Here is that in a little codepen:

See the Pen Stagger cards using sibling-index() by utilitybend (@utilitybend) on CodePen.

Dynamic color spectrum: Give each card a different color using sibling-index() and sibling-count()

Ever wanted to create a bunch of cards where each one of them has a different background, color, or border-color? What if you want to have a fixed starting color and want to end on a fixed color as well, giving each card an equal hue in between? Well, this just got a lot easier.

The idea here is that we calculate a “hue” based on an element’s position in a list (sibling-index()). We can use this to create some sort of gradient that flows across any number of items, without ever having to write a single line of JS or add manual style tags with custom properties..

Let’s look at the CSS right away. Now… the calc() function might seem a little much at first, but once we break it down, it will make sense. As a sidenote, this is one of the reasons I write about this stuff, to keep these calculations as a snippet for future reference. (I thanked my past self a few times)

In this example, we’re going to have the background of our cards range between a 180deg on the hue wheel for the first item, to a 300deg for the last item. (hence the variables in the next example: 180 + 120 = 300).

Here is the gist of it:

.spectrum-item {
  --start-hue: 180;
  --hue-range: 120;
  background-color: oklch(
    65% 0.35
      calc(
        var(--start-hue) + (var(--hue-range) / (sibling-count() - 1)) *
          (sibling-index() - 1)
      )
  );
}

The formula to achieve this is the following:

start + (range / total_steps) * current_step

The hard part here was figuring out how far along the color spectrum each item should be, as we want to start and end on the same color and want everything equally spaced on the hue wheel.

The first step is to determine the size of each “step” in our color transition. To do that, we need to know how many steps there are in total. That’s where sibling-count() - 1 comes in. If you have 5 items, there are only 4 steps between them.

Next up, we divide our “color journey” (the --hue-range of 120 degrees) by the number of steps we just calculated. This gives us our “hue increment,” aka, the exact amount the color should change from one item to the next.

Finally, we need to know which step we’re currently on. That’s where sibling-index() - 1 comes in. We subtract one because we want our calculation to start from zero. The first item is 0 steps away from the start color, the second is 1 step away, and so on.

In my demo, it starts with 5 items. So in that example that would mean the following:

For five items, the hue amount for each step is 30: 120 / (5 - 1).

Item 1: The hue is 180 + (30 * 0), which equals 180 (our start color).
Item 2: The hue is 180 + (30 * 1), which equals 210.
Item 5 (the last one): The hue is 180 + (30 * 4), which equals 300 (our end color).

Here is a little sandbox of the idea:

See the Pen Dynamic color spectrum with oklch, sibling-index and sibling-count by utilitybend (@utilitybend) on CodePen.

Placing items in a circle using sibling-index, sibling-count, and CSS functions

Staggered animations and color spectrums are cool and all… But what if we want to fundamentally change the layout of our elements?

I’m talking about arranging items in a perfect circle, a task that can be a real pain in the… I already played with this in another article about select elements. But this time I wanted to start fresh. Before we continue, here is the demo:

See the Pen The circle using sibling-index , sibling-count and functions by utilitybend (@utilitybend) on CodePen.

To create this behavior, you’d typically have to calculate every single position manually in JavaScript or use a pre-processor with complex loops.

With the combination of sibling-index() and sibling-count(), we can bring some trigonometry directly into our stylesheet to hack on some perfect circle placement. I’m also throwing the new CSS @function in the mix, just because I can, and I really love this feature.

First, let’s look at the custom functions that do the heavy lifting.

@function --pos-x(--index, --count, --radius) {
  result: calc(var(--radius) * cos(360deg / var(--count) * (var(--index) - 1)));
}

@function --pos-y(--index, --count, --radius) {
  result: calc(var(--radius) * sin(360deg / var(--count) * (var(--index) - 1)));
}

I’d like to think of these two functions as our little engines. So cool we can set these aside like that, these CSS Functions will really help for cleaner code.

They calculate the exact X and Y coordinates for any point on a circle. To do this, they need to know three things:

The total number of items (--count)
Which item we are currently placing (--index),
How big the circle should be (--radius)

Let’s break these functions down:

First, we need to figure out how big each “slice” of our circular pie is. A full circle is 360 degrees. By dividing 360deg by the total number of siblings (sibling-count()), we get the angle for each segment. If we have 6 items, each one gets a 360 / 6 = 60-degree slice of the circle.

Next, we determine the specific angle for the current item. We multiply the size of each slice by the item’s position (sibling-index() - 1). Just like in our color spectrum example, we subtract 1 so that our first item starts at an angle of 0 degrees (at the right of the circle).

For our 6 items, the first item would be at 60 * 0 = 0 degrees.
The second item would be at 60 * 1 = 60 degrees.
The third item would be at 60 * 2 = 120 degrees,
and so on…

This is where the trigonometry comes in. The cos() function gives us the X coordinate for a given angle on a circle, while sin() gives us the Y coordinate.

Now that our functions are ready, using them is incredibly clean. We apply a transform to each item, passing the dynamic sibling values directly into our functions.

.circle-container div {
  --radius: 120px;
  position: absolute;
  top: 50%;
  left: 50%;

  transform:
    translate(-50%, -50%)
    translateX(--pos-x(sibling-index(), sibling-count(), var(--radius)))
    translateY(--pos-y(sibling-index(), sibling-count(), var(--radius)));
}

We start by centering each item perfectly with translate(-50%, -50%). Then, we apply two more translations. translateX pushes the item horizontally by the amount calculated by our --pos-x-function, and translateY pushes it vertically based on --pos-y.

It’s a really cool effect! You can see the items smoothly rearrange themselves to form a new, perfectly symmetrical circle.

Now, truth be told… this might not be the best way to create a circle, I’ve seen a very clean way to do this as well by Temani Afif. In my example, the radius is rather static, but at the same time gives a bit more layout control. I think both methods have their benefits. But the idea by Temani is really awesome!

Check out this method of placing images in a circle with CSS here.

Creating a casino cards fan effect using sibling-index() and sibling-count()

So far, the demos were mostly about progressing from a start point to an end point. But what if you want to create something symmetrical, fanning out from a central point? Think of holding a hand of playing cards. The cards don’t all lean to one side; they fan out evenly.

See the Pen Add and remove a card fan effect with sibling-count() and sibling-index() by utilitybend (@utilitybend) on CodePen.

Let’s take a look at the code first:

.card {
  --rotation-per-card: 8deg;
  --center-index: calc((sibling-count() + 1) / 2);

  transform:
    rotate(
      calc(var(--rotation-per-card) * (sibling-index() - var(--center-index)))
    )
    translateY(calc(4px * (sibling-index() - 1)));

  transform-origin: bottom center;
}

You see that our card has two custom properties, which will be used as levers for this demo. I’ll get to the --rotations-per-card in a bit, but first of all, I want to go to the secret to this entire effect: --center-index.

Inside of this --center-index custom property, you can find a simple calculation: calc((sibling-count() + 1) / 2).

This calculation finds the middle item in our list based on the number of siblings, for example:

If we have 5 cards, the calculation is (5 + 1) / 2, which gives us 3. The 3rd card is our center.
If we have 6 cards, it’s (6 + 1) / 2, which gives us 3.5. This means the center point is right between the 3rd and 4th card.

Since we already have our center point, we can go on to calculate the rotation for each card. Look at the rotate() part of the transform:

calc(var(--rotation-per-card) * (sibling-index() - var(--center-index)))

This calculates each card’s “distance from the center” and multiplies it by our desired rotation amount (8deg), this is one of those levers we set (--rotation-per-card).

Let’s use a 5-card hand for a starting example, where the center index is 3:

Card 1: The distance is 1 - 3 = -2. The rotation is 8deg * -2 = -16deg (tilted left).
Card 2: The distance is 2 - 3 = -1. The rotation is 8deg * -1 = -8deg (tilted slightly left).
Card 3: The distance is 3 - 3 = 0. The rotation is 8deg * 0 = 0deg (perfectly straight).
Card 4: The distance is 4 - 3 = 1. The rotation is 8deg * 1 = 8deg (tilted slightly right).
Card 5: The distance is 5 - 3 = 2. The rotation is 8deg * 2 = 16deg (tilted right).

The result is a symmetrical fan. Cards to the left of the center get a negative rotation, and cards to the right get a positive one.

But! There is more! There’s one little effect that was added as the final detail: the translateY().

This pushes each card down slightly, creating the illusion that they are physically stacked on top of one another. The formula calc(4px * (sibling-index() - 1)) simply moves each subsequent card down by an additional 4px and adds a bit of depth. That is more of a gut feel than an exact science. Once again, we can rely on sibling-index() to just really finalize this example. Ah, sweet sibling counting, I’m a fan!

Further experiments, demos that didn’t make the article

I’m trying to switch up my blogging and demos a bit; Maybe you noticed it on my demos. I wanted to add some information on there for when people come across them in other places. I’m also thinking of writing some more comments. But it’s a fine line between overcommenting and just enough.

For this article, I created some other experiments that I thought would be a bit too much. One of them is this bar chart, almost the same as the animation stagger effect, but using a bit of CSS conditionals in there just for funsies! (When the value is 100, it gets a perfect label on top).

See the Pen Bar chart using if() and sibling-index by utilitybend (@utilitybend) on CodePen.

And last but not least, I have this demo, combining the hue changing with some 3D experimentation. I might make another article about that one specifically. Feel free to give a shout-out if that interests you. I’m not that good at 3D stuff in CSS. I based the demo on a bunch of other pens and did some hacking. But to prettyfy this demo, I had a little secret:

I put in a prompt to A(I)mit Sheen, who is a true wizard in this sort of thing. If you haven’t heard of his work, you really should! Check out some of Amit’s work.

Here is a little 3D example (And thank you, Amit!):

See the Pen 3D adding frames in a rainbow style using sibling-count and sibling-index by utilitybend (@utilitybend) on CodePen.

To close…

I really love this feature, I love it so much that once again, my article might’ve been a bit too long. It’s how my brain works… I start something, and then I get stuck in experimenting and demos. I could cut these articles up into smaller pieces, but it’s just not in my nature. Anyway, for you, who actually went through the whole thing, thank you for your attention! And for those who just skimmed the article for the demos, that’s fine too.

HTML popovers shown on interest should be accessible on mobile devices

Brecht De Ruyte — Thu, 07 Aug 2025 00:00:00 GMT

Most of you reading my blog know I love me some good popovers, and I’m so happy that things are moving forward at a rapid pace. Currently, if you use Chrome Canary with the experimental web platform features enabled, you can play around with the new way to trigger popovers, using a new attribute. I’ll try to keep the intro short in order to make my statement. This post is “general accessibility” on touch devices; I am not the right person to debate about detailed accessibility for specialized assistive technology (e.g., Screen readers).

How do interestfor and popover=“hint” work?

Just as you would do with regular popover using popovertarget (or commandfor if the browser supports it), you can trigger popovers on hover/focus using the following snippet:

<button interestfor="my-popover">Default speed</button>
<div id="my-popover" popover="hint" role="tooltip">Hi! I'm a popover</div>

These popovers get triggered on hover, and you can update the delays by using CSS:

[interestfor] {
  interest-show-delay: 0.24s;
  interest-hide-delay: 0.44s;
}

If you want the same delay for both entry and exit, you can even write a shorthand:

[interestfor] {
  interest-delay: 0.24s;
}

Both of these actions would be possible on <a> and <button> elements.

Accessibility/UX hot take

I created a little demo, playing around with the delay parameters. At first, I found the default speed too slow, but to be honest, I think it matters on your use case. If you have a lot of these popovers and a person is tabbing through them using a keyboard, it can get really frustrating and thus not a good UX. In those cases where popovers would just keep jumping up, a bit of extra delay doesn’t hurt. If you only have one or two of them, feel free to ramp up the speed a bit. As in a lot of cases… it depends. Put the user central. So yes.. I kind of like the default speed to be a bit slower as a good default.

Here is that delay demo:

See the Pen Speed checker intersettarget by utilitybend (@utilitybend) on CodePen.

I also added a video if you don’t want to check in Canary:

Your browser does not support the video tag.

Also note that in this example, I used a role="tootlip" in the popover. This is still a bit opinionated, and I don’t consider myself an expert on this, so use with care. I came across an interesting thread on this tooltip role (Also whether tooltips should or should not contain interactive elements).

There are more nuances than this, but popover="hint" is used as a new stack of popovers, allowing you to have an auto popover open while toggling between different hints. Think of an example where you would have tooltips inside of an auto popover.

I created a little playground that you can use in Chrome Canary to illustrate these differences. (I didn’t bother to create actual “tooltips” from the popover hints with anchoring, to keep the demo on point)

See the Pen Popover playground with interest by utilitybend (@utilitybend) on CodePen.

Your browser does not support the video tag.

There is a bit more information (and a cool example!) to be found on Una’s blog

But what about touch devices…

I know for a fact that the Chrome DevRel team has been reaching out to developers at conferences and has done a couple of surveys on the possible solutions to do this. I am quite opinionated on those, but let’s review some of the options first.

I’m going to do a quick version on this, but a full version can be read on the Open UI website; the animated gifs images I’m using are also from that page (but a bit more compressed). I will summarize them and add some of my thoughts on this. I do hope you read the whole thing at Open UI to create your own ideas! We need more input on this.

Note that the following part will have some animated GIFs in them; They do not pause, but I’ve hidden them in collapses so you can toggle them if you find them too distracting.

Option 1a: do nothing

Although this is not in the explainer of Open UI, it is an option that was discussed at CSS Day. Not showing it on mobile devices is one of the options, and I am completely against that idea… But I should at least add the arguments I heard:

Arguments:

Tooltips shouldn’t contain important information from a UX standpoint, so it’s not needed
It makes things easier as we only need to think about one sort of implementation.

The reason I don’t think the argument adds up is that we don’t know which information the authors will put in there. Yes, there shouldn’t be important info in there, but that doesn’t mean there can’t or won’t be. I applaud the argument as it was clearly by a person with good UX intentions, but bad UX is still a thing that will happen - and that is why - I believe that if something is written in a well-structured HTML, it should be accessible by default on every web-capable device. The main benefit of writing some solid and smart HTML fixes most of the accessibility problems we see today. I don’t like the idea of something not visible/accessible by default in just HTML.

Take into account translation labels provided in a CMS, where non-technical, non-UX people might have a final say. Before you know it, labels such as “Will increase final price” will be added to that popover.

Option 1b: Let the UA handle it

Let each browser vendor figure this out by themselves might seem like the easy solution here. However, as someone who started in the Internet Explorer 5 era, I’m always a bit scared of these kinds of solutions.

Argument

Will speed up initial development
Behavior can be tailored to the UI/UX direction of the device

Even though I love to see features ship fast, I’d rather have a uniform way of how these interest popovers work. Fewer caveats and author confusion should be important

This idea came initially from open UI. The idea is that the popover and the context menu would both be visible when long pressing an <a> element, and only the popover on a <button> element:

View example

Anchor link

Button

Argument:

There is a lot of native behavior on touch devices where people use a long press

I agree with the idea in general, an author could, for example, add an icon on the link to indicate a tooltip is behind it (for example, using an ::after pseudo-element with an info icon). The downside I see is bigger popovers, as we can’t always control what authors put in there.

Here it is using the long press again, which keeps it the same for buttons, and it would work out of the box. However, for links, the long-press gesture already brings up a context menu. This option proposes adding a “View more info” item to the existing menu.

View example

Arguments:

It doesn’t alter any existing user experience and is easy to implement.
Popovers are not bound to a limited space

I personally like this idea (for me it’s certainly one of the favorites). The biggest downside is that it will take some time for people to get acquainted with this added item in the context menu and that the “view more info” is a fixed label that can’t be altered by the author (I think…).

Option 3.5: Long press and add an opt-in “info” button pseudo-element

So the idea here is basically the same, but instead of context menu an optional pseudo-element could be added next to the invoker. That pseudo-element alone would trigger the option.

View example

Argument:

clean?

It could look like this:

@media (any-pointer: coarse) {
  .my-link::interest-hint {
    content: '' / 'profile preview';
    background-image: url('icon.png');
  }
}

I personally think this is a really clean idea, of course people will have to add correct sizing of the icon for the thumb action.

But here is that optional part again, and once again, I don’t really like this to be optional by default. I’d rather have the pseudo-element on by default with a UA chosen icon if this would be the way to go. At least then, the author needs to explicitly remove or alter it in CSS.

But I recently came to a new proposal in Open UI which will be discussed: an Alternative HTML-only version of the ::interest-hint feature, via command invokers.

Just to show, we are not there yet which is exactly why feedback at this stage is extra important.

Option 4: Single-tap interest

Instead of using a long-press, this option suggests that a single-tap on an element with interestfor would show the popover. A second tap (perhaps within a set time) would then activate the link or button.

View example

Anchor link

Button

Argument: Since a single-tap is used for the popover, the user can still long-press to access the standard context menu.

But the downside here is something called “tap uncertainty”. Users won’t know if a single tap will navigate to a new page or just show a popover, which could be confusing and discourage link-tapping, maybe even create dark-patterns.

With this option, long-pressing an element with interestfor would immediately trigger the popover, but the standard context menu would not appear.

View example

Argument:

Direct and clear action

The downside is simple: but what if I want to copy text, open in new tab,… There is loss of functionality here.

Option 6: A new gesture and alternatives

I don’t have anything here for gestures 🙂 Think about it.

Did I pop your interest?

Which option to choose, that’s the question, right? I did not hide that I have my favourites, but that doesn’t mean they are the best ones. I don’t have the direct answer here on which on of the options should be provided. I know for sure it will be a hassle to get every user agent on board for a single solution.

But if you read this, I do want you to share your opinion on this. For me, it needs to tick the following boxes:

Make it accessible on a mobile/touch device by default, as we don’t know the content (it’s fine if an author can turn it off)
Make it a uniform way between user agents, so that there isn’t any author confusion
Make it clear to users that something else will happen (can be partially by author, such as adding an icon)

The customizable select - Part five: Optgroup, creating a true select menu

Brecht De Ruyte — Fri, 11 Jul 2025 00:00:00 GMT

Quick recap

If you were following this series, I’m sure you are pretty much in love with the select element and have been tinkering with it at least for a bit. I am not going to go on about how the progressive enhancement works in this article and the various elements. I’ll just quickly talk about the idea and fundamentals of this demo and some others.

If you do get lost, I suggest you go back to the previous in this series:

What we’re making

Here is the full demo showing a menu-picker:

See the Pen An actual Select Menu with optgroups by utilitybend (@utilitybend) on CodePen.

Adding our HTML: A select with optgroup

In the final demo, there are a few of these selects, but we’ll be focusing on just one, as the others are just a copy. First of all, let’s set our HTML, a <select> with categories in <optgroup> elements and some <option>s inside. Let me jump right in with a full example and add an explainer below:

<label for="main-course-select">
  Main Course
</label>
<select name="main_course" id="main-course-select">
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <!-- This wrapper is for some extra styling -->
  <div class="menu-options">
    <!-- placeholder text -->
    <option value="" selected disabled>Select a main course...</option>
    <optgroup label="Meat & Poultry">
      <option value="filet_mignon">Filet Mignon
        <span class="info">Served with potato gratin</span>
      </option>
      <option value="rack_of_lamb">Rack of Lamb
        <span class="info">With mint & root vegetables</span>
      </option>
    </optgroup>
    <optgroup label="Fish">
      <option value="sea_bass">Pan-Seared Sea Bass
        <span class="info">With lemon-caper sauce</span>
      </option>
    </optgroup>
    <optgroup label="Vegetarian">
      <option value="risotto_funghi">Mushroom Risotto
        <span class="info">With truffle & parmesan</span>
      </option>
      <option value="gnocchi">Handmade Gnocchi
        <span class="info">With sage butter sauce</span>
      </option>
    </optgroup>
  </div>
</select>

A few things are noteworthy here:

We added a <label> for our <select>, which is just good practice, especially for assistive technology users.
We will be using the <selectedcontent> element to style our selected option’s content.
We created a placeholder text for our select with an option that is both disabled and selected
We categorized our dishes into <optgroup>, giving each a distinct label
Inside our options, we have an extra <span> that will be used for some smaller text
We have an extra .wrapper div-element, which we’ll need for styling

Note that the date in this select is different from in the final demo, but I wanted to keep the text of the options a bit shorter in the article.

The base styles for all browsers

The first thing we want to do is create our base styles. To keep things simple, we’ll just add the opt-in somewhere separately:

select {
  appearance: none;
  @supports (appearance: base-select) {
    &,
    &::picker(select) {
      appearance: base-select;
    }
  }
}

And first, let’s create our select, there are a bunch of variables I’m using as constants, they are mainly for colours, and borders, but I’ll add these here for completeness:

 :root {
   --text-dark: #5a4a42;
   --text-heading: #8c6b4f;
   --border: #dcd3c9;
   --border-accent: #e0cda9;
   --border-hover: #8c6b4f;
   --font-heading: "Fleur De Leah", cursive;
   --font-body: "Lato", sans-serif;
   --card-max-width: 700px;
   --border-radius: 8px;
}

And here is the styling of that <select>:

select {
  width: 100%;
  padding: 1rem 2.5rem 1rem 1rem;
  border: 2px solid var(--border);
  border-radius: var(--border-radius);
  background-color: var(--card-bg);
  background-image: url("chevron-down.svg");
  background-repeat: no-repeat;
  background-position: right 1rem center;
  background-size: 20px;
  font-family: var(--font-body);
  font-size: 1rem;
  font-weight: 700;
  color: var(--text-dark);
  cursor: pointer;
  transition: border-color 0.3s ease;
  &:where(:hover, :focus) {
    border-color: var(--border-hover);
  }
}

This bit of default styling gives us a good starting point and will be available in all browsers:

Withs some extra styling on the label this is that result:

But yes, when opened we get our default picker as a fallback, still pretty usable and slick to start with.

Time go custom!

The next part is best to be wrapped inside the @supports query. I’ll break it down step by step:

body:has(select:open) {
  overflow: hidden;
}

This is quite the heavy selector, but we’ll be needing it as we want our ::picker(select) to take the full height of the screen.

select {
  padding: 1rem 2.5rem;
  justify-content: center;
  &::picker-icon {
    display: none;
  }
  ::checkmark {
    display: none;
  }
}

We are updating the paddings, removing the ::picker-icon, and hide the :checkmark inside of our <select>.

These are all things we’ve done before, but we’re going somewhere new in the next bit.

::picker(select) {
  gap: 3vw;
  position-anchor: --body;
  inset: 0;
  width: 100%;
  height: 100%;
  max-height: 100%;
  opacity: 0;
  transition: opacity, translate, display, overlay;
  transition-duration: 0.4s;
  transition-timing-function: ease-in-out;
  transition-behavior: allow-discrete;
}

There are a few things going on here with the ::picker(select). We’re going to give it a “fake” position-anchor (or you could actually give your <body> that anchor-name if you want to…). This allows us to set our picker fixed to the root element instead of the select itself, allowing us to create something full width and height.

We’ll also set up a smooth animation. The picker starts out invisible (opacity: 0) and then we’ll transition its opacity to fade it in and its translate property to move it into place with @starting-style later on. To make sure the top-layer transition works perfectly, we also animate two discrete properties: display and overlay.

The open state for that transition will be the following:

select:open::picker(select) {
  opacity: 1;
  translate: 0;
  @starting-style {
    opacity: 0;
    translate: 0 20vh;
  }
}

Next up, I wanted my options to flow in two columns. I did this with CSS columns and a simple media query, but feel free to give it your own spin. This is why we needed the extra wrapper; Otherwise, we would run into overflow issues:

.menu-options {
  @media (width > 600px) {
    columns: 2;
    columns-width: 45vw;
  }
}

Styling the optgroup and options

All that is left to do is some basic styling.

Just as our options we can now style our optgroup:

optgroup {
  padding: 1.5rem 1.5rem 0.5rem;
  margin-top: 1rem;
  border-bottom: 2px solid var(--border-accent);
  font-family: var(--font-heading);
  font-size: 2.25rem;
  font-weight: 400;
  text-align: center;
  color: var(--text-heading);
  cursor: default;
  &:first-of-type {
    margin-top: 0;
  }
}

That’s it! I did some extra things for the options, which might be interesting. I will remove the presentation styles in the next example. Feel free to see the demo for those:

option {
  display: flex;
  flex-direction: column;
  white-space: normal;
  break-inside: avoid;
  &:first-of-type {
    break-before: avoid;
  }
  &:disabled {
    display: none;
  }
}

These are some of the extra-special things I did with the option. First, we set the white-space to normal again, countering the UA-stylesheet. We do not want a break with the CSS column inside the options, so this is why we have break-inside: avoid; in there.

For cleaner presentation, we also don’t want an <optgroup> text separated from he first option, which is why the first option in an option group is set to break-before: avoid.

We also hide our disabled placeholder select from the select itself.

To finalize, we style our extra .info a bit and center our <selectedcontent> to match the styles:

.info {
  display: block;
  margin-top: 0.25rem;
  font-size: 0.9rem;
  font-weight: 400;
  font-style: italic;
  text-align: center;
  color: var(--text-heading);
}

selectedcontent {
  text-align: center;
}

Here is that final demo again.

See the Pen An actual Select Menu with optgroups by utilitybend (@utilitybend) on CodePen.

More fun with option groups

Another idea I did with <optgroup> is the following:

See the Pen Customizable select optgroup by utilitybend (@utilitybend) on CodePen.

Based on my previous potion selector demo, I went with a radial theme. In this example, the <optgroup> text is only visible when hovering. This is the trick behind this:

optgroup {
  &::after {
    content: attr(value);
    color: var(--text-color);
    position: absolute;
    opacity: 0;
  }
  &:hover,
  &:has(option:hover),
  &:has(option:focus-visible) {
    &::after {
      opacity: 1;
    }
  }
}

What happens here is that we don’t visually show the optgroup but instead use an ::after pseudo-element that uses the attr() syntax to contain the value op the <optgroup> inside the content property. Next up, we show this pseudo-element when the <optgroup> is hovered, or an option inside that optgroup is hovered/focused.

Conclusion

I can’t wait to see what people will do with this new power where we can also style the <optgroup>. I always had some sort of country selector in mind where the optgroup, for example, could be the layout of Europe, and the countries could be options. Feel free to steal that idea, I’d love to see it!

This almost concludes my series on the customizable select for now. I will be doing one more in a week or so, just to quickly highlight some other demos I created without going in-depth, because they do deserve a place on this blog.

The customizable select - Part four: Scroll snapping, state queries, monster hunter, and gamification

Brecht De Ruyte — Fri, 20 Jun 2025 00:00:00 GMT

This is a long one… and I still wasn’t able to cover everything. So I can understand if you want to jump to some sections.

Setting up the HTML
CSS setup
Adding the gamification with JavaScript
Accessibility: context is everything here
Conclusion

For those that just want to play around with it, here is that final result already 😉

See the Pen Monster Hunter World item wheel with customizable select by utilitybend (@utilitybend) on CodePen.

The idea: Monster Hunter games

I am a big fan of the Monster Hunter games, with “Monster Hunter Wilds” being the last in the series. I started this demo while waiting for that last entry to be released, so visually it has more of a Monster Hunter Wold vibe (the previous version). If you are clueless about what I’m going on about, here is a video that shows the UI in the game:

I also added a little screenshot for easy reference:

Where we left off…

In the previous parts, we’ve covered basic styling, radial positioning, and sticky options. This time, we’re going horizontal and focusing on keystrokes and making it draggable. It’s a different idea, but I think the result turned out really cool. It’s quite a long demo so I won’t be going over every border or style in detail. Instead, I’d like to highlight a few parts on how this actually works.

Setting up our HTML

Let’s start with the structure. It’s a bit more complex than our previous demos because we need scroll arrows and an extra frame, more about those later on.

<select aria-label="Monster Hunter items">
  <button class="trigger">
    <selectedcontent></selectedcontent>
  </button>
  <div class="frame"></div>
  <div class="items" id="itemlist">
    <button class="arrow arrow-left" type="button">
      <!-- Left arrow SVG -->
    </button>
    <option>
      <div class="item">
        <svg class="icon" aria-hidden="true">
          <use xlink:href="#potion" />
        </svg>
        <div class="title">Potion</div>
        <div class="amount">10</div>
      </div>
    </option>
    <!-- More options... -->
    <button class="arrow arrow-right" type="button">
      <!-- Right arrow SVG -->
    </button>
  </div>
</select>

The options

The options consist out of a few elements that we’re going to position differently. Each of the options will hold an icon with the image of an item, a .title containing a name and an .amount containing how many items are left of the type.

The extra elements

There are few extra divs to found here, more info on them below but for a fast read, here is a run down of why certain elements are added:

The .frame is used because we want the items to be visually dragged behind the frame, the item in the frame is the focussed item which will be selected
The extra .items element is what we’ll need to set up our scroll-snapping
The arrows are for single pointer modality

We are taking things a bit further here with the .frame element and the scroll arrows. Notice that I’m adding the type="button" on the scroll arrows as well as I don’t want the opt-in to think of this as a trigger button. The arrows are added because I wanted to make this accessible as possible by at least offering a single pointer modality. More on the accessibility part of things later on because it does raise a few questions.

Basic CSS setup and not so progressive enhancement…

For this demo I didn’t really go the full progressive enhancement route. Don’t get me wrong, it’s still a fully functional select, it’s just not styled because I thought the CSS was already getting complicated enough. I still added a feature query tho.

First of all, let’s set some variables we’ll be using throughout this demo. They are pretty much self-explanatory, just your colors, borders, and sizes.

:root {
  --base-icon-size: 64px;
  --icon-size-wrap: 50px;
  --btn-bg: rgba(70 70 70 / 0.9);
  --border-color: #282929;
  --border-width: 4px;
}

Sizes to note:

The --base-icon-size will be the size of an option
The --icon-size-wrap will be the actual size of an icon.

Next up, it’s time to set our opt-in. The following part of the CSS setup will be wrapped in a feature query:

@supports (appearance: base-select) {
  select,
  ::picker(select) {
    appearance: base-select;
  }
  /* Next parts in here */
}

Ok, let’s start with some of that basic select styling:

select {
  position: relative;
  display: flex;
  padding: 0;
  justify-content: center;
  anchor-name: --my-select;
  background: none;
  border: none;
  &::picker-icon {
    display: none;
  }
}

A few things are going on here. The first thing to notice is that the select is relatively positioned. The reason for this is that we’ll be placing some pseudo-elements on it later on. However, compared to my other demos, where I position the picker on top of the select, for this one, I am setting my custom anchor-name to the select element. We will be hanging a lot more items on the select, such as the .title and .amount, which is why we need that bit of extra control.

We’re also hiding the ::picker-icon again.

The borders and selectedcontent on open state

In the example UI, we see a bunch of borders. To create this kind of behavior, I wanted to add those to the open state of the select. Feel free to visit the example in detail to get the full styling of it. Another important thing that we wanted to do is that we don’t see the SVG in our <selectedcontent> when the select is :open, so we’ll make that one invisible as well.

select {
  /* previous styles */
  &:open {
    selectedcontent svg {
      opacity: 0;
    }
    /* The horizontal lines in our options */
    &::before,
    &::after {
 	  /* Border styles and positioning */
    }
  }
}

Creating the frame

This was the trickiest part to figure out. I wanted items to scroll under a frame, like they’re behind glass. The solution was to create two identical-looking elements, one of those will be our button holding the <selected> content, which I gave the .trigger class for convenience, the other one is the dedicated .frame element:

.trigger,
.frame {
  inline-size: var(--base-icon-size);
  aspect-ratio: 1;
  border: var(--border-width) solid var(--border-color);
  border-radius: 5px;
  &::before,
  &::after {
    position: absolute;
    inset-block-start: 40%;
    inset-inline: -17px auto;
    inline-size: 30px;
    aspect-ratio: 1;
    background: var(--border-color);
    clip-path: polygon(50% 0%, 80% 50%, 50% 100%, 20% 50%);
    content: "";
  }
  &::after {
    inset-inline: auto -17px;
  }
}

But, there is more, we’re going full anchoring in this demo by setting an anchor-name for the trigger button (--button) and for the frame (--frame). While also providing a bit of positioning. We also want a visible overflow on the trigger because we’re going to position some of the text in our <selectedcontent> outside of our <button>.

.trigger {
    anchor-name: --button;
    overflow: visible;
  }
  .frame {
    position: absolute;
    top: 0;
    left: 50%;
    z-index: 2;
    transform: translateX(-50%);
    anchor-name: --frame;
    pointer-events: none;
  }

The .trigger button is what we’ll see when the select is closed. The .frame sits on top with pointer-events: none so that we can drag through it. Those little diamond shapes hanging on the frame are made with pseudo-elements using a clip-path to give a bit more that MH World feeling.

Styling the picker and options

First thing we need to do is set the ::picker(select) to be anchored to the --button in this case and remove some of those UA-styles

::picker(select) {
  position-anchor: --button;
  left: anchor(center);
  top: calc(var(--base-icon-size) / -1);
  transform: translateX(-50%);
  padding: 0;
  background: transparent;
  border: 0;
}

Maybe not a bad idea to take a look at what we have now:

Ok, it still looks a bit messy, but we can see a few things happening: we see our double frames, our borders, and our texts. We almost got the complete setup. We have a bit of an offset for the frame, that is because we are using the icon size to calculate the top, this should be fixed when we position the text inside of our options.

Setting up the horizontal scrolling

We are once again using the --base-icon-size variable to calculate the width of our flex container. We are setting a scroll-snap on the x-axis and will remove the scrollbar for this example:

.items {
  display: flex;
  max-width: calc(var(--base-icon-size) * 5);
  padding: 0 calc(var(--base-icon-size) * 2);
  overflow-x: auto;
  scroll-snap-type: x mandatory;
  scroll-behavior: smooth;
  scrollbar-width: none;
}

That padding is also super important, it lets the first and last items scroll to the center. Without it, they’d get stuck at the edges.

Styling our options

Without completely showing every style of the options. In essence, we decide to set the option to have a relative position and hide the checkmark.

option {
  position: relative;
  /* Look and feel styles */
  &::checkmark {
    display: none;
  }
}

Scroll-state queries for snapped position

The SVGs inside start small and scale up when they are snapped, just as in the example. This is a great idea for scroll-state queries. I have written a small guide to scroll-state queries in the past, but for this demo, this is the gist of it:

First, we set the SVG in the option to have a smaller size overall:

option svg {
  scale: 0.6;
  transition: scale 0.2s ease-out;
}

If your browser supports scroll-state container queries, we can detect when an item snaps:

option {
  @supports (container-type: scroll-state) {
    container-type: scroll-state;
  }
  svg {
    @supports (container-type: scroll-state) {
      @container scroll-state(snapped: inline) {
        scale: 1;
      }
    }
  }
}

This is pretty experimental stuff, but when it works, it’s really smooth. The item scales up automatically when it snaps to center.

That’s it for our picker and options styling. This is what we have so far

We got some scrolling here, it’s great! But we still have to handle the text in those options.

Adding the title and amount displays

Using anchor positioning again, we can place the title and amount relative to our select:

.title {
  position: fixed;
  position-anchor: --my-select;
  top: anchor(bottom);
  left: anchor(center);
  transform: translate(-50%, 15px);
  /* presentation styles */
}

The amount gets positioned in the corner:

.amount {
  position: fixed;
  position-anchor: --my-select;
  top: anchor(bottom);
  right: anchor(center);
  /* Presentation styles */
}

Adding the arrows

It’s a great idea to add some arrows in here to scroll the pane (more on the JS side of things later on). The styling of the arrows is very straightforward and just uses absolute positioning based on its select container.

.arrow {
    position: absolute;
     /* Presentation styles, positioning and hover/focus states */
 }

And with some added presentation styles in general, we already have our design in order:

Now all that’s left for us is to add that game functionality. Because as it stands now, it’s not really usable.

Let’s recap how this works so far:

We can open the select and use our left / right arrow to navigate the options
We actually broke select behavior a bit because of this and our up and down arrow keys do not work anymore… this is why we need some JS.

Adding our gamification behavior with JavaScript

First, let’s set up the variables we’ll need to track everything:

let isDragging = false;
let dragStartX = 0;
let scrollStartX = 0;
let focussedElement;
const leftArrow = document.querySelector(".arrow-left");
const rightArrow = document.querySelector(".arrow-right");

The isDragging boolean helps us know when someone is actively dragging. The dragStartX and scrollStartX variables store where the drag started - both the mouse position and the current scroll position. We’ll need these to calculate how far to scroll as the user drags.

The focussedElement variable is crucial for keyboard navigation, it keeps track of which item should be selected when the user presses Enter.

Handling the drag behavior

The drag functionality is split into three functions:

function handleDragStart(event) {
  event.preventDefault();
  isDragging = true;
  itemlist.classList.add("dragging");
  dragStartX = event.pageX - itemlist.offsetLeft;
  scrollStartX = itemlist.scrollLeft;
}

When the user starts dragging, we prevent the browser’s default drag behavior (which would try to drag the element itself). We set our dragging flag to true and added a .dragging class to the container. This class disables scroll-snap in our CSS, so dragging feels smooth instead of snappy.

For this, in our CSS the following is added:

.items {
  /* Previous code */
  &.dragging {
    scroll-snap-type: none;
    cursor: ew-resize;
    scroll-behavior: auto;
  }
}

The event.pageX - itemlist.offsetLeft calculation gives us the mouse position relative to our scroll container, and itemlist.scrollLeft tells us where we currently are in the scroll.

function handleDragMove(event) {
  if (!isDragging) return;
  event.preventDefault();
  const currentX = event.pageX - itemlist.offsetLeft;
  const scrollDistance = (currentX - dragStartX) * 2; r
  itemlist.scrollLeft = scrollStartX - scrollDistance;
}

During the drag, we calculate how far the mouse has moved from the start position. The * 2 multiplier makes the scrolling feel faster and more responsive - without it, you’d have to drag really far to scroll a little bit.

function handleDragEnd() {
  isDragging = false;
  itemlist.classList.remove("dragging");
  updateArrowVisibility();
}

When the drag ends, we clean up: set the flag to false, remove the dragging class (which re-enables scroll-snap), and update the arrow visibility.

let isDragging = false;
let dragStartX = 0;
let scrollStartX = 0;

function handleDragStart(event) {
  event.preventDefault();
  isDragging = true;
  itemlist.classList.add("dragging");
  dragStartX = event.pageX - itemlist.offsetLeft;
  scrollStartX = itemlist.scrollLeft;
}

function handleDragMove(event) {
  if (!isDragging) return;
  event.preventDefault();
  const currentX = event.pageX - itemlist.offsetLeft;
  const scrollDistance = (currentX - dragStartX) * 2;
  itemlist.scrollLeft = scrollStartX - scrollDistance;
}

When dragging, we add a class that disables scroll-snap so it feels natural. When you let go, snap kicks back in.

Since we broke the natural behavior of arrow keys in a select when using the up/down keys, we are going to re-add them using JavaScript:

function handleArrowKey(event) {
  if (event.key === "ArrowUp") {
    event.preventDefault();
    itemlist.scrollLeft -= 40;
  } else if (event.key === "ArrowDown") {
    event.preventDefault();
    itemlist.scrollLeft += 40;
  } else {
    return;
  }
}

The magic of scrollsnapchange

Here’s where things get really interesting, or rather, the magic of this demo starts. There’s a new event called scrollsnapchange that fires when an item snaps into position:

itemlist.addEventListener("scrollsnapchange", (event) => {
  if (!isDragging) {
    event.snapTargetInline.focus();
    focussedElement = event.snapTargetInline;
    delayedUpdateArrowVisibility();
  }
});

When an item snaps to center, event.snapTargetInline gives us that specific element. We set focus on it so that if the user presses Enter, that item gets selected. We also store it in focussedElement for later use.

The if (!isDragging) check is important - we don’t want to mess with focus while someone is actively dragging around.

Handling clicks outside the picker

function handleOutsideClick(event) {
  if (!event.target.closest("#itemlist")) {
    if (focussedElement) {
      focussedElement.selected = true;
    }
  }
}

Since we do not trigger the selection of an item on click but rather based on the center of the frame, we had to add this. If someone clicks outside the item list, we automatically select whatever item is currently focused.

Managing the scroll arrows

The arrow buttons need to be disabled when you can’t scroll further in that direction:

function updateArrowVisibility() {
  const isAtStart = itemlist.scrollLeft === 0;
  const isAtEnd = itemlist.scrollWidth - itemlist.clientWidth <= itemlist.scrollLeft;
  leftArrow.disabled = isAtStart;
  rightArrow.disabled = isAtEnd;
  leftArrow.classList.toggle("disabled", isAtStart);
  rightArrow.classList.toggle("disabled", isAtEnd);
}

We check if we’re at the very beginning (scrollLeft === 0) or at the end (when scrollLeft equals the maximum possible scroll distance). Then we disable the appropriate arrows and add a .disabled state.

The delaying trick (lazy haxorz)

Ok, this is a bit lazy on my part, I agree…

When someone clicks an arrow or scrolls, we temporarily disable both arrows for 300ms. This prevents rapid clicking while the smooth scroll animation is happening. The 300ms sort of matches our CSS scroll-behavior: smooth timing, this is not an exact science…

function delayedUpdateArrowVisibility() {
  leftArrow.disabled = true;
  rightArrow.disabled = true;
  setTimeout(updateArrowVisibility, 300);
}

Centering focused elements

This function makes sure that when you open the ::picker(select), the focused item scrolls to the center. We calculate the center point of both the container and the focused element, then scroll by the difference.

function scrollToFocusedElement() {
  const focussedOption = document.activeElement.tagName === "OPTION";
  if (!focussedOption) return;

  const focussedElement = document.activeElement;
  const container = focussedElement.closest("#itemlist");
  if (!container) return;

  const containerRect = container.getBoundingClientRect();
  const focussedElementRect = focussedElement.getBoundingClientRect();

  const containerCenterX = (containerRect.left + containerRect.right) / 2;
  const focussedElementCenterX = (focussedElementRect.left + focussedElementRect.right) / 2;

  const offset = focussedElementCenterX - containerCenterX;

  container.scrollBy({
    left: offset,
    behavior: "smooth"
  });
}

Wiring it all up

Finally, we attach all our event listeners:

itemlist.addEventListener("mousedown", handleDragStart);
itemlist.addEventListener("mousemove", handleDragMove);
itemlist.addEventListener("mouseup", handleDragEnd);
itemlist.addEventListener("mouseleave", handleDragEnd);
itemlist.addEventListener("keydown", handleArrowKey);
document.addEventListener("click", handleOutsideClick);
leftArrow.addEventListener("click", () => scrollItemList("left", 40));
rightArrow.addEventListener("click", () => scrollItemList("right", 40));

Accessibility: context is everything here

This is all about context, right? From a screen-reader perspective, I noticed that everything is still okay-ish and that there are enough ways to navigate the element. That being said, this is not the behavior a user would expect from a select, using the snap for selecting an item.

So yes, this UI can make sense in a browser game, because in games, UI needs to be learned a bit. But for your everyday website, this might not be your accessible option as it might cause your users a bit of frustration. Context is everything!

Conclusion

This demo definitely pushes the boundaries of what people expect from a select element. While it works great with keyboard navigation and screen readers, it’s not your typical form control. I’d recommend being careful about when you use something like this. It’s cool, but it might confuse users who expect a normal dropdown.

That said, I had a blast building it, and I think it shows how creative we can get with these new CSS features. The combination of customizable select, anchor positioning, and scroll-snap creates possibilities I wouldn’t have imagined a few years ago.

Here is that final result again:

See the Pen Monster Hunter World item wheel with customizable select by utilitybend (@utilitybend) on CodePen.

CSS Day 2025, a little story by a little man on quite a big stage

Brecht De Ruyte — Fri, 13 Jun 2025 00:00:00 GMT

Silly, isn’t it? Some people struggle to speak in front of a group. I know a thing or two about that. No, I don’t want to overly dramatize everything, but back in 2023, I was lacking sleep for days just because I had to speak to 60 people at a local meetup. It was never my intention to be “a speaker”; I just wanted to evolve as a human being, take on a challenge, try something… different. Fastforward to 2025, a few conferences later, it has gotten a bit better. I love doing the conferences and talking to people, getting inspired by people. But this experience was a bit different, because this time I would be speaking at the conference I attended as much as possible myself… the conference I look forward to all year as an attendee.

CSS - long time to go - Day

The nerves didn’t change all that much, if I’m honest. Instead, the days turned into hours and then into minutes. At least for most conferences, but then…

I remember getting the message from PPK asking me to speak at CSS Day. I recall being shocked, honored, but I wasn’t sure. Me? Really? The next thing that happened was I sent a panicky text to Bramus: “CSS Day asked me, should I do this? Will you help me?”

A nice little nudge by him, and I answered confidently: I’ll do it! (while dying of fear inside)

So, I prepped my slides ( a lot!) and did a few other conferences, tried to spice those up a little with snippets of my CSS Day talk, and gave a test run of the full talk at a local meetup Devs.gent. All went great, and I got some feedback on my slides from Bramus, which I fixed (mostly involved me using outdated browser icons). I was ready, I didn’t feel ready, but there wasn’t much more I could do.

Two presentations in two countries in one week

What didn’t make things easier was doing another presentation the same week on Tuesday. Speaking at the international PHP conference by DevMio in Berlin about popovers and invokers. Berlin is a beautiful city, and I enjoyed that conference. The organisation was nice, the hotel splendid, and so was the speakers’ dinner. But I do remember that after my presentation, the only thing on my mind was getting on that plane to Amsterdam and doing the talk for CSS Day. I practiced in my hotel room in Berlin once more and then left early morning for Amsterdam.

CSS Pre-Day

When the plane touched the Netherlands’ soil, I quickly went to the hotel. I really wanted to go to the pre-event to see the presentations by Nils Binder and Miriam Suzanne.

After a sweaty, exhausted dash, I burst into the lobby… and then… Standing right there were Chris Coyier and John Allsopp, two absolute heroes in the web development world! I managed a “hello,” trying desperately to shove my inner, screaming fanboy back down into my gut and play it cool. First impression: Such nice people!

Unfortunately, after dropping off my stuff, doing a quick refresh, I was a little too late for the event, and I entered the pre-event just at the end of Nils Binder’s talk. If you are reading this, Nils… I do hope to see it someday! I did pick up the presentation by Miriam. I guess that I was not the only one doing two presentations in one week. Even more so, the one Miriam did was completely different and based on an article about tech being political. It’s one of those topics that needs to be told, but the world would be better if there weren’t a need for this presentation in the first place. I believe Miriam would agree with that. I love every bit of the way this was presented with a truthful and open mindset, and without needless shouting.

It was there that I also got to meet up with Bramus, Quentin, Amit, Roland, Jeremy, Josh, and so many others as well. And so that event ended, and we went on to…

CSS Boating

You know what else gets me nervous? Boats! I have some serious motion sickness issues, which can get amplified in closed spaces. The speaker’s dinner was on a boat, and I’ll be completely honest, the first 20 minutes felt really bad. But thanks to some chats (especially with Nils, thank you, you calmed me in some way), I was able to enjoy a very nice dinner and a few drinks. I met all the speakers there and the organisation, but also some other heroes such as Una Kravets, Julia Miocene, Penelope Mclachlan, and Michelle Barker. You can tell it from the boat as well, the CSS world has a really beautiful blend of different nationalities and genders. Yes, it can be better in various ways, but I do think there is a strong foundation here, and more tech events should be like this.

I thought the hardest part of the day was still to come; my talk was going to be the next day. I wouldn’t possibly be able to sleep. But guess what, after a plane, the rush, the “boatstress”, I went to bed and almost 8 hours later…

CSS D-Day

There was a bit of sunlight in my beautiful princess room, and I felt the comfy sheets on top of me as a nice hug. While I slowly awakened, I did a stretch and here are my first thoughts of the morning:

O wow, I slept fantastically… wait, where am I now? Right, Amsterdam. So nice to see everyone yesterday, that was so cool. Oh, and I didn’t get sick, what was I even worried about, I’m such a tool haha…. So, I need to speak today…

Fuuuuuuck, it’s today! shit shit shit!
(and so on… sorry for the language readers, I don’t usually do this, but this is the truth)

And there it was, I never felt so awake, so fast without a drop of coffee. I was so stressed that I even misread the starting time of the conference and came way too early. Luckily, Bramus was there setting up the Google CSS Help desk, so I could nervously annoy him a bit while he was setting things up.

But then it hit me, calm… out of nowhere, I felt calm again. It’s crazy how the human brain goes. During the whole morning, watching great talks by Adam, John, and Miriam, I constantly felt ups and downs, and I had no idea how this would turn out.

Noon struck, my belly filled with one croissant and 4 spoons of rice, a quick laptop and soundcheck done, it was almost time for me to go on. First, there was a presentation by Cyd Stumpel, who creates some amazing animations and designs on the web. But truth be told, even though that talk was really good, it will be the one I’ll have to re-watch later on; My focus was shifting towards presenting. Sorry about that, Cyd, I’m sure she’ll understand.

So here we go, standing next to that stage, microphone on, and these are my thoughts:

Will I be breathing too loudly? Ok, Cyd is coming down with a big smile! I hope I’ll feel the same way. Oh, here we go, let’s set the laptop up. Stephen is starting to announce me, he’s such a great guy… Wow, he pronounced my name like a pro, that’s crazy! The announcement is done, my heart is racing, people start clapping, and then this happened:

Calmth…

I was there, no turning back, I told my story as I wanted to tell it, a few misspoken lines, a few mispronunciations, carefully looking if people were nodding, maybe having a little laugh with my dumb jokes. Looking for familiar faces (not finding Una, who was staring straight at me, I heard afterwards). Right in front of me, a whole line of people, listening to me, while I feel I should be listening to them. A lot went through my mind while speaking, but I had found my pace, my calm, dare I even say, my fun?

I think I told my story about the customizable select, from how you can use it today as a progressive enhancement to some of the more experimental ideas I created with it. Showing how those new CSS capabilities can work together with this new feature. While also reminding people to have a bit of fun.

So, I do have a lot of nerves, but at the same time, I don’t feel impostor syndrome, even though it might sound like it. I know I did the work, I did follow the meetings, created those demo’s and have a passion for it that can’t be faked. But still, the idea of standing in front of so many people, you want to give them value for their money, you want them to learn something, as well as maybe bring them a little bit of joy. And I truly care about that, and from the moment I would stop caring, I’d better stop doing this. This is important every time… Whether it’s a 20 people meetup or a filled CSS Church. I also learned that people can tell if you prepared something very well, and that an audience is usually more cheerful to a nervous person who came prepared instead of a confident person who just flung some slides together. And that’s the cool thing about CSS Day… There is always so much quality!

I was followed up by Rachel Andrew and later by Brad and Ian Frost. All those names are just stellar, I can’t believe I was there on a stage, even now, it still feels like a dream.

After that, we had some food, got a couple of drinks. I even met someone who came from Japan for CSS Day, can you believe it?

The next night, I didn’t sleep at all; I was still processing this day. Dead tired, I went on the next day… Coffee helps.

CSS Hacking (the other scary moment)

So, I might do a blog post on the talks, because this day was completely filled with fantastic presentations. But on day two, I wanted to highlight a funny moment that shows how cool CSS Day can be, and at the same time, it was probably the scariest thing for me besides presenting.

While sitting next to Chris Coyier, I noticed he was hacking in a CodePen, and I quickly noticed it was a customizable select! So I asked what he was doing. Chris wanted to create some stagger effect and was trying some things out. There was currently a break going on, so I took my laptop and started hacking on it next to him. A few seconds later, Una jumped into the party. So here we are, trying to hack on that select, with 3 people. I’m not going to spoil it, but it was a cool effect, and suddenly I got a little breakthrough on how we could manage it. And then it happened, what started as 3 devs doing a little competition on hacking a select turned quickly into a collaboration with me on a laptop trying to understand what Chris is going for, and Una standing behind me screaming out of enthusiasm: YOU FORGOT THE SEMICOLON!

I had no idea you could have such a nerve-wrecking and beautiful moment at the same time! It might not read as nice as the moment was, but this is one of those characteristics of Una that I think is just awesome. When she gets excited about a breakthrough, you’ll know it.

So many lovely chats… so many lovely people. Still gotta work on my selfie skills…

But it shows how cool CSS Day is. How cool my heroes are and how passionate they are about the web. How welcoming they are, and supportive. What PPK created is more than a conference… It’s a mindset, a place where people might have a different culture, where people challenge each other in ideology for the web, but can still work together towards making that web a more beautiful place. This is why I went 6 times to CSS Day, it’s not just about the tech, it’s about the people as well.

Keep supporting these conferences by buying tickets!

CSS Café

After a night going out for way too long, we had some CSS Café in the morning. The post-meetup where only the real nerds go to and stay for a bit longer xD

Really, a fantastic initiative. And a very cool closing moment for CSS Day. Unfortunately, I had to leave early and wasn’t able to get the full experience. I did manage to get a preview from Julia on the talk she was going to present.

CSS Day

I did wonder if I should write this story… But I think it should be heard. For those who, just like me, have a hard time scraping together the courage or just don’t know where to begin. Many of us have a story to tell, whether that is a technical web story or something completely else. And even though I’m still an absolute beginner in this, I believe it’s worth it. These few days will be locked in my heart, together with some of the greatest memories. I hope this article will help some a bit more than the AI-generated: “here are 10 tips to get over stage fright”. Because - in the end -, what you need to do… is “take the leap”.

This was a time of joy, a rollercoaster of emotions. Not afraid to admit here that I had some tears of joy.

To everyone involved, to everyone I chatted with, to all of those who were patient with me! For your acceptance, for your jokes, for your laughs. There is only one more thing to say.

Thank you, and see you next year!

The customizable select - Part three: Sticky Options

Brecht De Ruyte — Tue, 27 May 2025 00:00:00 GMT

Quick recap

In the previous part, I showed how we can use anchor positioning to place our picker holding our options on top of the select itself. We will be re-using this idea, but with a twist! After all, anchoring is part of Interop 2025, so we’d better get acquainted with it as much as possible.

The idea for this is to use the :checked pseudo-class of an option to drag it right to the center to create a fun experience.

If you have been following this series from the start, you know that I like to live in a real world where I just can’t ship an unstyled select for browsers that don’t support this feature. So this example will also have somewhat of a progressive enhancement ideology.

This is what we’ll be creating:

Your browser does not support the video tag.

The setup of our emoji picker

The HTML for this example is pretty straightforward. We won’t even need the <selectecontent> element for this one. This is the main setup:

<label for="mood-picker" class="inclusively-hidden">Select a mood</label>
<select id="mood-picker">
  <div class="items">
    <option>👍</option>
    <option>😂</option>
    <option>😍</option>
    <option>😢</option>
    <option>😡</option>
  </div>
</select>

This is a pretty straightforward select. Note that I added a label here with the class .inclusively-hidden. I’m going to visually hide my label, but keep it available for screen readers. It’s perfefctly ok to keep this label visible, I’m just doing it to pretty my demo a bit. Still I wanted to keep the label there as a reminder that we should label our form elements… always.

This is how you can do this, if you want to do the same:

.inclusively-hidden {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

Ok, our HTML is set, let’s start by creating some of the groundwork of our customizable select.

We will be needing two colors which I will add in variables, a basic background color and a selected color. We will be transitioning to a width: auto;. Thanks to interpolate-size: allow-keywords, this has become a possibility and can be used as a progressive enhancement as well. There is a way to do this individually with cal-size(), but I’d like to take the lazy route for this one by adding the following to the root of my CSS:

:root {
  --selected-color: oklch(99% 0.44 280);
  --light-color: oklch(90% 0.49 269);

  @supports (interpolate-size: allow-keywords) {
    interpolate-size: allow-keywords;
  }
}

This will allow us to animate from, for example, a width: 64px to width: auto. We’ll circle back to this later on, but first, let’s set up some of that basic select styling. Remember, I’m first styling for every browser before we get to the main dish:

select {
  appearance: none;
  display: flex;
  place-items: center;
  justify-content: center;
  width: 64px;
  height: 64px;
  padding: 0;
  border: 0;
  border-radius: 50%;
  font-size: 2rem;
  line-height: 1;
  text-align: center;
  text-align-last: center;
  background: var(--selected-color);
  }

This would currently result in the following for every browser:

But when you click it, you get the default picker:

The only special fix here is the text-align-last property, which is used to center our select’s content for Safari. Ok, we got a nice and solid foundation, let’s get going to our select with sticky options.

Opting in and positioning our ::picker(select)

First, we want to create our opt-in to the customizable select and sprinkle a nice little anchor positioning on top, to place our ::picker(select) above the select. I am also directly hiding the ::picker-icon pseudo-element, we don’t really want it for this demo:

select {
  /* ... */
  @supports (appearance: base-select) {
    appearance: base-select;
    &::picker-icon {
      display: none;
    }
  }
}

/* For easy tinkering, I wrap the whole custom shebang in a new feature query */
@supports (appearance: base-select) {
  select::picker(select) {
    appearance: base-select;
    inset-block: anchor(top) anchor(bottom);
    width: 64px;
    height: 64px;
    overflow: clip;
    padding: 0;
    border: 0;
    background: var(--light-color);
    border-radius: 60px;
  }
}

There are a few things going on here. By using the anchor functions, I am placing the picker on top of my select, clipping overflow, and giving it the same size as the select itself. This is the setup for magic to happen.

Why do we use anchor functions for our positioning?

The ::picker(select) is inside the top-layer, located outside of the document flow. We don’t really need to provide an anchor-name for this because the picker is automatically associated with the select button via CSS anchor positioning. This is why we are still using anchor functions to position the picker.

By now, you should have something like this:

Once again, notice how our options are on top of our select and completely visible. Now let’s add a bit of styling.

Styling the picker and options

For easy tinkering, what I would suggest is to remove the comment on our previously set width and height we’ve set on our select for now:

select::picker(select) {
  /* comment out these lines
  width: 64px;
  height: 64px;
  */
}

That way, we can see our options completely:

So let’s get to styling, first off, let us set the .items wrapper to flex our options:

select .items {
  display: flex;
  overflow: auto;
  scrollbar-width: none;
}

We are also hiding the scrollbar in this example as we don’t really want to see this peeping. The overflow needs to be set to auto for the sticky effect to happen later on.

Next up is for us to add a bit of styling to our options and hide that checkmark:

option {
  display: flex;
  align-items: center;
  font-size: 2rem;
  flex: 0 0 66px;
  width: 66px;
  height: 66px;
  line-height: 1;
  padding: 0 1rem;
  background: var(--light-color);
  transition: background 0.4s;
  cursor: pointer;
  &::checkmark {
    display: none;
  }
}

We are mainly just setting our options to be full height and set in the middle. I did however notice some pixel rounding issues from time to time, so I decided to make them a bit higher than the picker, because the overflow is clipped anyway, that’s perfectly fine here. Since the example works with rounded corners, we will also need to give our first and last-child a bit of a border-radius:

option {
/* Previous code */
  &:first-child {
    border-radius: 60px 0 0 60px;
  }
  &:last-child {
    border-radius: 0 60px 60px 0;
  }
}

We currently see how we want our select to be when expanded:

Now let’s uncomment the width and height of our picker again:

 select::picker(select) {
  /* uncomment out these lines */
  width: 64px;
  height: 64px;
}

Creating the open effect and sticky dragging of the checked option

We haven’t created an animation for our select to open up. I have some thoughts on this, so do read on after the code blocks.

Let’s update our picker to have a transition on width:

Note: Currently, there seems to be an issue on touch devices. There is a workaround for now by setting pointer-events only to trigger when the select is fully open. I will keep this article updated for progress on that part, and will also inform on my social when the issue would be fixed. So, currently the pointer-events hack is added.

select::picker(select) {
  /* Previous code */
  transition: width 0.5s ease-out, display 0.5s, overlay 0.5s, pointer-events 0.5s;
  transition-behavior: allow-discrete;
}

Let’s also set the final state of our open select and the @starting-style

select:open::picker(select) {
  display: flex;
  width: auto;
  pointer-events: auto;
  @starting-style {
    width: 64px;
    pointer-events: none;
  }
}

Because we’ve set interpolate-size: allow-keywords on our :root, we can transition from a fixed width to an auto width. Since the picker is inside the top-layer we have to set transition-behavior: allow-discrete to transition the overlay and display property, and use @starting-style for when that picker is opened.

Ok, our select opens smoothly and so the last piece of the puzzle is to add position: sticky to the :checked option

option {
  &:checked {
    position: sticky;
    background: var(--selected-color);
    inset-block: 0;
    inset-inline-end: 0;
    z-index: 1;
  }
}

We now have our “sticky options” effect, and I think it’s pretty cool that we can do this!

In the final demo, I also updated some hover animations for the options and some alternative on smaller window sizes. Do check it out:

See the Pen Customizable select with sticky option by utilitybend (@utilitybend) on CodePen.

At the current time, the demo seems to have some issues on mobile devices, something to look at for sure.

Some thoughts

I would never consider myself an accessibility expert, although sometimes I get the feeling I know more than some “experts” (If you’re reading my blog, chances are high you’re not the kind of person I’m referring to). But after some quick testing I did notice small nuances on how VoiceOver handles the menu items, sometimes I get a count (eg: item 1 of 5), sometimes I only get a general “5 items”. And this is why I’m not an expert, I test this, I notice the difference, but what is the real impact here? I think it’s an honest question. A user can surely navigate this example, and I think it makes sense, but inconsistencies are never a good thing. So, I’m certainly not red-flagging this as an accessibility hazard, but still, something to keep in mind.

Besides this concern… To quote Una recently at Google I/O, we are entering a golden age of UI.

It’s so cool that we can create these little fun experiences.

Oklchroma: an OKLCH color pattern generator that generates CSS variables

Brecht De Ruyte — Thu, 08 May 2025 00:00:00 GMT

If you are wondering about the presentation by Mathias Ott that inspired this, take a look here.

Naming my picker

I don’t have anything against Oklahoma, and I do hope naming this tool didn’t offend anyone. But if you are wondering for the rest of this article, how do I pronounce this thing - well, it’s “Oak-ul-kroh-muh.”. Naming things is hard…

Here you can see the Oklchroma tool in action

I won’t be going into code details on how I created this tool, mostly because I am in no way React-savy enough to be an educator on the matter. But if you are wondering, yes, the sliders, controls, everything except for the color magic itself, is React / Typescript. The repository is public if you want to see some bloated non-best-practice code.

The idea for an OKLCH pattern generator

The idea of this color picker is to have one color input that is then thrown into some calculations to create a color pattern. I believe a handpicked color pattern will always be far more superior to a mathematically generated one. It’s pretty neat that we can do this with CSS nowadays. The example shown in the presentation came in two-fold. First, Mathias stated that generating a pattern could be handled like this with CSS:

:root {
    --primary: oklch(56.6% 0.27 274);

    --primary-10: oklch(from var(--primary) 10% c h);
    --primary-20: oklch(from var(--primary) 20% c h);
    --primary-30: oklch(from var(--primary) 30% c h);
    --primary-40: oklch(from var(--primary) 40% c h);
    --primary-50: oklch(from var(--primary) 50% c h);
    --primary-60: oklch(from var(--primary) 60% c h);
    --primary-70: oklch(from var(--primary) 70% c h);
    --primary-80: oklch(from var(--primary) 80% c h);
    --primary-90: oklch(from var(--primary) 90% c h);
    --primary-100: oklch(from var(--primary) 100% c h);
}

Basic explanation of this syntax: The oklch() color function starts with an input color, which is specified right after the “from” keyword. Based on that input color, we can create a new output by adjusting the Lightness, Chroma, and Hue. In this first example, the lightness of the color changed.

But that was not the mind-blowing part. The colors generated in this first example do look a little bit flat. Usually, what we see in color patterns is that we can see some sort of curve, where, for example, the dark colors are really dark and the light ones are almost pale, while the middle is very vibrant. What happened next was really smart. By using a base value and the trigonometric sine() function, Matthias showed some sort of easing curve that would adjust the Chroma of the color.

:root {
  --primary: oklch(56.6% 0.27 270);
  --c-base: 0.05;

  --primary-10: oklch(
    from var(--primary) 10% calc(var(--c-base) + (sin(1 * pi) * c)) h
  );
  --primary-20: oklch(
    from var(--primary) 20% calc(var(--c-base) + (sin(0.9 * pi) * c)) h
  );
  --primary-30: oklch(
    from var(--primary) 30% calc(var(--c-base) + (sin(0.8 * pi) * c)) h
  );
  --primary-40: oklch(
    from var(--primary) 40% calc(var(--c-base) + (sin(0.7 * pi) * c)) h
  );
  /* ... */
}

Note: What is Chroma?
In short, the Chroma is not a percentage, it is a value between 0 and 0.37. This value represents the vividness of the color.

I thought this was a great idea, and I quickly started wondering how this would work with other color inputs, or how about absolutely mental base modifiers that extend the Chroma way beyond what’s normally possible? Because theoretically, the vividness of a color goes to infinity. I played around with it a few times, but never really created a tool for it at that point. But finally, after a long time, I started planning:

Must-haves

I wanted to re-create the output from the presentation, but also with a twitst. The primary objective was for people to easily copy the output.

My must-haves for this picker were the following:

Multiple color syntaxes as input
A way to easily copy the output CSS
Since I want an easy output, a way to rename the variables easily would be nice

Want-to-haves

This already seemed a cool thing, but I wondered: Can I actually turn this into a tool that I would want to use when creating a quick demo? Maybe even better, a tool that someone else wants to use from time to time. So then I thought, wouldn’t it be cool to create a system where people could share the pattern they created, or how about creating a full-fledged system.

Make people add multiple patterns
Make it so that url changes and there is a share link for it.
Make color inputs more fancy by color updating range sliders (Check the sRGB one as reference)
Light and dark theme!

They weren’t in my first prototype, but as I’m very late on doing a write-up about this, I can say they have been added. To be completely fair, this required me to go beyond my usual React skills and had a bit of help from a friend (an AI friend).

This is the part where it all became a bit “icky” for me. My skills were too few, and to be fair, I have a whole bunch of other things that I really want to learn before polishing this. The code became a bit more out of my control. So I decided to leave it there before going more into that rabbit hole.

While creating this, I added another feature that could be done with CSS in the future, changing the color of text of tab based on the picked color, while at the same time have a good color contrast, there are a few hacks for this already, but I kinda want to wait until we have the real thing, which brings me to the next thing…

Future additions

There are a few additions that I want to create. For example, I love that we can crank-up the Chroma beyond 0.37, but I should at least give a little warning in those cases that results can vary.

Add a warning when Chroma exceeds 0.37 based on the base-modifier
Add more CSS features to replace the JS I’ve written (such as the contrast checker)
Maybe do something with CSS functions and Mixins when that comes along?
Clean it up a bit
Maybe….just maybe give it a custom domain?

That’s pretty much it. I wonder what you think of it? It’s not often that I create little tools like this, but with my CSS knowledge, basic React skills, and a little bit of help from an AI friend, I was able to do this quite easily. It felt like the perfect combination regarding the amount of AI that went into it, just enhancing my capabilities as a developer instead of just basic “vibe coding”. But let’s not go into that debate right now.

Happy color picking!

The customizable select - Part two: Potions, anchoring, and radial shenanigans in CSS

Brecht De Ruyte — Tue, 15 Apr 2025 00:00:00 GMT

In the first part of this series, I never really said how many parts this series is going to be. To be honest, I don’t really know myself. Between the first article and now, I already had the inspiration for another article, this select capability is just so cool…

So, there will undoubtedly be parts 3 and 4, and I’m guessing a part 5 is also cooking somewhere in my brain. This part will be about a single demo, a radial select, and a potion picker with CSS. I don’t want to go back into history as I did in the first article, but it is worth mentioning that this is one of the very first demos I created with the customizable select, back when the initial idea was still a new element. However, I do believe that this demo also had a bit of a helpful contribution to the end product we have now, as it did expose some difficulties to browser engineers regarding animating options that overlap the select button while clicking. Look at me talking like I make a big difference… but really, I just loved experimenting and I’m happy it helped, even if it’s just that tiny little bit.

CSS Anchor positioning and the customizable select

CSS Anchor positioning is one of those features that I’m really excited about, what’s even more fantastic, is that it’s part of Interop 2025. I won’t be going into the full syntax of anchoring but will focus on some trickery specifically for this use case. (I also have written on anchor positioning before)

Where we left off…

In the previous article, we ended up with images inside of our options and used the new <selectecontent> element to show the checked option’s contents. We are going to keep building on this idea. This is what we’ll be making in the end:

For the rest of this article, I am going to presume you are already familiar with the intro on the customizable select. Ready? Let’s get to it!

The HTML of our potion selector

<select>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <div class="items">
    <option value="health">
      <div class="potion-holder">
        <svg class="icon icon-health" aria-hidden="true">
          <use xlink:href="#potion" />
        </svg>
      </div>
      <span>Health</span>
    </option>
    <option value="mana">
      <div class="potion-holder">
        <svg class="icon icon-mana" aria-hidden="true">
          <use xlink:href="#potion" />
        </svg>
      </div>
      <span>Mana</span>
    </option>
    <!-- and the options in this trend.. -->
  </div>
</select>

This is looking pretty much the same as the things we did previously. We have our <select> and inside of it, we added a <button> containing our <selectedcontent> element. Quick recap: The <selectedcontent> element will hold the full content of the current selected <option>.

Inside of every option, we’ll add an SVG that holds the image of a flask as well as a <span> containing the text of that option. Please note, that I’m adding aria-hidden="true" to these SVG’s as they are purely decorative in this example. The main difference here is that there is an extra wrapper around the options with the .item class, more on that later on.

The basic setup in CSS - variables and basic select styles

The first thing on the agenda for our custom select is to create some variables and make sure that we include this as a progressive enhancement. In my :root variables, I also did a bit of default styling to my body background, but I’m not covering this to stay on point. Here are the color names I used and the sizing:

:root {
  /* colors */
  --color-space: #282f44;
  --color-dark-liver: #453a49;
  --color-liver: #634570;
  --color-catawba: #6d3b47;
  --color-catawba-light: #8c516c;
  --color-lightest: #fafafa;
  /* sizing */
  --orb-size: 110px;
  --option-size: 80px;
  --circle-size: 320px;
}

The first thing we should handle is to create a bit of basic styling for browsers that do not support this feature yet. Once again, we are using the following system for this:

select {
  appearance: none;
  @supports (appearance: base-select) {
    &, &::picker(select) {
      appearance: base-select;
    }
  }
}

For the default styling, I want to set the pieces in play for our customized select as well. I think it’s rather nice to have a strong default. That way it becomes truly progressive enhancing instead of “graceful downgrading”. Here are the updated select styles and what we have so far. (info below the image)

select {
  appearance: none;
  display: flex;
  align-items: end;
  justify-content: center;
  text-align: center;
  text-align-last: center; /* Safari fix */
  border: 4px dashed var(--color-space);
  width: var(--orb-size);
  aspect-ratio: 1;
  padding-block: calc(var(--orb-size) / 2) 15px;
  border-radius: 50%;
  cursor: pointer;
  font-family: "Fondamento", cursive;
  box-shadow: inset 0 1px 1px #ccc, inset 0 -1px 1px #aaa, 0 2px 4px -3px #666;
  transition: box-shadow 0.3s ease-out, color 0.3s ease-out;
  color: var(--color-lightest);
  background-color: var(--color-dark-liver);
  &:is(:hover, :focus) {
    background-color: var(--color-liver);
    box-shadow: rgba(50, 50, 93, 0.25) 0px 30px 60px -12px inset,
      rgba(0, 0, 0, 0.3) 0px 18px 36px -18px inset;
  }
  @supports (appearance: base-select) {
    &, &::picker(select) {
      appearance: base-select;
    }
  }
}

This is a great starting point for what we want to achieve. It’s a nice little orb with a fun hover state. So, important here is that we set the width with our custom property. I used a pixel value in the variables, but this can surely become a container unit, viewport unit, or whichever you desire. The idea I have is that we want this to work as a calculation throughout the code (you’ll see more of that soon). The font I’m using for this demo is Fondomento, I thought it gave a rather nice touch to the theme. The rest of the code mostly contains padding, borders and an aspect ratio to keep things square (or round… in this case). I like to set cursor: pointer as well for selects, or is that just me?

So… it does look alright, but it could be nice to give it a bit of extra “oomph” for browsers that don’t support this feature and add a little background-image for the flask. So in the example, the following was added:

select {
   /* ...Previous code */
  background-image: url("potion.svg");
  background-repeat: no-repeat;
  background-position: center 12px;
  background-size: calc(var(--orb-size) / 4);
  /* Hover state and support query... */
}

I added a few background properties to position a flask in the center of the select. For demo purposes, I did not shorthand them in this article so that you can see what is going on more clearly, but in the final demo this became the following:

background: var(--color-dark-liver)
    url("potion.svg") center 12px /
    calc(var(--orb-size) / 4) no-repeat;

We now have our starting point:

Going custom: anchoring the ::picker(select) to our select element

Everything is set in place for us to create a fun experience. We already had our opting-in set with the following:

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

The way I see it, there are two ways to approach this, we could further CSS-nest everything inside of that select or we could start some new rules. I found the latter to be a bit cleaner, but this is of course subjective, and if you want to keep on nesting everything feel free to do so.

So below the previous code, I added a new line with a feature query and started working inside of that:

@supports (appearance: base-select) {
  select {
    padding-block: 0;
    background-image: none;
    &::picker-icon {
      display: none;
    }
    .icon {
      width: calc(var(--option-size) * 0.375);
      height: calc(var(--option-size) * 0.625);
      transform: rotate(20deg);
      transition: transform 0.15s;
    }
  }
}

What happens here? We removed the padding of our select, as we don’t need it for the custom version, and also removed that background-image we set earlier as the <selectedcontent> will hold the actual potion from our checked option, so we don’t need that background anyway. We also added some styling for our SVG’s in there, giving them a width and height based on the previously set --option-size custom property.

note that for the rest of this article, I won’t be repeating that feature query, we will be working inside of it for the rest of the time

Below our select, let’s style our picker:

::picker(select) {
  --rotation-divide: calc(180deg / 2);

  top: anchor(center);
  left: anchor(center);
  transform: translate(-50%, -50%);
  overflow: visible;
  transition: overlay 0.5s, display 0.5s;
  transition-behavior: allow-discrete;
  /*  Removing some UA styles */
  margin: 0;
  padding: 0;
  background: transparent;
  border: none;
}

First thing you see here is that we added a new custom property --rotation-divide, this is used to place our options in a circle, this will set the default for the use-case when two options are available, more on that later. Let’s focus on the anchoring.

The ::picker(select) is inside the top-layer, located outside of the document flow. We don’t really need to provide an anchor-name for this because the picker is automatically associated with the select button via CSS anchor positioning. This way, we can directly use the anchor function and a little transform, making sure that the picker is set to the center.

To remove potential flashing of scrollbars, the overflow here is set to visible and we are also adding a transition-behavior for top-layer transitions.

Styling the radial options

If you are actively following this tutorial, I suggest for the next steps, you reduce your select to only contain one option (just put the others in comment for now):

<select>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <div class="items">
    <option value="health">
      <div class="potion-holder">
        <svg class="icon icon-health" aria-hidden="true">
          <use xlink:href="#potion" />
        </svg>
      </div>
      <span>Health</span>
    </option>
  </div>
</select>

Ready? Then it’s time to style our options, notice how we’re setting up some custom properties (--half-circle, --deg, --negative) that will be crucial for positioning and rotation later on.

option {
  --half-circle: calc(var(--circle-size) / -2);
  --deg: var(--rotation-divide);
  --negative: calc(var(--deg) / -1);

  display: flex;
  align-items: center;
  justify-content: center;
  position: absolute;
  top: 50%;
  left: 50%;
  width: var(--option-size);
  aspect-ratio: 1;
  margin: calc(var(--option-size) / -2);
  background: var(--color-catawba);
  border-radius: 50%;
  opacity: 0;
  box-shadow: inset 0 1px 1px #ccc, inset 0 -1px 1px #aaa, 0 2px 4px -3px #666;
  transition: opacity 0.5s, box-shadow 0.3s, transform 0.5s;
  cursor: grab;
  &::checkmark {
    display: none;
  }
  &:checked {
    background: var(--color-catawba-light);
  }
}

The new variables: --half-circle, --deg, and --negative are being calculated based on other variables we’ve set before. --half-circle will help with positioning around the central orb, --deg will determine the rotation angle, and --negative will be its inverse. The reasoning behind this is that we set the option by default right over the main select orb by using absolute positioning and negative margins based on the options orb size. I’m sure there are some better ways to do this with trigonometric functions nowadays but to be honest, I am not that good at maths…

We are also setting the options to an opacity of 0 because we want to fade them in using a transition. Further on, we will hide the default ::checkmark of the customizable select, and set our own little background color for the select option using the :checked pseudo-class.

Let’s also style our label inside of the option:

option {
  /* ... previous styles */
  & span {
    position: absolute;
    bottom: -30px;
    left: 50%;
    transform: translateX(-50%);
    font-size: 1.1rem;
    color: var(--color-lightest);
    opacity: 0;
  }
}

The text will also be absolutely positioned based on the option, and we’ll fade that in later on based on the :open state of the select, we can already add a little animation for that:

@keyframes fade-in {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}

For now, we laid our groundwork, it’s time to make these options appear!

The fan-out effect

We have everything set for our transitions, and now we will make use of those custom properties to make those options “fan-out”

select:open option {
  transform: rotate(var(--deg)) translate(var(--half-circle))
    rotate(var(--negative));
  opacity: 1;
  & span {
    animation: fade-in 0.4s ease-out forwards 0.4s;
  }
  @starting-style {
    transform: none;
  }
}

Let me break down how this transform works:

rotate(var(--deg)) rotates each option around the center of the select. The --deg variable will be calculated based on the number of options (we’ll add those in a bit).
translate(var(--half-circle)) moves the rotated option outwards along its rotated axis, placing it on the circumference of an imaginary circle.
rotate(var(--negative)) counter-rotates the option so that it remains upright despite being positioned on the circle.

And to finalize things, let’s add a bit of a hover/focus effect that rotates the potion-icon a little bit and set a pronounced inset shadow as well. We’re also going to leave that potion rotated when the option is `:checked.

option:is(:hover, :focus) {
  box-shadow: rgba(50, 50, 93, 0.25) 0px 30px 60px -12px inset,
    rgba(0, 0, 0, 0.3) 0px 18px 36px -18px inset;
}

option:is(:hover, :focus, :checked) .icon {
  transform: rotate(0);
}

This is what it currently looks like with one option:

But of course when adding a second option, the following will happen:

This is why these custom properties need to be updated based on the amount of children. For this, we’ll be using :has(), but once again. I am aware the easier calculations might be possible these days for those strong with trigonometric functions.

The rotation adjustment

In the end this is what I want to achieve:

It’s a bit sad, that most people won’t see the full potential of this demo, but I absolutely love the way they were positioned based on the amount of items. O well….

To achieve this behavior, there are two sets of rules:

The first set uses the :has() pseudo-class in combination with :nth-child() to target the parent element .items, we can not target the ::picker(select) directly with this method, which is why we needed that extra wrapper. Based on the number of options present, we’re recalculating the --rotation-divide custom property.

.items:has(option:nth-child(2)) {
  --rotation-divide: calc(360deg / 2);
}
.items:has(option:nth-child(3)) {
  --rotation-divide: calc(360deg / 3);
}
.items:has(option:nth-child(4)) {
  --rotation-divide: calc(360deg / 4);
}
.items:has(option:nth-child(5)) {
  --rotation-divide: calc(360deg / 5);
}
.items:has(option:nth-child(6)) {
  --rotation-divide: calc(360deg / 6);
}

Next, we have rules that target each specific option using :nth-child() and adjust their rotation:

option:nth-child(2) {
  --deg: calc(var(--rotation-divide) * 2);
}
option:nth-child(3) {
  --deg: calc(var(--rotation-divide) * 3);
}
option:nth-child(4) {
  --deg: calc(var(--rotation-divide) * 4);
}
option:nth-child(5) {
  --deg: calc(var(--rotation-divide) * 5);
}
option:nth-child(6) {
  --deg: calc(var(--rotation-divide) * 6);
}

And the last rule here is that we only allow a certain amount of options, a maximum of 6 that is. This potion satchel isn’t infinite:

option:nth-child(1n + 7) {
  display: none;
}

Future: `sibling-count()` and `sibling-index()`

In the future, the previous calculations with :has() and :nth-child() could be reduced to a single line of code:

At the place where we set our option styling:

option {
    --half-circle: calc(var(--circle-size) / -2);
    --deg: calc(var(--rotation-divide) * sibling-index());
    /* Rest of the code */
}

And the complete counter could be reduced by this:

.items:has(option:nth-child(2)) {
    --rotation-divide: calc(360deg / sibling-count());
  }

If you’re feeling experimental, I added an extra example for Chrome Canary that you can access here.

The final result

I love the way we can use anchor positioning with the customizable select and I’ll be adding a few more of those examples later on. But this one might’ve gotten a bit complicated due to the rotation of the orbs. Sorry if I lost you there…

I did however have a blast writing this article because this was one of my first select demos ever. It’s been through so many iterations of the customizable select and I’m happy that I could clean this up a little to write this article. It’s also been one of those demos that got share on quite a few interesting places such as the Chrome blog. Does make me a feel proud though 🙂 I for one hope this demo may inspire you to create some other cool customizable selects.

Here is that final demo!

See the Pen Potion selector by utilitybend (@utilitybend) on CodePen.

Interop 2025 - Which browser features to get acquainted with this year and why you should care

Brecht De Ruyte — Fri, 28 Mar 2025 00:00:00 GMT

Read the article at iO tech_hub

The customizable select - Part one: history, trickery, and styling the select with CSS

Brecht De Ruyte — Thu, 13 Mar 2025 00:00:00 GMT

This article could probably be read a 10-fold if I just named it: “10 ways to style your customizable select with CSS”. But I don’t want to do that. Instead I’m going to write a little series, starting with a bit of history and basic workings behind this new capability, and just follow it up with some in-depth examples and trickery.

I do encourage you to read a bit about the history as it might be some good food for thought, but since this is quite the long article, I added a few anchors:

The History
Styling the Customizable Select
Adding Images in the Select
The Selected Content Element

The history

The customizable select has been in the works for quite some time. Following the evolution of ideas on how we could solve the styling capabilities for developers was something I could witness close by. I’ve learned much about legacy, trade-offs and “naming things” by following along with Open UI for a few years. Even if it was just giving my opinion during Open UI meetings, early adoption, and reporting bugs by creating demos for each iteration of “customizable select”, it puts a big smile on my face to see this feature land in Chrome as of version 134. The amount of work this costs is not to be underestimated, and so many people had a part in this. I, for one, am just really happy I could see it all take shape.

More often than not when I give presentations about new UI capabilities, people ask me if I participate in these W3C community groups as a part of my job, or they wonder if I make some money doing it. The answer to that question is: “no, and I’m not the only one”. Same as in open source projects, some people do this kind of thing out of a passion. Maybe in some cases it’s about frustration as well? Eg: ”I’ve been doing this job for over 10 years, why can’t I style a select already?”

From new - to progressively enhanced element

A lot had been done for this already, but the first iteration (end 2022) I witnessed and based demos on was a new element called the <selectmenu>. There was even a moment when I thought it would be: “the final version”! So, I did what I usually do: I created a fancy article/demo and was convinced that this would be released in stable browsers (oh boy, was I wrong…). The months after, new names were bikeshedded and in about two months, there was a completely different name for this element: the <selectlist>. Ok, just a minor change, so I updated all my demos, feeling confident that this was just a little pre-release change for better naming, as a select isn’t a “menu”.

Even after name changes and other adjustments, the proposals still lacked a bit of clarity, specifically about progressive enhancements and accessibility. A new element does make things a lot more complicated for accessibility: Keyboard controls need to be specified correctly, screen readers would need to be updated to recognize the new element, and users would have to update their screen reader software to even notice that new element for what it is. It could become a real hassle.

One thing became clear during that period, there is a thin line on where you want to block authors for doing certain things. Do we give developers full control? Where should we block things? By default, everything should be accessible in HTML, let’s not forget that. It’s a thin line to which degree you want to give developers a pair of scissors and let them run with it. Please don’t take that the wrong way, I’m just as equally guilty in creating some shady stuff. But where and how could you avoid this, that’s the question.

Let’s fast forward a little bit. In the end, what Open UI does, is write explainers. This kind of research goes on to be presented to the HTML and CSS working groups, and a lot of feedback can come from those steps. One thing that started to happen was collaborative meetings. Mostly due to bad hours for me to follow those, I only joined a few of them, to listen. But I did notice that a lot of handy feedback came from those meetings and things started to move forward at an inclined pace. Everyone loved the capability and the work by Open UI, the things we could do, but the new element idea, it just didn’t sit right. And that’s when a new idea was born…

Let’s re-use the select, and create an opt-in via CSS.

Can we? Shall we? This is where I got lost so many times, this is where talk started to happen on parsing HTML and what is and isn’t possible due to the browser engine and even OS differences. Because a select does differ based on OS as well, especially from an accessibility standpoint. Here is a party trick to do with your colleague:

Create a select, “colleague one” views that select on Windows, the other one on macOS. Use your keyboard to access the select, focus on an option using arrow keys, press the ESC button, which colleague selected the focused option? Who still has the previous selected option? I’ll let you figure out the answer 😉

Anyway, a lot of thought went to this progressive enhanced select, and I don’t know all the details on the browser engineering perspective. However, I did learn that implementing this kind of behavior was difficult. There is a huge collection on GitHub by Joseph that if you want to dive deep on the amount of work, I can highly recommend it.

The most baffling thing is that someone noticed that when you put a <button> inside of a <select>, it just gets completely ignored by browsers and that became the window to truly progressively enhance the <select> and open up a variety of styling possibilities. Do not put an input element in there, for example. (I might get back on that one in a future article) It’s only the <button> element that gets ignored, you can not put an <input> element in there without breaking the backwards compatibility.

Another benefit is that it would ignore unknown elements, which allowed the <selectedcontent> (first named: selectedoption) element to be nested inside of a <select>.

I did spare out some details, conversations about keyboard navigation, the timing of cloning <selectedcontent>, naming (a lot of) things, pseudo-element choices and names, how the checkmark should be defined, etc.

A lot is going on here, and that’s exactly why I at least wanted to write up a little bit of history. There are so many little choices, that we take for granted when new things get added to the web platform. People are excited for this, me being one of them. So many hours went into getting this to the platform. Every engineer, accessibility expert, developer, contributor, is doing a little part in moving this forward. I’ve at least learned to be a little less ignorant, by understanding why these things take time.

All that time, sometimes frustratingly re-creating demos due to changed (pseudo-) element names or behavior - I believe the wait was certainly worth it.

A lot of people will use the word “finally” when podcasting, writing, and video tutorialing the customizable select. But just as we forget with open source, there was a lot of work, for the better. So from me, to all those involved, whether you get paid to do these groups or not: thank you.

Now let’s get styling!

Styling the customizable select

Remember that this is a beginner tutorial so we’re going to keep things as easy as possible for now and create something like this:

The opt-in via CSS and the anatomy of a customizable select

First thing we need to do is to create our <select> using HTML and do the opt-in via CSS, for this demo, I do want to progressively enhance this <select> a bit, because I believe this is where a lot of the power lies, so let’s start with some HTML:

<select>
  <option value="first">First option</option>
  <option value="second">Second option</option>
  <option value="third">Third option</option>
</select>

Now let’s opt-in via CSS:

select {
  appearance: none;
  @supports (appearance: base-select) {
    &,
    &::picker(select) {
      appearance: base-select;
    }
  }
}

So, let’s explain this small CSS snippet a bit. First of all, I set my select to have appearance: none;, this was already possible, and I’m doing this because I do want a bit of styling for my select for browsers that do not support this new feature. Which brings me to the feature query:

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

This ensures that when the feature is supported, the select and the picker appear as base-select, opting into that customizable select capability.

Let’s quickly compare side-by-side. On the left, you have Chrome 134, which supports this new behavior. On the right, you have another browser that falls back to the default appearance: none.

But what happened when we opted in with CSS? Well, a lot of things became available to us, here is an image highlighting things we can target (explainer below):

There are a few things that we can select with CSS directly:

::picker-icon : Allows us to change the little icon indicating the select (arrow-down)
::checkmark : allows us to alter the check icon that is next to the checked option
:checked : A pseudo-class to select our checked option
::picker(select) : The bounding box that surrounds/lists our options

Styling our select

Let’s start with the basic look and feel of our select, we’re going to set display: flex to get the arrow positioned next to the text, give it a bit of border-radius and just some basic styling, it’s all good here, do something you like for this step:

select {
  display: flex;
  justify-content: space-between;
  align-items: center;
  color: white;
  border-radius: 5px;
  border: 2px solid plum;
  cursor: pointer;
  font-weight: 700;
  padding: 10px;
  background-color: hotpink;
}

Next up, we’re going to make sure that we still have a good experience for browsers that don’t have the new support. Inside of my select, let’s add a little arrow by updating the background and paddings:

select {
  /* Previous properties, but updated the padding */
  padding-block: 10px;
  padding-inline: 10px 30px;
  background: hotpink url("arrow.svg") right 10px center / 20px no-repeat;
}

This gives the padding at the end bit more room and provides a background-image of an arrow to clarify this is a select element. And there you have it, we have a perfectly styled select for browsers that don’t support this new feature:

Progressive enhancing our customizable select

Now that we have set a good basis, let’s dive a bit deeper. According to the anatomy, we can now access the ::picker-icon pseudo-element to update our arrow, let’s do this right away.

We will remove the background-image on our select itself and reset the padding in favor of using the pseudo-element as a progressive enhancement:

select {
  /* Previous properties with background-image */
  @supports (appearance: base-select) {
    padding-inline: 10px;
    background-image: none;
    &::picker-icon {
      content: "";
      width: 20px;
      height: 20px;
      background-image: url("arrow.svg");
      transition: rotate 0.2s ease-out;
    }
  }
}

Noticed that I added a transition on the ::picker-icon? We also get an :open pseudo-class with this new feature, let’s put that in action and rotate our icon when the select is open:

select {
  /* ... */
  @supports (appearance: base-select) {
    /* ... */
    &::picker-icon {
    /* ... */
    }
    &:open::picker-icon {
      rotate: 180deg;
    }
  }
}

This is our current state when the select is open:

Styling the select picker and options

Now is the time to finally style what we came here for: styling the picker and options. With the ::picker(select) pseudo-element we can style the box that contains our selects.

For this part, let’s keep building it up inside of that @supports query:

select {
  /* ... */
  @supports (appearance: base-select) {
    &:open::picker-icon {
      /* ... */
    }
    &::picker(select) {
      padding: 0;
      margin-top: 5px;
      border: 2px solid hotpink;
      background: white;
      border-radius: 5px;
      font-weight: 400;
    }
  }
}

This allowed us to style the listbox and this is the result:

Wonderful! All that is left for us to do is to style the options themselves, in a nutshell, this is what I’ll be doing here:

Remove the checked icon by setting the ::checkmark pseudo-element to display: none
Create my own checked state with the :checked pseudo-class
Add a bit of beautiful styling and some transitions

option {
  padding: 10px;
  border-top: 1px solid plum;
  cursor: pointer;
  transition-property: color, background;
  transition-duration: 0.2s;
  transition-timing-function: ease-out;
  &:where(:hover, :focus, :active) {
    background: plum;
    color: white;
  }
  &:checked {
    background: violet;
    color: white;
  }
  &::checkmark {
    display: none;
  }
  &:first-child {
    border: 0;
  }
}

And there you have it, a beautifully styled select:

Animations

I am going to keep the animation part for another articles as I’m planning to go a bit wild with animations for those. Do not forget that the picker is inside of the top-layer, so you will need to animate with that in mind. However, I don’t want to keep you hanging completely, so for this example you could do something such as animate the height and opacity:

select {
  /* ... */
  @supports (appearance: base-select) {
    &:open::picker-icon {
      /* ... */
    }
    &::picker(select) {
      /* ... */
      opacity: 0;
      height: 0;
      overflow: clip;
      transition: height 0.5s ease-out, opacity 0.5s ease-out, overlay 0.5s,
      display 0.5s;
      transition-behavior: allow-discrete;
    }
    &:open::picker(select) {
      opacity: 1;
      height: calc-size(auto, size);
      overflow: auto;
      @starting-style {
        opacity: 0;
        height: 0;
      }
    }
    /* ... */
  }
}

Final note on the first example

In contrast to the non-customizable-select, the width of the select is fluid, meaning that it does not take the size of the largest option by default. So you will need to provide something for this. In the final example I added a min-width.

Here is the full CodePen:

See the Pen A customizable select with only pseudo-elements by utilitybend (@utilitybend) on CodePen.

Adding images in the select’s options!

Now that we know the foundation of the customizable select, it might be interesting to know that this new feature allows us to add images or icons inside of the options. Re-using the same select (but with a bit of different styling), this is an example where I just added some SVGs inside of the options:

You could do something like this:

<select>
  <option value="pokeball">
    <img src="..." alt="" />
    Pokeball
  </option>
  <option value="greatball">
    <img src="..." alt="" />
    Great ball
  </option>
  <option value="ultraball">
    <img src="..." alt="" />
    Ultra ball
  </option>
</select>

And in my CSS, I updated my options a bit:

option {
  display: flex;
  align-items: center;
  padding: 10px;
  gap: 10px;
}

The result is that inside of my options the images are visible:

See the Pen A customizable select with images inside of the options by utilitybend (@utilitybend) on CodePen.

This is great, no harm done for non-supported browsers as they don’t get rendered for those, but wouldn’t it be nice if we were able to see that image inside of our select when it’s closed?

The selectedcontent element

One of the great things is that buttons and new elements get ignored in browsers that don’t support this feature. Taking the same poké-adventure, let’s make that Pokéball pop up in the selected content. This is how I updated the HTML:

<select>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option value="pokeball">
    <img src="https://assets.codepen.io/159218/pokeball.svg" alt="" />
    Pokeball
  </option>
  <option value="greatball">
    <img src="https://assets.codepen.io/159218/great-ball.svg" alt="" />
    Great ball
  </option>
  <option value="ultraball">
    <img src="https://assets.codepen.io/159218/ultra-ball.svg" alt="" />
    Ultra ball
  </option>
</select>

The <selectedcontent> will clone the content of our selected option inside of it. We do need to style it a bit with CSS:

selectedcontent {
  display: flex;
  align-items: center;
  gap: 10px;
}

This is our final result:

See the Pen A customizable select with images inside of the options and the selectedcontent by utilitybend (@utilitybend) on CodePen.

In case you were wondering, if this feature is not supported, it is still a perfectly beautiful and usable select:

One more step

The last thing I want to address is that we can visually hide some text inside of that <selectedcontent>, thus really manipulate the look and feel between the select itself and the options. I am not going to go in detail on this right now, but this means you could do something like this:

More on that later, but if you can’t wait to dig in, you can find that CodePen here.

Much more to come

In the next few articles, I’m going to focus on some specific demos and techniques to create some really cool gamified experiences. I’m really happy this feature landed in Chrome and I just love playing around with it. It gives the ability to create some fun experiences, never forget to have some fun with the web.

What’s more, I will be talking about this in depth at CSS Day this year!

I know this was a long article, I promise the next ones will be a bit shorter. But here is the foundation for you to start creating those awesome customizable selects as a progressive enhancement!

Happy selecting!

Love at first slide! Creating a carousel purely out of CSS

Brecht De Ruyte — Fri, 14 Feb 2025 00:00:00 GMT

Carousels, who likes them? Clients! Yes, clients love them. Developers, not that much… During my career, I’ve spent a lot of time finding the perfect slider, tweaking the default styles of slider libraries, and hacking them to be awesome. This was usually accompanied by a lot of swearing behind my keyboard. But maybe - just maybe - this new idea of creating a carousel with CSS might be a way to remove a lot of that frustration and, dare I say, even make creating sliders something enjoyable.

Let’s start with some basic theory before I show you what it can do.

Scroll markers what are they?

As usual, it starts with a new magical CSS property: scroll-marker-group.

When this new property is set to a scroll container (aka, a box with scrolling overflow) It creates a new ::scroll-marker-group pseudo-element attached to that container.

.some-container {
    overflow-x: auto;
    scroll-marker-group: after;
}

This ::scroll-marker-group has three possible values:

none
before
after

Compared to the ::before and ::after pseudo-elements, this value will place this new ::scroll-marker-group as a sibling preceding or following the scroll container it is attached to.

But that ::scroll-marker-group does not do anything by itself, it is a container that collects different scroll-markers, more about those later.

The new ::scroll-button() pseudo-element

When you add a ::scroll-button(<direction>) pseudo-element on your scroll container, you can add some buttons that move the scroll position based on the value of their flow-relative direction:

::scroll-button(inline-start)
::scroll-button(inline-end)
::scroll-button(block-start)
::scroll-button(block-end)

To make them visible, you will need to add the content property, just as you would with a ::before, ::after pseudo-element.

According to the spec, they are both focusable and activatable by default, with their activation behavior being to scroll their originating element by one “page” in their associated direction, similar to pressing the PgUp/PgDn keys, But we’ll get to that later.

The new ::scroll-marker pseudo-element

Just like our ::before and ::after pseudo-elements, all elements will be able to have a ::scroll-marker pseudo-element (yes, all of them). Just as our previously known pseudo-elements, we’ll need to give this a content property in order to work. These new elements have some special knowledge:

They contain the scroll-target of the element they’re attached to
They behave like anchor links when you click on them.
They know when their corresponding element is visible in the scroll container
They have a stylable pseudo-class when their linked element is visible: :target-current

Ok, I tried to keep this short and to the point, there are probably a lot of caveats here, but let’s get into the sliding of things.

Snaps with benefits

The groundwork for creating a slider with CSS was already done some time ago. We already can use scroll-snapping in our projects, but it always felt like it missed a bit of control.

Without further ado, let’s create a basic slider with just CSS. First, let’s set up the HTML:

<div class="carousel">
  <div>
    <img src="..." alt="...">
  </div>
  <div>
    <img src="..." alt="...">
  </div>
  <div>
    <img src="..." alt="...">
  </div>
</div>

And let’s make this a scroll-snapping container, notice that I created it so that the images have an aspect ratio of 16/9, it’s a simple technique here, but that’s the whole point, keep the first demo as simple as possible:

.carousel {
  display: grid;
  grid-auto-columns: 100%;
  grid-auto-flow: column;
  overflow-x: auto;
  overscroll-behavior-x: contain;
  scroll-snap-type: x mandatory;
  scrollbar-width: none;
  scroll-behavior: smooth;
  div {
    scroll-snap-align: start;
    scroll-snap-stop: always;
  }
  img {
    width: 100%;
    aspect-ratio: 16/9;
    object-fit: cover;
  }
}

Ok, great, we now have our scroll-snapping container in place. A little note on this: You can perfectly use proximity in your scroll-snap-type property as well, however for this example to give that real slider feel on scroll, mandatory works best from a UX standpoint. We are also hiding the scrollbar with scrollbar-width: none; because we are going to provide our custom controls. We also set the scroll-behavior: smooth; as this will give a nice feel when the controls are in place.

Your browser does not support the video tag.

Ok, this is our basic set up, let’s add the markers:

Creating the controls: slider bullets

Let’s just dive in right away and add the following to our previous code:

.carousel {
  /* previous code */
  scroll-marker-group: after;
  div {
    /* previous code */
  }
}

This will open that group of markers, we can clearly see this ::scroll-marker-group in our DevTools, which is a very nice feature to have:

Ok, moving on, it’s time to add those ::scroll-marker pseudo-elements to our sliders children:

.carousel {
  /* previous code*/
  scroll-marker-group: after;
  div {
    /* previous code*/
    &::scroll-marker {
      display: block;
      content: " ";
      aspect-ratio: 1;
      width: 24px;
      border-radius: 50%;
      border: 1px solid silver;
      cursor: pointer;
      background: transparent;
      justify-content: center;
      transition: background 0.5s ease-out;
    }
  }
}

Let’s update this just a little further before I show you what we created. In the theory, I mentioned that we can set a style when a ::scroll-marker is active, let’s do that as well and give the little bullet a background when that happens:

.carousel {
  /* previous code*/
  scroll-marker-group: after;
  div {
    /* previous code*/
    &::scroll-marker {
      /* scroll marker base styles */
    }
    &::scroll-marker:where(:hover, :active, :focus) {
      background: lightgray;
    }
    &::scroll-marker:target-current {
      background: white;
    }
  }
}

This is what we can see now in our DevTools:

Now they are just sitting there on the side of my slider, which isn’t ideal, however, it does work very nicely:

Your browser does not support the video tag.

This is where our ::scroll-marker-group comes into play, it’s quite refreshing to see something like this in CSS as it dedicates itself as a wrapper around the children’s ::scroll-marker pseudo-element, meaning that this wrapper can be used for layout as well:

.carousel {
  /* Previous code */
  &::scroll-marker-group {
    width: 100%;
    display: flex;
    gap: 12px;
    align-items: center;
    padding: 20px 0;
    justify-content: center;
    z-index: 20;
  }
  /* children styling */
}

And there you have it, a fully functional slider:

Your browser does not support the video tag.

Adding the scroll buttons

Let’s add a left and right arrow button for our slider. The ::scroll-button() pseudo-element accepts logical naming, so let’s add this right away:

.carousel {
  &::scroll-button(inline-end),
  &::scroll-button(inline-start) {
    cursor: pointer;
    content: "";
    inline-size: 44px;
    aspect-ratio: 1;
    background-color: rgb(255 255 255 / .6);
    background-image: url("arrow-left.svg");
  }
  &::scroll-button(inline-end) {
    content: "";
    background-image: url("arrow-right.svg");
  }
  &::scroll-button(inline-end):where(:hover, :focus, :active),
  &::scroll-button(inline-start):where(:hover, :focus, :active) {
    background-color: rgb(255 255 255);
  }
}

I kept the properties to a minimum here, but of course, they are a bit more styled in the final version (you can watch the full code in the demo later on). Let’s break down this code a bit:

First, I set the scroll buttons to have an empty content property.
As I want them to have arrows, I also give them a background-image containing an arrow
Lastly, I set hover and active states for these buttons to light up a little bit.

All that is left for us, is to position these buttons. For my use case, I found the quickest way was to use anchor positioning in CSS. This is how I positioned them:

.carousel {
  anchor-name: --carousel;
  &::scroll-button(inline-end),
  &::scroll-button(inline-start) {
    z-index: 1;
    cursor: pointer;
    position: absolute;
    position-anchor: --carousel;
    top: anchor(center);
    inset-inline: anchor(start) anchor(end);
  }

  &::scroll-button(inline-end) {
    top: anchor(center);
    inset-inline: auto anchor(end);
  }
}

By setting an anchor-name on my scroll container (.carousel), it’s really easy to position the pseudo-elements on it. I can do this by using the anchor() function on my scroll buttons to position them right into place. As for some readers, this anchor positioning might still feel like a new thing. I wrote a little guide to anchor positioning in CSS before.

If you read this article this far, I have good news! You made it!, This is the final result and the CodePen. I tested this experimental feature in Chrome Canary. If you want to play around with them you’ll have to enable the Experimental Web Platform features after going to chrome://flags

Your browser does not support the video tag.

See the Pen Carousel Pure HTML and CSS by utilitybend (@utilitybend) on CodePen.

Note: In the CodePen I used layers to make it easier to follow along with this tutorial.

Further experimentation (and cool stuff on scroll-markers in CSS)

I created a bunch of fun stuff with this… It’s kinda how this goes for me, when I love a feature, I can’t help myself. I might do an in-depth tutorial of one later on…

Experiment 1: Inherit colors in ::scroll-marker and full-axis slider

The fun thing about the ::scroll-marker pseudo-element is that they are children of our carousel’s children. Which in turn means we can inherit colors:

For example:

.slider-item:nth-child(1) {
  background: oklch(0.73 0.28 339.69);
  color: oklch(0.92 0.22 101.77);
}

.slider-item:nth-child(2) {
  background: oklch(0.92 0.22 101.77);
  color: oklch(0.73 0.28 339.69);
}

.slider-item::scroll-marker {
  border-color: currentColor;
  background: inherit;
}

I combined this with a scroll-snap over both axis to create a 3by3 slider. And this my first Valentines Day Demo:

Your browser does not support the video tag.

See the Pen Scroll Markers 3by3 grid carousel by utilitybend (@utilitybend) on CodePen.

Experiment 2: Recreating a slick-slider with just CSS

This one might deserve a new article on itself later on, but recently, Chrome release the new attr() possibilities. Which allows reading more attributes from HTML into our CSS. Read about the new attribute capabilities here.

In my years as a developer, I created a lot of webshops, so inspiration for this was easily found

This is the experiment:

In my HTML I did the following:

<div class="carousel">
  <div data-src="url(my-slick-image.webp)">
    <img src="my-slick-image.webp" alt="">
  </div>
   <!-- other items in the same way -->
</div>

I added a data-src attribute on my sliding item, with the new update mentioned above, this means I can read this inside of my ::scroll-marker:

.carousel > div {
  /* Get the attribute of the div containing the background-image (Chrome since v133) */
  --image: attr(data-src type(<image>), "");
  &::scroll-marker {
    /* Set image variable from parent as background */
    background: var(--image, green);
    background-size: cover;
    background-repeat: no-repeat;
  }
}

Result:

Your browser does not support the video tag.

See the Pen Webshop slick slider remake in CSS by utilitybend (@utilitybend) on CodePen.

Experiment 3: More than one item on a slide

As a last one, I wanted to show the capability on skipping some items. In this example, I wanted my slider items to be shown 3 by 3 and snapped in the center. Now because of this, I wanted my slider items to scroll by 3 using scroll-markers, and this is how I did that:

.carousel > *:nth-child(3n + 2)::scroll-marker {
  content: "";
  aspect-ratio: 1;
  width: 24px;
  border-radius: 50%;
  border: 1px solid silver;
  cursor: pointer;
  background: transparent;
  justify-content: center;
  transition: background 0.5s ease-out;
  border-color: white;
}

Your browser does not support the video tag.

See the Pen Carousel scroll-markers - scroll by three by utilitybend (@utilitybend) on CodePen.

Accessibility concerns - Love is in the air

While I was experimenting, I noticed that when focusing on the buttons and markers, we do not get a default focus ring, do take note that this is still a work in progress and it might be a bug, or a feature yet to be developed. Also, the current scroll markers don’t show up in the accessibility tree, but I’ve been informed that this is due to a bug and it’s been reported.

Since we’re talking about accessibility, maybe a quick hot tip for the future: If your slider contains a lot of items, try to be so kind as to provide a skip-link at the start of it, your users will thank you for it.

Learn more from Adam

If you think these demos are crazy, wait until you see what Adam from the Chrome DevRel team made! Adam is working on a full Carousel Gallery also combining state queries and a lot of other goodies, check it out!

He will also be talking a bit about this on CSS Day, I’ll be there to bombard him with questions on it for sure, and if you can’t make it, no worries, I’m sure he and the team will be writing some in-depth about this future.

Other resources

I can’t wait to experiment more with this. I still have some question marks on it, but this might be one of those features I never thought we’d get in CSS. It can reduce dependencies, I can style it just the way I want without overruling some baked-in library styles… You know what… I’m gonna say it:

I love sliders!
Happy Valentines Day

Transitioning Top-Layer Entries And The Display Property In CSS

Brecht De Ruyte — Wed, 29 Jan 2025 00:00:00 GMT

Read the article at Smashing Magazine

Revisiting SVG filters - my forgotten powerhouse for duotones, noise, and other effects

Brecht De Ruyte — Mon, 27 Jan 2025 00:00:00 GMT

Before you get angry and yell at me that SVGs are still relevant, let me tell you that I’m completely aware of this. I see a lot of great people creating amazing things with them, but the truth is that in my day job, I don’t use them that often. It’s kind of a shame and recently I had a project where I found a good use case for them once again, so I thought to myself: “maybe I should revisit some of those basic effects?” This means that I will be keeping things at a basic level. Back in 2018, I didn’t write on this blog, and I used to be quite good at writing those filters by hand, so here is me documenting some of my favorite effects I used back then as I noticed some of those skills got lost over time. By no means am I an expert when it comes to SVG filters, which is exactly why I wanted to write about them.

Creating an SVG filter

In this article, I’ll be focussing on SVG filters that we can call in our CSS. To achieve this, you’ll need an SVG element with a filter defined inside of it. This filter will have a unique ID that we can target through our CSS filter property.

<svg>
  <filter id="my-filter">
      <!-- filter effects -->
  </filter>
</svg>

.some-thing {
   filter: url(#my-filter);
}

Duotones and other color manipulations

Who doesn’t love a good old duotone? To illustrate this, I will be using the same image over and over again. It’s a picture taken the first time I went to Berlin.

Before we get into the SVGs, let’s take a quick look at the built-in filters we have available in CSS.

We can mimic duotones in CSS, for example, the filter property does have a grayscale() filter, so we can turn our image into black and white. We also have a sepia() duotone ready-to-use:

img {
  filter: sepia(100%);
}

By combining sepia and a hue-rotate() filter we can even sort of mimic a colored duotone with CSS:

img {
  filter: sepia(100%) hue-rotate(250deg);
}

Even though this looks kinda great, it still lacks a bit of control, especially If we want to work with brand colors for our clients. This is where SVG filters come in handy.

Color SVG filter part 1: Black and White

Before we go into the coloring part, the first thing we’ll need to do is set our image into black and white. But just this one action already opens up a lot of opportunities.

To manipulate color, the best way to start is with the <feColorMatrix>. This is a real powerhouse and I’ll try to explain the basics as easy as possible. Let’s start by recreating a grayscale:

<svg viewBox="0 0 0 0" width="0" height="0" aria-hidden="true">
  <filter id="grayscale">
    <feColorMatrix type="matrix" values="
        .33 .33 .33 0 0
        .33 .33 .33 0 0
        .33 .33 .33 0 0
        0 0 0 1 0" />
  </filter>
</svg>

The “fe” stands for “Filter Effects”, this is something we’ll see a lot in the rest of this article. So we added the ColorMatrix effect with a bunch of values. The syntax looks a bit overwhelming (with all those values), but trust me, these values do make a lot of sense, and we’ll get there, just a quick example of our result when targeting with CSS:

img {
   filter: url(#grayscale);
}

Let’s dive into those values so that you can play around with them. I on purposely set those values in 4 rows. And this is what they do:

[ R ] : [ r  g  b  a  o ]
[ G ] : [ r  g  b  a  o ]
[ B ] : [ r  g  b  a  o ]
[ A ] : [ a  a  a  a  o ]

Each of the first three rows specifies which color we want to adjust. For example, the first row will let us change the reds, the first three values inside of it are where we declare the new color for all our reds, followed by our alpha transparency and offset.

As an overly simplified example. If I wanted all my reds to turn into greens, all my greens into reds, and keep the blues it would look like this:

<feColorMatrix type="matrix" values="
  0 1 0 0 0
  1 0 0 0 0
  0 0 1 0 0
  0 0 0 1 0" />

So by setting each of those channels to .33 you create a grayscale, just as you would in an RGB color rgb(10 10 10). You want each column to have the same value to create a grayscale image.

This already opens a lot more possibilities compared to our CSS grayscale filter as we can adjust the darkness based on each channel. In this example. I want my blues really light and my reds somewhere in the middle, creating a completely different type of grayscale:

<feColorMatrix type="matrix" values="
  0.5 0.2 0.8 0 0
  0.5 0.2 0.8 0 0
  0.5 0.2 0.8 0 0
  0 0 0 1 0" />

A few things I didn’t mention yet is that the last row of the matrix [A] affects the alpha (transparency) channel. The last column of the matrix provides additive offsets to the color channel, I sometimes use this to darken or lighten my grayscale as well. That opens a whole bunch of other possibilities that I haven’t invested enough time in (yet), but feel free to play around with it to notice its effects.

 <feColorMatrix type="matrix" values="
    .33 .33 .33 0 0
    .33 .33 .33 0 0
    .33 .33 .33 0 0
    1 1 1 0 0" />

Extra: Creating a NEOPAN-like black and white

As I said before, there are endless possibilities with SVG filters. When I shoot in black & white with my camera, I always try to mimic a Fuji NEOPAN style of film. I just love the contrasts and the dramatic colors. You could emulate these kinds of things. It’s not perfect for every use-case but this is an exaggeration of it:

<svg viewBox="0 0 0 0" width="0" height="0" aria-hidden="true">
  <filter id="neopan">
    <feColorMatrix type="matrix" values="
      0.5 0.44 0.1 0 -.02
      0.5 0.44 0.1 0 -.02
      0.5 0.44 0.1 0 -.02
      0 0 0 1 0" />
    <feComponentTransfer>
      <feFuncR type="linear" slope="1" intercept="-0.02" />
      <feFuncG type="linear" slope="1" intercept="-0.02" />
      <feFuncB type="linear" slope="1" intercept="-0.02" />
    </feComponentTransfer>
  </filter>
</svg>

As you see, I added an extra filter named <feComponentTransfer>. I’ll keep the explanation of this example short:

<feFuncR>, <feFuncG>, and <feFuncB> perform a color component transfer function. This is handy to adjust contrast and brightness after the color transformation we did with <feColorMatrix>.

In short, for each of those RGB color functions we can change the following:

Slope: Adjusts the contrast for that channel. > 1 increase contrast, < 1 lowers the contrast
Intercept: Brightens the image when > 1, darkens the image when < 1

Note that I’m only going about the “linear” value for the type attribute, there is a lot more to it and the options can vary based on that type. (for reference, the other are: identity | table | discrete | linear | gamma). All these SVG filters probably deserve an article on their own. However, this particular one will be re-used for our duotone.

So now that we’ve gotten this far in all the black & white settings. The next part should be a lot easier:

See the Pen NEOPAN-ish by utilitybend (@utilitybend) on CodePen.

Color SVG filter part 2: Duotone!

Let’s start by creating our cool duotone colors. First thing we’ll need to do to achieve this effect is to set our image in grayscale once again. If you were following along, that should be rather easy by now.

<svg viewBox="0 0 0 0" width="0" height="0" aria-hidden="true">
  <filter id="duotone-purple">
    <feColorMatrix type="matrix" values=".33 .33 .33 0 0
        .33 .33 .33 0 0
        .33 .33 .33 0 0
        0 0 0 1 0">
    </feColorMatrix>
  </filter>
</svg>

This creates a nice and simple grayscale image to start with as we did before:

Alright, so we’ve got our grayscale image, and now we want to inject some color, turning it into a proper duotone. We’re going to use the <feComponentTransfer> element again, just like in the NEOPAN example, but this time with a twist. This filter effect lets us manipulate the color channels individually after the grayscale conversion.

<feComponentTransfer color-interpolation-filters="sRGB">
  <feFuncR type="table" tableValues=".996078431  .984313725"></feFuncR>
  <feFuncG type="table" tableValues=".125490196  .941176471"></feFuncG>
  <feFuncB type="table" tableValues=".552941176  .478431373"></feFuncB>
</feComponentTransfer>

Remember those <feFuncR>, <feFuncG>, and <feFuncB> elements? They’re back, and this time we’ll be using the type="table" attribute. This is where the magic happens for creating duotone colors.

Instead of linear which we used before to adjust contrast and brightness, table lets us create a lookup table. What this table does, is that for each input value, we provide a corresponding output value.

The tableValues attribute is the key here. It’s a space-separated list of numbers between 0 and 1. In this case, we’re providing two values for each color channel. This means we are defining two points on a graph. The filter interpolates between these points.

But how do we get these colors? It’s easiest explained with an example. Let’s set our duotone in the following two colors:

rgb(224 36 111) and rgb(201 200 44)

As I mentioned before, we are not using RGB color values but a value between 0 and 1. For each of our color channels, we are going to get that value by getting the channel value and divide it by 255. Here is the rundown:

rgb(224 36 111):

Red: 224 / 255 = 0.878431373
Green: 36 / 255 = 0.141176471
Blue: 111 / 255 = 0.435294118

rgb(201 200 44):

Red: 201 / 255 = 0.788235294
Green: 200 / 255 = 0.784313725
Blue: 44 / 255 = 0.17254902

We will follow up by adding those values in this manner:

<feComponentTransfer color-interpolation-filters="sRGB">
  <feFuncR type="table" tableValues="RED1 RED2"></feFuncR>
  <feFuncG type="table" tableValues="GREEN1  GREEN2"></feFuncG>
  <feFuncB type="table" tableValues="BLUE1  BLUE2"></feFuncB>
</feComponentTransfer>

So our final result will be the following:

<feComponentTransfer color-interpolation-filters="sRGB">
  <feFuncR type="table" tableValues="0.878431373 0.788235294"></feFuncR>
  <feFuncG type="table" tableValues="0.141176471 0.784313725"></feFuncG>
  <feFuncB type="table" tableValues="0.435294118 0.17254902"></feFuncB>
</feComponentTransfer>

Here is our full code:

<svg viewBox="0 0 0 0" width="0" height="0" aria-hidden="true">
  <filter id="duotone-purple">
    <feColorMatrix type="matrix" values=".33 .33 .33 0 0
        .33 .33 .33 0 0
        .33 .33 .33 0 0
        0 0 0 1 0">
    </feColorMatrix>
    <feComponentTransfer color-interpolation-filters="sRGB">
      <feFuncR type="table" tableValues="0.878431373 0.788235294"></feFuncR>
      <feFuncG type="table" tableValues="0.141176471 0.784313725"></feFuncG>
      <feFuncB type="table" tableValues="0.435294118 0.17254902"></feFuncB>
    </feComponentTransfer>
  </filter>
 </svg>

Here is that codepen:

See the Pen Duotone purple-ish by utilitybend (@utilitybend) on CodePen.

Here is an example with more filters:

See the Pen Barnaby duotones by utilitybend (@utilitybend) on CodePen.

Fun fact: This article actually just contains that one image with all the effects, cool huh?

Motion blur

Alright, so we’ve played with colors and duotones. Now, let’s take a look into something a bit different: blur. Blur can be used for a variety of effects, from subtle background softening to creating a sense of depth or movement. Let me tell you: SVG blur has a lot more control than the CSS blur() filter.

.background {
    filter: blur(5px);
}

The blur filter unfortunately only accepts one value, while in SVG filters you can set an X and Y value in which you want a blur to happen. Here is an example of that filter:

<svg width="0" height="0" viewBox="0 0 500 350" aria-hidden="true">
  <filter id="blurX">
    <feGaussianBlur stdDeviation="15 0"></feGaussianBlur>
  </filter>
</svg>

Notice the stdDeviation="15 0" on our GaussianBlur filter effect:

The first value (15) controls the blur radius in the x-axis, while the second value (0) sets the vertical or y–axis blur to 0.

There isn’t that much more to say about this effect, but I did create a demo to illustrate the difference between the two types of blur:

See the Pen SVG motion blur vs CSS blur demo by utilitybend (@utilitybend) on CodePen.

At the end of the article, I have a little something that has the vertical blur as well, stay tuned ;)

Extra info on the SVG horizontal blur demo

I created a bunch of filters in this demo and targeted the background, road, and car.

With a tiny bit of JS, I made those filters change their value, each and every one of those has a different maximum, which I calculated.

I’m also using a CSS variable that sets the animation speed and am using :has() to toggle between the radio buttons (because I’m lazy, do avoid many :has() checks on the root though, as it could cause performance issues, but for this demo, it’s fine…)

I don’t mind giving a complete rundown of this demo if people would be interested. Just give a little shout-out. But to keep this article from getting too bloated, let’s quickly move on.

Noise

Let’s hear some noise for svg!!!
Ok… dad jokes… sorry.

Noise is one of the things that can be created with <feTurbulence>, but it’s just the tip of the iceberg as this filter effect can create so much… From subtle textures to dramatic effects. To create a noise filter, you can use something like this:

<svg width="0" height="0" viewBox="0 0 500 350" aria-hidden="true">
  <filter id="noiseFilter">
    <feTurbulence
       type="fractalNoise"
       baseFrequency="0.85"
       numOctaves="3"
       stitchTiles="stitch" />
  </filter>
</svg>

There are a few attributes inside of this turbulence filter, here is the short explanation of them:

type="fractalNoise": specifies the type of noise to generate. fractalNoise creates a more natural, organic-looking noise.
baseFrequency="0.85": is the frequency of the noise. Higher values result in smaller, more detailed noise, while lower values create larger, more spread-out noise. Play around with this value to create the desired effect
numOctaves="3": determines the number of octaves (dare I say layers?) of noise to combine. More octaves create a more detailed and complex noise pattern
stitchTiles="stitch": this attempts to create seamless transitions between the tiles of noise, creating a beautiful repeating pattern

Since I recently started to brush up my drawing skills with a pencil, I created a hamster with CSS based on a drawing and added some noise to it:

See the Pen hamtaro by utilitybend (@utilitybend) on CodePen.

This is pretty much all you need to know when it comes to noise, but there are SVG wizards that create amazing stuff with turbulence. And I am far off an SVG wizard. Still, a bit of noise does come in handy from time to time.

Much more…

There are a lot more things we can do with SVG. I brushed up an old demo I created five years ago (that was kept on a USB stick… can you imagine?) to show some of the other effects you could create with SVG. But as I stated before, I wanted to keep this article introductory and I think my current knowledge just isn’t enough to give an accurate description on how to use displacement maps or <feComposite> which combines filter effects into one, as the examples below:

See the Pen Grungy letters with SVG filters by utilitybend (@utilitybend) on CodePen.

I also spotted this cool collection of SVG text effects on CodePen.

If you want to learn more about displacement maps check this Smashing Magazine article: A Deep Dive Into The Wonderful World Of SVG Displacement Filtering

In conclusion…

So, I wrote this article not as a person who knows all things SVG but as someone who suddenly remembered that in this cool era of new and awesome CSS capabilities, we still have room for some solid SVG tinkering. I don’t use SVG filters on a day-to-day basis, but it’s a shame to lose some of those skills while they can still be very relevant today. It probably depends on the kind of work you do. But hey, this is just a reminder that when you stumble upon a certain effect that would be cool for a client and you have no idea how to achieve it, think SVG, it might just be the solution.

Happy tinkering!

Bonus: hamster parachute

I was creating my demo with the car and thought about doing something with a parachute for vertical motion blur. Then our 6-year-old daughter came into the room and showed her best project management skills. Besides criticism on some of my other demo here were the key asks:

Can you make the parachute go up as well?
Can you hang something on the parachute?

And so this happened:

See the Pen Parachute hamster! by utilitybend (@utilitybend) on CodePen.

Reflecting on a year well spent! Looking forward to 2025

Brecht De Ruyte — Tue, 31 Dec 2024 00:00:00 GMT

A record in writing articles this year

This year, I will have written 22 articles, and taking into account that I want to write a minimum of one article/month means that I’m way above target. This is something I try to think about going into next year. I might not achieve that number in 2025, especially combined with giving more presentations and some other goals (more on those later), I want to be realistic about that.

Articles were spread on my blog, iO tech_hub, and Smashing Magazine, and they were mentioned in many newsletters by so many people I look up to… I am a complete social (media) awkward person from time to time, still, it does mean a lot to me. All the shares, the likes. It’s not my prior reason for writing, which is still mostly about documenting and pushing myself to learn more and help others. But the love does help me to go the extra mile: The extra demo, some screenshots, some video, etc…

I had articles translated into Japanese, which was a fun thing to happen for sure. I went to Japan a decade ago and want to go back someday… (just dropping a hint here)

Next year: articles.

As stated before, I’ll keep it realistic, one article each month is still the idea. We’ll see if I write more. I hope so. I still didn’t use any ads or sponsored posts and will keep it that way. Some might have noticed that I added a “buy me a coffee” button. I don’t expect much of it, but 😀you’re always welcome to.

Presenting. Am I a “public speaker” now?

If you’d told me a year ago If I would speak at such a variety of conferences, I probably would’ve laughed. It’s been great… I’m not going to be falsely modest and I do realize that I must be doing some things right. I handle speaking with the same care as articles, making sure it’s something that people can enjoy, giving it a personal tone while at the same time trying to be as informative as possible.

From Middlesbrough to the Isle of Man, to Catania, and some conferences in Belgium and The Netherlands. It was a pleasure doing all of them. I had food poisoning in one of them, Took an 11-hour train ride due to problems, and even had to update demos an hour before a workshop because Chrome Canary updated (once again, thank You Luke Warlow for helping on that one).

I’m always honest about this… I stress, every time, whether it’s for 20 people or 200 people. But I believe that’s a good thing, as long as I stress about it, it means that I want to give attendees everything I got, with correct info and a laugh or two.

The people I meet during those conferences, that’s probably the best thing about it. I meet so many interesting people. From people I look up to (and be star-struck when meeting them) to people who just do the most amazing things such as teaching kids and making a difference in the world. And yes, visiting a few new places while I’m at it is a great bonus of course.

I did about 10 presentations (small and big), but I still don’t consider myself a public speaker… I feel like the guy who writes some stuff that wants to share a little story. So what’s next?

Next year: speaking.

I’ll keep doing it and I have a few announcements soon. First up: NDC in London at the end of January.

I’m mostly giving my Open UI talk about popovers, invokers, and the upcoming customizable select. It seems to be a bit hot topic at the moment and I love talking about it, but I have some other presentations I’d like to share with people. We’ll see… no real resolutions on this.

Books read in 2024

I started reading again in 2024. Although not that much I did read a few books:

Solve for happy - Mo Gawdat
how to win friends and influence people - Dale Carnegie
Ted Talks - Chris Anderson
the subtle art of not giving a f*ck - Mark Manson
Problemen die er geen zijn - Herman Brusselmans

I usually like non-fiction books, there is one exception in this list, a book with some short stories by Herman Brusselmans. The reason I don’t like reading big novels is time and distractions…

I didn’t really like “How to win friends and influence people”, even though this is one people call a classic. I’d recommend each and every other one on this list.

Future books!

Engineering management for the rest of us - Sarah Drasner
Bounce - Matthew Syed
The Last Wish - Andrzej Sapkowski

Long overdue to read the book by Sarah Drasner, looking forward to it. Bounce came recommended and for my short stories, I’ll be reading a bit about The Witcher… loved the games, and the series, should at least try and read the books a bit.

2024 was good, highlights.

My father got a bit better from cancer. That’s the number one on the list right there.
Me and the wife took our first trip by plane together with our daughter. A trip to Lisbon and it was fantastic.
During my job, I got the chance to work on improving the developer experience and community inside the company. It’s a work in progress, but I love doing it.
The people I met, and those I haven’t had the pleasure of meeting.
The work done in W3C Community groups (CSS-Next, Open-UI). Kudos to the new CSS logo!

My daughter loves taking pictures… I love doing the same thing, I think mom felt a bit lonely from time to time with those two amateur photographers

So… no real New Year resolutions?

There are, but this time they aren’t that web-related. My focus will still be on family. But to give you an idea here are the resolutions:

Losing weight… yes, a typical one, but I’m going for it this time. Even though I am quite active when it comes to sports, It’s hard… My genes don’t even allow me to look at a pizza without gaining a pound.
Learn to draw better My daughter loves drawing and coloring. I’m going to join her. I never was any good at drawing and I’m going to try and get better, together with her.
Write better Yes… handwriting… a lost art. Improve it!
Journaling In 2024 I started journaling. I love doing it, and now that I look at my little book at the end of the year, it’s a real treasure. I want to do it again, but better and a bit more consistent. It was a good first run though.
Get my “GVB” - Golf licence
Be a bit less social media awkward - I really should pay more attention to socials…
Tell more people I love them (period)

We already started on the drawing part!

When it comes to web-related things. Keep doing what I’m doing for now. Maybe learn a new programming language (If I find the time) but I definitely want to spend some more time for the W3C communities which might come at the cost of some articles, we’ll see.

I hope 2025 will be great. Every year has its ups and downs, but there were many positives in 2024 so the bar is set quite high. Even though the resolutions list isn’t small, it’s mostly about some lifestyle changes. But in general, I just want a bit more of the same, nothing wrong with that, right?

What I wish for

A world with less conflict… Not only less war in the world but also less screaming and more decent conversation. The term “woke” already has a negative ring to me because it makes me think of people screaming instead of conversing. Those screaming people should know that sometimes, they actually do more harm to their cause than helping the world move forward. I know that in the end, screaming might be all that is left to do, but really, for the sake of a better world:

Converse, be patient, converse some more, scream later

I also wish that we for a free web because the web belongs to everyone. A better web, that is more performant and accessible.

It’s the World Wide Web, not the Wealthy Western Web. - Bruce Lawson

Special thanks

To you… the person reading this.

I am grateful, the list is long. I hope that most people that should know…know. If not, well, it’s in my 2025 resolutions.

But now, it’s time to close off and have a great start to the New Year with some friends.

Wherever you are, no matter which part of the world, no matter which holiday you were celebrating, I hope you are safe, that you have the warmth of family and/or friends around you, and that if you had a bad year, the year switch makes you hopeful and gives you energy, if you had a great year, the next will be just as well.

Happy New Year!
Brecht

(Credits: I went a bit lazy crating this articles visual by using a fireworks svgs created by freepik.com

Stylish holidays! Creating a scroll-driven Christmas tree in CSS

Brecht De Ruyte — Tue, 17 Dec 2024 00:00:00 GMT

SVG, scroll-driven animations, anchoring, @property, offset-path, and container style queries combined

This year, I went for a Christmas tree with a whole bunch of goodies in it. That does mean that I had to drop a bit of browser support for it. This year, my Chrismas greetings are Chromium only… sorry 🙁

The idea behind this article is more about my thoughts and technique behind it, but for how each and every one of those CSS features works, I’ll drop a bunch of links at the end of this article.

But first a video of the finished product, or you can click here to go to the CodePen at the bottom right away.

Your browser does not support the video tag.

The setup: A bunch of SVG work.

The first thing I had to do was to create my assets. I had 2 single path drawings. One of the tree and one for the baubles. The inside of the baubles were created later on, but the important thing was that they were the same shape and size, to keep my coding consistent.

I knew I was going to animate the strokes of these SVGs with stroke-dasharray and stroke-dashoffset, so I needed to get those values. I used Illustrator to create my assets, and if you want to know the correct length for these values you can go to window > document info. Inside that panel, you can click the hamburger menu icon and you will find objects. The first thing you will get to see is the path info that holds a length.

I had to set these values as variables and I knew I was going to do some animating with them inside of a single timeline, this is why I chose the @property syntax right away.

@property --o-tree {
  syntax: "<number>";
  inherits: true;
  initial-value: 1031.69;
}

@property --o-ball {
  syntax: "<number>";
  inherits: true;
  initial-value: 148.443;
}

Setting up HTML: The star that follows…

I’m not going to go through everything inside of the HTML, but this is the basic outline (explainer below):

<div class="tree-wrapper">
  <div class="svg-items">
    <svg class="ball ball__3">
      <path class="ball__path" d="..." style="stroke:var(--color-ball-3);" />
      <path class="ball__inner" d="..." />
    </svg>
    <svg class="ball ball__2">
      <path class="ball__path" d="..." style="stroke:var(--color-ball-2);" />
      <path class="ball__inner" d="..." />
    </svg>
    <svg class="ball ball__1">
      <path class="ball__path" d="..." style="stroke:var(--color-ball-1);" />
      <path class="ball__inner" d="..." />
    </svg>
    <svg class="tree">
      <path d="..." style="var(--tree-color)" />
    </svg>
  </div>
  <div class="star">
    <div class="spark"></div>
  </div>
</div>

The tree-wrapper, will be my single point of animation, passing through custom properties to all its children
We have 3 ball__path items that have the exact same stroke, those are the outlines, the ball__inner items are purely the decorations which will fade in at the end.
The tree has a single path containing the tree outline
Finally, we have our .star that will follow along the same path as the stroke-dashoffset with offset-distance. We will attach the star to the correct elements by using anchor positioning.

You might notice that I’ve used some lazy inline CSS with variables on my SVGs. I just set some colors for the strokes on my root:

:root {
  --tree-color: #1d5b2d;
  --color-ball-1: #5386e4;
  --color-ball-2: #e072a4;
  --color-ball-3: #0e7c7b;
}

I will break this demo down as much as possible without getting lost in details.

The tree and baubles

We have a bunch of offsets that we will need to animate, these are set with @property, we will set the initial value to 0. The starting points of these are already declared by --o-tree and --o-ball

@property --dash-offset-tree {
  syntax: "<number>";
  inherits: true;
  initial-value: 0;
}

@property --dash-offset-ball-1 {
  syntax: "<number>";
  inherits: true;
  initial-value: 0;
}

@property --dash-offset-ball-2 {
  syntax: "<number>";
  inherits: true;
  initial-value: 0;
}

@property --dash-offset-ball-3 {
  syntax: "<number>";
  inherits: true;
  initial-value: 0;
}

Presentation styles aside, the tree itself has the following CSS:

.tree {
  stroke-dasharray: var(--o-tree);
  stroke-dashoffset: var(--dash-offset-tree);
  anchor-name: --tree;
}

Here you see that we set the stroke-dasharray to the value we set in --o-tree, the stroke-dashoffset will start with the previously set base-value, but we will update that with the timeline to end at 0. We also set an anchor-name, this is where the .star will be aligned to. We actually do pretty much the same for all of the baubles, here is an example of the first one:

.ball__1 {
  anchor-name: --ball-1;
  .ball__path {
    stroke-dasharray: var(--o-ball);
    stroke-dashoffset: var(--dash-offset-ball-1);
  }
}

Just like before, this gets a unique anchor-name and the path containing the bauble outline will get the stroke-dashoffset animations.

The wrapper that passes everything

It’s time we talk about the .tree-wrapper. As this is our single point of passing through custom properties. Once again positioning and presentation styles aside, this is the code:

.tree-wrapper {
  --star-anchor: --tree;
  --dash-offset-tree: var(--o-tree);
  --dash-offset-ball-1: var(--o-ball);
  --dash-offset-ball-2: var(--o-ball);
  --dash-offset-ball-3: var(--o-ball);
  --scroll-me-opacity: 1;

  animation: story auto linear;
  animation-timeline: --page-scroller;
}

We will set the position of the star to the --tree anchor as this is the starting point. The dash-offsets are set equally to their maximum offset size, we will update those while scrolling to 0.

Finally, we call our story animation and set the animation-timeline to --page-scroller. This can be found in my root.

html {
  scroll-timeline: --page-scroller block;
}

I know this isn’t necessary as it is the root scroller I’m using, but I like a named timeline.

The star

The custom properties for the star are the following:

@property --star-offset {
  syntax: "<percentage>";
  inherits: true;
  initial-value: 0%;
}

This will control the star offset, aka, the animation path it will follow.

@property --star-opacity {
  syntax: "<number>";
  inherits: true;
  initial-value: 1;
}

This will update the opacity from time to time, right between jumping between anchors

@property --star-transform {
  syntax: "<transform-function>+ | none";
  inherits: true;
  initial-value: none;
}

This is a property for a space-separated transform list. This is used at the end to enlarge the star.

The star itself:

.star {
  --ball-path: path(..);
  position: fixed;
  top: anchor(var(--star-anchor) top);
  left: anchor(var(--star-anchor) left);

  opacity: var(--star-opacity);
  offset-distance: var(--star-offset);
  transform: var(--star-transform);
  transform-origin: center;
  offset-path: path(...);
  @container style(--star-anchor: --ball-1) {
    offset-path: var(--ball-path);
  }
  @container style(--star-anchor: --ball-2) {
    offset-path: var(--ball-path);
  }
  @container style(--star-anchor: --ball-3) {
    offset-path: var(--ball-path);
  }
}

Woah, a lot is happening here, I know, bear with me. Firstly, I set a general --ball-path variable, which contains the path of the bauble outline. The actual default offset-path property on the star is the same as the tree path. Also, notice that we are setting --star-anchor, this contains --tree as a starting name, but we will update that custom property during the animation, switching it from --tree, to --ball-1, --ball-2, etc.

In those cases, the offset-path should be the shape of a bauble, which is why we use style queries to set the offset-path to that shape when the anchor changes.

The timeline

To create my scroll, I just set the body to a min-height of 500vh. The timeline itself might be a bit much…, but I enjoyed making this. You can view the full timeline in the CodePen below. But here is a short explanation of what happens in the timeline:

The star keeps the opacity of 1 for the start of the animation
Meanwhile, the anchor of the star is set to the --tree and the offset is placed to 100%, creating the animation along the path.
Between that 1% the star fades-out
From 0% to 25%, the stroke-dashoffset of the tree gets animated from the start value to 0.
Very quickly (25.1%), the stars offset gets reset and the anchor is shifted to --ball-1, also triggering that style query we wrote before an setting the correct offset-path. The stroke-dashoffset of the ball is set to the initial value of 148.443, ready to be animated to 0 as well.
The star fades in and stays like that in for some time
50%, we repeat this story to go over to --ball-2, with a reset of the anchor setting at 50.1%,
And we continue this loop till the end

@keyframes story {
 24% {
   --star-opacity: 1;
 }
 25% {
   --star-offset: 100%;
   --star-anchor: --tree;
   --star-opacity: 0;
   --dash-offset-tree: 0;
 }
 25.1% {
   --star-offset: 0%;
   --star-anchor: --ball-1;
   --dash-offset-ball-1: var(--o-ball);
 }
 28%,
 49% {
   --star-opacity: 1;
 }
 50% {
   --star-offset: 100%;
   --star-anchor: --ball-1;
   --star-opacity: 0;
   --dash-offset-ball-1: 0;
 }
 /* ... */
}

Happy holidays!

Even though this animation won’t run off the main thread (because custom properties just don’t…), it was just so much fun creating this demo. I’ll probably write one more article this year for a recap of 2024. But I just wanted to share my CSS Christmas card for this year.

Whichever holiday you are celebrating this end of the year, I wish you all a beautiful holiday season and a lot of love/warmth with family and friends.

See the Pen Stylish holidays! by utilitybend (@utilitybend) on CodePen.

Shout out!

Added to my CSS reset: interpolate-size, the quality-of-life feature we all wanted at some point

Brecht De Ruyte — Tue, 12 Nov 2024 00:00:00 GMT

So what’s this all about?

Well, it’s about this little CSS snippet that I will be adding to my CSS reset from now on:

:root {
  @supports (interpolate-size: allow-keywords) {
    interpolate-size: allow-keywords;
  }
}

That is, I will be adding this mostly for new projects. I’ll get back to maintaining some legacy projects later in this article. The thing that happens with this small snippet is that interpolate-size: allow-keywords sets a flag on a :root level, allowing you to transition from and to widths and heights that have a keyword value, for example: auto, max-content, min-content, stretch, etc…

To say it in fancy words: It allows you to animate between an intrinsic-size-keyword and a length-percentage.

At the time of writing this is only available in Chrome, which is why it’s best to add the @supports feature query.

Take the following demo as an example and hover or focus the buttons:

See the Pen Quick interpolate-size by utilitybend (@utilitybend) on CodePen.

By setting the interpolate-size on a root level, I was able to animate the text of the buttons when hovering or focusing on them, by going from a fixed width to an auto width:

button {
  width: 4rem;
  overflow-x: clip;
  transition: width 0.35s ease;
  white-space: nowrap;
  &:is(:hover, :focus) {
    width: auto;
  }
}

So this demo is actually not that much work, which is great, that’s the whole point of this demo.

It just gave me the superpower to animate to by using the auto keyword.

You can choose to do this case by case with calc-size()

If you’re like me, you’re also maintaining some projects you initially created some years ago. In those cases, you might not feel “safe” in changing the default behavior, because in some cases things could break or create unwanted animations.

In this case, the calc-size() function is a great idea. Instead of setting interpolate-size: allow-keywords on the root level, we could - based on the previous example - do the following:

button {
  /* same as before */
    &:is(:hover, :focus) {
      width: auto;
      @supports (width: calc-size(auto, size)) {
        width: calc-size(auto, size);
      }
    }
  }

You will still need the @supports query for now as at the moment this is still only available to Chrome. Do note that this is Chrome first, not Chrome only. This is a CSS feature that has a spec and it will come to other browsers eventually. Which makes it the perfect progressive enhancement. If you open the demo in non-supported browsers it just doesn’t animate, and that’s fine in most cases.

Some great use cases where keyword animation can speed up your development

In this section, I thought it would be nice to show where this “animating to size-keywords” can come in handy as a progressive enhancement.

A fun idea could be to have cards that animate on click, whether that is horizontal or vertical (I just had a bit of fun here), the idea is pretty much the same the whole time. In this demo I wanted an image container to grow based on the max-width of a card. Of course, there are other ways we could do this, but this makes it so easy to write and manage.

See the Pen interpolate-size: allow-keywords width by utilitybend (@utilitybend) on CodePen.

This is the code in nutshell:

:root {
  @supports (interpolate-size: allow-keywords) {
    interpolate-size: allow-keywords;
  }
}

.image {
  width: 0;
  overflow: clip;
  transition: width 1s ease;
}

.card:has(button[aria-expanded="true"]) .image {
  width: auto; /* set width auto when expanded */
}

.card {
  display: flex;
  /* ... */
  max-width: clamp(280px, 80vw, 600px);
}

What happens here is that the .image wrapper fills the space available (a space limited by the max-width of the card). We set this wrapper initially to zero and clip the overflow. When the button is pressed, we animate this .image wrapper to have a auto width that just fills the space. It can really help us to create cool effects, fast.

Another case is where we can toggle a setting for a platform’s navigation to show text or icons only, something I’ve seen a few times before. This is in my opinion the perfect example where a user probably doesn’t care whether something animates or not.

In the following demo, you’ll see just that. I also included an extra idea containing a collapse of a warning notification. Just to show some of those things you might encounter…

The code is pretty much the same as before, so I won’t go into it, but maybe it can help you in the future:

See the Pen interpolate-size: allow-keywords examples by utilitybend (@utilitybend) on CodePen.

I believe in progressive enhancements, and as this is a simple flag to turn on and off, it’s neat that the behavior of a page can be different between browsers, but stays easily consistent in the browser of choice.

Bonus: The update on the details element in combination with interpolate-size

First, I thought I’d write a separate article on this, but it just fits so nicely in these examples. While I was starting to create demos on this, a great article was released on this: more options for styling <details> by Bramus. There are some really neat examples on this and I suggest you read it, but with eyes on the interpolate-size feature let me summarise it just a little bit.

In my presentation “The future of UI is open” I talk a bit about exclusive accordions. This gives you the possibility to turn the <details> element into an accordion by combining them using the name attribute. Here is a basic example of that:

<details name="my-accordion">
  <summary>
    This is an example
  </summary>
  <!-- content -->
</details>
<details name="my-accordion" open>
  <summary>
    Of an accordion
  </summary>
  <!-- content -->
</details>

See the Pen Exclusive Accordion by utilitybend (@utilitybend) on CodePen.

Since then, something new was added and set to be released in Chrome 131. The ability to target the content of a <details> element instead of just the <summary>. This can be targetted by a pseudo-element named ::details-content. When reading about this the first time, I thought the following would be enough to animate this (but there is a caveat):

@supports selector(::details-content) {
  ::details-content {
    height: 0;
    transition: padding-block 0.3s, height 0.3s ease,
      content-visibility 0.3s ease allow-discrete;
    overflow: clip;
  }

  details[open]::details-content {
    height: auto;
  }
}

Unfortunately, this was not enough. There is a (new) property that is being set on the ::details-content pseudo-element: content-visibility. This property controls whether or not an element renders its contents. We will need to transition this property as well, and since this is a keyword, it’s a job for transition-behavior: allow-keywords.

I’ve written some basics on transition-behavior before, but I really should revisit it as the times when we can benefit from it seem to rise.

This is the updated code, note that we don’t actually need to set the values of content-visibility as these are handled by the user-agent stylesheet, but we do need to set the ability to transition it:

@supports selector(::details-content) {
  ::details-content {
    height: 0;
    transition: padding-block 0.3s, height 0.3s ease,
      content-visibility 0.3s ease allow-discrete;
    overflow: clip;
  }

  details[open]::details-content {
    height: auto;
  }
}

Another thing to remember is that allow-discrete should come last in the transition shorthand.

Here is the quick animated accordion I made (for Chrome 131):

See the Pen details element content animation by utilitybend (@utilitybend) on CodePen.

I know this might be a bit basic, which is why I suggest you check out the article by Bramus, I love the horizontal cards in it. But once again, this feature is a complete progressive enhancement as in some browsers that don’t support it, it just won’t animate. Although the HTML part of it has a full browser support… In case a user would use a browser that doesn’t support the name attribute for <details>, the details elements would still work, although not in an accordion manner but as single collapses.

And that’s it, just add it!

No need for big conclusions, I can only encourage you to set this in your CSS reset or reboot. This might be one of my favorite candidates for interop as well. It would be nifty to have this in complete browser support.

We should all invest more in smaller developer communities, or at least, try to

Brecht De Ruyte — Wed, 23 Oct 2024 00:00:00 GMT

When we think of conferences and Google DevFest, we usually think about the big cities and the huge events. And while I agree that those places are probably worth a lot in marketing material, I also strongly believe we should think more about the small events. This occurred to me in local meetups, but also in Middlesbrough, which was a medium-sized event, but at heart was a conference that tried to place the North of the UK on the map. The same passion and dedication were felt in the Isle of Man. A handful of people trying to bring developers together, showing the world, that they too have a community - maybe small - but brave and full of talent.

I know that if you’re a speaker, you are probably skimming this article as fast as possible, but I promise to make my point quickly and well before the end of this article.

Harley and Darren, are two fantastic people trying to place the Isle of Man on the map by starting a GDG and organizing a Google DevFest. From my first interview with Harley, I felt the passion and the desire to grow. As a GDE we do get travel reimbursed by Google for DevFest events and even though it was almost 11 hours of travel, I decided to go to check out the community on this Isle and I say so without regrets. So instead of giving a full story, let me just answer a few questions:

Even if my hotel is sponsored, why should I travel to an event so far away?

Look, let’s be honest here, I know as a speaker we probably won’t pay ourselves to go and give a presentation. But if your flight and hotel are reimbursed why are you always aiming on the big ones? Why did you start speaking? Is it out of the inner ego trying to get yourself on video and getting likes and hits? I hope not, I sincerely hope you are doing it for a passion, a passion for sharing, a mission to inspire young people, getting to know new people and talk about tech (and maybe do some sightseeing while at it ;) ).

And that’s exactly what you should do. I can guarantee that I hadn’t met anyone present at the Isle of Man before, and I had wonderful conversations. I heard people who hope to have a bigger community that grows. I saw very inspiring people from Code Club IoM showing kids a way into coding for over 10 years out of pure passion. That… is golden.

Yes, you might be speaking at about 40 people tops which is smaller than some meetups in bigger cities, but I’d rather talk to 40 passionate people, than 90 people who are mainly there for the free food. To be honest, for me, the talk barely mattered, I feel that this trip has made me grow, and left me inspired and energized to do more where possible.

And if that doesn’t convince you…

I can tell you, you will be treated wonderfully. Harley and Darren picked me up at the airport, bought me a fantastic meal and we had a fantastic chat the first day. I felt right at home. If you go to these kinds of places, you’re not a number, you are the person they trust to help them grow by giving community enthusiasts more hunger for these events in the future. Yes, don’t let the 40 people turn into a conclusion it doesn’t matter, maybe - just maybe - it might mean more.

So please… make the extra effort if you’re able

Even if it takes you double the time for fewer people. Even if you’d have to transfer planes just to get there. If you can get your travel reimbursed, go for it. You can thank me later for this tip.

Before I get a whole lot of people shouting bad experiences to me… yes, those might also exist and I might not have run into them as a “junior speaker”. But also make sure that when you go to these events, that you are humble. Do not act as the big shot speaker (that you probably are) but act like me, the junior guy with the imposter syndrome.

About the GDG Douglas - Isle of Man

If you were just here for my rant, you can stop reading now. But I can’t just leave this article without writing a bit about my experience on the Isle of Man.

On the first day after a long trip, GDG group organizers Darren and Harley from Craft Applied were waiting for me at the airport. After a drive, saying “hi fairies” when crossing the fairy bridge (mandatory) and a quick bag drop-off at the “Sefton” hotel (which was lovely), we went for a speakers’ dinner. This is where Felipe joined in, who is also an organizer, but more about him later. We had a lovely conversation about a lot of things and also talked a bit about shop, but we made it an early night. I was dead tired and they had to get some early sleep before the event.

The morning after - the day of the event - I was awake way too early as always. So I took a walk around the Douglas while everyone was still sleeping. What a beautiful place!

The DevFest at Douglas

I arrived on time, met up with everyone, and had a bit of coffee, you could feel the nerves of the organization a bit, it showed their passion for making this a success. Luckily one of the organizers Bransom Bean was an expert in lightening the mood. You just feel it, these people have one goal: bringing developers together from all over the Island.

A bit later, Dominika Zając, the first speaker of the event arrived. After just a brief introduction, I could feel her passion as a GDE. I knew right away this was going to be a perfect start to this event. It was a great talk on accessibility with examples, jokes, and memes, and it opened a lot of questions and discussions over the day. I’ve seen quite a few accessibility awareness talks, but never with this kind of positive energy and great spin on AI and DevTools. You could tell she knows her stuff and there was probably a lot more she could talk about when given the time.

Next up was Guneet Mutreja on “Leveraging Machine Learning and Google Earth Engine for Satellite Data Processing”. As a webUI geek, this might’ve been a bit too far off my domain, but still, there were some great examples in there of city growth and global warming illustrated. Unfortunately, the audio wasn’t always perfect and I’m quick to lose attention when watching a video in a conference… Sorry Guneet, it’s not you, it’s me 🙂

The next presentation was named “Is it still coding if there are no lines of code?” and this was an amazing talk given by Felipe Ceotto and Owen Cutajar. What’s better to see than two passionate people getting kids into coding from their early years until their teenage years and beyond… They’ve been doing this for 10 years(!!!). It shocked me how casually they were saying that! I thought this was a major achievement in itself. So interesting to see how they evolve techniques in coding to keep kids to teenagers interested, from Scratch to Lego, to Unreal engine,…

I needed this talk, We needed this talk, we need these kinds of people. These are the things that matter and I wish them many more years and successes to come. More info on https://codeclub.im/

After some great lunch with sandwiches and desserts, it was my turn to talk about popovers, invokers, and customizable selects. I’ll cut this part of the story short as it feels wierd talking writing about myself, here is a picture:

As a closure of the day, we went from solving problems with UI to Solving problems with AI by Chris Kissack. It showcased many good ideas on how to make the best use of AI making your life easier but at the same time raised a variety of questions, and I loved how Chris tackled this. Let me be honest, after a year of conferences full of AI, it’s hard to create something fresh, and this presentation was something very welcome as it also illustrated some findings Chris had by working with young people, as well as the elderly. Had a lovely chat with him as well.

So yes… Isle of Man has some great talent, and even if not the biggest community, a very heartwarming and dedicated one that asks great questions and opens beautiful conversations full of pure interest and respect.

After the event, we all went for some drinks, which was lovely but then something happened. I received an email…

Your flight has been canceled due to “storm Ashley”

I was supposed to leave the day right after but that sure wasn’t going to happen. I contacted the travel agent and they helped me right away.

I got an extra night and a new flight for Monday (Thank you Google and thank you to the worktrips.com team… really!) It took a little while to get finally sorted, which makes sense but they were so helpful, and patient an made me feel at ease. So I continued with my original plan of that evening and visited Summerhill Glen together with Dominika. She was already planning on staying Sunday as well and she offered me to do some sightseeing together. This Island is absolutely magical…

After handling things with iO, I was happy that I could just take that extra day and enjoy it to the fullest. I decided to work on the airport on Monday during a long layover period.

An extra day - Isle of Man, there is something magical there

Forget about the TT motor race for a second, there is a lot to see and do for tourists at the Isle of Man. The beautiful vistas, nature, steam train. I am grateful I got to spend this other day, and also thankful for - my partner in crime for a day - Dominika. Exploring is always more fun when you can share some laughs, I hope we run into each other at another event in the future, maybe I’ll give that karaoke a try (big maybe). Later in the evening, we met up with Darren and Harley again, they seemed well rested and happy, it was great to see.

After a good nights rest, they drove us to the airport.

Yes, it was a long travel and I had a 6-hour layover time due to the other route, but it was worth it. Will I go to the Isle of Man again any time soon? That I don’t know, but one thing is for sure…

This event, the people, and the Island will always have a special place in my heart.

Is the sticky thing stuck? Is the snappy item snapped? A look at state queries in CSS

Brecht De Ruyte — Tue, 17 Sep 2024 00:00:00 GMT

For this article, I’d like to start by showing how we could use state queries in Chrome Canary for now, following up with the scroll snap events in JS. But first, a small warning that these are still experimental features at the moment of writing. To view the demos, you should be using Chrome Canary, go to chrome://flags, and enable the Experimental web platform features. To support some quick reading of the article, videos of the demo will be provided as well.

The basic syntax of a state query

The current implementation of a state query re-uses the container-type property in pretty much the same way as container queries. So to check the state, we need it to set that container-type in order to query the children inside of it.

<div class="the-container">
  <div class="the-query">
  </div>
</div>

For now, the state queries are all about scroll-state but this might change in the future. The first thing we’d have to do is set the container-type accordingly:

.the-container {
  container-type: scroll-state;
}

Now that this is set, we can use a state query:

.the-container {
  container-type: scroll-state;
  .the-query {
    @container scroll-state(<scroll-state-type> : <scroll-state>) {
	/* Do something with this based on .the-container state */
    }
  }
}

Ok, that’s enough high-level information, let’s get practical.

State queries for sticky positioning

Is the sticky thing stuck? A lot of us have been there, we have a header navigation that should remain sticky and should only show a shadow from the moment it gets stuck. It always involved some sort of extra scripting to get this working, or we just put the shadow on there by default. But with state queries, all of this is over and we could just use CSS for it.

Let’s set up the basic HTML:

<div class="topbanner">
  <!-- A top banner, non-sticky -->
</div>
<div class="header-container">
  <!-- header-container will be sticky -->
  <header>
    <div class="container">
      <h1>Some title</h1>
      <nav><!-- nav items --></nav>
    </div>
  </header>
</div>
<div>
  <!-- A lot of content with main and aside -->
</div>

Let’s set up the container-type and the sticky positioning:

.header-container {
  container-type: scroll-state;
  position: sticky;
  top: 0;
}

We want things to go a bit smoothly so let’s also set the header to have a transition for the box-shadow:

header {
  transition: box-shadow 0.5s ease-out;
}

Now that our container-type is set, all, that is left to do is to create our state-query and add a box-shadow tot the header when the .header-container is stuck:

.header-container {
  container-type: scroll-state;
  position: sticky;
  top: 0;
}

header {
  transition: box-shadow 0.5s ease-out;
  @container scroll-state(stuck: top) {
    box-shadow: rgba(0, 0, 0, 0.6) 0px 12px 28px 0px,
      rgba(0, 0, 0, 0.1) 0px 2px 4px 0px,
      rgba(255, 255, 255, 0.05) 0px 0px 0px 1px inset;
  }
}

It’s nice that we can use some nesting for this as well. Do note that if this lands Chrome-first we might want to provide this as a progressive enhancement. We can do this with a feature query, and for this example, it might be a good idea to just handle this with a bit of CSS nesting to not repeat ourselves too much:

.header-container {
  position: sticky;
  top: 0;
  @supports (container-type: scroll-state) {
    container-type: scroll-state;
    header {
      transition: box-shadow 0.5s ease-out;
      @container scroll-state(stuck: top) {
        box-shadow: rgba(0, 0, 0, 0.6) 0px 12px 28px 0px,
          rgba(0, 0, 0, 0.1) 0px 2px 4px 0px,
          rgba(255, 255, 255, 0.05) 0px 0px 0px 1px inset;
      }
    }
  }
}

If you are wondering about the other values for the stuck query, they handle all directions, including logical property variants.

All the query values for stuck:

none
top
left
right
bottom
inset-block-start
inset-block-end
inset-inline-start
inset-inline-end

With a few more bells and whistles, this is the final demo, I created:

See the Pen Sticky headers with scroll-state query, checking if the sticky element is stuck by utilitybend (@utilitybend) on CodePen.

Your browser does not support the video tag.

State queries for scroll-snapping

Is the snappy item snapped? From the moment Adam Argyle gave his “Oh Snap!” presentation at CSS day 2022 it was one of the things missing. How can we know if an item is snapped? There was a great workaround with IntersectionObserver, but let’s be honest, it wasn’t the thing we wanted, there just wasn’t a better alternative. But now there is, in two forms actually, one JavaScript solution planned to be shipped in the next Chrome release that gives a lot more than just the snapped item, but also state queries.

Since I started with state queries, let’s tackle that one first. The setup is pretty much the same as before, but let’s first create a scroll snap situation:

<div class="list">
  <ul role="list">
    <li><span>1</span></li>
    <!-- And a few more of these list items -->
  </ul>
</div>

Let’s set up some quick and easy CSS to create our scroll-snapping situation:

.list {
  max-width: 90vw;
  scroll-snap-type: x mandatory;
  overflow-x: auto;
  padding-left: 40vw;
}

ul {
  display: grid;
  grid-auto-flow: column;
  gap: 1vw;
}

li {
  scroll-snap-align: end;
  width: 29vw;
  height: 470px;
  span {
    display: flex;
    align-items: center;
    justify-content: center;
    width: 100%;
    height: 100%;
    background: slateblue;
    transition: background 0.4s ease-out;
  }
}

I know that this is a bit of a quick and dirty way to create the scroll-snapping situation, but this will create a good setup for our demo, you should have something like this:

Now we want the item at the end to change background-color when it gets snapped.

For this, we will add the scroll-state container query and set the scroll-state type to “snapped” followed up with the direction we want to snap, in this case, “inline”.

li {
   /* previous things */
  span {
    /* default span styling */
  }

  @supports (container-type: scroll-state) {
    container-type: scroll-state;
    @container scroll-state(snapped: inline) {
      span {
        background: lightcoral;
      }
    }
  }
}

By setting the container-type to the list-item we can check inside of its children whether this container is snapped or not, when we do that, we can do all sorts of things to those elements such as changing the background-color.

With a bit of presentation styles, this is that demo:

See the Pen Scroll-state query to check which item is snapped with CSS by utilitybend (@utilitybend) on CodePen.

Your browser does not support the video tag.

The query values for snapped are pretty straightforward:

inline
block

Taking it a step further and combining it with CSS anchor positioning

A few months ago, my daughter started to show interest in Pokémon. She then started watching the first Indigo League series.

I felt inspired by this and wanted to create something fun for her based on the previous demo. The setup is pretty much the same as the previous demo, but let’s take a look at the result first:

See the Pen Scroll-state query to check which item is snapped with CSS, Pokemon version by utilitybend (@utilitybend) on CodePen.

Your browser does not support the video tag.

So quite a few animations are running when the item gets snapped, but the special case here is the frame that moves over the snapped item. To create this effect, we can use the newly available CSS anchoring positioning API. Here is how that works:

We re-use the .list we had before, but as a sibling to the ul, a .frame is placed:

<div class="list">
  <ul role="list">
    <!-- List items -->
  </ul>
  <div class="frame"></div>
</div>

Next up, set the .list to a position: relative and the .frame as position: absolute:

.list {
  position: relative;
}

.frame {
  position: absolute;
}

We’re going to set the position of the frame based on the snapped item, to do this (and remember, the basic setup is almost the same as the previous demo), we add the following to our state query:

li span {
  @supports (container-type: scroll-state) {
    @container scroll-state(snapped: inline) {
      anchor-name: --active-item;
     }
  }
}

Each time that our item gets snapped, the item gets an anchor-name, and all that is left for us to do is to position our .frame based on that anchor-name as well as set the sizing. We also add a little transition for the delay effect:

 .frame {
  position: absolute;
  top: anchor(--active-item top);
  left: anchor(--active-item left);
  width: anchor-size(--active-item width);
  height: anchor-size(--active-item height);
  transition: left 0.2s;
  border: 10px ridge slategray;
 }

And that’s pretty much all it takes. If you’re unfamiliar with anchoring, I wrote an intro to CSS anchor positioning a few months ago that you can check out.

Keeping that Pokémon inspiration going, It’s time to talk about some net JavaScript events.

Scroll-snapping JavaScript events

Expected to come in Chrome 129, we are getting some new events for scroll-snapping:

scrollsnapchanging
scrollsnapchange

This means that we will get these before state-queries in CSS. Let’s break them down:

I re-created a list of Pokémon just as before, this time adding an id on my .list:

<div class="list" id="pokedex">
  <ul>
    <!-- bunch of list items -->
  </ul>
</div>

The list itself is what contains the scroll-snap-type property, this is important. In this demo though, we’re scrolling the Y-axis:

.list {
  position: relative;
  max-height: 60dvh;
  scroll-snap-type: y mandatory;
  overflow-y: auto;
}

Scrollsnapchanging

The scrollsnapchanging event is dispatched multiple times while a user scrolls as new snap points are selected by the browser. At this moment the actual snap hasn’t occurred yet.

Scrollsnapchange

The scrollsnapchange event is dispatched once a scroll completes, indicating the newly snapped element. Thus, the actual “snap” has occurred.

Visualizing the difference

In the video below, you can see my demo at work. I open up the Pokéballs on scrollsnapchanging, and reveal the Pokémon on scrollsnapchange.

Your browser does not support the video tag.

Here is that code in a nutshell:

const listItems = pokedex.querySelectorAll("li");

pokedex.addEventListener("scrollsnapchange", (event) => {
  setTimeout(() => {
    listItems.forEach((listItem) => {
      listItem.classList.remove("active");
    });

    event.snapTargetBlock.classList.add("active");
  }, 200);
});

pokedex.addEventListener("scrollsnapchanging", (event) => {
  listItems.forEach((listItem) => {
      listItem.classList.remove("changing", "active");
  });
  event.snapTargetBlock.classList.add("changing");
});

And here is that demo for you to play around with:

See the Pen Scroll snap events with JavaScript by utilitybend (@utilitybend) on CodePen.

As a fantastic extra resource: A great demo by web.dev can be found here, a great visualizer for scroll snap events

Some closing thoughts on state-queries and the lack of a pseudo-class

So, state queries do pretty much what I hoped them to do, they certainly are a lot more versatile than adding pseudo-classes such as :snapped or :stuck. There is however one thing, especially for scroll snapping where I thought a pseudo-class might’ve been handy.

A combination with :has() would’ve been handy to target the previous siblings of the snapped item for some visual effects, Eg:

li:has(+li:snapped) {
  /* Might've been handy */
}

But of course, there are ways around that in the future with style-queries, especially if we go beyond custom properties for those, and let’s not forget that scroll-driven animations can help us a lot with visual effects.

Even though I think it would’ve been a nice addition, I like this a bit better because it’s more multi-purpose, and updating the container-type for more purposes seems to make perfect sense.

This is of course still experimental, but this is a real quality of life improvement I’m really looking forward to use, starting as a progressive enhancement.

A spec update on CSS anchor positioning

Brecht De Ruyte — Fri, 09 Aug 2024 00:00:00 GMT

Naming things is hard and that’s what this is all about, we were warned on CSS Day by Tab Atkins that this spec might still update, so here are the two changes:

Change 1: position-try-options becomes position-try-fallbacks

Starting from Chrome 128 position-try-options will be renamed to position-try-fallbacks. I’ve already updated my examples to be compliant with the latest version of the spec. Yes, the examples might be broken a bit in the current stable Chrome version while writing this (127), but I do believe that this is the way forward so no use in keeping the old name for now.

Change 2: Inset-area becomes position-area

Starting from Chrome 129 (Current Canary version) the inset-area property will be renamed to position-area.

Currently, I’ve updated my examples to support both syntaxes as Chrome 129 is a few more months away. You will now see those examples like this:

.anchored {
    inset-area: top span-all;
    position-area: top span-all;
}

This ensures that when position-area is not supported, it will fall back to inset-area. In due time, I will remove the inset-area.

Updating an article… just this once

I usually do not update articles, but in this case, I will update my previous anchoring article. With a small disclaimer linking to this information you’re reading here. Mostly because it’s still a recent article that has a decent amount of traffic and I want to inform people correctly.

You can find the updated version of the CSS anchoring article here.

It’s Time To Talk About “CSS5”

Brecht De Ruyte — Mon, 05 Aug 2024 00:00:00 GMT

Read the article at Smashing Magazine

Time for a little break - summer 2024

Brecht De Ruyte — Sun, 21 Jul 2024 00:00:00 GMT

I need to be honest right off the bat here. I have been doing a bunch of conferences and meetups lately and noticed that I lost a bit of the time where I would’ve created some demos and played around with new things. I’m also very behind on all the articles in my RSS feed. The last week or so, I’ve been catching up on those a bit, but as this week has ended, it’s time for me to do a complete shutdown for a bit when it comes to writing, demoing, and presentation creations. It’s also time to read some of that non-web-related stuff I’ve postponed.

A quick throwback

Let’s start with the beginning of June, I will not talk about the articles I’ve written as you can find those here, but I do want to look back at some of the awesome events. This piece will probably have the most pictures of myself in like…ever. But sure, why not I guess…

CSS Day and CSS Café

I’m always happy to return to CSS Day, so many people I get to see again or get to meet for the very first time. This is always a great one for me and feels like coming home. I did a full article on CSS Day at the tech_hub and they’re uploading the presentations weekly now. I want to encourage people to go to these conferences as you get to talk to a lot of people and you can take away so much more than just watching videos. So, for that reason, here is me probably trying to explain some Open UI demo I created to Joey Arhar using hand gestures as he knows a lot more about how this stuff works than I do.

(Photo by Richard Theemling for CSS Day)

Google I/O Connect

As a Google Developer Expert, I was invited to Google I/O Connect in Berlin. I absolutely had a fantastic time. There were some interesting Q&A sessions and so many things to see and do. I got to hang out a bit with Bramus and Una and meet some Googlers who work on fantastic stuff such as Barry Pollard, Sam Dutton. So nice to have a chance to talk to them in-person.

I had a demo about speculation rules by Jeremy Wagner who sold it to me like a pro (yes… I probably WILL write an article about that later this year). And of course, I had my colleague from Amsterdam Dave Bitter with me, always a pleasure to hang out with him.

The things at Google I/O are probably worth an article by itself, but for now, I’ll keep it to these brief words. I do have a head full of wonderful memories and hope to do this again next year.

Middlesbrough Front End

I got to speak at Middlesbrough Front End this week. It was quite exciting for me as it was the first time that I had to give a presentation to so many people who are native English speakers. I was dead tired when getting there due to some delays with the train, But thankfully I met one of the speakers there, Lu Wilson, also known as TodePond. If you read this Lu… thank you for getting me through that train ride! For those that don’t know Lu, you probably should as they are working on something cool called tldraw.

But honestly, once I arrived, everything was perfect, the people managing the event were awesome and the other speakers were so friendly and kindhearted that I quickly forgot the delays and lack of sleep. I am so happy I got to meet them, I’ll be honest, I was a bit starstruck as well. I had some insightful food tips from Harry, was amazed by all the things Daniel worked on, and was blasted away by the entertainment surge Salma ( I could never to Twitch, but really, I might start watching it a bit from time to time, I got convinced I guess). I also got to talk to Michelle IRL, which is funny, because I’m a long-time reader of CSS-IRL. Really, to all of them, it was an absolute blast.

I also met Jake Archibald, I felt like a groupie “hey, I love your podcast”. But really, super friendly, and it was a pleasure.

A lot of them are far more experienced than I am, and hearing from them they enjoyed my presentation (or even took notes) meant a lot to me. But in general, except for a little microphone beep at the start of my talk, I’m pretty happy, the attendees have been so good to me, and the organization as well.

It’s in my nature to mostly remember what I didn’t do well and where to improve. But I went home satisfied, even though I still have a full list of pointers, I feel I did ok.

I recommend this conference to everyone, and I hope it keeps existing. A beautiful conference, professionally handled in the North of England where you feel that community matters. I will be promoting this conference in the future because I believe this is an important one for the North UK community.

Here’s a few pictures

(Photo by Colin)

And an after-event-drinks photo: FLTR: Lu Wilson, Me, Shawn Anuptra Martin, Michelle Barker, Ryan Varley.

(PS, after the event, Shawn started blogging, check it out here.)

And then now: A well-deserved holiday

I’ve met so many people in the last month, it’s been absolutely bonkers…

But for now, it’s time… Yes, time for family, to go on trips, to amusement parks, and to the zoo. Time to read that book I never got to. Enjoy our garden and create + eat tasty food.

I also started some golf lessons, just out of curiosity which I will take during this summer.

So yes, It will be packed with a lot of things to do, but when it comes to the web, I’ll mostly just be boosting some posts from time to time, not creating demos, not joining meetings, a bit of digital detox. I’ve already written an article that might still get published during my holiday, but that’s about it.

So to everyone out there, enjoy your holidays, I know I will.

An update on invokers: Invoker commands in HTML

Brecht De Ruyte — Mon, 15 Jul 2024 00:00:00 GMT

A note of warning

What I’m writing about is still experimental. The invoker commands feature is being made available in multiple browsers, however, I tested my demos in Chrome Canary. If you want to play around with them you’ll have to enable the Experimental Web Platform features after going to chrome://flags

Update 10 March 2025:

This article was slightly updated with the latest syntax
In Chrome 135 invoker commands will be available for dialogs, popovers and custom commands, more info on the Chrome blog
At current state, Chrome Canary needs to be launched with the following flags for the video, picker and stepper examples: --enable-features=HTMLInvokeActionsV2,HTMLCommandActionsV2
I plan to write some updated information on this later on, but most of this article still adds up for the future of invokers

Why care about an experimental feature?

The reason you should be interested in this feature is that talking about it does help to move things forward. If we notice a big interest from people, it gets placed on top of the pile by the different working groups out there.

I will be re-using some of the older demos I created and will add a new one as well. I’ll once again cover some of the basics while also adding a few differences compared to the previous explainer. If people land on this page, they don’t need to go back and forth on demos, so it seemes like the correct thing to do.

The basics: Creating a button and adding a command

For the basic example, let’s take a look at how we could trigger a dialog by just using HTML:

<button commandfor="my-modal" command="show-modal">Trigger dialog</button>
<dialog id="my-modal">This is my dialog</dialog>

This opens the dialog element in the top-layer with the ::backdrop pseudo-element attached. The only thing needed is the commandfor referencing an id and the command attribute specifying the showModal action.

Your browser does not support the video tag.

One new thing compared to the old explainer we need to take into account is that when the command attribute is missing it will default to an invalid state. There will be some exploring to enable implicit command and/or commandfor values where the value can easily be inferred. (but probably after the initial shipping of the feature)

Taking it one step further, what happens when you want to create your own little close button? Well, you could just add the following inside of your <dialog>:

<button commandfor="my-modal" command="close">
  Close
</button>

Most of the time, when creating these kinds of experiences, we want a click on the ::backdrop to trigger a close event of the dialog. For that, we can write a bit of extra JS. This should be fine for that:

const dialogs = document.querySelectorAll("dialog");

dialogs.forEach(function (el) {
  el.addEventListener("click", ({ target: dialog }) => {
    if (dialog.nodeName === "DIALOG") {
      dialog.close("dismiss");
    }
  });
});

Update 10 March 2025:

At the moment, Chrome recently gained support for the closedby attribute.
<dialog closedby=“none”>: No user-triggered closing of dialogs at all.
<dialog closedby=“closerequest”>: User pressing ESC (or another close trigger) closes the dialog.
<dialog closedby=“any”>: User clicking outside the dialog, or pressing ESC, closes the dialog. This is similar to popover=“auto” behavior.

For the animations in and out of the top-layer we can rely on @starting-style. If you haven’t heard about that, I created an article about that a little while ago and the good news is that it’s part of Interop 2024.

It’s nice that this controls so easily, here is that CodePen demo (remember, tested in Chrome Canary)

See the Pen Invoke dialog by utilitybend (@utilitybend) on CodePen.

A note on popovers

The commandfor attribute can also be used to target popovers, this will be added with the initial release of the attribute. If an element has both a popovertarget and commandfor attribute, then popovertarget is ignored, or simply put: commandfor takes precedence.

The command attribute for popovers will handle the following options:

toggle-popover
hide-popover
show-popover

These are the equivalent of the attribute popovertargetaction with options: toggle, show, and hide.

In case you need to add other methods for closing, such as certain hardware buttons, do take a look at the CloseWatcher API. This API gets used under the hood for popovers and dialogs and is already available in Chrome 120 and has a polyfill.

What I love about these attributes is that we have so much that can be used straight out of the browser. Something that could only be achieved with custom scripting or libraries just a while ago. This is a great win for performance, but there is (potentially) a lot more to come… Let’s take a look at the potential next phases for invoker commands.

The future phase of invoker commands

Currently planned for a future phase in the invoker plan is to give the ability to invoke the <details> element and even form controls such as the <select> or certain <input> types.

The basics are still the same, for a <details> element we could add the following:

  <button commandfor="my-details" command="toggle">
    This will toggle the details
  </button>

  <details id="my-details">
    <summary>This is a summary</summary>
    This is the content
  </details>

With command having the following options:

toggle
open
close

Details were originally added to phase 1, but have been delayed. Let’s take a closer look at the input elements because those could potentially be a lot of fun.

Showing pickers with the command showPicker()

Imagine you want to create an <input type="date" /> with a custom icon, It would look something like this:

Now unless you do some hacks for the icon to be clickable (I’ve done some before), it could be nice to have this as an actual button just by using HTML and CSS. In that case, this could be our markup:

<label for="date">Pick a date</label>
<div class="input-group">
  <input id="date" type="date" />
  <button commandfor="date" command="show-picker">
    <!-- add an icon here -->
  </button>
</div>

And by just adding a bit of styling…

/* Remove the default date calendar picker */
[type="date"] {
  &::-webkit-calendar-picker-indicator {
    display: none;
  }
}

/* Style the input group with invoker */
.input-group {
  display: flex;
  [type="date"] {
  /*  Presentational styles here */
  }
  [commandfor] {
  /*  Presentational styles here */
  }
}

This could be a result:

Your browser does not support the video tag.

See the Pen Invoke date by utilitybend (@utilitybend) on CodePen.

(This demo does not work well inside the CodePen iframe, view it in debug mode)

The same technique could be used to trigger a <datalist> with a separate button. Note that we need to trigger the <input> element’s id, not the one from the datalist:

<label for="food">What would you like?</label>
<div class="input-group">
  <input list="foods" name="browser" id="food">
  <button commandfor="food" command="show-picker">
    <!-- icon -->
    Open input picker
  </button>
</div>

<datalist id="foods">
  <option value="🍙 Onigiri"></option>
  <option value="🍜 Ramen"></option>
  <option value="🍣 Sushi"></option>
  <option value="🥟 Dimsum"></option>
</datalist>

Your browser does not support the video tag.

See the Pen Invoke Datalist by utilitybend (@utilitybend) on CodePen.

Isn’t it great how natural this feels? The CSS also seems less hacky this way instead of doing some workaround. Giving us the option of using the browser’s built-in date or datalist option picker with a custom button. (That’s just lovely…)

This showPicker() action can be used on a numerous of elements: <input type="color" /> or <select> elements, or even <input type="file" />:

<label for="fileinput">Upload some files?</label>
<button class="uploadzone" commandfor="fileinput" command="showPicker">Click this huge square to upload</button>
<input type="file" id="fileinput" />

Here is a demo of that:

Your browser does not support the video tag.

See the Pen Invoke file by utilitybend (@utilitybend) on CodePen.

Truth be told, you could probably create this effect with the label itself, but this being an actual <button> element could be a handy tool.

Number inputs with custom steppers

A feature that would be welcome for people who create a lot of webshops ( I am such “people” ) is the ability to add custom stepper buttons on an <input type="number" />. There is a possibility to do this with invoker commands and this is how it works:

<div class="counter">
  <button commandfor="num" command="step-down">-</button>
  <input type="number" min="1" id="num" value="1">
  <button commandfor="num" id="btn" command="step-up">+</button>
</div>

Using the stepDown and stepUp events for the command, we can control the number of the input type. This takes into account any of the extra attributes on the input as well such as min, max, and step.

Using the HTML above and some extra styling this is something I created with it:

Your browser does not support the video tag.

See the Pen Invoke number by utilitybend (@utilitybend) on CodePen.

While still a big “if” when speaking about this feature (because, well.. Experimental and such), I love the idea of implementing this with invoker commands. It seems that this invoker idea is fantastic when it comes to consistency, and I can only applaud that.

There are a few caveats at the moment of writing. For the moment a "change" event doesn’t trigger when clicking our stepper buttons, this is something that has been discussed and is still in the works.

While we’re not done yet with all the things you can do with invoker commands, let’s take a little detour as events just came to mention:

Custom commands

Invoker commands will dispatch events on the Invokee element. Using a double dash as the start for the command allows for custom JavaScript to be triggered without having to wire up manual event handlers to the button. By listening to the command event listener we can attach our action to it:

<div class="counter-button">
  <input id="my-counter" type="number" value="0" />
  <button commandfor="my-counter" command="--add-num" value="10">+10</button>
  <button commandfor="my-counter" command="--add-num" value="50">+50</button>
  <button commandfor="my-counter" command="--add-num" value="100">+100</button>
</div>

<script>
const counter = document.getElementById("my-counter");
counter.addEventListener("command", (e) => {
  if (e.command === "--add-num") {
    counter.value = Number(counter.value) + Number(e.source.value);
  }
});
</script>

Your browser does not support the video tag.

There are more examples to be found at the Open UI explainer

See the Pen Invoker commands with custom action by utilitybend (@utilitybend) on CodePen.

Custom video and audio controls with command

I’ve been showing some short demos of this while presenting about the future of UI and this is one of those things where I notice people gasping and getting a smile on their faces. Seems like people really had some struggles when it comes to custom controls for video and audio. Well, I hear you and Invoker actions might just make all of these things a bit more easy.

This is how we could create a custom play button:

<video id="custom-video">
    <source src="..." type="...">
</video>
<button commandfor="custom-video" command="play">
    Play
</button>

Keeping the consistency going (love this!), we can create a command="play" attribute and this will fire that play event for the video. This works with a whole bunch of events such as:

play
play-pause (toggle between play and pause)
pause
toggle-muted
toggle-fullscreen
request-fullscreen
close-fullscreen

A bit of styling and you could create something like this:

Your browser does not support the video tag.

See the Pen Invoke command video - Would be cool to have :playing pseudo-class - cross browser for this by utilitybend (@utilitybend) on CodePen.

The only bit of JavaScript needed for this example is to add a class when the video is playing. This would not have been necessary if the :playing pseudo-class was supported everywhere, but unfortunately that isn’t the case at the moment.

In case you were wondering, the same kinds of things can be achieved for audio as well.

For more goodies and information about invoker commands, check out the following links:

Only the tip of the iceberg

I am only scratching the surface here, but if you want to read the full list of built-in commands being suggested, do check out the full list here.

As a conclusion to this update, I know that these things might change once again, but I do feel it’s important to talk about them. I feel this feature leads to more consistency and readability in code, and I’m a sucker for that sort of thing.

It’s more than a little quality-of-life update to HTML, but even if you think of it in that regard, imagine how many tedious tasks will get removed on a day-to-day basis.

Open UI is a group effort but once again, I do want to give a shoutout to Keith Cirkel and Luke Warlow, who really have put a lot of effort into this feature and are continuing to do so. After this explainer update, the experimental implementations in browsers are already being handled for an update as well, absolutely legendary.

Do remember that all of this is a work in progress. But if you like this and want to support this, create demos, provide feedback and make some noise.

Note that some of my examples in this article might not be the perfect accessible examples at the moment. Keep in mind, that the group is working on improving accessibility, it is a topic that is highly rated.

I do hope that by sharing these features people go check them out and give them a spin. I also hope that by writing this article and speaking about this, I can project a bit of my enthusiasm to others. Always feel free to tag me if you create something with them, I’d like to create a little collection on CodePen as well.

This was CSS Day 2024 - the 10th edition

Brecht De Ruyte — Thu, 27 Jun 2024 00:00:00 GMT

Read the article at iO tech_hub

Let’s hang! An intro to CSS Anchor Positioning with basic examples

Brecht De Ruyte — Mon, 03 Jun 2024 00:00:00 GMT

Before I get into the details of why some things are still missing in the Anchoring API, I want to get on the hype train. Because, no matter the small issues (or, let’s call them missed opportunities?) I spotted, this is something I wanted for a long time and it’s pretty awesome. The anchoring API has been inside of my future of UI talk for quite some time and in just a moments time, I had to change this from experimental code to specced code, and soon after as available in Chrome. Yes, you read that right, what we’ll be covering here is already available in Chrome 125 (at the moment of writing, the latest version).

For this article, we won’t be creating the most fancy examples out there, this is a (complete) basic introduction with clear examples. After reading this, you sould have a solid basic understanding on how this anchoring system works.

Note: This article and examples within have been updated on the 9th of August 2024 with the new spec. For just once, I decided to update this article. You can find information about the updates here.

Anchoring API - two specs merged into one?

There are currently two major ways how you can get anchoring to happen. Without going too much into the history, this is the short version of why that is: There was an experimental implementation with the anchor() function and @position-fallback (not position-try, we’ll get there) when a new idea was launched by Webkit with an alternative solution using more of a grid-like system. From what I can tell, some frustrations happened and this certainly slowed things down, but this has some benefits:

We get to have the best of both worlds, both ideas were great
The original anchor() idea is probably more powerful and versatile, while the grid idea gives a more easy and quick everyday solution

Besides that, there are a few downsides:

This is harder to teach to people as there are multiple ways in using anchors
Both methods don’t have a fallback for arrow indications on tooltips and I wanted both methods to have it on first spec… (more on that later)

This is why, in this article, I’d like to focus on all the basics with simple demos, but I’ll be adding some links to other sources and tools as well. Let’s start off with taking a look at the basics of these two methods:

The basics of anchoring with CSS

As we’re going for some solid understanding, let’s get the tutorial started by creating 2 <div> elements. For easy reference for the rest of this article, let’s name these with a class .anchor and .anchored.

<div class="anchor"></div>
<div class="anchored"></div>

Inside of the .anchor I added an anchor icon for reference, this is purely optional. Let’s add some basic styling to differentiate the two:

body {
  display: flex;
  flex-direction: column;
  place-content: center;
  align-items: center;
  margin: 0;
  min-height: 100vh;
}

div {
  height: 20vmin;
}

.anchor {
  background: goldenrod;
  aspect-ratio: 1;
}

.anchored {
  background: olive;
  aspect-ratio: 16/9;
}

The elements are placed in the center of our viewport by giving our body display: flex; We gave both of the div elements a relative height of 20vmin (20% of the viewport’s smallest side). We also added a different aspect-ratio to each of the items, this will come in handy visually later on.

Besides the extra background added to the <body> for prettifying the demo a bit, this should pretty much be the result:

Method 1: using anchor()

The first method is the closest to the original proposal back when I first heard about this API. Let’s introduce a few new properties, anchor-name and position-anchor.

First, we’ll need to define our anchor, this is where anchor-name comes in. Let’s add the following to our .anchor

.anchor {
  anchor-name: --anchortome;
  /* previous code */
}

The anchor name should be prefixed with -- , just as you would do with CSS variables but besides that, you can give it any name you want.

Next up, let’s add the position-anchor to our .anchored item, this will create the missing link (anchor) between the elements:

.anchored {
  position-anchor: --anchortome;
  /* previous code */
}

We don’t see much happening yet, that’s because we still need to position our items. To do this, we will absolutely position our .anchored element, and we will introduce the anchor() function to position it, this is the full updated code:

.anchored {
  position-anchor: --anchortome;
  position: absolute;
  top: anchor(center);
  left: anchor(right);
  /* previous code */
}

What we’re saying here is:

Place the top of this div to the linked anchor’s center, and place the left of this div to the right of the linked anchor.

This results in the following:

But there are more options available, we could use a <percentage> unit for our top, instead of using anchor(center) as the value of our top property, let’s add a percentage of anchor(20%). This would result in the following:

Besides percentages, you could also use logical properties for the alignment, for example:

.anchored {
  position-anchor: --anchortome;
  position: absolute;
  inset-block-start: anchor(center);
  inset-inline-start: anchor(end);
}

This way, you can anchor based on the writing mode.

See the Pen Basic anchor example by utilitybend (@utilitybend) on CodePen.

Method 2: Using the position-area syntax

Let’s remove everything we did in the first method and use a different approach to how we can anchor something.

On our .anchor, we’ll once again add the name, same idea as before:

.anchor {
  anchor-name: --anchortome;
}

Next up we’ll link our anchor again and add a new property named position-area to our .anchored item:

.anchored {
  position-anchor: --anchortome;
  position: absolute;
  position-area: top span-all;
}

This will give you the following result (explained below image)

What happened here? The position-area method draws a 3x3 grid around our .anchor behind the scenes, with the anchor item being in the middle column and row, something like this:

In our example position-area is set to top, making our item sit at the top row of our anchor grid. The second option is set to span-all, telling the browser that it’s ok the span over the other two columns of the 3x3 grid.

You can span over both axes, part of an axis, or none at all, you can even use logical properties. I would get lost in getting to the foundations of this article so I’ll just refer to this handy anchor-tool created by Una Kravets, and suggest you play around with it to see the potential. To see all the spanning options out there, I’d like to refer to the anchoring spec as well

Note on the basic anchoring methods

Using the position-area syntax will likely be the most commonly used. I’m talking about popovers, tooltips, fly-out menus, etc…

Although two methods make it harder to explain to people, I am happy that both of these methods came to exist simultaneously as the first method gives us much more flexibility for the times we need it. The power of these anchoring methods goes far beyond these basic demos, but they do show the capability,

Let’s take it one step further because when anchoring an item, we get some new things to play around with that give us the possibility to provide a fallback position to our anchored items based on the viewport.

Using the CSS anchoring basic fallback: position-try-fallbacks

More often than not, we want our anchoring to be visible no matter where the edge of our screen is. This happens a lot in software menus or tooltips for example. Some keywords were added for this to happen, a lovely addition. These keywords get referenced as “try-tactics”:

flip-block
flip-inline
flip-start

It’s great that this uses logical naming from the start… Let’s go back tot he first example, but this time around, we’ll give it some position-try-fallbacks. We’ll make the first fallback a block flip, followed by an inline flip, if that still doesn’t work, it should flip both axes:

.anchored {
  background: olive;
  position-anchor: --anchortome;
  position: absolute;
  top: anchor(center);
  left: anchor(right);
  aspect-ratio: 16/9;
  position-try-fallbacks: flip-inline, flip-block, flip-block flip-inline;
}

If the anchor now gets placed to the bottom right, this is the result:

That’s flippin’ awesome!

Here is a full demo to play around with ( I added some controls):

See the Pen Anchoring flipping with position-try-fallbacks by utilitybend (@utilitybend) on CodePen.

(note: you could easily do this with the position-area example as well)

Creating our own position-try-fallbacks with @position-try

What if we needed something more tailered to our needs and those basic try-tactics just aren’t enough? For those occasions we have the possibility to provide some position-try-fallbacks ourselves. Let’s create a basic example with a custom fallback. We’ll use the same anchor as before but this time add some text inside the anchored element:

<div class="anchor">
    <!-- icon -->
</div>
<div class="anchored">In this example, the anchor has a custom position-try</div>

What we want to achieve is to have our .anchored item to be the exact height of our .anchor, we can manage this by setting the top and bottom of the anchored item to 0. The CSS of our anchor stays the same, but we need to update our .anchored element, this is the fully updated code:

.anchored {
  position: absolute;
  padding: 20px;
  position-anchor: --anchortome;
  top: anchor(top);
  bottom: anchor(bottom);
  left: anchor(right);
  align-self: stretch;
  position-try-fallbacks: --hold-left;
  overflow: auto;
  background: olive;
}

The value of the position-try-fallbacks property allows a custom name as a value. Same as with anchor-name it should have two dashes (--) to start. It can be combined with the basic try-tactics as well.

We’re going to try and position our .anchored item completely left or right from our .anchor filling in the full height. For this, we only need one fallback, but you can add as many as you want separated by a comma. Do note that the order matters.

Let’s create that custom try option with the @position-try rule:

@position-try --hold-left {
  top: anchor(top);
  bottom: anchor(bottom);
  right: anchor(left);
  left: auto;
}

We just created our own little position-try-option, so cool that we can do this! Inside the @position-try rule, only the following properties are allowed:

inset properties
margin properties
sizing properties
self-alignment properties
position-anchor
position-area

It offers a lot of possibilities, however, I still notice some issues with this from time to time, but then again, it’s still an early implementation. I have yet to play around with everything available here.

This is the result:

See the Pen Anchoring API: Using custom position-try-fallbacks with @position-try by utilitybend (@utilitybend) on CodePen.

Picking what matters most for our anchoring options with position-try-order

Having the ability to pick different fallbacks is awesome, what’s even more handy is to have a bit of control over how the fallbacking should occur. With position-try-order we can tell the browser what’s most important to us for the anchored item:

normal: the default
most-width: Chooses the fallback that provides the most width for the anchored item
most-height: Chooses the fallback that provides the most height for the anchored item
most-inline-size: Chooses the fallback that provides the biggest inline-size for the anchored item
most-block-size: Chooses the fallback that provides the biggest block-size for the anchored item

With more CSS features rising, it’s always good to have the logical variant of widths and heights baked in from the start. The same goes for position-try-order. If you’re unfamiliar with logical properties, I recommend you get into those as soon as possible. There is a great episode of the CSS podcast about getting into logical property.

But why would we need this? As an example, I took the previous demo, and gave the anchor a left offset of 20vw from the center.

Well, it still works… But it could be better:
We have more room on the left of the anchor and it could make sense to place the anchored item over there.

Since being anchored to the right is the default, it’s not doing that because it does have enough room to show it on the right of the anchor. So let’s update the anchored item and tell the browser to focus on getting our anchored item as wide as possible:

.anchored {
  /* Same styles as before */
  position-try-fallbacks: --hold-left;
  position-try-order: most-width;
}

We can even write this a bit shorter with the shorthand. In that case, the order comes first and the options second:

.anchored {
  position-try: most-width --hold-left;
}

And here is that final result, taking the most-width into account:

See the Pen Anchoring API: Using position-try-order to get the most-width option by utilitybend (@utilitybend) on CodePen.

I did run into issues…

With position-try-fallbacks, I have run into the situation from time to time that the browser doesn’t understand my intent. This makes sense as there are still some bugs open related to this property. When creating an omnidirectional popover I just couldn’t get it perfect.

See the Pen Anchored popover by utilitybend (@utilitybend) on CodePen.

Future things to look out for in anchoring

There are a few things I’m looking forward to, some of them, I kinda wished would’ve shipped together with the things already covered in this article. But it is what it is…

anchor-scope

One property that is currently not yet available and has been specced is the ability to scope anchor names. When a design pattern is re-used, anchor-scope can prevent naming clashes across identical components.

When anchoring items, you need a unique name for now, and especially when creating tooltips, this could be a hassle. I played around with this before, setting an inline style to the buttons and popovers which set a variable with a unique name:

See the Pen Anchoring API and Popover API with position-fallback by utilitybend (@utilitybend) on CodePen.

But this could be removed in the future and be turned into something like this in CSS (If I read the spec right) If you’re reading this after anchor-scope became available, I will leave the demo in here for historic value (how i had to do it and a remembering of how awesome it is to have the scope feature)

button {
  anchor-name: --tooltip;
  anchor-scope: --tooltip;
}

[popover] {
  position-anchor: --tooltip;
}

Did you notice the previous CodePen with the arrow not showing in the correct position, well, that brings me to the following:

::tether pseudo-element? Or alternative idea

There has been talk about a ::tether pseudo-element in the CSSWG, and other ideas were given as well. I’m not part of the CSSWG, but I’m really rooting for a solution for the arrows in combination with position-try-fallbacks. It’s probably something clients will ask to have as well…

DevTools!

Yes! Just yes! More debugging tools for DevTools such as showing which try-option is currently active would be lovely.

A note on accessibility and feature flagging

Do note that even though you hang items to each other with the anchoring API, this is only visual. Although it’s now perfectly possible to tether elements to each other that are at complete different locations in the DOM, it has no effect on the accessibility tree, be mindful of that. Since this is an early feature, it’s something that we might just try out from time to time as a progressive enhancement. This is how you can check for support in your CSS:

@supports (anchor-name: --boat) {
  /* Add your anchor awesomeness */
}

Looking forward to learning more at CSS Day!

In conclusion, I can only say that I’m absolutely happy that this Anchoring API has been specced. Apart from some issues, it’s clear that this will be a total game changer for popovers, flyout menus, awesome navigation, etc. Maybe Chrome released it a bit too quickly? 🤔 Just an honest thought, but I’m sure they are on top of the open bugs related to this API.

We’re just a few days away from CSS Day and I’m sure there will be a lot of talk about Anchoring Position. Tab Atkins will be giving a talk about it, really looking forward to that one.

We are getting spoiled with CSS, I was kind off expecting things to slow down a bit after the crazy two years we had, but that’s far from true. We’ve only started with Anchoring, scroll-driven animations, transition-behavior, and view transition and it seems we’ll soon be animating from height auto to a value as well. But that’s a story for another time.

Almost time for a few days of extreme CSS geeking at CSS Day!

Some more cool demos and resources about the anchoring API:

Introducing the CSS anchor positioning API - by Una Kravets
Future CSS: Anchor Positioning - by Roman Komarov
CSS Anchoring positioning spec (really well written)

Modern CSS Layouts: You Might Not Need A Framework For That

Brecht De Ruyte — Wed, 22 May 2024 00:00:00 GMT

Read the article at Smashing Magazine

Invoking elements by using only HTML: A first look at invokers

Brecht De Ruyte — Tue, 23 Apr 2024 00:00:00 GMT

Attention: This article presents information from an experimental phase. An update on this article has been written, also documenting the latest updates to the explainer and demos. The article can be found here: An update on invokers: Invoker commands in HTML.

The article below is kept for historic purposes.

Now that full browser support for popovers is right around the corner, it might be a good time to start talking about invokers. The starting point of this idea can be traced back to 2018 and started with a shortcoming of the dialog element. To trigger a dialog element as a modal, adding the backdrop functionality and all that goodness, we had to rely on JavaScript, there just wasn’t another way. An issue was created for that, but a lot of ideas and iterations later we might finally get to see a solution for this in the form of invokers. But invokers include much more than that, and that’s exactly what this article is about.

The reason why I love writing about this feature is that I will be talking more about the possibilities instead of the syntax, because that’s the beauty of it: it’s quite a simple syntax. This also translates to a great developer experience - and yes - I’ll be saving the best for last.

A note of warning
What I’m writing about is still experimental, but from what I read and heard about it, it does get some nice interest from different browser vendors. The reason I want to write about this is because I love where this is going, but that’s just from a developer’s point of view. ( And because it gets discussed in the Open UI community group and that’s just an awesome group )

The invoker feature is being made available in multiple browsers, however, I tested my demos in Chrome Canary. If you want to play around with them you’ll have to enable the Experimental Web Platform features after going to chrome://flags

The basics: Creating a button and applying an invoke action

For the basic example, let’s take a look at how we could invoke a dialog by just using HTML:

<button invoketarget="my-modal">Trigger dialog</button>
<dialog id="my-modal">This is my dialog</dialog>

This opens the dialog element in the top-layer as a modal with the ::backdrop pseudo-element attached. The only thing needed is an invoketarget that references the id of the dialog. Pretty sweet, right?

Your browser does not support the video tag.

There is a second attribute that we could call that allows us to attach a certain event to the invoker, this is the invokeaction. For our close button, we could add the following

<button invoketarget="my-modal" invokeaction="close">
  Close
</button>

For dialogs, there are a few invoke actions we can apply:

showModal
Close

Not providing an action will call showModal() when the dialog isn’t open, otherwise it will close and use the button value for returnValue.

const dialogs = document.querySelectorAll("dialog");

dialogs.forEach(function (el) {
  el.addEventListener("click", ({ target: dialog }) => {
    if (dialog.nodeName === "DIALOG") {
      dialog.close("dismiss");
    }
  });
});

It’s nice that this controls so easily, here is that CodePen demo (remember, tested in Chrome Canary)

See the Pen Invoke dialog by utilitybend (@utilitybend) on CodePen.

(view invoker demos in debug mode in CodePen)

A note on popovers

The invoketarget attribute can also be used to target popovers, this will be added with the initial release of the attribute. If an element has both a popovertarget and invoketarget attribute, then popovertarget is ignored, or simply put: invoketarget takes precedence.

The invokeaction attribute for popovers will handle the following options:

togglePopover
hidePopover
showPopover

These are the equivalent of the attribute popovertargetaction with options: toggle, show, and hide.

What I love about these invokers is that we have so much that can be used straight out of the browser. Something that could only be achieved with huge libraries just a while ago. This is a great win for performance, but there is (potentially) a lot more to come… Let’s take a look at the potential next phases for invokers.

The future phase of invokers: Invoking Details, Select, and Input

Currently planned for a future phase in the invoker plan is to give the ability to invoke the <details> element and even form controls such as the <select> or certain <input> types.

The basics are still the same, for a <details> element we could add the following:

  <button invoketarget="my-details">
    This will open the details
  </button>

  <details id="my-details">
    <summary>This is a summary</summary>
    This is the content
  </details>

With invokeaction having the following options:

toggle
open
close

Details were originally added to phase 1, but have been delayed. Let’s take a closer look at the input elements because those could potentially be a lot of fun.

Showing pickers with the invokeaction showPicker()

Imagine you want to create an <input type="date" /> with a custom icon, It would look something like this:

<label for="date">Pick a date</label>
<div class="input-group">
  <input id="date" type="date" />
  <button invoketarget="date" invokeaction="showPicker">
    <!-- add an icon here -->
  </button>
</div>

And by just adding a bit of styling…

/* Remove the default date calendar picker */
[type="date"] {
  &::-webkit-calendar-picker-indicator {
    display: none;
  }
}

/* Style the input group with invoker */
.input-group {
  display: flex;
  [type="date"] {
  /*  Presentational styles here */
  }
  [invoketarget] {
  /*  Presentational styles here */
  }
}

This could be a result:

Your browser does not support the video tag.

See the Pen Invoke date by utilitybend (@utilitybend) on CodePen.

(view invoker demos in debug mode in CodePen)

The same technique could be used to trigger a <datalist> with a separate button. Note that we need to trigger the <input> element’s id, not the one from the datalist:

<label for="food">What would you like?</label>
<div class="input-group">
  <input list="foods" name="browser" id="food">
  <button invoketarget="food" invokeaction="showPicker">
    <!-- icon -->
    Open input picker
  </button>
</div>

<datalist id="foods">
  <option value="🍙 Onigiri"></option>
  <option value="🍜 Ramen"></option>
  <option value="🍣 Sushi"></option>
  <option value="🥟 Dimsum"></option>
</datalist>

Your browser does not support the video tag.

See the Pen Invoke Datalist by utilitybend (@utilitybend) on CodePen.

(view invoker demos in debug mode in CodePen)

This showPicker() action can be used on a numerous of elements: <input type="color" /> or <select> elements, or even <input type="file" />:

<label for="fileinput">Upload some files?</label>
<button class="uploadzone" invoketarget="fileinput" invokeaction="showPicker">Click this huge square to upload</button>
<input type="file" id="fileinput" />

Here is a demo of that:

Your browser does not support the video tag.

See the Pen Invoke file by utilitybend (@utilitybend) on CodePen.

(view invoker demos in debug mode in CodePen)

Truth be told, you could probably create this effect with the label itself, but this being an actual <button> element could be a handy tool.

Number inputs with custom steppers

A feature that would be welcome for people who create a lot of webshops ( I am such “people” ) is the ability to add custom stepper buttons on an <input type="number" />. There is a custom implementation possible with invokers and this is how it works:

<div class="counter">
  <button invoketarget="num" invokeaction="stepDown">-</button>
  <input type="number" min="1" id="num" value="1">
  <button invoketarget="num" id="btn" invokeaction="stepUp">+</button>
</div>

Using the stepDown and stepUp events for the invokeaction, we can control the number of the input type. This takes into account any of the extra attributes on the input as well such as min, max, and step.

Using the HTML above and some extra styling this is something I created with it:

Your browser does not support the video tag.

See the Pen Invoke number by utilitybend (@utilitybend) on CodePen.

(view invoker demos in debug mode in CodePen)

While still a big “if” when speaking about this feature (because, well.. Experimental and such), I love the idea of implementing this with invokers. It seems that this invoker idea is fantastic when it comes to consistency, and I can only applaud that.

While we’re not done yet with all the things you can do with invokers, let’s take a little detour as events just came to mention:

Custom behaviour

Invokers will dispatch events on the Invokee element. Using a dash in the invokeaction allows for custom JavaScript to be triggered without having to wire up manual event handlers to the Invokers. By listening to the invoke event listener we can attach our action to it:

<button invoketarget="my-custom" invokeaction="my-frobulate">Frobulate</button>

<div id="my-custom"></div>

<script>
  document.getElementById("my-custom").addEventListener("invoke", (e) => {
    if (e.action === "my-frobulate") {
      alert("Successfully frobulated the div");
    }
  });
</script>

(example from the Open UI explainer)

Custom video and audio controls with invoke actions

I’ve been showing some short demos of this while presenting about the future of UI and this is one of those things where I notice people gasping and getting a smile on their faces. Seems like people really had some struggles when it comes to custom controls for video and audio. Well, I hear you and Invokers might just make all of these things a bit more easy.

This is how we could create a custom play button:

<video id="custom-video">
    <source src="..." type="...">
</video>
<button invoketarget="custom-video" invokeaction="play">
    Play
</button>

Keeping the consistency going (love this!), we can create an invokeaction="play" and this will fire that play event for the video. This also works with a whole bunch of other events such as:

playpause (toggle between play and pause)
pause
toggleMuted
toggleFullscreen

A bit of styling and you could create something like this:

Your browser does not support the video tag.

See the Pen Invoke video - Would be cool to have :playing pseudo-class - cross browser for this by utilitybend (@utilitybend) on CodePen.

The same could be achieved for audio, I might make a demo for that later on as well.

For more goodies and information about invokers, do check out the following links:

Conclusion

I love where this invoker idea is going. If I’m honest, I was a bit skeptical at first but now that I see the potential and the possibilities when it comes to consistency, I think it’s something we need and probably long overdue. The things in Open UI are a group effort but I do want to give a shoutout to Keith Cirkel and Luke Warlow, who really have put a lot of effort into this feature and are continuing to do so. There is a lot more stuff in the works that I’d be happy to write about once they are in further stages.

Do remember that all of this is a work in progress. But if you like this and want to support this, create demos and provide feedback. Open UI is an open group and does care a lot about developer experience. I am by no means a browser engineer, but if this one opinion of a little agency front-ender from Belgium could help to push these kinds of features, then I’d be glad to do so (every bit helps, right?).

That being said, I do know that some of my examples might not be the perfect accessible examples at the moment. Keep in mind, that the group is working on improving accessibility, it is a topic that is highly rated.

I do hope that by sharing these features people go check them out and give them a spin. I also hope that by writing this article and speaking about this, I can project (invoke!) a bit of my enthusiasm to others. Always feel free to tag me if you create something with them, I’d like to create a little collection on CodePen as well. Happy Invoking

Why I care about a Google Developer Expert certificate and Web communities

Brecht De Ruyte — Sun, 07 Apr 2024 00:00:00 GMT

I absolutely HATE it when people call me an “influencer” or even worse, a “guru”. Still, I proudly hang my newly obtained Google certificate on the wall, perfectly visible to my webcam. The reason for this is simple: this is actually the first “piece of paper” I got, proving I can develop stuff that helps people. Sounds silly, right? I’ve made tons of websites and platforms in over a decade, so why would I even care about such a thing?

Most people I work with have some higher degree and they all say the same thing about it: “Almost no company cares”, “I don’t even know where it is, maybe somewhere in the attic”, “It’s only handy for when you get started”,… But as I went above 30 years old, I kinda wanted a degree and swore that if I’d ever get one, I’d proudly place it somewhere in sight.

Now, of course, A GDE Certificate is not a degree, but it felt like a “thank you” or general appreciation for doing some work (and I do study for that work). If you know me a little, you know that appreciation means something to me. So going on, I’d like to talk about some of the things I believe are important in communities and why I put in the work. I can tell you one thing for certain: it’s not about an extra income.

It starts with a shared passion

It would be impossible to name every person who has influenced me, I wouldn’t be a developer if I had never read Andy Clarke’s Transcending CSS, heard my first UX talk by Aral Balkan, read books by Rachel Andrew, articles by Jeremy Keith, Followed an SVG course by Sara Soueidan and many more. I’m not about to go all fanboy for a bunch more of them, but those are the people who gave me a chance to become a developer even without a degree. Yes, some of them make a living out of teaching now, but that wasn’t always the case for them, they all started from one point: community and a passion for the web. This is where it started for me, and I just want to give a bit back to the community. Maybe it was becoming a dad that triggered that, or just some point in time when I thought about how hard it was just to “get that first chance”.

A lot has changed though, In the past, the whole community could be summarized with a nice Twitter timeline without a bunch of ads and could easily be read with your morning coffee. But it’s about these people just blogging about the web, inventing some cool techniques that I could train myself in while working in a factory in the morning, and trying out some web development in the afternoon. Now this is more than a decade ago, and I never really got involved with communities much. So why now?

Thinking “I’ll never be good enough”

The reason I never really did a lot of writing before was fear. I always thought the following: “There are already people writing about this”, “The others have credentials”, and “Who even cares?”. And I’m still like that, this is still reflecting me in some way.

I’ve been blogging for 3 years now, and this is the first article where I just write about “me”

Because:

Who even cares?
There are more interesting people out there, so why should I write about myself
Others do it better, and I don’t even have some credentials

It’s not that I don’t have any other passions or hobbies besides the web: I love outdoor cooking, manga, board games, photography, building Lego, and playing a mean bit of guitar. I just don’t think I should write about these things. Truthfully, I need to set aside some of those things to stay involved with the community. But that’s ok, as long as my family comes first.

If you have the same thing let me tell you something that helped me: When I started writing, I had about 20 readers on my articles tops and I was the most happy person ever. I told some coworkers that I started blogging and most of them reacted positively, some thought it was strange but there was this one (ex) coworker who during a little discussion said “Ow, cus you have a blog” in a very demeaning manner. I’ll add this in bold:
Never let these kinds of people let you down.

Think of it like this: Even if I only had 20 readers, people read the stuff and liked it, how cool is that! But soon I noticed that whether I had 20 or 1000 readers, it didn’t matter because every article I wrote, made me learn a bit more about the subject. It made me a better developer (slow and steady). I do love that more people are reading the things I write, but I still do it out of curiosity or just simply sharing if I find something that I’m passionate about. But I still withdraw from writing personal pieces, mostly because “Who even cares?”.

Another thing that I learned is that you should never rely on the number of readers to begin with. I had articles that I worked hard on, more than 16 hours of creating demos and just finding the right words, to notice it barely gets any views. A few weeks later, I chose to write a quick article on a Saturday morning, and it’s a hit. This doesn’t matter, If you learned something from that big article and are happy that you wrote it, that’s the important part. Unless you are writing for a company where views are important, on your personal blog, stick to things you love doing.

So taking some of those fears into account, I think it’s understandable why I don’t write a lot of big opinionated articles and keep it technical. In contrast to that, I love reading opinionated articles and some people are just so good at it. Different points of view matter to me, which brings me to the next bit:

And here it is…

Getting involved with web communities

For the moment, I’m part of some internal communities at iO (my job), some W3C open community groups (Open UI and CSS4), and of course the GDE community. The most interesting part is learning from people’s opinions. It all starts with listening and asking questions.

As an example of communities: In Open UI you have so many types of people: browser engineers, accessibility experts, CSS experts, and Maintainers of design systems, It’s a fantastic group that deeply shows the difference in what matters most to certain groups of people. In my eyes, it’s a great experience to be part of. I mostly create some demos and spend some time asking questions, adding small contributions, or giving an opinion here and there, and people listen, help, and are respectful.

It’s a great example of how a community should be. And it starts with yourself, I know I said a lot of dumb things as well, but that’s great, it helps me move forward and learn. Believe it or not, it can also help the community, because sometimes, “that dumb thing”, Is the smart question people forget to think of and helps to move things forward. Also, I had never spoken to browser engineers before, and being part of this group made me really respect the work they do even more. (Almost made me want to give it a go as well ;) )

The reason why I speak so passionately about this group is because I’m being sincere, I mean every word. And that - once again - brings me to the following:

Be ******* grateful - always!

When someone helps me with a quick finish of a demo, helps me out by explaining some new specs a bit closer, or reviews an article or a demo I’ve written, I thank them. Maybe_ a bit too much_ but I mean it, every time. When people take time for you, time that they could’ve easily spent on something else, that’s golden. When I give a presentation my last sentence is “thank you” not because it should be, but because I mean it. I am happy to be invited to speak, happy to write, and to maybe help a few people find some answers. I’m not an AI, I’m a human being, spending hours a week next to my day job for the sake of the community. And to all those others doing the same thing, remember that you could be the one that brings a low-educated factory worker to a web development job.

Even when your opinions clash, be respectful, and give your opinion but also “pick your battles”.

Why I suggest everyone should get involved with at least one community

If you’re a developer, chances are high there is something you are passionate about. It might not be the same thing as your day-to-day job, but that doesn’t matter. There are many ways you can get involved with open source projects, W3C community groups, Frameworks, take your pick… Every bit you do to contribute helps. Whether that is commenting on issues, helping with an implementation or even just listening and spreading the word. It can make you grow as a person and you would be surprised by how little this world of web developers is. I’m not suggesting everyone should blog about the work they do, hell no, I might’ve started an outdoor cooking blog and I even used to have a photography blog long ago. Write what you are passionate about. But you’d be surprised how much an hour/week involvement in web communities can make you grow.

This is how it all started for me, by “joining stuff and”, “listening about stuff”, and now I get to speak about stuff to students and others.

I still have so much to learn, and so many things I want to do, I’m glad that people and initiatives such as the GDE program help me with that, spreading my enthusiasm for Web UI.

For now, I’m trying not to undersell myself, and celebrate some of the achievements. This is probably the hardest thing for me completely, because deep inside: I’m still that 20-year-old, working in the factory morning shift, trying to learn things that all these amazing people are writing about. But maybe that’s my strength, who knows…

For me, my passion for the web has always been UI and CSS, and I love sharing this learning journey with you on this blog. So yes, this was a little personal blog post and I probably won’t be adding much of those soon, but still, I’m happy I did.

Animating clip paths on scroll with @property in CSS

Brecht De Ruyte — Tue, 26 Mar 2024 00:00:00 GMT

There are a lot of features coming in CSS and one of the things I often think about is how to combine all of them. How can I create some practical use cases for all this stuff? So, in this article, you will see a lot of things: Scroll-driven animations, @property, container units, clamping, and other goodies. Time to write some modern CSS

Clipping and animating on scroll

Before we get to the big demo, let’s start with a smaller one to showcase some of the basic techniques we’ll be using later on and since I’ve already written about the basics of scroll-driven animations, let’s dive right into animating clip paths on scroll. This is the first effect we’re going to create:

Your browser does not support the video tag.

In this demo, we have an image set fixed to the center of our screen. For demo purposes, let’s give the <body> a height of 300vh to have some overflow to play around with. This is the CSS attached to the image, the bottom three properties are the ones we’ll be working with:

img {
  position: fixed;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  display: block;
  width: 100%;
  max-width: 50vmin;
  height: auto;
  aspect-ratio: 1;
  object-fit: cover;
  border: 5px solid deeppink;

  clip-path: circle(20% at 0% 0%);
  animation: rotateOrb linear both;
  animation-timeline: scroll();
}

When we want to animate clip-paths there are two options we can go for.

Option 1: Just animate the property

The easiest way to do this would be to just animate that property again and again. When choosing that route, this would be the animation for what we want to achieve:

@keyframes rotateOrb {
  0% {
    clip-path: circle(20% at 0% 0%);
  }
  25% {
    clip-path: circle(20% at 100% 0%);
  }
  50% {
    clip-path: circle(20% at 100% 100%);
  }
  75% {
    clip-path: circle(60% at 0% 100%);
  }
  100% {
    clip-path: circle(150% at 0% 0%);
  }
}

Now, before I get a whole bunch of hate: Yes, this will be the shortest amount of code needed to create that effect, but for me, this always felt bloated, especially when using bigger animations. Circles are quite easy to understand because there are only 3 values involved, but when using polygons, it gets tricky. We could benefit from using something more understandable. Which brings us to the next part.

Option 2: Using custom properties

Let’s make all of this a bit more readable by using custom properties. This would make it a bit easier to tweak as well. So let’s change our code to set this up. First up, let’s update our code to animate variables instead of the clip-path property:

img {
  /* positioning properties */
  clip-path: circle(var(--scale) at var(--move-x) var(--move-y));
  animation: rotateOrb linear both;
  animation-timeline: scroll();
}

@keyframes rotateOrb {
  0% {
    --move-x: 0%;
    --move-y: 0%;
  }
  25% {
    --move-x: 100%;
    --move-y: 0%;
  }
  50% {
    --move-x: 100%;
    --move-y: 100%;
  }
  75% {
    --move-x: 0%;
    --move-y: 100%;
    --scale: 60%;
  }
  100% {
    --move-x: 0%;
    --move-y: 0%;
    --scale: 150%;
  }
}

One might think that the only thing left to do is to set up our basic variables inside of the root (spoiler alert, this won’t work):

:root {
  --move-x: 0%;
  --move-y: 0%;
  --scale: 20%;
}

This results in the following “jumpy effect”:

Your browser does not support the video tag.

So, why doesn’t this work?

At this point, the browser has no idea that it should animate these properties as a percentage, as custom properties can contain anything you want. Thankfully, we have something available in every major browser that could help with that issue, which is the @property syntax.

Instead of just adding the custom properties inside the root, let’s add them using @property:

@property --move-x {
  syntax: "<percentage>";
  initial-value: 0%;
  inherits: false;
}

@property --move-y {
  syntax: "<percentage>";
  initial-value: 0%;
  inherits: false;
}

@property --scale {
  syntax: "<percentage>";
  initial-value: 20%;
  inherits: false;
}

Now our demo will fully work. Here is the CodePen of this:

See the Pen Scroll driven animations circular reveal by utilitybend (@utilitybend) on CodePen.

So, as a conclusion to this: Yes, the code is a bit bigger, but it feels a lot smarter and I do think it creates a bit more control and easy tweaking. In the CodePen above, you could give the image a class .square-in which would trigger a new animation, using those same custom properties. So, yes, for a small demo like this, it might be a bit too much But looking at the bigger picture, it will be a lot easier to maintain, especially when using multiple animations in a project.

Another quick example of this is animating a polygon star:

See the Pen Animating to a star on scroll by utilitybend (@utilitybend) on CodePen.

I have no idea why I created this, but now, if you need it, you don’t have to :) I’ve also written another article if you’d like some extra information about @property.

Alright, believe it or not, this was the intro. Now that we’ve seen this technique, buckle up, and let’s create the actual demo:

Animating a CSS Journal with scroll-driven animations, @property, and clip-paths

In this step-by-step tutorial, we’ll be making a sort of CSS Journal. As I’ve recently been playing with the idea of keeping a journal in real life, I felt a bit inspired so, that’s kind of where this idea came from. The intake is to have a picture and a quote next to each other and we’ll be giving them a cool entry into the viewport. In the final demo, there will also be a little intro to notify users to scroll, but that’s a bit beside the point of the demo. Here is the final result of what we’ll be making:

Your browser does not support the video tag.

Setting up the HTML of our journal

Let’s start with setting up the HTML, we will alternate the image and text in the DOM for now as we’ll play around with that bit later on. So, without the actual content, this is our HTML:

<section>
  <article>
    <figure>
      <img src="..." alt="..." />
      <figcaption>...</figcaption>
    </figure>
    <div class="entry">
      <p>...</p>
    </div>
  </article>
  <article>
    <div class="entry">
      <p>...</p>
    </div>
    <figure>
      <img src="..." alt="..." />
      <figcaption>...</figcaption>
    </figure>
  </article>
  <!-- this gets repeated a few times -->
</section>

Let’s get over the function of our HTML elements for this demo:

The <section> will hold our articles, displaying them in a flex column
The <article> will be used as a wrapper for our items and add a grid layout
The <figure> will hold the image and will rotate a bit when entering the viewport
The <img> will get an animated clip-path to create the Polaroid film effect
The <figcaption> will be used as a description on the bottom of the polaroid
Then .entry will fade in a bit when entering the viewport, first the lines of the text, followed-up by the text itself.

The basic layout - a reset and organizing our entries

First of all, we’ll need a little reset, let’s get that out of the way right now. I also added a custom Google font for presentational reasons:

body {
  margin: 0;
  font-family: "Annie Use Your Telescope", cursive;
  background: radial-gradient(ivory 70%, transparent 30%),
  radial-gradient(ivory 70%, transparent 30%), #f5f3f3;
  background-size: 5px 5px;
}

figure {
  padding: 0;
  margin: 0;
}

img {
  display: block;
  width: 100%;
  max-width: 100%;
}

Next up, let’s create a flex column out of our section and give the items a bit of a gap, this will help the scrolling experience later on, we can also provide a padding-block: 50vh; to make sure there is enough spacing to view the scroll animations of all the items:

section {
  display: flex;
  flex-direction: column;
  gap: 40vmax;
  margin-inline: auto;
  padding-inline: 10vmax;
  padding-block: 50vh;
  max-width: 1400px;
}

Now let’s turn all of our <article> elements into a grid (I used a breakpoint of 750px for this, but choose freely). Our image will be set to be 2/5 of the width. By using :has() we can check where the image is located and change our grid based on that:

article {
  display: grid;
  align-items: center;
  gap: 8vmax;
  @media (min-width: 750px) {
    grid-template-columns: 2fr 3fr;
    gap: 10vmax;
  }
  &:has(.entry + figure) {
    @media (min-width: 750px) {
      grid-template-columns: 3fr 2fr;
    }
  }
}

Styling and animating the entry fade

This is where our first scroll-driven animation gets triggered, we’ll want to slightly animate the entry upwards into place while also changing the text color from transparent to black. We will animate the color instead of the opacity, because we’ll want to use the opacity property for the lines, as stated before: “The .entry will fade in a bit when entering the viewport, first the lines of the text, followed-up by the text itself.”

.entry {
  animation: revealEntry linear both;
  animation-timeline: view(block);
  animation-range: cover 20% contain 40%;
}

@keyframes revealEntry {
  from {
    color: transparent;
    transform: translateY(20%);
  }
  to {
    color: black;
    transform: translateY(0%);
  }
}

One of the things you might be wondering is how we can find the perfect animation-range for these effects. For that, I usually open a tab and play around with the ranges tool created by Bramus. He made a Chrome plugin for it as well, but I like this one a bit better in my workflow, the choice is yours of course.

Next up, is to create the lines for our text and slightly make those appear a bit earlier, this will just be a simple basic fade-in animation. This is the complete code:

.entry p {
  font-size: clamp(1.25rem, 0.9891rem + 1.3043vi, 2rem);
  background-image: repeating-linear-gradient(
    to top,
    #95d9c3 0 0.125rem,
    transparent 0.125rem 1lh
  );
  background-position-y: 0.8lh;

  animation: fadein linear both;
  animation-timeline: view(block);
  animation-range: entry 10% contain 10%;
}

@keyframes fadein {
  0% {
    opacity: 0;
  }
  100% {
    opacity: 1;
  }
}

The lines are created with a repeating-linear-gradient using the lh unit, a relative CSS unit based on the line-height of the current font. This is easy for re-sizing the text, especially if you’re using a bit of fluid typography with clamp(). I recently wrote a series about relative length units in CSS if you want to read a bit more about these techniques. But for this demo, I’m just adding it as a sweet bonus.

For the moment, you should be having something like this:

Your browser does not support the video tag.

Rotating our figures as they enter the screen

Before we get to the clipping, let’s start with the rotation of our <figure>. To do this, we’ll add some default styling, and give the figure an aspect-ratio: 1;. This makes perfect sense because these kinds of pictures are usually in a square aspect ratio:

figure {
  --rotate: 20deg;

  position: relative;
  aspect-ratio: 1;
  background: white;
  box-shadow: rgba(0, 0, 0, 0.1) 0px 4px 12px;

  animation: rotate linear both;
  animation-timeline: view(block);
  animation-range: cover 20% contain 30%;
  @media (max-width: 749px) {
    max-width: 350px;
    align-self: center;
  }
}

We also added a custom property --rotate to handle the rotation of our figure, we’ll be using that custom property in our keyframes:

@keyframes rotate {
  entry 100%,
  exit 0% {
    opacity: 1;
    rotate: var(--rotate);
  }
  exit 100% {
    opacity: 0;
    rotate: 0deg;
  }
}

Pretty sweet! If you’re actually following along with the demo, you might notice that all our figures are rotating in the same direction. It’s :has() to the rescue! Remember the following line in our article, and let’s update it:

&:has(.entry + figure) {
  @media (min-width: 750px) {
    grid-template-columns: 3fr 2fr;
  }
  figure {
    --rotate: -20deg;
  }
}

This will ensure that the image will rotate in the other direction when placed after the entry…
:has() is so freaking awesome!

Creating our image to Polaroid effect with clip-paths and @property

To create our frame, we will only need to animate two values, as our frame has 3 equally sized sides and only the bottom part is wider. Let’s create two custom properties for the clipping and set the initial-value to 0%:

@property --clip-1 {
  syntax: "<percentage>";
  initial-value: 0%;
  inherits: false;
}

@property --clip-2 {
  syntax: "<percentage>";
  initial-value: 0%;
  inherits: false;
}

For our image, we’ll add the default styling, giving it an aspect-ratio: 1; while also clipping it with inset. The values of inset clipping are familiar, it’s the same as margins: top, left, bottom, and right. So this will translate to:

inset(var(--clip-1) var(--clip-1) var(--clip-2) var(--clip-1));

Here is the full styling of our image:

img {
  aspect-ratio: 1;
  object-fit: cover;

  clip-path: inset(var(--clip-1) var(--clip-1) var(--clip-2) var(--clip-1));
  animation: createFrame linear both;
  animation-timeline: view(block);
  animation-range: cover 15% contain 40%;
}

In the animation, we will update these values and add a shadow:

@keyframes createFrame {
  to {
    --clip-1: 5%;
    --clip-2: 15%;
    box-shadow: rgba(50, 50, 93, 0.25) 0px 6px 12px -2px,
        rgba(0, 0, 0, 0.3) 0px 3px 7px -3px;
    }
}

You should now have something like this:

We’re getting close, two steps remain.

Animating the caption into the frame

We will be absolute positioning the <figcaption> while also giving it a max-width with a text-overflow: ellipsis. But since our frame changes depending on the width of the window, It might be interesting to size and position the caption based on its container.

To do this, let’s create a container out of our figure:

figure {
  container: frame;
  container-type: size;
  /* previous code... */
}

Now, in normal cases, it would be a problem to set the container-type to size because when using a block axis, this container needs to have some sort of defined height. Luckily, thanks to the aspect-ratio, this has been set.

figcaption {
  position: absolute;
  inset-inline: 5cqw;
  bottom: 1.2cqh;
  font-size: 8cqh;
  text-overflow: ellipsis;
  white-space: nowrap;
  overflow: hidden;
  z-index: 1;
}

So all that is left for us to do, is to make that text appear, once again, using an inset clip-path where we will animate that one custom property that we already created:

figcaption {
  --clip-1: 100%;

  /* previous presentational styles */
  clip-path: inset(0 var(--clip-1) 0 0);
  animation: revealText linear both;
  animation-timeline: view(block);
  animation-range: cover 25% contain 35%;
}

@keyframes revealText {
  to {
    --clip-1: 0%;
  }
}

Be weary of user preferences and browser support

One last thing to end this demo, is that you should always think about user preferences and browsers support.

As a best practice, you should do this as a progressive enhancement. But for demo reasons, I decided to use the not operator in a support flag, mostly to not overly pollute the demo:

@supports not (animation-timeline: view(block)) {
  .intro {
    animation: none;
  }

  section * {
    animation: none;
  }

  figure {
    rotate: var(--rotate);
  }

  figcaption {
    --clip-1: 0%;
  }
  img {
    --clip-1: 5%;
    --clip-2: 15%;
    box-shadow: rgba(50, 50, 93, 0.25) 0px 6px 12px -2px,
        rgba(0, 0, 0, 0.3) 0px 3px 7px -3px;
  }
}

You could use the same approach for users that prefer reduce motion. In this case, the same code can be inside of it:

@media (prefers-reduced-motion) {
    /* Same as the support query content */
}

The final result

If you followed along with the article, you should have ended with a similar result as the demo I’m embedding to this page.

In this final version, I also added some cascade layers into the mix for easy grouping and a little intro, but that’s the only difference.

See the Pen CSS Journal (@property, Container units and Scroll Driven Animations) by utilitybend (@utilitybend) on CodePen.

I do hope you enjoyed this little showcase of modern CSS features, I had a blast creating this demo and looking forward to seeing what other magical things people will be making with scroll-driven animations combined with clip-paths. After being busy with mostly HTML and web components, it was nice to return to CSS a bit. I really enjoyed it. One question remains: Will I start creating a real physical journal and start “journaling”, I’m still not sure, but at least, this little demo sprouted from that idea.

A Valentine's Day special: A web component to show hearts on your website

Brecht De Ruyte — Wed, 14 Feb 2024 00:00:00 GMT

Each year I add an article on the 14th of February. Not because I’m a big fan of the commercial day called Valentine’s Day, but rather that I started it off as a laugh and somewhat stuck with it. Now It feels like something I have to do, but it does help me to invent something new each year, and since I was learning a bit more about web components at the end of 2023. I thought it would be cool to create a little web component for this day, giving users a little plug-and-play option for animated hearts on their web page.

Setting up our workspace with Vite

Let’s start by setting up our default workspace, Open up the terminal and navigate to the place where you want to install the web component:

cd ./projects/

Initialize Vite

npm create vite@latest

Install dependencies if needed. In my example, the project is named for-love

Next choose Lit as a framework
As a variant in this case, choose Typescript
Change the directory to the folder, npm install, and npm run dev as described after initializing Vite.

Why choose typescript for a web component

To be completely honest, I added the Typescript mostly out of peer pressure. Typescript is an important thing, especially in big projects, but if you ask my personal opinion, for a simple web component like this, it might be a bit too much.

Adding Lit for the developer experience

The Lit library makes it easier and more efficient to work with web components. It provides a more declarative syntax for defining components. This can make our code more readable and maintainable compared to the imperative style required when working directly with the Web Components API. In this tutorial, we’ll be using this library mostly for the basic features of developer experience, but it has a lot more to offer (I’m still learning about it myself).

Setting up the basics of our for-love web component

For this tutorial, it might be a good idea to make the component grow a bit, almost in the same way it was set up from the beginning, and expand it later on. Not every little detail of the web component will be covered in this article, for example, the “contained” and ”multicolor” options will not be added.

So for this for-love-element, we want a few options:

Easily change the amount of hearts with an attribute
Randomly place the hearts
Change the size and color through CSS custom properties
Change the amount the hearts sway from left to right with custom properties
Change animation duration, iteration, and easing with custom properties

Let’s start with setting up the basic component by reading the amount of hearts as an option and iterating that amount to show a bunch of hearty divs:

Let’s remove everything inside the src folder created by the Vite install, and let’s create our new file called for-love.ts. Let’s add the following.

import { html, css, LitElement } from 'lit';
import { customElement, property } from 'lit/decorators.js';

@customElement('for-love')

export class ForLove extends LitElement {
  @property({ type: Number }) amount = 10;

  static styles = css`
    /* we will add our styles here */
  `;

  render() {
    return html`
      <div class="for-love-hearts" part="hearts-container">
        ${Array(this.amount).fill('heart').map(index => {
          return html`<div class="heart" data-item="${index}">Heart</div>`;
        })}
      </div>
    `;
  }
}

declare global {
  interface HTMLElementTagNameMap {
    'for-love': ForLove;
  }
}

Inside of our index.html change the <my-element> custom element to our <for-love> element. You should now see “Heart” printed 10 times. Inside our <for-love> element, we can adjust the amount by adding <for-love amount=”40”></for-love>. Go on, give it a try…

So, what we did here: We included html, css and LitElement from Lit. This last one is needed to create our custom element with Lit, while html and css give us the possibility to add markup and styling through that cool template literal system. We added a placeholder for our CSS and returned some HTML when the component loads. Inside this component, we add a loop that iterates over our set amount property.

This @property({ type: Number }) amount = 10; decorator defines a public property named amount with a type annotation of Number. This ensures type safety and lets Lit know how to update the property based on its type. We will be needing this because It might not be the best Idea to allow just about any number of hearts in our web component, so let’s restrict it. The following bit of code will check if the amount is more than 400, If so, it will just return 400.

Let’s remove

 @property({ type: Number }) amount = 10;

And replace it with:

  private _maxAmount = 400; // Set your maximum value here

  @property({ type: Number })
  get amount() {
    return this._amount;
  }

  set amount(value: number | string) {
    const parsedValue = typeof value === 'number' ? value : parseInt(value);

    // Check if the parsed value is a valid number
    if (!isNaN(parsedValue)) {
      // Set the value to the maximum if it exceeds the maximum allowed
      this._amount = Math.min(parsedValue, this._maxAmount);
    } else {
      console.warn('Invalid value for amount property. Please provide a valid number.');
    }

    this.requestUpdate('amount'); // Notify LitElement to update the property
  }

  private _amount = 10;

Explaining the maximum value code

First, we define a private property named _maxAmount and set it to 400. This variable determines the highest allowed value for the amount property. This is our safety net, maybe 400 is too much, I’ll let the reader be the judge of that.

Creating the Property:

Next, we declare a public property called amount. Here, we use the @property decorator and specify the type again as Number. This not only clarifies the expected data type but also helps Lit understand how to update the property efficiently, which is one of those superpowers of the library.

We then create a getter and a setter for the amount property. The getter simply returns the current value stored in the private _amount property, providing read access.

The setter is where the magic happens. It handles setting the amount property, accepting either a number or a string as input. Let’s delve into the steps it takes:

Parsing the Input: The code checks if the input is already a number. If so, it’s used directly. If it’s a string, the code attempts to convert it to a number using parseInt. This ensures we’re working with numerical values.
Checking for Validity: The code uses the isNaN function to verify if the parsed value is a valid number. If it’s not, it means the input wasn’t a proper number and a warning message is logged to the console to alert the user.
Enforcing the Limit: If the parsed value is valid, the code compares it to the _maxAmount. Using the Math.min function, it sets the _amount property to the smaller of these two values. This effectively enforces the maximum limit you defined earlier.
Triggering an Update: After setting the _amount property, the code calls this.requestUpdate('amount'). This tells Lit that the property has changed and prompts the component to update itself with the new value. This ensures your UI reflects the latest accepted input, (aka the amount set in the attribute).

Finally, we set the initial value of the _amount property to 10, our default value.

Creating our hearts animation with CSS and custom properties

Time for us to add some love to our component and style our hearts using CSS. We will be using custom properties to create the ability for options in easily. Let’s go inside of our CSS template literals and add the following:

:host {
  --_color: var(--fl-heart-color, #F8C8DC);
  --_size: var(--fl-heart-size, 3vw);
  --_sway: var(--fl-sway, 5);
  --_iteration: var(--fl-iteration, infinite);
  --_duration: var(--fl-duration, 10s);
  --_ease: var(--fl-ease, ease-in-out);
}

.for-love-hearts {
  position: fixed;
  inset: 0;
  pointer-events: none;
  overflow: hidden;
}

If you haven’t heard of :host before, this is a CSS pseudo class that is used to style our custom element itself, this is a great place to store our variables.

Using underscore variants as private variables in these custom properties, we can read if a variable is present or else use a fallback. I like this way of working, it’s pretty clean. Our fixed container is going to fill in the whole window and pointer events will be set to none. This is the container that will contain our hearts.

Now let’s create our hearts with CSS only, I’m not going to go into much detail about this technique as this is a bit off-topic. The important part here is to notice the usage of custom properties, we will be placing these hearts in a random matter across the width of the screen. For that, we will need a new custom property called --left.

.heart {
  position: absolute;
  top: 0;
  margin: auto;
  left: var(--left, 0);
  height: var(--_size);
  width: var(--_size);
  background-color: var(--_color);
  rotate: -45deg;
  pointer-events: none;
}

.heart::after, .heart::before {
  background-color: var(--_color);
  content: "";
  border-radius: 50%;
  position: absolute;
  width: var(--_size);
  height: var(--_size);
  top: 0px;
  left: calc(var(--_size) / 2);
}

.heart::before {
  top: calc(var(--_size) / -2);
  left: 0;
}

Let’s make that new custom property --left work, Let’s update our hearts loop to set that custom property inline of each heart between a range of 0% and 100%:

${Array(this.amount).fill('heart').map(index => {
    const randomNumberLeft = Math.floor(Math.random() * 101);
    return html`<div class="heart" data-item="${index}" style="--left: ${randomNumberLeft}%;"></div>`;
})}

Great! We now have a bunch of hearts sticking at the top of our screen:

All that’s left for us to do is add a bit of animation. However, they are not perfectly optimized yet as I’m still using a margin for the swaying (which doesn’t make use of the GPU). I might update that later on, but for now, this is how I made the animation:

@keyframes goToTopHeart {
  0% {
    opacity: 0;
    translate: 0 100vh;
    scale: .2;
    margin-left: calc(var(--_sway) * 1px);
  }
  10% {
    opacity: 1;
  }
  18% {
    scale: 1;
  }
  10%, 30%, 50%, 70%, 90% {
    margin-left: calc(var(--_sway) * -1px);
  }
  20%, 40%, 60%, 80%, 100% {
    margin-left: calc(var(--_sway) * 1px);
  }
  80% {
    opacity: 1;
    scale: 1;
  }
  100% {
    translate: 0 -100%;
    opacity: 0;
    scale: 0;
  }
}

And let’s now initialize the animation on our hearts, once again making use of those custom properties that we’ve set in our :host:

.heart {
  /* previous code */
  opacity: 0;
  animation: goToTopHeart var(--_duration) var(--_iteration) var(--_ease);
  animation-delay: calc(var(--delay) * .1s);
}

Notice that we’ve set a delay, we will be needing this later on. Because - for now - our hearts look like this:

Your browser does not support the video tag.

All that is left for us to do is to add a delay for each heart, let’s do that by overwriting that custom property inside of our loop, the full html will look like this:

 return html`
        <div class="for-love-hearts" part="hearts-container">
          ${Array(this.amount).fill('heart').map(index => {
            const randomNumberLeft = Math.floor(Math.random() * 101);
            const randomNumberDelay = Math.floor(Math.random() * 101);
      return html`<div class="heart" data-item="${index}" style="--left: ${randomNumberLeft}%; --delay: ${randomNumberDelay};"></div>`;
    })}
        </div>
    `;

Consider user preferences

Keep in mind that there are users out there that don’t want to have any unintentional animations on the screen. Yes, it would make this web component a disturbing factor, but better that, than an unhappy user. Let’s disable animation and hide the container for users that set their preferences to reduced motion by adding the following to our CSS:

@media (prefers-reduced-motion) {
  .heart, .for-love-hearts {
    display: none;
    animation: none;
  }
}

All of these things together result in the following:

See the Pen for-love-element basic by utilitybend (@utilitybend) on CodePen.

A lovely little experiment…

If you’d like to take a bit of a deeper dive inside of this web component, here are a few links:

For-love-element on GitHub
for-love-element on npm
Previous article “Getting into web components” with some handy links for those that want to learn more about them

Although I’m absolutely sure that this web component is useless and not production-ready because it could use some optimising, I’m very pleased to have created my first web component. I do think it could solve a lot of the tedious tasks we have as front-end developers and I do believe they deserve a bit more attention in 2024.

See the Pen for-love-element multicolor by utilitybend (@utilitybend) on CodePen.

Getting into web components - an intro

Brecht De Ruyte — Mon, 05 Feb 2024 00:00:00 GMT

A two-part post on web components

This article will be split into two parts. In this first section, I’d like to cover the basics of web components, while the second part will serve as a tutorial on creating my first (useless) component.

For those who are utterly clueless about web components - no need to feel ashamed; I’m catching up myself. In this article, I want to delve into the theory and some basic terminology that was complete gibberish to me until a few months ago. One of the key aspects of my blog is documenting the things I learn, with the hope that others can also benefit from it. While there might be better in-depth tutorials available on this subject, I’ll write about some basics and include some recommended reads at the end of this article.

If you do not care about the basics and lingo and just want to hop over to the component I created, that’s fine.

The for-love-element on GitHub

What are web components?

One of my favorite weekend activities is opening a box of LEGO Classic with my daughter and simply building things—sometimes following the booklet, sometimes relying on our imagination. When we search through the LEGO boxes for pieces, we occasionally come across some that are still connected, making it easier for us to avoid starting everything from scratch. It’s perfect; you’ve found yourself a component that you can easily reuse.

This is a perfect analogy for web components; they’re like building blocks for websites, or perhaps even groups of building blocks.

I’m sure that this analogy has been made a lot in the past as I did a quick Google search and got a few hits, but it’s just perfect for it so I’m shamelessly re-using it here. (See what I did here? The analogy just became a component)

Let’s start with the lingo: Custom Elements

Instead of sticking with standard tags like <div> or <button>, we can design your own tags, such as <my-button> or <for-love>. These tags represent unique components that we can use and reuse across our website or web app. It’s like having your own arsenal of tools perfected to your needs. Custom elements always need to have a hyphen inside of them to distinguish them from standard HTML elements and to follow the naming conventions set by the Web Components specification.

The main reasoning behind the hyphen is to avoid conflicts - reducing the chance of naming conflicts with standard HTML elements. Since standard HTML elements don’t contain hyphens (and now of course, never will).

Light and Shadow DOM

Here is where it got a bit complicated for me at first, but this is kinda the best way for me to learn/visualize it:

The Shadow DOM is like a hidden room for web elements. Let’s say you have a workspace where you’re building different parts of a website. Some parts need to do their job without affecting the rest. The Shadow DOM provides an encapsulated space that does just that. It’s like putting a transparent curtain around a specific area. Elements inside this “hidden room” can have their own styles, scripts, and structure without interfering with the styles and scripts of the main page or other elements. Those other elements we’re referring to are what we call the Light DOM.

I can’t remember where I heard that transparent curtain analogy, I didn’t invent it, but it’s the one that stuck with me. That and this simple example of a web component that has an output “This is content inside the Shadow DOM”:

<div>
  <p>This is content outside the Shadow DOM, thus "Light DOM".</p>
  <my-element></my-element>
</div>

<script>
    // Create a new custom element
    class MyElement extends HTMLElement {
      constructor() {
        super();

        // Create a Shadow DOM for this custom element
        const shadow = this.attachShadow({ mode: 'open' });

        // Create a paragraph inside the Shadow DOM
        const paragraph = document.createElement('p');
        paragraph.textContent = 'This is content inside the Shadow DOM.';

        // Append the paragraph to the Shadow DOM
        shadow.appendChild(paragraph);
      }
    }

    // Define our custom element
    customElements.define('my-element', MyElement);
  </script>

The Shadow DOM has some very specific characteristics:

Encapsulation:

Inside of the Shadow DOM, your styles and scripts are not affected by the outside world. This behavior helps to prevent your styles from accidentally messing with other elements on your webpage. Outside CSS won’t have any effect on it except for custom properties.

Composition:

The Shadow DOM introduces slots, little placeholders where you can slide in your own content. This means you can customize the insides of your elements without messing with the original design. This is so powerful and let me tell you why:

In the following example, We will slot an <h2> and <p> inside of a web component. The only thing that it will do is place an <hr> between them (I know, not something you would use web components for, but it’s a simple example).

 <my-card>
    <!-- Content placed inside the slots -->
    <h2 slot="title">Card Title</h2>
    <p slot="content">This is the content of the card.</p>
  </my-card>

  <script>
    class MyCard extends HTMLElement {
      constructor() {
        super();

        // Create a Shadow DOM for this custom element
        const shadow = this.attachShadow({ mode: 'open' });

        // Create a container for the card content
        const cardContainer = document.createElement('div');

        // Create slots for title and content place hr between them
        cardContainer.innerHTML = `
          <slot name="title"></slot>
          <hr>
          <slot name="content"></slot>
        `;

        // Append the card container to the Shadow DOM
        shadow.appendChild(cardContainer);
      }
    }

    customElements.define('my-card', MyCard);
  </script>

Now imagine JavaScript fails, the page would still be showing the slotted content that is provided inside of the web component as this is just some light DOM and the only thing missing would be the <hr>. Even if you would have to support a browser that doesn’t support this, it could still be a progressive enhancement.

Accessibility:

Accessibility features are a shared language. Elements inside the Shadow DOM can understand and speak the same accessibility language as elements outside. What’s even more is that it can really help us in some of the harder accessibility use cases such as tabs. A great collection of web components that does just that can be found at genericcomponents.

Separation of Concerns:

Shadow DOM lets you neatly arrange your structure, styles, and behavior in their own compartments. Imagine having a library of web components for all those repeating tasks: accessible tabs, image zooms, and animatable dropdowns. We can still use custom properties for styling because those will bleed through the web component. But if we want to do some serious theming and want to create flexible web components, the next one is probably even more interesting…

The ::part pseudo element

It allows you to style specific named parts of a web component from outside its Shadow DOM.

Here is an example of this. Let’s combine a few things; Imagine the following example:

<my-element>
    <h2 slot="header">Header Content</h2>
    <p slot="content">Main Content</p>
</my-element>

This is what our web component looks like (give extra attention to the attributes of the innerHTML):

class MyElement extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({ mode: "open" });
    shadow.innerHTML = `
	    <style>
            div {
            border: 3px solid blue;
            }
        </style>

        <div part="header"><slot name="header"></slot></div>
        <hr/>
        <div part="content"><slot name="content"></slot></div>
    `;
  }
}

customElements.define("my-element", MyElement);

Now the best way to explain this is to visualize it with borders. By default, the <div> element inside of our shadow DOM has a blue border. We want to give a green border to the <div> wrapping the header slot, we can access this:

/* style our default h2 */
h2 {
    margin-block: 30px;
    color: red;
    border: 3px solid red;
}

/* style our web component parts green border for header */
my-element::part(header) {
    border: 3px solid green;
}

Here is that in a little CodePen:

See the Pen Web components part demo for article by utilitybend (@utilitybend) on CodePen.

The developer experience of web components

I’ve shown you some basic examples and it’s time to be honest… Writing webcomponents like this isn’t a great developer experience… at least in my opinion. It seems to work fine for basic examples, but I just love a bit of structure and colors in my editor instead of just throwing every output into a string.

Inspired by Lucien Immink, a colleague of mine who has been touring with a presentation stating that a little library called “Lit” is on fire. I decided to give it a go… and yes! It was a lot more fun to write a little web component. Thank you Lucien for the hot tip.

Lit: Using a library to help create web components

The Lit library is designed to make it easier and more efficient to work with web components. It offers several advantages that can ease some of the burdens by just writing them the normal way.

Lit provides a more declarative syntax for defining components. Using this approach can make our code easier to understand and manage, as opposed to the more complex style needed when dealing directly with the Web Components API. It also has this neat templating system that combines HTML and JavaScript template literals, making it more convenient to work with dynamic content. This not only helps with some nice colors in our editor but also helps with their updating strategy that only updates the parts of the DOM that have changed. This can lead to improved performance compared to manual updates.

With all of these things combined, I’d say it’s worth taking a look at it if you’re serious about web components as this library is only about 6kb in size.

There is a lot more going on such as experimental server-side rendering, but I’m just starting with this and will need to get into the details a bit more myself.

To give an example, this is the same border demo, but then in Lit

See the Pen Lit example for article by utilitybend (@utilitybend) on CodePen.

Final thoughts and demo

I’ve just gotten into this whole web component thing and I really like what I see. I’m so late to the party and it has been on my list for a while. I love the web platform and because I keep a high interest in Open UI, I was inspired to take a deeper dive into this kind of thing.

I love the philosophy behind web components and believe that it’s an important thing to get into. As companies grow bigger, so does the need for different frameworks, which makes web components a perfect thing to integrate in your company’s ever evolving tech stack.

So many people are talking about them lately and I’m just giving it a go. I found the basics and lingo hard at first, so I hope that writing this article this could clear up some of the fog for others sharing the same struggle.

Here are a few reads that I enjoyed:

HTML web components by Jeremy Keith
HTML Web Components are Just JavaScript? by Miriam Suzanne
Web Components Will Outlive Your JavaScript Framework by Jake Lazaroff
Why Lit is on fire by Lucien Imminck
A Complete Introduction to Web Components by Craig Buckler

And also a special shoutout to the Frontend masters course on web components by Dave Rupert. Yes, it is a lesson you need to buy, but it helped me to get a start on the matter. In the next article, I will be doing a little breakdown of how I created my first (useless) web component.

Yes, it’s useless
Yes, It might not be the best example out there
Yes, it’s an npm package
Yes, I am so proud of it because “I did a thing”

You can find the for-love element with info here

And an example right here at the end of this article. Next article I will do a step by step of the creation of it.

See the Pen for-love-element basic by utilitybend (@utilitybend) on CodePen.

Going beyond pixels and (r)ems in CSS

Brecht De Ruyte — Tue, 30 Jan 2024 00:00:00 GMT

Read the article at iO tech_hub

Taking a closer look at @property in CSS

Brecht De Ruyte — Mon, 08 Jan 2024 00:00:00 GMT

Without going too much into the history about this technique of handling our custom properties, it might be nice to repeat just a little of the basics for those landing here and having absolutely no clue what I’m going on about.

What is this @property thing?

The @property rule is part of the CSS Houdini umbrella of APIs, which aims to provide more control and flexibility for authors. It was introduced in the CSS Properties and Values API Level 1 spec around 2019 and has had a long support in Chrome and Edge, followed up by Safari. I personally didn’t experiment that much with Houdini when it first came around as it never felt natural to me.

The Purpose of @property

The @property rule allows developers to explicitly define custom CSS properties (also known as CSS variables). This provides several benefits:

Property type checking and constraining: We can specify the data type of a custom property, such as <number>, <color>, or <length>. This helps prevent errors and ensures that custom properties are used correctly, a win for design systems and we all love typing these days, right? Find the full list of syntax types here
Setting default values: We can set a default value for a custom property declared this way with the initial-value property. This ensures that the property has a fallback when not set elsewhere in the stylesheet.
Defining inheritance behavior: We get to choose whether a custom property can inherit values from its parent elements or not. That way we can manage how our custom properties are applied in the cascade, more about that later on.

Basics of @property

The @property rule gives us a more structured and powerful way to create and use custom properties. This opens up new possibilities for customization and especially theming. Here’s an example of how to define a custom property named --primary-color with a initial-value of #ea1ca5:

@property --primary-color {
    syntax: "<color>";
    inherits: true;
    initial-value: #ea1ca5;
}

This definition specifies that --primary-color is a color property, it can inherit values from parent elements, and its default value is #ea1ca5.

Once a custom property is defined, it can be used in CSS declarations just like any other property:

body {
  background-color: var(--primary-color);
}

This declaration sets the background-color of the body element to the value of the --primary-color custom property.

Now that we got the basics right, off to the fun stuff! Let’s talk about the opportunities this opens.

Property type checking and constraining

By using @property to define custom properties with clear types, we can easily maintain and update our code. This can make it less time-consuming and error-safe to modify custom properties as a project evolves. It’s even a bigger win when building a design system that gets used by third-parties, showing the users that something doesn’t seem right in DevTools.

Just as the first example, let create a little playground with color:

At the top of our CSS we will add the following:

@property --color {
    syntax: "<color>";
    inherits: true;
    initial-value: #ea1ca5;
}

Our playground HTML will contain three div elements, each with a different class:

<div class="color-1"></div>
<div class="color-2"></div>
<div class="color-3"></div>

Now let’s set the default custom property on the <div> element, give it some width and height. Next up, we’ll overwrite this custom property for each of the classes:

div {
    display: flex;
    justify-content: center;
    width: 20vw;
    height: 100px;
    background: var(--color);
}

.color-1 {
    --color: #1a535c;
}

.color-2 {
    --color: rgb(100, 200, 0);
}

.color-3 {
    --color: #3e47db;
}

With a bit of extra styling, this is the result.

What happened here?

Notice that it doesn’t really matter how we write the colors when using the <color> type. For example, in .color-2, we chose to use the rgb() function and it still works.

So all of this is valid, but let’s take a look at what happens when we change .color-1 to an integer.

.color-1 {
    --color: 4;
}

We are now seeing our fallback color as the value is invalid. It’s handy to have a fallback system like this and personally, I love this.

Debugging @property in Chrome DevTools

With Chrome version 118, DevTools provides useful information about typed custom properties. Let’s inspect the element with an invalid color value after setting the --color property to 4. A warning icon appears next to the custom property. Hovering over the icon reveals an error message stating that the property value is invalid and the expected type is <color>.

" loading="lazy" decoding="async" fetchpriority="auto" width="160" height="90">

An anchor below the warning directs us to the custom property declaration.

When hovering over a valid custom property, we receive detailed information about the property:

The current value
The expected syntax
The inherits boolean
The initial value
And an anchor to the declaration

This DevTools functionality significantly enhances the efficiency of using typed custom properties.

See it in action in this video by the DevTools team

Defining inheritance behavior

If the inherits property is set to true, the custom property value can be inherited by child elements. This means that if we set a value for the custom property on a parent element, that value will be applied to all of its child elements unless they have their own value set for the property. This is also the default for custom properties.

Let’s keep using our colors demo for this and add a new element inside of the div with class .color-2. This is now the updated HTML:

<div class="color-1"></div>
<div class="color-2">
    <div class="inner"></div>
</div>
<div class="color-3"></div>

Now let’s give this new div.inner a bit of styling. To see our element clearly, we’re going to give this a white border as well.

 .inner {
    background: var(--color);
    border: 3px solid white;
    width: 50px;
    aspect-ratio: 1;
}

We are making it inherit the --color custom property for its background, this will result to the following:

Now let’s update our declaration of the custom property and set the inherits to false.

@property --color {
    syntax: "<color>";
    inherits: false;
    initial-value: #ea1ca5;
}

The result:

Because the inherits property is set to false, the custom property value cannot be inherited by child elements. This means that each child element must explicitly set its own value for the property, thus in this case, showing the initial-value color.

Why set inherits to false?

Disabling inheritance for custom properties could be a good practice when we need to have more control over the styling of individual elements and avoid unintended overrides (for example, in design systems or web components). It can also simplify our CSS code and make it more maintainable. However, if we would want to maintain a consistent style across a hierarchy of elements, inheritance can be a useful tool. This why I believe that setting inheritance to false should come with a sense of caution to avoid confusion when working on a large project with multiple authors. But that’s just my 2 cents, and writing documentation can go a long way.

Unlocking new possibilities with @property

The introduction of @property opened up exciting possibilities for CSS, particularly in the realm of animations. One of the most popular demonstrations of @property is the animation of a hue rotation wheel.

Consider the following example:

:root {
    --hue: 0deg;
}

.item {
    background: hsl(var(--hue), 50%, 50%)
}

@keyframes {
	from {
        --hue: 0deg;
    }
    to {
        --hue: 360deg;
    }
}

This won’t work at all, because the browser has no idea on how to animate hue rotation. However, using @property, we can explicitly instruct the browser to interpret the --hue variable as an <angle> value, enabling smooth animation:

@property --hue {
    syntax: "<angle>";
    inherits: false;
    initial-value: 0deg;
}

See the Pen Hue wheel rotate by utilitybend (@utilitybend) on CodePen.

Here is another example using that same technique in combination with some SVG:

See the Pen iO Style yours challenge by utilitybend (@utilitybend) on CodePen.

Animating clip-path with custom properties

For a scroll driven animations demo I wanted a dotted line to appear in a timeline. To initially hide that line, animating a clip-path seemed like good idea, but we can’t just animate the percentages from a clip-path with a custom property. @property however, can be used to animate the dimensions of a clipping mask. For instance, to gradually reveal an element, we can define variables for the vertical and horizontal percentages of the clipping mask and animate them.

@property --clip-vertical {
  syntax: "<percentage>";
  inherits: false;
  initial-value: 95%;
}

@property --clip-horizontal {
  syntax: "<percentage>";
  inherits: false;
  initial-value: 100%;
}

.item {
  clip-path: inset(0 0 var(--clip-vertical) var(--clip-horizontal));
}

We can set the initial value to (almost) completely hide the element with a full clip-path. To animate the removal of the clip-path, we can create an animation:

.item {
    clip-path: inset(0 0 var(--clip-vertical) var(--clip-horizontal));
    animation: showLine linear both;
}

@keyframes showLine {
  0% {
    --clip-horizontal: 100%;
    --clip-vertical: 95%;
  }
  60% {
    --clip-horizontal: 0%;
    --clip-vertical: 95%;
  }
  100% {
    --clip-horizontal: 0%;
    --clip-vertical: 0%;
  }
}

This example can be found in the following demo (In combination with Scroll Driven Animations):

See the Pen Scroll driven animation timeline by utilitybend (@utilitybend) on CodePen.

Animating Background-Image Gradients

Animating the colors of a background-image gradient is unfortunately something that isn’t possible by default. However, by defining the gradient colors using @property, we can finally do this:

By animating the --from-color and --to-color variables, we can create visually appealing transitions between gradient colors, This would be that basic idea:

@property --from-color {
  syntax: "<color>";
  initial-value: #f0f;
  inherits: false;
}

@property --to-color {
  syntax: "<color>";
  initial-value: #0ff;
  inherits: false;
}

.item {
  background: linear-gradient(to right, var(--from-color), var(--to-color));
  animation: gradient 4s linear infinite;
}


@keyframes gradient {
  0%,
  100% {
    --from-color: #f0f;
    --to-color: #0ff;
  }
  50% {
    --from-color: #00f;
    --to-color: #ff0;
  }
}

Here is that in action:

See the Pen Animating Background-Image Gradients with @property by utilitybend (@utilitybend) on CodePen.

Or take a look at the following example where I animate another gradient (with kudos to gradient.style)

See the Pen Animated Gradient BG with @property by utilitybend (@utilitybend) on CodePen.

It is a game changer

This is really going to be a fantastic addition for those of us that love creating design systems and fancy animations. Remember that these are just some basic examples. I’ve seen quite a few examples out there by far greater minds than myself where even numbers were converted to integers. Really looking forward to what this will bring, whether that is for animations or just really clever typed design systems.

I really went the extra mile with writing this as I hope that for some this can be a great entry point. To be honest, this was an entry point for myself as I was doing research while writing this article. Not bad for a first article of the year, not bad at all….

Let 2024 bring you lots of happiness, love and beautiful splashes of CSS once again. May you be joyful, playful and keep on coding the amazing things you do.

Happy holidays and a popping start of 2024!

Brecht De Ruyte — Thu, 21 Dec 2023 00:00:00 GMT

My gosh, has it been a year already. Time sure does fly when you’re having fun. About a year ago, I wrote my holidays blogpost with a few goals:

Keep writing, do something related to scroll driven animations and CSS anchoring
Return to CSS day
Do some more guest writing
Follow Open-UI a bit more closely
Try public speaking

If this were a checklist I’d say I pretty much checked all of those points. I wrote about 17 articles this year, including 3 guest articles for Smashing Magazine. I haven’t written for CSS-Tricks anymore as they - unfortunately - don’t allow any guest writers anymore.

But on a positive side, Geoff Graham started working at Smashing Magazine, so I was able to work with him again, which is just awesome.

W3C community groups

I did keep following along with Open-UI. I still learn a ton out of this community group and I love the direction it is going. Now with invokers being available in Canary, exclusive accordions getting releases in multiple browsers and selectlist having a great prototype, it really is a joy to play around with all these goodies.

What’s more is that there actually are releases for popover in Chrome, Edge and Safari. With the polyfill available, it’s going to be a popping 2024. I’ve also started following along with the CSS Next community group. But I’m still playing a bit of catch up.

Keep building fresh content or updates

I try to write fresh content, or at least approach something from a different angle and will continue to do so in 2024. This is also a journey for me and articles get created by exploring and learning new things around the web. It’s also just nice to look back at the things I’ve learned.

I think it’s important to be true to yourself and others. When I write about a certain technique inspired by someone else, I will always mention the person who created it. When showing a demo by someone else while speaking, I add it to the credits and mention it out loud. I think that’s just basic respect and I hope people would do the same with the things I create. I’d rather write nothing, than to just steal something without shame.

Public speaking

From a first try-out at fullstack Belgium to speaking in Berlin as a GDE, If you would’ve told me that at the beginning of this year, I probably would’ve laughed at you. I’m still not the confident person that I want to be when doing this, but it’s gotten a bit better. I did learn that public speaking is something that can be trained, so when opportunities are presented for it, I will keep trying and working to get better (in my own “quirky” way).

A word of thanks

I’m grateful to a lot of people… Because this blog and the content I bring would be nothing without the patience, tutoring, retweets and invites by a lot of people.

It’s impossible to name everyone, but to summarize: Thank you, to everyone at the Open-UI group (Greg, Mason, Scott, Hidde, Luke and many more) for being patient with me and letting me help out, to the Google DevRel people (Una, Adam, Bramus) sharing my content and inspiring me, the people at Smashing Magazine (Iris, Geoff,…), to Dries and Freek for giving me my first chance to public speaking at Fullstack Belgium, to Claudia, for my first time speaking at Fronteers Belgium, all my colleagues at iO for the fun times, inspiration and hard coding sessions and the fantastic front-end developer day this year!

And especially, thank you to my family, my wife and my daughter, I’d be lost without them.

Goals for 2024

This might sound a bit strange, but I’m pretty happy at the moment. I was thinking of trying something with video as well, but as I hate a camera in my face, that remains to be seen.

I think I mostly want to keep improving at the things I’m already doing and who knows, maybe speak for more people than ever before.

I’d love to work a bit more on the Google Developer Expert program and i’m brainstorming about doing a bit more for students as well. Maybe this is something iO can support me in during the course of next year by allowing me to spend some extra time on it.

So, in contrast to last year, I haven’t got anything specific except for getting more involved with the community and improving myself as a speaker and just keep writing those articles.

I wish everyone of my readers a happy new year! Enjoy some time with family and friends and even though there are a lot of issues in the world, never forget those close to you, they are so important. Treat each other with respect and patience and make 2024, the best year ever.

PS: As by tradition: a CSS holiday card:

See the Pen Fireworks - Happy New Year 2024 by utilitybend (@utilitybend) on CodePen.

CSS Scroll Snapping Aligned With Global Page Layout: A Full-Width Slider Case Study

Brecht De Ruyte — Wed, 13 Dec 2023 00:00:00 GMT

Read the article at Smashing Magazine

Elevate your CSS debugging skills with these Chrome DevTools tricks in 2024

Brecht De Ruyte — Tue, 14 Nov 2023 00:00:00 GMT

Viewing CSS layers

I’m actually starting off with a feature that was added before 2023, but one that I’ve only been using recently as I was working on a modern CSS “bootstrap file”.

When working with multiple layers, especially across multiple files, it is possible to get a bit lost. Thankfully, DevTools has got our back as we can now see in which layer a selector was specified by looking right above it in our style panel:

It does get a bit better than this though. If we’d like to see a great overview of our layers, we can just click on the layer itself to view where this layer is added in our cascade. This is especially handy when working with a lot of nested layers, to keep our sanity in check:

If we just want to view the layer tree, we can also click this little Icon in the style panel

At first sight, some people might think this really isn’t something with a big use case, but if we work on multiple projects in multiple layers and start nesting these layers as well, it can really help us out:

@layer theme {
    :root {
        --font-family-heading: Georgia, times, serif;
    }
}

@layer components.typography {
    h1,
    .h1 {
        font-family: var(--font-family-heading);
    }
}

Layers are starting to get used a lot more often, so it’s great to have these tools.

Checking selector specificity

This little update might’ve gone unnoticed for some, but it’s one of those little additions that can really help while debugging or just building our design system.

When we hover over a selector, we now get to see the specificity:

No more guessing or using external tools for this, we can just view it in our devtools. I love how sometimes little additions can have a big impact, this is one of those.

No idea what these three digits are about?
You can read up on it on MDN, but if you’d rather have someone explain it to you, you can always watch this part of a talk by Bram.us.

Clear nesting support

This year, we also got a bit of extra tooling when it comes to nesting. It’s just another one of those quality of life improvements that shows the parent selector grayed out in the styles panel. Once again, a little visual update, that goes a long way!

HD color formats

We have all these new color spaces in CSS and they are so much fun to play around with. We might need to add fallbacks for browsers that don’t support it yet when using them. However - in DevTools - we can easily see when we leave the sRGB color space when opening the color panel in the styles panel (notice the area marked with a red border).

In this example, I was using an oklch. There is a simple way to change the current color space we’re working in by clicking the area marked in green on the screenshot above. I’m not sure if this is something we’ll use a lot, unless designing straight in the browser. But it did help me out creating some of those demo’s.

The demo i was referring to is the following one:

See the Pen Cocktail glass with oklch slider and color mix by utilitybend (@utilitybend) on CodePen.

Linear timing support in the easing editor

When using the animation-timing-function: linear(); function, we can now easily update the curves by clicking on it and dragging around in the curve. Just left click to add an extra point and double click to remove it, there are also some presets to be found on the left.

🔥 Extra hot tip: Did you know that by clicking the arrows at the bottom of this little popover you can get a lot more presets created by cubic-bezier()? Pretty cool for tweaking those animations and want to find something “just right”.

Transparency preference in the rendering tab

The rendering tab is probably one of the tabs I use the most for that final accessibility check and test for reduced animations, vision deficiencies, etc. I talked the rendering panel in a previous article and used the contrast emulations for a little article on Smashing Magazine. It has something new though.

We can now check if a user has toggled a reduced transparency preference.

This goes hand in hand with a new media feature query (currently only in Chrome and Edge):

.transparent {
    opacity: 0.5;
}

@media (prefers-reduced-transparency) {
    .transparent {
        opacity: 0.85;
    }
}

Why reduced transparency matters

Various operating systems provide a preference for reducing transparency, and user agents are likely to rely on these system settings. For now, this feature query is only supported in Chrome and Edge, but I’m sure other browsers will follow. Especially as this is a setting that can be set on both iOS and macOS as well.

I think the ability to make the web platform an extension of user systems in their operating system is a great thing. Especially for applications running on the web.

Editing @property defined custom properties

In case you missed it, we are finally getting full browser support for @property very soon with Firefox planning to release it in the next version. In Chrome DevTools we now have the ability to do some debugging, the @property declarations are grouped together and we can change the values in the style panel. This will come in handy and also reminds me that I really want to write about @property sometime.

Bonus: Scroll Driven Animations debugging

I’m a big fan of the new scroll driven animations spec, I even updated my homepage with it. But now, there is a way to easily debug it. This is a bonus as it is an extension that we can add to our devtools. The extension can be found at the chrome web store. Add the SDA debug tool to Chrome here.

When installed we get an extra panel next to the styles, layout, accessibility panels. This will give us a little minimap when using scroll driven animations:

This is so cool! Especially because I still haven’t completely wrapped my head around the terminology yet (eg: cover, contain, crossing, etc). This tool gives us the chance to play around with these values and makes life just a bit easier:

For more ins and outs on how this tool works, check out the video on the Chrome web store page. One note though, we can not access this tool via iframes, so if we want to test it with a codepen, we have to use debug mode in our pens. You can use this link if you want to do a quick test.

Maybe in the future we can have a native version of this in DevTools, removing some of the restrictions of a plugin.

Conclusion

Most of the things I wrote about here are just about those little ease of life things. Those things that have been updated but might’ve gotten under our radar. These little changes really create a big impact when put together. I’m sure not all of these are little when it comes to developing them, so a big kudos to the DevTools team.

I have a feeling many more things are coming our way for animations (maybe a native DevTools Scroll Driven Animations debugger?). This would make sense because the DevTools Team asked a lot about the animations panel earlier on CSS Day this year and we also have a lot of new animation stuff, not only on scroll, but also view transitions.

So who knows, maybe some cool big animation update in 2024? Let’s see.

Hungry for more DevTools:

Animations and transitions from and to display none with @starting-style

Brecht De Ruyte — Tue, 10 Oct 2023 00:00:00 GMT

Situating the problem - transitioning and animating display: none

Animating from and to display none was something we could only achieve in a hacky way. We could play around with JavaScript to change classes or use some other hacks. However, we do have number of reasons why we want animation to work with the display property:

display: none; is not the same as a full transparency with opacity, because with display none, it’s hidden for all users and devices (including screen readers)
We don’t want the elements to keep the space when fading out, but instead be completely gone.
We might want to make it easier for users to understand what is happening on the page. For example, you could animate a loading spinner popping in while a page is loading, or animate a success message in when a user completes a task.

So, why was this so hard? The CSS transitioning spec:

In Level 1 of this specification, transitions can only start during a style change event for elements which have a defined before-change style established by the previous style change event. That means a transition could not be started on an element that was not being rendered for the previous style change event

Quote from CSS Transitions Level 2 spec

In simple terms, this means that you cannot start a transition on an element that is hidden or that has just been created.

Entering CSS transitions level 2 and @starting-style

This is a quick (simplified) deciphering of the “before-change style” explanation of the CSS Transitions Level 2 spec.

The @starting-style rule can be used to define the starting style for an element. The starting style is the style that a transition will start from when the element does not have a previous style.

The @starting-style rule is only applied to elements that were not rendered or not a part of the DOM during the previous style change event. For example, if you add an element to the DOM and then start a transition on that element, the transition will start from the element’s initial style, defined in the @starting-style rules.

Note: I thought for this article, it could be interesting to dig a bit into the spec, so that’s why I wanted to summarize it a little. It’s a real “down the rabbit hole” feeling when digging in these specs. But let’s get started with some of those demo’s now, as a bit of code can say more than a thousand words ;)

Using keyframes from and to display none

Prior to writing this article, I didn’t realize that animating to and from display: none with CSS keyframes was already supported in Chrome 116. That’s great!

A simple zoom out animation that ends with a display: none can be achieve by just doing the following (nothing extra needed):

.zoom-out {
    animation: zoomOut 0.3s linear forwards;
}

@keyframes zoomOut {
    from {
      opacity: 1;
    }

    50% {
      opacity: 0;
      transform: scale3d(0.3, 0.3, 0.3);
    }

    to {
      opacity: 0;
      display: none;
    }
}

That way, you get a great animation, while still keeping the benefits of display: none.

See the Pen Animate to display: none; by utilitybend (@utilitybend) on CodePen.

Using transitions from and to display none with @starting-style

Taking things a bit further let’s re-create this example but use transitions to animate our cards and create a slow fade-out.

For the HTML, we create a simple grid structure that has three types of cards:

<div class="grid">
  <div class="card card-error">
  </div>
   <div class="card card-warning">
  </div>
  <div class="card card-success">
  </div>
</div>

At the top of the page, let’s add three checkboxes that will control which cards are hidden:

<div class="controls">
  <label>
    <input class="hide-error" type="checkbox">
    Hide errors
  </label>
  <label>
    <input class="hide-warning" type="checkbox">
    Hide warnings
  </label>
  <label>
    <input class="hide-success" type="checkbox">
    Hide success
  </label>
</div>

Now all that remains for us, is to fade out the cards based on a selection using CSS transitions and also make sure they are actually set to display: none; at the end.

To do this, two things are necessary, we will need to define the @starting-style but also tell our CSS that it should allow discrete properties to be transitioned. There is a new property for that called transition-behavior.

Sidenote: What are discrete properties?

Discrete properties in CSS are properties that cannot be interpolated, or smoothly transitioned, between two values. This means that when a discrete property is animated, it will jump abruptly from one value to the other at the end of the animation.

(or at least, they used to, we can fix this now)

In the following CSS we set transition-behavior: allow-discrete;, allowing our display property to be transitioned. This can also be added inside of the transition shorthand property, but remember that it should come in last. We will set the @starting-style for our grid items to have an opacity of 0 using CSS nesting.

.grid > * {
    transition: opacity 0.7s ease-out, display 0.7s ease-out;
    transition-behavior: allow-discrete;

    @starting-style {
      opacity: 0;
    }
  }

The transition-behavior: allow-discrete property is necessary because the display property is a discrete property. As mentioned before, this means that it cannot be interpolated, or smoothly transitioned, between two values. The transition-behavior: allow-discrete property tells the browser to allow discrete properties to be transitioned.

Now that’s a lot of power with just a single property! To actually toggle the states of our checkboxes, we can use the :has() pseudo class, checking the state of the checkboxes (as this was just for demo purposes), for example:

:root:has(.hide-error:checked) .card-error {
    opacity: 0;
    display: none;
  }

You can play around with it right here:

See the Pen Warnings and errors show and hide with allow-discrete transitions by utilitybend (@utilitybend) on CodePen.

Transitioning an element entering the DOM with @starting-style

A nice benefit of @starting-style is that we can also take control of transitioning elements entering our DOM. Something we do a lot when using JavaScript frameworks.

I created a little static todo list where list-items get added with the click of a button. Handling the transforms and opacity purely with CSS transitions. In short, this is how I did it:

li {
  opacity: 1;
  transform: translate(0, 0);
  transition: transform 0.5s ease-out, border-radius 0.5s,
    opacity 0.3s linear, background-color 0.3s ease-out;
  @starting-style {
    opacity: 0;
    transform: translate(0, 50%);
  }
  &.removing {
    opacity: 0;
    transform: translate(-100%, 0);
    ~ li {
      transition: translate 0.5s ease-out;
      translate: 0 -100%;
    }
  }
}

When entering the DOM, the starting style will be taken into account. For this, we do not have to allow discrete properties and just let @starrting-style do its magic. One thing that we can’t do yet is transition to DOM removal, unfortunately. I had to add a bit of custom JS for this adding the “removing” class for half a second before removal:

removeButton.addEventListener("click", () => {
    // Remove the list item from the list
    listItem.classList.add("removing");
    setTimeout(() => {
      listItem.remove();
    }, 500);
  });

Still, I think it’s pretty neat what we can achieve with just some basic transitioning now, take a look at the demo to find some hidden transitioning gems I added:

See the Pen Enter and exit dom with @starting-style by utilitybend (@utilitybend) on CodePen.

Transitioning from and to the top-layer

There is another place where something is entering and exiting, which is the top-layer. Mostly used for popovers and dialogs for now. For these cases, we can actually handle the entry and exit animations using transitions. For a dialog, the open state is defined with the [open] attribute, while popovers have the :popover-open pseudo class.

Without the presentation style, for popovers, it can look like this:

[popover] {
    --transition-time: 0.5s;
    /* End of animation (on close) styles */
    opacity: 0;
    transform: translateY(-30px);
    transition: opacity var(--transition-time),
      transform var(--transition-time) ease-out,
      display var(--transition-time) allow-discrete;
    &:popover-open {
      /* Open styles */
      opacity: 1;
      transform: translateY(0);
      @starting-style {
        /* Right before open styles */
        opacity: 0;
        transform: translateY(-30px);
      }
    }
  }

Here is a quick demo:

See the Pen Popover transition with @starting-style by utilitybend (@utilitybend) on CodePen.

A great thing to have

These starting styles and the ability to animate from and to display: none; are a great thing to have. Personally, I never thought this would be possible some day, so I got pretty adjusted to workarounds by now, so it might take some time adjusting into using this. Unfortunately only on the latest Chrome (117) version for now, but I’m really looking forward to more browser support. Especially in combination with elements in the top-layer it’s a must-have for everything that pops.

I'm officially a Google Developer Expert

Brecht De Ruyte — Tue, 03 Oct 2023 00:00:00 GMT

The best thing about becoming a GDE is by far the community. Being able to get a lot of chances to learn and share at the same time. I think it’s a wonderful thing and I’m really looking forward to it.

So, I’m an “expert” now?

Let’s keep things real. I never was the biggest fan of the word “expert”. I’m very curious by nature and I read and learn a lot of things on a daily basis. I try to learn something new every day. I don’t want to downplay it completely, I’m aware that I know a thing or two, but it’s not like the “expert” badge will change anything from a personal standpoint.

I have noticed that I love sharing with the community as I believe that this is an important feature. A lot of developers need to work against the clock, get burned out, or even just find it hard to keep up with all the evolutions on the web. If I can at least help a few people with that, then it’s worth the extra hours I spend on a daily basis, besides my full-time job.

Web technologies, because I love the platform

I will be taking on the Google Developer Expert role in the category “web technologies, UI and tooling”. This is mostly for my love for good UI and CSS and of course my interest in Open UI.

I’m really looking forward to what the Google community will mean for me in the future and I won’t let this chance go to waste, that’s for sure.

But first I have some more reading to do and just looking around in this community. Really excited for this. And to all the people who read my little tutorials, stories or tips and tricks. Thank you. It wouldn’t have been possible without you.

Grid ideas: Creating a CSS subgrid utility class for rows

Brecht De Ruyte — Tue, 12 Sep 2023 00:00:00 GMT

What is this CSS subgrid?

Subgrid is part of the level 2 CSS Grid Layout specification and is a value that can be applied to grid-template-columns and grid-template-rows. When you add display: grid; to a container, the direct children become grid items and everything inside of those gets displayed in the normal flow again.

By adding this new value to the direct children of our parent grid, we can make the elements inside of our grid items follow the tracks of a parent. A handy feature indeed.

That’s enough theory from my side, A fully, better technical explainer can be found on MDN.

What is all the fuss about?

To be honest, there are a lot of people that are way more hyped about subgrid than I am, but I did run into a few cases where it can be really handy and it’s especially one of those cases I want to highlight.

Let’s take a look at the following grid:

This could be a bit better, right? When we have cards like this, a preferred presentation could be to have the heading, images, paragraphs and buttons aligned on the same track. All in good time, let’s get started with our basic grid utility.

The CSS grid utility class

This is one of my favorite ways to add a grid utility class. This idea was shown to me at CSS Day, by an amazing talk by Stephanie Eckles. I suggest you check that out for a full picture. In order to explain how I got to the idea of my subgrid utility, it’s important to understand the basics of this method first.

It all start with a utility class in your HTML

<section class="grid">
    <article>grid item</article>
    <!-- bunch of other grid items -->
</section>

Now, the following bit of CSS code will create a grid layout where the number of columns adjusts automatically based on the container’s width. Each column has a minimum width of 400 pixels (or 100% if the container is narrower) and shares the remaining space equally. This is a responsive grid layout that ensures the columns are not too narrow on smaller screens while utilizing available space efficiently on larger screens. This way, you get a fluid grid, without having to write a container or media query.

.grid {
  display: grid;
  grid-template-columns: repeat(
      auto-fit,
      minmax(min(400px, 100%), 1fr)
    );
    gap: 24px;
}

Pretty cool right?

But it’s not really a utility yet, to achieve this, we need to add some custom properties into the mix. In the example by Stephanie, she created two layers for this, a theme layer for :root custom properties and a layout layer which will include the .grid itself to inherit some of those :root properties.

@layer theme {
  :root {
    --layout-column-min: 400px;
    --layout-gap: 24px;
  }
}

@layer layout {
  .grid {
    --grid-min: var(--layout-column-min);
    --grid-gap: var(--layout-gap);
    display: grid;
    grid-template-columns: repeat(
      auto-fit,
      minmax(min(var(--grid-min), 100%), 1fr)
    );
    gap: var(--grid-gap);
  }
}

The benefit of this is that we now have a flexible utility class. If we - for example - would want to make another product grid, which derives from the default. We could just add the following to our HTML and CSS

<section class="grid grid-products">
	<!-- bunch of items  -->
</section>

.grid-products {
    --grid-min: 500px;
    --grid-gap: 16px;
}

This is only the beginning. In the presentation by Stepanie, there is a great idea on how to add a flex utility class based on this as well. But as we’re talking about grid, I’m going to end it here. Here is a codepen of her full approach to grid and flex:

One thing I do need to mention is that in this system, all the grid (or flex) items are set to be a container, by adding the following:

:is(.grid, .flex) > * {
    container: var(--grid-item-container, grid-item) / inline-size;
  }

This allows for some really modern web development! But there is a gotcha about this later on.

Creating our subgrid utility class

Our grid is set, but now we want to have a subgrid inside of this. We will need to adjust our markup a bit, because our grid-items on which we want our subgrid on need to be direct children of the parent grid.

Subgrid is powerful, but not flexible

This is one thing about subgrid that’s important to know. It is pretty powerful, but it’s not very flexible. Our grid-items on which we want to put the subgrid value on need to be direct children of a grid. More importantly, we need to know the number of children of our subgrid as well. But let’s not give up on creating a utility class for this.

Let’s add a new class to our grid to tell we want the rows to be in a subgrid:

<section class="grid subgrid-rows">
<article>
    <h2>A title</h2>
    <img src="..." alt="" />
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit…</p>
    <footer>
      <button>Some button</button>
    </footer>
  </article>

<!-- more of those article elemnts  -->
</section>

As you can see, our article on which we want to add the subgrid has 4 direct children (h2, img, p, footer). Based on this, let’s create the default of our utility. At the bottom of our layout layer (or in a separate one behind it) let’s add the following to our CSS:

.subgrid-rows {
    > * {
      display: grid;
      gap: var(--subgrid-gap, 0);
      grid-row: auto / span var(--subgrid-rows, 4);
      grid-template-rows: subgrid;
    }
  }

This time, I already provided some custom properties which could be overwritten based on the use case, especially for the amount of tracks (children) and the gap.

And here is an example of this (spoiler, it doesn’t work)

You can’t combine container-type with a subgrid

The container-type property is used to control how a grid item is laid out in its parent grid. The subgrid value of the grid-template-rows property tells the nested grid to use the tracks defined on the parent grid. However, the container-type property can only be applied to grid containers, not grid items. Therefore, we cannot combine the container-type property with the grid-template-rows: subgrid value.

So, we could update our default selector that declared that direct children of a grid should be a container. We could overrule it in our utility, or use :not(). I chose the second option.

  :is(.grid:not(.subgrid-rows), .flex) > * {
    container: var(--grid-item-container, grid-item) / inline-size;
  }

Making our CSS Subgrid utility flexible

The question that remains is how can we make this utility as flexible as possible and there are two methods that came to mind when I was creating this:

Adding an inline style attribute to our grid to set --subgrid-rows
Using :has() and create a bunch of defaults

Method 1 is pretty straight forward, we already added the custom property for this. We could update our HTML with a custom property:

<section class="grid subgrid-rows" style="--subgrid-rows: 4;">
 <!-- items -->
</section>

Method 2 does create some unneeded CSS, but on the other hand it can automate some things in the future. You could add the following lines of code into your CSS file

.subgrid-rows {
    &:has(> :nth-child(1):last-child) {--subgrid-rows: 1;}
    &:has(> :nth-child(2):last-child) {--subgrid-rows: 2;}
    &:has(> :nth-child(3):last-child) {--subgrid-rows: 3;}
    &:has(> :nth-child(4):last-child) {--subgrid-rows: 4;}
    &:has(> :nth-child(5):last-child) {--subgrid-rows: 5;}
    /* and you can keep going... */
    > * {
      display: grid;
      gap: var(--subgrid-gap, 0);
      grid-row: auto / span var(--subgrid-rows, 5);
      grid-template-rows: subgrid;
    }
  }

This will count the exact number of children up to 5 and pass this as a custom property to the subgrid.

I think it might be dependent on the project or use case to pick a favorite. But I think these are a few valid first drafts.

Here are the two examples in action:

Method 1 with inline style

Method 2 with :has()

Conclusion of CSS Subgrid

I think subgrid is a fantastic addition to CSS. It however, lacks a bit of flexibility and it might get overwhelming if we have projects full of subgrid tinkering. I do mostly see a bigger benefit in using it for rows than columns, but that’s purely subjective. Surely there are many use cases out there on which it could be handy for columns. I’ll write about it when i need it.

It has been a feature that I didn’t use as progressive enhancement because of the big market share of Chrome and Edge. But since it’s just around the corner for both of them, It’s time to do some implementations and further experiment with it.

Keep tinkering on those grids, y’all

Recharging batteries - Taking breaks is important

Brecht De Ruyte — Tue, 08 Aug 2023 00:00:00 GMT

Being honest to yourself and your company

I always think it’s important to reflect on the time you invest in certain side projects. I love doing things such as following along with Open UI meetings, spreading the word by giving presentations, tutor some CSS and writing about my own take on it. It helps me grow as a developer, as a writer, maybe even as a presenter.

All of these things happen in my free time. I do enjoy my job at iO in general as I get to write CSS for a living, but making 3 presentations in 8 months is hard as well as trying to write good content and creating demos. These things are especially hard if you have to do them in evenings and weekends while working on a hard deadlined project. I never get to use any company time for these things, so yes, It does take up a lot of energy.

Family matters

I am a truly blessed person with a supportive - and just generally fantastic - wife and a healthy daughter who allow me to follow my passion. But not everything is perfect as my dad is still fighting cancer and this is still a struggle. I don’t talk about it that much, for the same reason that I don’t share a lot of pictures of my daughter on social media. I like to keep things a bit private.

But I’m looking forward to spending 4 weeks with my daughter, taking walks, maybe teaching her a thing or two, creating awesome foods and sporty activities. It’s going to be awesome! As well as some well-deserved rest together with my wife. Barbecues, board games, all that stuff.

Hobbies

I don’t get around doing much photography anymore, I hope to pick this up again as well. I do have a few personal “lazy side-projects” I’ve been willing to do: Build that Lego set I’ve never finished, start playing the latest Zelda game and start jamming on that guitar again - cranking it to 11 - just for the heck of it.

An “almost” digital detox

I’m mainly going to stay away from overly using social media, the day job and writing in August. I will be following the Open UI telecons but that will be pretty much it. Keeping the code to the minimum and enjoying some sunlight and activities. I don’t really have to “turn off social media” as I’m pretty lousy at following up socials anyways.

But mainly, thanks from me

I’ve noticed a growth in popularity of this blog, people sharing, commenting on Mastodon or Twitter (X?). It’s grown from a handful to thousands and I really want to thank all of you readers, even though I don’t really know who you are. The support really matters, a simple “retweet” or “like” can make my day. This blog has already given me the opportunity to meet a lot of interesting people and I hope to continue this in the future - after - the break.

One last demo

Before I end, some final demos in which I played around with OKLCH colors in Chrome with the theme “summer vibes”. One of them as an “iO challenge” and one of them in my spare time. This time without explainers, if you’d like me to give some more info on them, let me know, but it will have to wait for now…

☀️ Summer mode engage ☀️

Scroll driven animations in CSS are a joy to play around with!

Brecht De Ruyte — Mon, 24 Jul 2023 00:00:00 GMT

Scroll driven VS scroll triggered

You heard that right, we’re talking about scroll driven animations, which is not completely the same as scroll trigger animations. In this case the animation gets played while the user is scrolling the page, using the scrollbar as its timeline. Although there are some tricks on how you can achieve a scroll triggered animation by using some modern CSS, you might still want to use an intersection observer in JS for this. These animations can be blazingly fast when using transforms as they run on the compositor in contrast to popular JS methods which run on the main thread increasing the chance of jank.

The basics to create an animation on scroll

I’ve already written an article which covered the basics on scroll driven animations, but let’s repeat the basics really quick. It starts off with a basic animation in CSS but instead of giving it a timing, we add an animation-timeline:

div {
  animation: reveal linear both;
  animation-timeline: view(inline);
}

@keyframes reveal {
  0%,
  100% {
    translate: 0 -25%;
    scale: 0.7;
    opacity: 0.2;
  }
  50% {
    scale: 1;
    translate: 0;
    opacity: 1;
  }
}

A few pointers to add about this:

Do not add a timing to your animation
The animation-timeline is not part of the animation shorthand

I’m really happy that the CSSWG decided not to add this in the animation shorthand, because - let’s be honest - this shorthand is a bit of a mess and I always seem to forget the correct order for “animation” (luckily, browsers do forgive us most of the time when using this)

Combining scroll driven animations with scroll snapping

One of the things I love about all these new nifty CSS features is how well they go hand in hand. It seems only yesterday since we had scroll snapping in CSS and now we can already think about combining it with scroll driven animations… It’s pretty wild.

As an easy example, I created a Legend of Zelda game timeline with a horizontal scroll.

It basically is a timeline with articles inside of it that has some scroll snapping in the center, the HTML build-up is quite simple:

<section class="timeline">
  <article>
    <img src="..." alt="" />
    <div>
      <h2>The legend of Zelda</h2>
      <time>1986</time> -
      <strong>NES</strong>
    </div>
  </article>
  <!-- and a lot more articles for each game -->
</section>

Next up we have some basic styling by adding the articles next to each other with flexbox and add some general look and feel which I will leave out of the code example in order to stick to the essentials:

.timeline {
  position: relative;
  display: flex;
  gap: var(--gap);
  overflow-x: scroll;
  scroll-snap-type: x mandatory;
  width: 100%;
  padding-inline: calc((100vw - var(--item-size)) / 2);
}

.timeline article {
  scroll-snap-align: center;
  scroll-snap-stop: always;
  animation: reveal linear both;
  animation-timeline: view(inline);
}

@keyframes reveal {
  0%,
  100% {
    translate: 0 -25%;
    scale: 0.7;
    opacity: 0.2;
  }
  50% {
    scale: 1;
    translate: 0;
    opacity: 1;
  }
}

So, what happened here? We created a centered horizontal scroll snap and added a “reveal” animation to the parent scroll in the inline axis. The animation itself will place the article to its “active” state at 50%, which will be the 50% of its scroll distance and also the place where it snaps.

To avoid throwing insane chunks of code in this article, there is a lot more CSS going on for the styling, but when it comes to the scroll animations: The exact same animation technique was used for the images and the info panel that pops out to create the following little demo:

Your browser does not support the video tag.

View Timeline Ranges

Another great feature that comes together with scroll driven animations is the ability to specify ranges of where the animation should play.

Current options for these are:

cover: Represents the full range of the view progress timeline.
entry: Represents the range during which the principal box is entering the view progress visibility range.
exit: Represents the range during which the principal box is exiting the view progress visibility range.
entry-crossing: Represents the range during which the principal box crosses the end border edge.
exit-crossing: Represents the range during which the principal box crosses the start border edge.
contain: Represents the range during which the principal box is either fully contained by, or fully covers, its view progress visibility range within the scrollport. This depends on whether the subject is taller or shorter than the scroller.

(list from developer.chrome.com/

You can change the range of where the animation should play by defining a range-start and range-end by giving each of them a name and an offset (percentage, of fixed).

div {
  animation: reveal linear both;
  animation-timeline: view();
  animation-range: contain 0% entry 80%;
}

To be completely honest, I find the naming of these ranges quite hard to memorize and I’m really looking forward to DevTools updates to work with them.

For now, there is a nice little helper created by bram.us with the fantastic title: The Scroll-driven Animations View Progress Timeline Ranges and Animation Progress Visualizer (say it 10 times, I dare you)

Jokes about the title aside, this tool really helped a lot in creating this little timeline demo:

Your browser does not support the video tag.

Few things to note about this demo:

I used @property to animate the clipping path for my timeline branches and to animate the gradient in the background on scroll
Using different animation-ranges to play around with the timing of the scroll animation

Multiple View Timeline Ranges in keyframes

Instead of using the animation-range property, we can also declare multiple ranges inside of our keyframes. Syntax looks like this:

@keyframes inAndOut {
  entry 0% {
    opacity: 0;
    transform: translateX(-50%);
  }
  entry 100% {
    opacity: 1;
    transform: translateX(0);
  }

  exit 0% {
    opacity: 1;
    transform: translateX(0);
  }
  exit 100% {
    opacity: 0;
    transform: translateX(-50%);
  }
}

For me this feels a bit more natural because it’s actually inside of our keyframes. I would prefer to use this method more than a separate property, but that might just be me.

I went a bit over the top with the effect, but created a little demo with this technique as well:

Your browser does not support the video tag.

Learning scroll driven animations

I know that this article wasn’t much of a tutorial, but more some sort of teaser to get you hyped into this new feature. Creating these demo’s was fun but also didn’t take too long to be honest and that’s a good thing.

Although the view timeline ranges are a bit hard to memorize, the basics of working with these scroll driven animations are quite easy to learn (but as many things with CSS, probably hard to master)

So where should you start when learning about this spec:

By bram.us (who contributed a lot to this spec):

Going beyond constants with custom properties

Brecht De Ruyte — Mon, 26 Jun 2023 00:00:00 GMT

Read the article at iO tech_hub

This was CSS day 2023

Brecht De Ruyte — Sat, 10 Jun 2023 00:00:00 GMT

This year, I did things a bit differently, by going to the iO offices in Amsterdam to get a full day of work in and meeting some of the people who I’ve only been talking to online for now. Meeting some awesome people such as Dave Bitter and Sander de Jong. Although I was very tired of a 3 hour drive (waking up around 5 a.m. to get there in time). It sure was fun to see them and walk around the Amsterdam office.

But CSS Day did something different as well this year, starting off with a pre-conference event at the Kohnstammhuis in Amsterdam at 4 p.m. I was very late to the party and unfortunately missed all the talks there. Still It was great to join in with some of the speakers for a good chat. I was dead tired, so I was more listening than talking for the most part. But I was happy to join in with Adam Argyle and get some “Chrome swag”. The view of this building on the ninth flour alone was totally worth it to quickly hop over there!

So, after a well-deserved good night’s sleep, it was time to start the conference. With Adam Argyle setting it off as the MC (CSS! CSS! CSS!). Last year, I met him as a speaker, and I kinda knew he would nail it as an MC as well. After a quick intro and announcing his colleague Una Kravets, it was time to start the show and dig in for CSS Day 2023!

Una Kravets - State of the CSS Community

Perfect start of the day with a quick recap of which new goodies are now available, spread across browsers and some of the things to look forward to. I’ve been following along with the newest trends in CSS for some time now but it still amazes me how much work is actually being done at the moment when it comes to making the language better. Someone actually asked me if this was “just a recap” for me and my answer was “hell no”. An interesting 40 minute talk showcasing feature after feature and some insiders on the new ideas around targeting state via container queries for position sticky (and potentially position-fallback?). It’s amazing how Una can explain these features so correctly and simply at the same time. Well done Una! Unfortunately, I didn’t take a picture of the “one less dependency” slide, But I was able to take a picture of all the features she didn’t get a chance to talk about, can you imagine? CSS is on fire!

As an added side bonus we got to see the CSS podcast live for a few minutes, how awesome is that? If you don’t know the show and you’re into CSS, you must check it out!

Hidde de Vries - Dialogs & Popovers

I’ve met Hidde a few times as well during the Open UI telecoms so I was really excited for this one as well (He even helped me in reviewing one of my articles, thanks again for this mate!). When to use a dialog and when to use a popover will be a question that developers should be asking in the future. So I’m really glad that Hidde is taking it upon him to share some insights on when to choose which tool early on. With his background in accessibility and working for the Dutch government it was great to see these insights being shared. The popover UI will really change the way in how we handle some of our daily web UI in the future. UI considerations, Semantics and positioning will be key to defining which tool to use. When this gets shared on YouTube (I will of course update this article), you really should check it out! In the meantime, he wrote a bunch of great articles about it on hidde.blog.

Léonie Watson - CSS Speech

I was really looking forward to this one and - it seems - rightly so. When we use CSS to style the web we’re always thinking about the visuals, but why is it that we can’t control the speech of content pages? I love the fact that she didn’t really go into the “aria of things” but rather about designing for speech such as choosing a voice on how a page should be read by assistive technology or choosing the tone and pitch. There are some great ideas there and most importantly, there used to be a spec for this that didn’t get enough attention. So now is the time! Maybe we should all think about the possibilities this could give in the future. So yes, share her article, comment on it, do whatever we can to make this possible ( https://tink.uk/why-we-need-css-speech/ ) I am skeptical on a corporate level on how we can take clients on board to invest extra time (money) for us to create these experience. Nevertheless, it would be nice if we can do it (or as a developer secretly put in the extra effort).

Lunch breaks and breaks in between

I haven’t really talked about this, but this version of CSS day gave us the chance to talk to some of the people working on Chrome DevTools and the even had a CSS helpdesk. Geeky as I am, I found it very refreshing and interesting to have a chat with Ergün Erdoğmuş. Had a great little chat with him about the position-fallback possibilities and also talked a bit about animations later in the day with his team members from DevTools. Great opportunity, well done CSS day and Google! Maybe more on that soon in a future article ;)

Sanne ‘t Hooft - Tinkerer by Night

And OMG what a Tinkerer he is. A”light talk” after lunch sprinkled with a lot of mathematics, but I wasn’t bored at all. Using techniques such as :has() and a minimum of JavaScript to replicate the Dock effect from a Mac. But more importantly, using a lot of trigonometric functions in CSS ( which I’m still really bad at) to create some amazing effects. It really became clear that we need something to count the number of children of an element in this presentation. A great showcase of demos of which I took a lot of pictures and will need to study a bit more. I’m sure as hell going to geek off on this stuff in the next couple of weeks.

Patrick Brosset - Selector Performance

Performance is an important topic, so how about selector performance? Does using a wildcard (*) in your styles create some issues? Patrick already started his talk by telling us that there are probably a lot of other concerns that we will have to tackle before thinking about the performance of our CSS selectors. But all reassuring aside, there was an example on how it could potentially create some massive delays because of the changes that get triggered by using one selector. I especially enjoyed the explanation of the “purple bars of death” that are hard to fix when testing performance in DevTools (because they are about the browser and so - kinda - out of our hand. Some really interesting insights on how you can measure it. I’m not much of an Edge user but seeing some of these demos really makes me want to try some things out when it comes to testing performance and finding potential pitfalls. This talk was important, as we constantly try to make rules such as “this is bad for performance, don’t use it” while the truth is usually far more nuanced when it comes to being creative with selectors.

Heydon Pickering - Scope in CSS

Why isn’t CSS scoped? Sounds like a crazy question right? CSS is always scoped but we just try to create global patterns as much as possible for consistency (as it should be). But hearing Heydon speak really showed how much he understood the daily struggles of a front-end developer vs some of the strategists, marketeers and designers, who seem to be evil by nature. This was a lighter talk which went hand in hand with a few laughs, but I really enjoy these as they create a sense of community. And all of the things were recognisable such as why we don’t just write CSS? Do we really need to use all these crazy things in order to have multiple .button classes and just fix that by some dirty hash getting placed right after it ( .button_xlj23j ). Writing CSS can be so simple and elegant and readable, but after showing us a bit of @scope , we all know that this will be a handy feature and change the way we write CSS. There were so many good speakers this year and I wouldn’t be able to pick a favorite, but for day 1, Heydon definitely wins the “slide of the day award” by showing how to create a global style in CSS versus Styled Components:

Sophie Koonin - Personal Websites

Bring back the personal website! - Like -, yes! I took that jump a few years ago and really loved how it opened my mind and created some opportunities. And we should be proud about the personal stuff we create, I even bought myself some stickers with my website logo “just because”. She showed us her road from starting off with books to styling MySpace. I can really relate to this and especially loved the shout out to Neo Pets! Her talk definitely inspired me to create more personal stuff and maybe something just silly and stupid and place it on some free hosting. She also said that she wasn’t all that creative but don’t undersell yourself Sophie, I really love the things you created and wish I had a bit more of those creative juices in my brain!

Start of day 2

The second day of CSS Day we were welcomed by a new MC: Michelle Barker. Last year, I was happy to see a talk from here and now she’s the MC, there is a theme going on here. A bit of a different style of presenting than Adam, a bit more toned down but I just can’t help to love her enthusiasm and lovely British accent. She started of with a warm welcome, the general code of conduct and of course announcing the speaker, which was no one else but…

Miriam Suzanne - Container Queries

If you heard about Container Queries (or Susy, if you’re a fossil like me) you probably have heard about Miriam. A spec writer and what a powerful speaker on the subject. Instead of just showing us container queries and how they worked, she took a different and in my opinion far better approach by telling us why things don’t work, or at least didn’t used to work. Some powerful insights here on how containment actually works and why it was so hard to get this spec going, why containers don’t have the data we need, or it’s just dangerous to get it out of them. Still in the end, things got rolling and we have them supported in all major browsers. That is, for container queries that calculate inline-size and for the future: Style queries are on the way (already available in Chrome for custom properties). Last but not least, in the future there might be state queries avialable, seeing if an element is “stuck” when using position sticky or checking which fallback is used in position-fallback. That last one for me (creating some tooltip demo’s for Open UI recently) is a feature I’m rooting for. She even showed us a little demo by my colleague from Eindhoven: Maarten Van Hoof. It’s hard to keep myself from turning this into a technical article by hearing this talk. But as promised, this is just a small recap and I’m going to let all the things I heard sink in a bit further.

Umar Hansa - Tooling & Workflows

I recently did a shoutout to the mailing list with DevTools tips by Umar. I knew I was in for a wild ride about tooling. Umar showed us so much fun stuff to increase our workflow from snippets in VSCode, to browsersync, AI tools such as copilot and bloop, ghosttext, jumpy and of course some awesome DevTools tricks. I will be checking out some of these tools in the upcoming weeks for sure! Yes, this might look like a small paragraph, especially for all the tools he shared with us. But oh my… let me do a bit of further research first, okay?

Stephanie Eckles - Building Components

How do we handle a reset in CSS in 2023? There were some really powerful tips & insights here especially when it came to creating a “general” sort of grid and flex layout, powered with custom properties and declaring a container on the html element. I noticed that some people were getting hungry for lunch, but honestly, I was still hungry for more. It was a bit more technical but very practical for the people who actually work on different projects on a day to day basis and I loved every bit of it. It’s a bit of a shame that I didn’t really get a chance to talk with her afterward, i would’ve loved to share some of my ideas around working with custom properties, oh well, maybe next time, but for now, I’ll surely follow her on twitter.

Jhey Tompkins - Creative Coding

There is no way to describe all the cool creative demo’s from Jhey in this article. To the CSS Day organization: Perfect fit for after lunch, just sit back and enjoy the ride. Also a part of the Open UI community and ex Google DevRel, he just shows some amazing stuff with :has(), form elements and of course popover and the selectmenu. I create some practical demo’s for the selectmenu which are semi-creative, but Jhey really just cranks the creativity of these things to 11. If you haven’t heard from him or viewed some of his work, you should definitely check out his codepens. Creating a lot of demos makes you better, creating “useless stuff” makes you think deeper and helps you understand how CSS works and that’s probably the main take on it. Keep practicing, stay creative and yeah, “just flip it”.

Cassondra Roberts - Styling Web Components

Cassondra’s talk was a bit different, at least for me as I’m not the biggest user of web components out there. I loved how she presented her material with some “nerdy spacey jokes”, but the topic itself wasn’t something I use on a day to day basis. That being said, I really should be working on these web components a lot more often. Maybe this talk was just a bit too hard for me because of all the new things and the brain overload kicking in from two days into CSS day. But I did talk to some people later that day that really work a lot with web components and they seemed to have picked up a lot of things about it. One thing though, it made me want to learn more and when the videos come out, I’ll be sure to revisit.

Bramus Van Damme - Scroll-Driven Animations & View Transitions

Pfoeh, this is hard… What can I say about Bramus? He supported and motivated me so much for a year, I can’t thank him enough. He’s such a friendly guy, but let’s keep it about the things he brought to CSS Day. Taking over the View Transition talk from Jake Archibald and adding a bit of that scroll-driven animations sauce, we got two talks for the price of one. So let’s start with view transitions. This is something I haven’t explored enough, but such a powerful tool for creating immersive experiences. For the moment only available for single page applications and a more experimental implementation available for multi page applications (which is another fancy name for “websites”). I loved how he explained this topic so visually by showing us some 3D examples of the “pictures” that get taken from your DOM nodes and how they move while the transitioning is happening. Also clearly explaining how these things work so that we don’t try to do things like animating the color while the page is transitioning (that won’t work, it’s a screenshot, not a dom node anymore…). It really made the topic easy to understand and I’ll sure be playing around with it a bit more later on. He really can’t hide his past as a teacher and believe me, that’s a good thing! Understanding how these things work by showing it on a visual level is important.

So, scroll driven animations… I really need to update my own demos on that spec (added to the todo list, and yes, he warned me on Twitter… and yes, I always forget to do it, my bad). It’s so interesting to see this spec is really growing up. At first, we just had the ability to change our animation from a duration standpoint to a scroll driven one, but now with the inclusion of timeline ranges, it’s really going to be a tool in our CSS bag to have “one less dependency” (cfr Una). If you want some more demo’s be sure to use Chrome Canary and visit some of his collection and tools at scroll-driven-animation.style

Manuel Matuzović - Structuring & Restructuring

Manuel was banned from Twitter and got a bit lost in all the new things happening in CSS, and who can blame him. There is A LOT of CSS. So he did a crazy thing, a 100 day challenge where each day he learns something new. I sometimes struggle to write one article each month so, massive respect for that!. But by the end of those 100 days he learned so much and showed us some of his favorite things about the new ways we can write out CSS. Using the power of custom properties and using inline styles to create some smart web component design systems. Even using the (only available in Chrome and Edge) style queries to create some sort of a Mixin. His talk was perfectly balanced between jokes and serious information and in my opinion was the perfect talk to end this year of CSS Day.

Drinks, talking and a summary

I had a blast talking to so many of the speakers and meeting some people IRL of the Open UI community, giving some thanks to people who reviewed some of my articles in the past. I learn a lot from these people and just being able to have a little chat with them is inspirational and just simply pleasant. Now if you reached the end of this article and haven’t yet yelled out to me saying “You didn’t actually show code or shared stuff in this article!” First of all let me thank you for reading this and I absolutely will be taking some inspiration from these talks for future articles and demos. But I need to process, and read a bit more on the subjects covered. Call this a “fanboy article”, or even “clickbait”, I really don’t care. But if you’re thinking: “Oh, CSS day seems cool, full of quality and I want to go”, then I achieved my goal here. Next year will mark the 10th edition of CSS Day. And last but not least a very special thank you to the organization once again! Thank you for providing some ice cream on the second day as it was hot as hell and very welcome. And as for me, I’ll do anything in my power to return to this amazing conference next year!

( And now I need to run to the CSS Cafe post-conference event. On a Saturday? yep, i’m that geeky )

Advanced Form Control Styling With Selectmenu And Anchoring API

Brecht De Ruyte — Thu, 01 Jun 2023 00:00:00 GMT

Read the article at Smashing Magazine

The button case - Using custom properties for a smart button system

Brecht De Ruyte — Wed, 24 May 2023 00:00:00 GMT

A bit of background: SCSS vs CSS

If you’re a front-end developer, chances are high that you’ve been using SASS or SCSS for quite some time. One of the things that really made an impact when SASS came along was the ability to use variables. CSS already has an alternative for this for quite some time in the form of custom properties, also known as “CSS3 variables”.

A small comparison, if you would style the background your body tag in “hotpink” by using a SASS variable, it would look something like this:

$color-primary: hotpink;
body {
  background: $color-primary;
}

The same could be achieved by using CSS custom properties by writing the following:
Note: Custom properties are always prefixed by a double dash.

:root {
  --color-primary: hotpink;
}
body {
  background: var(--color-primary);
}

There is quite a big difference here. Custom properties are something that the browser understands. Unlike SASS, which is a preprocessor, which means it will output a CSS file where your final code will look like the following if you use the SASS variable system:

body {
  background: hotpink;
}

So, why am I telling you the basics? Why is this important?

There is a lot more to custom properties than setting a variable in the :root and using it as a constant. The way custom properties are built, you can create some smart systems with them. A few of the benefits of using custom properties are the following:

They can be scoped
They can be overwritten
They can have a fallback
They can contain anything(!) you want
They can be controlled with JS

An important note is that they do impact the overall performance of your CSS. It’s not going to have a lot of impact by just adding a few colors to your root, but be mindful when using them that you don’t overdo it with heavy calculations or endless overwrites on a root level.

That being said, it’s time to get to the main part of this article.

The button case - SASS variables vs CSS custom properties

We will be styling buttons! 🥳 More specifically, these buttons:

Nothing mind blowing here, no fancy designs as well, just four buttons like we have seen on the web quite a few times, a primary and secondary button, who each have an outline variant. They all have a hover/focus state as well:

For the sake of making my point in this article, the buttons have some basic styling for padding and border-radius that I won’t be repeating for the rest of this article:

button {
  padding: 13px 20px;
  border-radius: 5px;
  font-size: 1.1rem;
  cursor: pointer;
}

Using SASS variables to style our buttons

When using SASS variables for coloring our buttons, we’d probably use mixin of some sorts. But as this is not a “SASS tutorial”, I want to talk about the output it creates. If we would create these buttons by using SASS variables, the coloring of them would grant you the following output (big chunk of code coming up):

button {
  background: black;
  border: 2px solid black;
  color: white;
}

button:is(:hover, :focus) {
  background: DarkCyan;
  border-color: DarkCyan;
}

button.secondary {
  background: deeppink;
  border-color: deeppink;
}

button.secondary:is(:hover, :focus) {
  background: purple;
  border-color: purple;
}

button.outline {
  background: transparent;
  color: black;
}

button.outline:is(:hover, :focus) {
  border-color: DarkCyan;
  color: DarkCyan;
}

button.outline.secondary {
  color: deeppink;
  border-color: deeppink
}

button.outline.secondary:is(:hover, :focus) {
  background: transparent;
  border-color: purple;
  color: purple;
}

So although we might’ve used something smart such as a mixin, by using SCSS variables, our processed code looks very repetitive by constantly overwriting the colors and getting that specificity just right. We can do better! So let’s start fresh and apply the same styles, but this time by using custom properties. You can view this output example on CodePen.

Using custom properties to style our buttons

Let’s rewrite this by just using CSS instead of a preprocessor. If we look at our buttons, we notice they have one thing in common, they change color on hover. So let’s start using custom properties to create a smart system for our “filled buttons”

button {
  --color: black;
  background: var(--color);
  border: 2px solid var(--color);
  color: white;
}

button:is(:hover, :focus) {
  --color: DarkCyan;
}

button.secondary {
  --color: deeppink;
}

button.secondary:is(:hover, :focus) {
  --color: purple;
}

What did we just do? We created a custom property named --color and scoped this to our button element. Then we updated the background- and border color to read these custom properties. As custom properties can be overwritten, we will just update the custom property instead of re-declaring our border and background. This reduces our CSS size significantly.

We haven’t introduced a fallback yet, which in this case might not be needed, but for tutorial sake, let’s do this. Let’s update our default button by making it read the --color variable and fallback to the default color when it isn’t available. Instead of adding a fallback to each usage of var(), we can use a single custom property to handle that. I will prefix that custom property with an underscore for now, this is just a convention as it was used to indicate private variables in JavaScript before const and let were a thing (ah, the good old days). Feel free to indicate these things in a way that fits your style. Updated part of the code:

button {
  --_color: var(--color, black);
  background: var(--_color);
  border: 2px solid var(--_color);
  color: white;
}

Great! Now all we need to do is create our outline version of our buttons. We already have all the tools in play by using custom properties for our filled buttons, the only difference our outline buttons have is that they have a transparent background and change text color instead of background color. Now we can really take a shortcut to make this happen:

button.outline {
  background: transparent;
  color: var(--_color);
}

We have now styled our 4 buttons! Reducing our code significantly. Including white spaces, we started out with about 40 lines of code and by using custom properties, we turned that down to 19, which is more than a 50% reduction. Here is the version we just created:

The button case - enhanced usage of custom properties

If you’re like me, you don’t give up easily. I was wondering if we could somehow even make our code smarter. There is even a smarter way to create our four buttons by introducing a second custom property for the hover and focus color. Reducing our code to 17 lines and making new color variants even less redundant. This is the full code:

button {
  --_color: var(--color, black);
  background: var(--_color);
  border: 2px solid var(--_color);
  color: white;
}

button.secondary {
  --color: deeppink;
  --hoverColor: purple;
}

button.outline {
  background: transparent;
  color: var(--_color);
}

button:is(:hover, :focus) {
  --color: var(--hoverColor, DarkCyan);
}

So instead of re-declaring our hover states, we added a general hover for our button element which reads the --hoverColor custom property and has a fallback to the default button hover state.

This does come with some up- and downsides which we need to address.

On the upside…

If we would style our buttons like this, we could easily create a new color variant that both has a filled and outline version of the button. For example, if I wanted to add a new orange variant I could add the following next to the secondary button:

button.orange {
  --color: orange;
  --hoverColor: darkorange;
}

And the downside…

We are getting in a bit of a specificity danger zone here as the hover state of the button needs to come last in our stylesheet. There is a way to prevent this by adding our basic button styles inside of a cascade layer. Whether this is worth the effort really depends on how much of these buttons you’re going to style and is completely subjective. The reason I’m showing these different methods is that you have a choice and carefully plan the approach which suits you best.

/* default buttons layer */
@layer buttons {
  button {
    --_color: var(--color, black);
    background: var(--_color);
    border: 2px solid var(--_color);
    color: white;
  }
  button.secondary {
    --color: deeppink;
    --hoverColor: purple;
  }
}

/* Non layered styles come last */
button.outline {
  background: transparent;
  color: var(--_color);
}

button:is(:hover, :focus) {
  --color: var(--hoverColor, DarkCyan);
}

/* then in another file or lower in the file, you can add them to the layer */
@layer buttons {
  button.orange {
    --color: orange;
    --hoverColor: darkorange;
  }
}

So, you’re still not using custom properties?

I think custom properties can really help us in creating some smart design systems. And if you haven’t been using them a lot, I completely understand. I was late to the party as well…
But once you start to grow a habit of using them, it’s like a completely new world opens up into writing CSS. So I would strongly encourage you to play around with them. In my presentation, I go over a lot more ways on how to use them, including progressive enhancements and even using them as booleans by adding container style queries and :has() into the mix. They can greatly benefit our workflow by writing smart code that does more with less. I hope this little button case really helped you into “thinking custom properties” and will enhance your upcoming project.

I’m sure I’ll see some more awesome tricks involving custom properties during the course of CSS-day which I will be attending next month, can’t wait! 🥳

Chrome DevTools tricks that deserve a spotlight

Brecht De Ruyte — Tue, 25 Apr 2023 00:00:00 GMT

A bit of a shorter article for this month, because I’ve been pretty busy with creating presentations and writing some articles as a guest writer. Nevertheless, I always wanted to write something about Chrome DevTools features. I try to keep myself from writing articles with clickbait titles such as: “5 tools that…”, “6 amazing …”, but to be honest, this is kind of such an article, sorry about that. Still I hope to give you something here you didn’t know about, or want to revisit. So let the list begin!

I will be using the shortcut cmd+shift+p (or ctrl+shift+p) a lot. This is probably the most important shortcut for DevTools, so you best remember it.

Taking a screenshot from an area, (full) page, or node

This one only recently came to my attention by following Umar Hansa. I’ve been subscribed to his mailing list for quite some time now and really learned a lot from his little DevTools tips in the past. Seems like he started sending those emails again after a break, that’s nice to see.

At iO, when we do a lot of visual changes to a project, it’s nice to add a screenshot of the update inside of a pull request. And I really love the node screenshot capture for this. It’s really easy, but not that many people know about it, so this is how you do that:

With DevTools open, press cmd+shift+p and start typing “screenshot”, You already see the 4 options here:

Capture area screenshot: gives you a cursor that allows you to take a screenshot of a selected area.
Capture full size screenshot: Take a screenshot of the complete page (full width / height
Capture node screenshot: Take a screenshot of the selected node you have selected in DevTools
Capture screenshot: Take a screenshot of the window

The node option really gives you such a clean screenshot in cases you want to share something with others about a specific element on the page.

The rendering drawer and toggling preferences

Chances are that the rendering drawer is not yet visible on your DevTools. You can get it easily by pressing cmd+shift+p and start typing “rendering”. Select the first hit, this should open the drawer:

There are a lot of things in the rendering drawer that come in handy for debugging or optimizing your project. I won’t be going in-depth for all of the items here as this drawer could be an article by itself, but let me highlight some of the basics:

Detection of potential rendering issues

The rendering drawer is divided in some sections with a border and the first part is handy for debugging. The ones that I like to use here are the first three (convenient):

Paint flashing to highlight the repaints
Layout shift regions in case layout shifts are detected
Layer borders can be handy as well when debugging those z-indexes

I haven’t really used the others a lot, but I do think they can be handy depending on the kind of work you do. I think there was a case where I could’ve used the “disable local fonts” feature in the past. There was a case where the client got some bad version of the font, but I didn’t know about this drawer then. But if it ever happens again, I’m glad to know I have something like this in the toolbox.

Emulate media features

This is the part of the rendering drawer that I use the most. It has some options to switch between user preferences such as light and dark mode, reduced motion and prefers-contrast. There is already an option to check for the reduced-data media feature, although there isn’t much support for it yet, something I think I’ll use a lot more in the future. There also seems to be a new one which forces the color-gamut that I have yet to play around with.

The benefit of this, is that the options stay active even while reloading the page.

It’s nice and easy to toggle these media features while optimizing your project for accessibility and I really suggest people taking a look at these features.

Bonus tip: Once you know the options available here you can use cmd+shift+p and start typing the rendering feature you want for easy access. I often just type in “reduce” to toggle the motion setting when creating animations.

Checking for visual deficiencies and disable image formats

There is an option to check for visual deficiencies which will “re-color” your project. There are so many types of small deficiencies, sometimes it’s nice to know if a certain type of color blindness could really mess up the experience. Haven’t used it a lot yet (mostly because I don’t design most of the projects I create), but it’s nice to have it when needed.

The last two options in this drawer are to disable the AVIF and WebP image format. If there are some problems because of the lack of next-gen image format support, you don’t have to leave Chrome at all and just toggle this setting.

The color picker

This little panel you have when clicking a color inside of your styles inspector has so many options. I’m still finding new ones from time to time. This is so much more than a single color picker. Here is what it looks like:

You can really fine-tune your contrast as it gives you some hinting on which color you need to get the best contrast. It even shows some lines inside the color picker to show you where those potential contrast improvements are. I wrote an article about this at the start of this year for Smashing Magazine: Creating A High-Contrast Design System With CSS And Custom Properties if you want to learn more about working with this panel for contrast.

Color variables and Color formats

If you use custom properties for your colors (which, in my humble opinion, you should) You can easily replace your colors with already defined custom properties inside of the inspector. In the swatches you see at the bottom, you can click the double arrows and select css-variables. This will provide you with swatches based on your custom properties and it will actually enter that variable when you select the swatch, pretty neat if you ask me! You can also filter on some other swatches including colors that were found by the devtools on your project in general.

With the new color formats entering CSS you also get some great visual hinting when selecting an HD format. For example when selecting LAB, you get to see which colors fall out of the sRGB spectrum and benefit from the HD color gamut. Aside from a few little personal demo’s, I still need to take a deeper dive into these new color formats, but it’s nice to know that DevTools can help me with this.

A full page accessibility tree in DevTools

This feature is still experimental for the moment. But it’s one that I’ve enabled as it can give me a nice overview of my landmarks and general structure for screen readers. I still believe that great testing involves actually using a screen reader and a person who actually uses them, but aside from that, this is a great starting point.

To enable this, go to “accessibility” inside of the elements panel (or use cmd+shift+p and type accessibility) and enable the little checkbox “Enable full-page accessibility tree”. You will have to reload DevTools after that.

When enabled, you get a little accessibility Icon in the top right corner of your elements which you can toggle to see the full-page accessibility tree. I don’t consider myself an accessibility expert, but I do my best and keep learning so this can help a lot.

CSS overview

Press cmd+shift+p and type in “CSS overview”. This is quite a handy panel to go to to see some information at first glance. It’s a great tool to spot potential contrast issues inside of the colors tab, find font information or even spot unused declarations. This is great in cases where you want to optimize your CSS as well by reducing the amount of media queries. I love sniffing around in that panel when I visit certain websites as well… I know, that might be a bit too geeky. I also have some things for my own website here that I really want to take care of that seems to get moved to my personal backlog all the time.

DevTools has so much more that I don’t know about

I really discover something new in DevTools at least monthly because it gets developed so actively. For example, I recently saw Bramus tweeting a specificity feature that is in the works. We use this in our toolkit on a daily basis and it has so much to offer. It’s a personal goal to become a bit more of a “power user”. If you want to learn more, I’d like to end this article with some of the places I frequently find new information on the subject:

Umar Hansa email tips
Google DevTools Blog
Google Chrome Developers YouTube channel
The CSS podcast has some great featured episodes on DevTools as well with Jecelyn as a guest.

Note: the CSS podcast link is for Spotify, but you can find some episodes on YouTube as well. I think I heard every episode in my car… That way people don’t bust me laughing out loud with some of the (maybe too) geeky jokes on the show.

Open UI and the Popover API

Brecht De Ruyte — Tue, 21 Mar 2023 00:00:00 GMT

I always wanted to learn about W3C communities and since the end of 2022, I started to get involved with Open UI. I contribute by creating demos, trying things out, listening closely to the meetings and following up the GitHub repo. It’s been a very interesting learning experience and I hope to do a bit more in the future with this awesome W3C community.

To spread the word a bit about the cool things this group is achieving, I thought I’d write this little article with a bit of information on the group itself and the basics of the Popover API. I’m planning to write more about this, so you might call this: “the first of a series”.

What is Open UI?

Open UI is a W3C community group in a quest to allow web developers to style and extend built-in web UI components and controls. Think about current UI elements that you can’t style such as the listbox of a <select> or a color picker, but it’s more than that. Your basic “web UI” where you normally would need JS such as tooltips, notes, panels and general pop-ups such as alerts.

Keep in mind that the mission is not to replace or update the current web UI, but rather to give us the tools to create our own design systems in a much more convenient way (can’t break the web, but sure as hell can enhance it).

To do this, the group works a lot around the parts, states and behaviour of the current UI and a large part of that is accessibility. They approach this by doing research around the large number of design systems out there and carefully mapping out what these systems have in common. On a personal note, I think that this will be the biggest strength, being able to style what couldn’t be styled before and getting the accessibility out of the box. If you’ve never heard of it and you love what you’re hearing, you can read the full charter.

You can start playing around with it

There is already a Popover API implementation in Chrome Canary. All you need to do is go to chrome://flags and enable the experimental web platform features. So keep in mind that this article is written with the current state in mind and is subjected to change. I will try to update this as much as possible.

They are not built-in to the web and we usually use JavaScript to handle them. There are some common characteristics that the Open UI group thinks about. Usually they are on top of every other content, they can be “lightly dismissed” by clicking beside it or pressing the ESC key and usually there is only one “active” at the same time.

Because they are on top of every other element, it makes perfect sense that a popover should be added to the top-layer, which is technically outside of the document flow. This is beneficial as we won’t have to hurt our brains on managing our z-index in CSS (let’s admit, we’ve all been there…)

There is a lot of information on the Popover API on the website and I won’t be copying all of the things written there. Instead, it’s demo time!

We can define a Popover by using the popover attribute. By default, the popover will have the “auto” value but we can set it to “manual” as well. Here is the basic syntax:

<div id="some-popover" popover>
  Hi, I'm a popover!
</div>

The popover will automatically be hidden inside of the top-layer.

The two different values of popover:

popover=”auto” is the default and will create a popover that has a light dismiss. It can be closed by either clicking outside of it, or pressing the ESC key on the keyboard.
popover=”manual” will result in a popover that can’t be light dismissed. So a custom action should be provided if needed. If you want the user to perform a specific action within the popup and then close it, this is your value of choice.

One of the biggest strengths of this new API, is that we can choose our own elements and aria-roles for it. In contrast to the dialog element which always gets the dialog role. Yes, this comes with some responsibility, but this also means that we can use it for multiple cases with some careful planning by using the correct elements or roles such as dialog, tooltip, alert, etc…

If you want to read up about the differences between the Popover API and the <dialog> element. There is a great article on that by Hidde: Dialogs, modality and popovers seem similar. How are they different?

What I personally love about this Popover API is that we don’t need any JavaScript to toggle our popovers. To open up our popover, we can simply add the following button to toggle it:

<button popovertarget="some-popover" popovertargetaction="toggle">Open the popover</button>
<div id="some-popover" popover>
  Hi, I'm a popover!
</div>

This button introduces two new attributes:

popovertarget will reference the id of the popover we wish to show, hide or toggle.
popovertargetaction provides the action that should occur, options are: “show”, “hide” or “toggle”.

The popovertargetaction is an optional attribute and the default is set to “toggle”.

These attributes are only supported on buttons (including: <button>, <input type=”button”>, etc.) as long as the button would not submit a form. In that case the form would be submitted and the popover would not be toggled.

If we would like to create a popover where we don’t want a light dismiss, we can easily create this by doing the the following:

<button popovertarget="some-popover" popovertargetaction="show">Open the popover</button>
<div id="some-popover" popover="manual" role="dialog">
  Hi, I'm a popover!
  <button popovertarget="some-popover" popovertargetaction="hide">Close the popover</button>
</div>

An important note on focus trapping

Popovers do not have focus trapping by default. The reason for that is because they are meant to be used in multiple conditions. Take for example an alert; You might not want to trap focus there but instead keep the focus on the element that triggered the alert. It is however possible to add the “autofocus” attribute on (or inside) the popover element which should help with your initial focus. But remember, this is only changing the next focus and isn’t the same as focus trapping itself.

Take note: If you’d like to use this for a modal you will need to implement your own focus trapping with JavaScript, and use additional ARIA attributes. Alternatively, one could simply use the <dialog> element with the .showModal() method.

Here is a default example of the Popover API on codepen (Remember, use Chrome Canary for now).

Animating our popovers

The initial demo used to animate before by only using transitions, but during the standardization process this was removed in favor of something else. There are a few open issues at the CSSWG which make a lot more sense for transitioning the popovers. Most of these are part of the css-transitions-2 spec and include:

Animation of discrete CSS properties (DONE)
Animating from/to display: none (RESOLVED)
Animating to and from the top layer (DONE)
Initial frame update
Inert for animating to display: none

You can still animate the entry of the popover by using CSS animations, but when it comes to transitions we will have to wait a bit. Here is an animated example 🙂:

Your browser does not support the video tag.

How to anchor our top-layered popovers to other items in our DOM - The anchoring API

It’s difficult to track relative positioning because a popover is outside of the document flow. But there are use cases where we want to “anchor” our popup to another element, especially when you think about tooltips, alerts, etc… So how can we do this?

Luckily, there is another new kid on the block, which is the “Anchoring API”. It will allow us to tether elements to each other with CSS positioning. I’ll just go over this quickly, but if you want to read up on that, there is a great intro to the anchoring API by Jhey Tompkins on the Chrome blog.

For the final demo in this article, we just need the basics. For anchoring to work, we need to give our element an anchor-name:

.the-anchor {
  anchor-name: --myCoolAnchor;
}

Now if we want to hang our top-layered element to this anchor, we can use the anchor name and its position:

.my-toplayered-element {
  position: absolute;
  top: anchor(--myCoolAnchor top);
  left: anchor(--myCoolAnchor center);
}

To handle multiple popovers such as tooltips, or in this case toggle tips, we can always add the name inside of a custom property.

My tooltip “toggle” will then get an inline style with that custom property and we will use this as an anchor name in CSS.

<button style="--anchor-name: --tooltip-1;" popovertarget="tooltip" popovertargetaction="toggle">click this!</button>

    button {
      anchor-name: var(--anchor-name);
    }

Our popover itself will then receive a custom property as well that we can anchor to the toggling element:

<span id="tooltip" style="--anchor: --tooltip-1;" role="note" popover>
  <span class="popover-inner">
    ✨Peek-a-boo✨<br />I'm a little popover
  </span>
</span>

[popover] {
  position: absolute;
  top: anchor(var(--anchor) top);
  left: anchor(var(--anchor) center);
  max-width: 300px;
  transform-origin: center;
  transform: translate(-50%, -100%);
}

This way we can create a dynamic system for our “toggletips”, full demo and video:

Your browser does not support the video tag.

What about hovers for tooltips?

For the moment it seems that hover and focus popups will be picked up in the future, but it’s coming! There are a lot more accessibility caveats to be discussed for those.

Final thoughts on popovers and Open UI

I think Open UI is one of the best things being worked on at the moment. It might partially be due to frustration of JavaScript libraries not being accessible, slowing my page down or not being customizable enough. I’ve worked with a lot of libraries and hacked a lot of them as well just to get the layout that was needed. This Popover API and things such as <selectmenu> will really make a big impact on the web. I’ve played a lot with <selectmenu> as well, but that’s also something for a later stage (and probably another article in the future).

I really enjoyed following the meetings as well, it’s so nice that this is an open group. I’m mostly contributing by listening, learning, spreading the word, creating demos and maybe giving a little opinion or two. This community is really getting attention from the right people. It’s great to follow along with this story and I’m sure many awesome things will be created in the future by the work these people are doing right now. Especially combined with the Anchoring API, the future for styleable UI has never been brighter.

Everyone can contribute! So if you’re interested, it’s time to get involved with Open UI.

I also want to add a little word of thanks to @jh3yy, @hdv and @gregwhitworth for taking the time to help me out and reviewing this article. 🙏

For the love of scroll driven animations in CSS

Brecht De Ruyte — Tue, 14 Feb 2023 00:00:00 GMT

Animating elements while a user scrolls the page is a popular practice on the web. With scroll-timeline and the scroll function available in Chrome Canary, we get a nice preview on how these scrolling animations in pure CSS will work. The perfect time to create some demos and play around with it.

If you want to try the demo’s, you should open them in Chrome Canary for now, or if you’re reading this and Chrome 115 is released, you might be good by just using that! :)

It’s time for some new properties again! Nothing too complicated to start with. Let’s take the following animation into account:

.animate-on-scroll {
  animation: fadeIn ease-out;
}

@keyframes fadeIn {
  0% {
    opacity: 0;
  }
  100% {
    opacity: 1;
  }
}

If you want to make this CSS animation run only when a user scrolls the page. Just add the following:

.animate-on-scroll {
  animation-timeline: scroll(root);
}

That was easy right? A few things are happening now. The percentage of our keyframes is the same percentage that the user scrolls. So in this case we are fading something from 0 to 1 over the whole length of a page scroll.

But what is this scroll() function we see here? This is something new and it’s very exciting.

The scroll function

The scroll function can have two values inside of it. The first part specifies whether the scroll port we’re targeting is the root scroller or the nearest ancestor. We can also specify the scroll direction in which the animation should occur. Options are: horizontal, vertical and logical variants block and inline. The default of this function is the following:

.animate-on-scroll {
  animation-timeline: scroll(block nearest);
}

It’s a really handy feature, especially for targeting the root scroller of a page. Maybe we want to show a little “scroll to top”-button when the user scrolls about 30% of the page’s length. This could be done easily without using JavaScript:

<main id="top">
  <!-- some content here -->
  <a href="#top" class="scroll-to-top"> Scroll to top </a>
</main>

And we can reveal our scroll to top button while scrolling simply by doing the following:

.scroll-to-top {
  animation: revealScroller ease-out;
  animation-timeline: scroll(root);
}

@keyframes revealScroller {
  0%,
  30% {
    opacity: 0;
    transform: translateY(100%);
  }
  38%,
  100% {
    opacity: 1;
    transform: translateY(0);
  }
}

When the user scrolled 30% of the page, the button will reveal itself and will be fully visible by the time the user scrolled 38% of the page. Here is the demo of this:

Your browser does not support the video tag.

I had a lot of fun playing around with this. Another useful example that many websites seem to have is a progress bar to indicate how much you’ve read of a certain article. I created my own little version of this with a little “chicky” walking on your screen while scrolling, be warned though, it has a bit of keyframe overload:

Your browser does not support the video tag.

The downside is that my animation seems to trigger a bit of moonwalking when scrolling back to top. Let’s just call it a feature for now, ok? 😉

Naming a scroll-timeline and scoping the parent

if the animated element doesn’t need to interact with the nearest ancestor or root scroll but rather with a scroll happening somewhere else on our page, we have the ability to target a custom scroll-timeline on the item we want to scroll and add a timeline-scope to the wrapping parent. As a simple example, take a look at the following HTML:

<section>
  <div class="list">
    <ul>
      <li>Ducks, geese, and waterfowl</li>
      <li>Pheasants, grouse, and allies</li>
      <!-- etc etc etc -->
    </ul>
  </div>
  <!-- item we want to animate -->
  <div class="animation"></div>
</section>

In this example, .list has an overflow-y: auto; and a fixed height. When we scroll in our .list we want .animation to do something. In this case, .animation isn’t a direct child, but we need to start with creating a custom scroll-timeline so we will use a scroll-timeline-name to name our .list:

.list {
  scroll-timeline: --listTimeline block;
}

scroll-timeline is a shorthand for:

scroll-timeline-name: provides a name to the selector
scroll-timeline-axis: The direction of the scroll: horizontal, vertical, block or inline.

Unfortunately, just adding this won’t be enough because our .animation isn’t a child of the element we’re scrolling, we’ll need some way to let the wrapping parent know that these belong in the same scope, this is where timeline-scope comes in handy. So let’s update the CSS based on our HTML example:

Please note that the timeline-scope will be a bit later to the party as this will be released in version 116.

section {
  timeline-scope: --listTimeline;
}

.list {
  /* other scroll snap related code */
  scroll-timeline: --listTimeline block;
}

By naming this list and scoping the wrapping parent we can now bind our .animation selector by declaring the animation-timeline again, but now using the name instead of the scroll function:

.animation {
  position: absolute;
  top: 0;
  right: 0;
  animation: moveBackground alternate linear;
  animation-timeline: --listTimeline;
  /* some repeating bg image */
}

@keyframes moveBackground {
  0% {
    background-position: 0 0;
  }
  100% {
    background-position: 0 100px;
  }
}

These are two results of using these techniques. One for the vertical scroll and another for a horizontal scroll:

Your browser does not support the video tag.

Checking for support for scroll-timeline

We can use a feature query to enable our animations only for those browsers that support it. It’s a good idea to do this as I noticed that your animation will just fire right away if the feature isn’t supported.

@supports (animation-timeline: scroll()) {
  /* cool scrolly stuff goes here */
}

When using this in our projects, it’s nice to check for user preferences if you’re animating a lot of things on scroll, so check if a user doesn’t want a lot of distractions because of the motion. For those people add the following media feature query:

@media (prefers-reduced-motion) {
  /* cancel the animations here */
}

I didn’t use this in my demo’s, but lately, I always make sure to do this for heavy-animated elements in projects.

Conclusion and final demo

There are still a lot of requests and questions being asked on the CSSWG github and it shows that this is only the beginning. Still, the spec has changed a few times and i’ve updated this article ver since. Personally, I’m wondering if we will be able to target the scroll direction so that my Chicky demo won’t have to moonwalk back into position (So, I asked the question, can’t hurt to try). Maybe there is an answer in state queries or something else. As it turnes out, it seems that this Spec will really remove the need of some heavy libraries such as GSAP. As these CSS animations will run off the main thread (when using transforms), they will be really speedy and running at a whooping 120hz refresh rate. The ability to trigger these little animations and create some extra interaction is a great addition to CSS. But I’m sure many more demo’s will be made soon with people going crazy on these things.

For more information on scroll driven animations, you should checkout scroll-driven-animations.style

And because I’m creating this as my valentine’s day article, let me share some love for the scroll with this extra demo:

Your browser does not support the video tag.

We've only scratched the surface with :has()

Brecht De Ruyte — Mon, 30 Jan 2023 00:00:00 GMT

About three months ago, I wrote an article about some practical uses of the :has() relational pseudo class. Because of that article and experimenting with it, I can’t stop thinking about how it can fix some everyday problems. Currently we’re still waiting for some support in Firefox and as I want to keep polyfilling to a minimum in my everyday work… I can’t wait for that to happen.

For some reason, :has() is always on my mind, not a week goes by without thinking: “ah, I could’ve done this with CSS”.

I’ve been a bit busy at the start of the year with reading, creating demos and presentations, while also releasing an article about creating high-contrast design systems with custom properties on Smashing Magazine, so I will keep things short here.

Solving how we can manage our content

Especially as a person working on a lot of content-heavy websites, I look forward to how we can manage our content a bit better by using :has(). With content mostly provided by a CMS, I find that it could help a lot with structuring content and giving more sense of freedom to clients. As a simple example, It could just be about styling of titles depending on their sibling.

/* Check if the h2 is followed by a blockquote */
h2:has(+ blockquote) {
  margin-bottom: 0;
  color: hotpink;
}

/* Only center the h2 if the next sibling is a cta 
and the cta itself is the last item in our content */
h2:has(+ .cta:last-child) {
  text-align: center;
  margin-top: 50px;
  margin-bottom: 0;
}

Better ways to structure our content or even better handle some of those crazy combinations that can happen and tackle them with :has() really seems like a much needed feature in CSS.

Here is a little (very simple) example of that:

Structuring good ol’ tables

Imagine the following use case: You need a table with two axis of headings. You want to draw a thick vertical line after the headings on the left.

This is easy, as we can just do the following:

th:first-of-type {
  border-right-width: 4px;
}

But suddenly, somebody decides that the first two items of the tbody should be a table heading. Imagine you have no control of the markup and now we need to find a way to only draw the thick line on the second child of the thead element. Seems like :has() to the rescue again:

thead:has(+tbody th:nth-child(2)) th:nth-child(2) {
  border-right-width: 4px;
}

thead:has(+tbody th:nth-child(2)) th:nth-child(1) {
  border-right-width: 1px;
}

It could also be about placing items sticky inside the table or some other styling you fancy. Here is a simplified demo of this idea:

Using :has() for interaction and animation

There are so many possibilities when it comes to animating things by using this pseudo class, as it makes it easier for us to animate two elements in relation to each other. I created a little pagination example with a fancy hover effect:

You can ignore the CSS counter for now. I just don’t use it as often as I should and thought I’d give it a go. The important thing here is how we animate out little orbs in relation to the element that was actually hovered.

The first thing I did was set a transform and the lightness of a hsl color with a custom property as default.

:root {
  --move-0: .6;
  --move-1: .4;
  --move-2: .2;
}
li a::before {
  --move: 0;
  --lightness: 18%;
  /* some other styling here */
  background: hsl(330deg 100% var(--lightness));
  transform: translateY(calc(var(--move) * -65%));
  box-shadow: rgba(50, 50, 93, 0.25) 0px 50px 100px -20px;
}

Then by using :has() I checked the hover (or focus) state of the element and targeted the two items before it and the two items after it. It turns to quite a heavy selector but once you get the hang of it, it’s quite easy.

li:has(+li a:is(:hover, :focus)) a::before, 
li:has(a:is(:hover, :focus)) + li a::before {
  --move: var(--move-1);
  --lightness: 31%;
}
a:is(:hover, :focus)::before {
  --move: var(--move-0);
  --lightness: 45%;
  box-shadow: rgba(50, 50, 93, 0.25) 0px 50px 100px -20px, rgba(0, 0, 0, 0.3) 0px 30px 60px -30px, rgba(10, 37, 64, 0.35) 0px -2px 6px 0px inset;
}
li:has(+li + li a:is(:hover, :focus)) a::before, 
li:has(a:is(:hover, :focus)) + li + li a::before {
  --move: var(--move-2);
  --lightness: 21%;
}

You could read the first part as:

If the list item has a list item next to which has an a element in it that is hovered or focussed -> style the before of this a element as follows

If the list item had an a-element inside of it with a hover or focus state, style the before pseudo of the next list item’s a-element.

In the second part you take the items next to the direct siblings and so on. Yep, CSS is starting to sound a lot like a full programming language to me.

But yes… this is only the surface

I really love these demos about :has(), there are a lot of cool ideas being made on how to control elements and the relation they have to each other. For me this really was the biggest thing released in 2022 for CSS and hopefully will have complete browser support soon.

I have used it for a bit progressive enhancement - once again, to limit polyfills in projects. If you want to check for browser support, you can do this with the following feature query:

@supports selector(:has(+*)) {
  /* this has support */
}

This checks for a full feature report. If you’d like to know why, I suggest you read the blogpost by Bram.us on why you want :has(+ ), not :has().

Let’s go for another awesome year of CSS in 2023 and keep making those demo’s ya’ll!

Creating A High-Contrast Design System With CSS Custom Properties

Brecht De Ruyte — Thu, 26 Jan 2023 00:00:00 GMT

Read the article at Smashing Magazine

Recap of the year, some thanks and best wishes for 2023

Brecht De Ruyte — Sat, 24 Dec 2022 00:00:00 GMT

To be honest, it wasn’t the first time I had the idea of writing articles on a personal blog, I’ve tried it before but never found the time. In 2022, I decided to just create time for it but without creating too much pressure on releasing articles. Some months were filled with inspiration and the ability to create demos past working hours, while others were a bit slow, but that’s ok. I have a full time job, an amazing wife and a lovely little active (almost) 4 year old daughter. They are and will always be my top priority.

Looking back at 2022, I really achieved some things with this blog

What a year it’s been… The first time I noticed that this writing paid off was during CSS day 2022 in June. While other years it felt like I was seeing new things the whole time, I noticed that my research paid off and could follow more easily with some of the more in-depth things the speakers were talking about. That’s great because in the end, it actually felt like I learned a lot more. And truth be told, because of all the new goodies in the CSS world, that felt like a good place to start as well. I was also shocked to hear that some people actually read some of my articles which really gave me a boost in motivation. For this, I should probably give a special shout out to Bram.us who motivated me to write some guest posts on other blogs.

And that’s exactly what I did. I was really scared at first because I’m not that confident in nature. I really make a lot of effort to make my own demos, learn things at my own pace and believe me… I really try some stupid stuff from time to time. Really strange things, such as. Would this work?

div:has(p:has(div:has(span)))) {
  /* why would you do that? I dunno, it sounded funny */
}

Yes, I could just read the spec for this, but sometimes it’s just more fun to try something and then read why it doesn’t work. It really helps me to get a grasp on things.

Just saying, I feel really small compared to some of those awesome writers out there, I’m not at their level at all, but they were very welcoming, supportive and I still learn tons of new stuff from them every day.

I also decided to buy a Chromebook to create some small coding tryouts. Thanks to Adam Argyle who showed me what you can do with these devices on CSS day. It was a good buy as it really helped me to write articles in my lazy chair and on the go, using this lightweight laptop instead of a heavy Macbook.

And so I started to do some guest writing

A special thanks to a lot of people such as Geoff, who really helped me with getting my first articles on CSS-tricks: Making a Real-Time Clock With a Conic Gradient Face and Creating Animated, Clickable Cards With the :has() Relational Pseudo Class

I couldn’t have done this without him and the help I received with writing was eye-opening. I really learned a lot from this experience and hope to continue this in the future. I also wrote my first article for Smashing Magazine: Easy Fluid Typography With clamp() Using Sass Functions

I hope to write more for those platforms in the future. It’s been great!

Some of the comments I received on these articles were really heartwarming and kept me going. It’s not what I expected because… once again. I still lack that confidence.

Working at iO

In 2022, I was able to join an expert group within iO called the front of front-end. I had the pleasure of learning how people work on other campuses within that group. A special thanks to Sander De Jong and Dave Bitter for starting / leading this group. It made me realize that there are some really smart people within iO of which I can still learn a lot from. Times were a bit hectic especially in the second half of the year with big projects, but even on the job, I was able to further increase some of the skills that I learned at home. I even went on to learn a bit more in-depth React stuff… Can you imagine? A special thanks to all my colleagues there to keep up the mood even though there were a few times with high pressure.

Near the end of the year, I was finally able to write my first (exclusive) article for the iO tech_hub, long overdue, but happy to finally do this: Why you should be using new CSS features today

I was able to give a presentation for “Artevelde Hogeschool” to try and motivate young students to learn CSS. I had some mixed feelings about it because my audience was still just starting out, but nevertheless an interesting experience.

I’ll also continue to work inside of the iO party team in Ghent for all those geeky events and of course do some kick-ass front-ending.

Not everything went so smooth

There were some downs during this year: problems with our house, sickness in the family and really just a lot of bad luck to be honest. I really can’t express my gratitude to Renée (my wife, who I love dearly) in this article to help me overcome some of these struggles. She did a lot for me. I do believe we both need (and deserve) some time off, to take a little breather. That - for one - is a plan we will execute as soon as possible.

And now, a bit of holiday and on to 2023

So what does the future hold? I know that I’ll keep writing about accessibility, UX and CSS. There is just so much more to explore. I still have a lot of things on my list especially related to scroll animations, CSS anchoring API, nesting… a lot of goodies for next year.

I would love to return to CSS day and maybe give a few presentations myself to get over my lack of confidence a bit. I will try to do some more guest writing but will also keep writing here on my personal blog as I feel it’s getting a bit neglected lately because of all that external writing.

I’ve also made a commitment to follow open-ui more closely and to help out as much as possible by creating demo’s, commenting on Github and joining the meetings. Because of all the “JavaScript hacks” I did in the past to create accessible dropdowns and tooltips, this is a feature that really feels important to me.

But in the end, I just want to keep making beautiful, accessible things, because in the end, that’s what it’s all about in the front-end world.

If there is one thing I want to wish everybody, then it’s a little bit of luck, some smooth sailing through a sea of potential dangers. That little luck can bring a lot of smiles and gets underestimated.

So with that. Some thanks were given, a recap was made. I wish you all the best! Have a great holiday and a Happy New Year.

Ps: I made a Christmas tree, it was “quick and dirty” But screw it, I’m on holiday ;) See you next year!

Why you should be using new CSS features today

Brecht De Ruyte — Mon, 12 Dec 2022 00:00:00 GMT

Read the article at iO tech_hub

Age 35: slowly becoming an "old developer"

Brecht De Ruyte — Mon, 21 Nov 2022 00:00:00 GMT

The simplicity of the web

This is one of the things that I miss the most of all. Not saying I don’t love the evolution of the technologies we have, that’s certainly not the case. I’m saying that I sometimes miss that feeling of creating “things on gut feel”. The web has grown up… and frankly, that makes it boring from time to time. Experimenting with code is still the best way to get better, but how many times do we get the chance to do that while working on projects. There are important factors in the world such as accessibility, marketing and UX. But sometimes things might get a bit too perfect, we’re at that point where you actually have to break rules intentionally to invent something new, while in the past, there just weren’t any rules to start with. And I, for one, love breaking rules, but you just get less chances to do so without being virtually murdered by some random guy on Twitter yelling “this is bad practice, you idiot”.

There are some “lost skills” that will never return

Ah sweet sweet hacks. The box-model hack, the rounded corner hacks, the art of making beautiful nested tables, old sticky footer techniques, clearfixes, the list goes on. Nobody really loves hacks and shady techniques, and thanks to recent developments in CSS they won’t be needed on a day to day basis. It’s great, but also a bit sad because those special things seem to be stuck in my head forever and will never see the light again.

I miss the developer socials and personal blogs

Ah… sweet Twitter from the past where it was mostly a community of tech people showing their stuff and what they had for dinner. It used to be relaxing checking out twitter and just seeing cool stuff on the web, now it’s just full of politics, yep, i’m saying it… politicians ruined Twitter way before Elon Musk.

And where did the overly crafty personal blogs go? There was so much good stuff on the web without ads, cookie pop-ups. I say, it’s time to bring blogging back. Here was one of my first attempts at it:

One of my early attempts to web designing

I’m mostly afraid for the next generation starting college right now.

A lot of the people attending colleges or universities right now had to spend important years in lockdown due to Covid. As if social media addictions weren’t enough, some of them will have a hard time communicating in person. I’m not saying this based on facts but on personal observation. You don’t have to take my word on it… But I really hope this will work out for them. It’s a lot of fun sitting next to a person and fixing some bugs or looking at some awesome stuff they just created and learning how they did it. Tackling problems face to face and having a laugh. I really hope to work with some motivated, fun, born past the year 2000 colleagues in the future. Surely, a lot of people work only remotely, but humans are social beings, that’s a scientific fact and I’m sure many have a bigger need for real-life social interaction than others, even if they don’t know that at the time.

But I am hopeful for the future of web development

Browsers are really an amazing piece of software. With the latest and upcoming updates to CSS and JavaScript, it’s amazing what we can achieve. Not that long ago, we were forcing designers to respect a 12-column grid, but with all the latest CSS updates there really isn’t a need for this except maybe for time-saving.

I’ve been taking a bit more of a deep-dive into React as well in the last couple of months, for me, it’s a necessary evil (sorry, javascripters, you know I love you). I enjoy the things it can do, and although there are just too many libraries out there, it really opens up a lot of opportunities on the web. But when push comes to shove, I’ll always enjoy my niche, which is CSS. It’s really growing up. And the fact that we will less need to rely on JavaScript for layout problems is a good thing for everyone. Lately, I’m also looking a lot into open-ui, but that’s a topic for later.

So… what to do in the next 35 years?

I really think about this from time to time.. It took me 33 years to start a blog and keep working on it. Even though I had some earlier attempts at blogging, it never really stuck. I’m not certain that working project to project will be something I’ll do until retirement, but for now, I enjoy it. Who knows, maybe I could do a bit more for the future generation of developers? As a self-taught developer, I was always grateful to the people who gave me a chance or believed in me. Maybe it’s time to start giving back a little? Seems like a nice thing to do.

But for now.. I made a CSS cake!

Creating Animated, Clickable Cards With the :has() Relational Pseudo Class

Brecht De Ruyte — Thu, 27 Oct 2022 00:00:00 GMT

Read the article at CSS-Tricks

Practical uses of the :has() relational pseudo class

Brecht De Ruyte — Tue, 11 Oct 2022 00:00:00 GMT

Using :has() as a simple parent selector

How many times have we added an extra class to check if an element contains an image, or has some extra information that we want to display. For example, You might want to make a grid where the grid item is shown bigger when it contains an image:

Whichever the templating language you’re using. You’ll probably add a condition to check if an image is available like this:

<div class="articles">
	{% for article in articles %}
        <article class="article{% if article.image %} has-image{% endif %}">
            {# content here #}
        </article>
    {% endfor %)
</div>

While this works and has worked for many years, there is a fundamental problem with this approach. We are actually using different class names and controlling those with our templating language. Usually adding a class name such as .has-image , but this can lead to inconsistencies when working with bigger teams. For example, another person might prefer to add a class to the grid saying .is-wide based on the availability of the image. Before you know it, those inconsistencies pile up, and the project becomes harder to maintain. With the :has() pseudo class, all of this is in the past as we can check the availability of an image inside of our grid with ease:

article:has(figure) {
	/* do stuff */
}

Here is a full example of that in action:

Using :has() and :not() pseudo classes combined

Taking the previous grid a step further we might want to display our grid a bit differently when there aren’t any images (figures) available. We can easily do this by combining the :has() and :not() selector. In this use-case I just wanted the “only text grid” to fill the space by using a flex layout instead of grid. So adding the following does just that:

.articles:not(:has(figure)) {
  display: flex;
  flex-wrap: wrap;
  text-align: center;
  border-radius: 10px;
}

.articles:not(:has(figure)) article {
  padding: 40px 20px;
  flex: 1;
  min-width: 280px;
}

Be mindful that the order plays an important role here. For example:

.articles:not(:has(figure)) Will target .articles that doesn’t have a figure
.articles:has(:not(figure)) Will target .articles that has anything in it besides a figure. So an empty .articles would not be targeted in this case

And you can see this in action here:

Changing a list-type based on hover without hassle

It might be something that isn’t as popular as it used to be when it comes to design, but I really implemented a lot of hover states in footer links where the bullet of a list item had to be filled when hovering over it. This usually required adding a pseudo element with absolute positioning. An image says more than a thousand words so let me just show what I’m talking about:

This could be done by creating a simple unordered list and doing something like this:

<ul role="list">
    <li><a href="..." target="_blank">Tim Berners-Lee</a></li>
    <li><a href="..." target="_blank">Robert Cailliau</a></li>
    <li><a href="..." target="_blank">Vint Cerf</a></li>
    <li><a href="..." target="_blank">Bob Kahn</a></li>
</ul>

ul {
  list-style: none;
  margin: 0;
  padding: 0;
}

li {
  margin-block: 6px;
}

a {
  display: flex;
  align-items: center;
  color: #6247AA;
  text-transform: uppercase;
  font-weight: 600;
  text-decoration: none;
}

a::before {
  content: "";
  display: block;
  width: 10px;
  height: 10px;
  margin-inline-end: 10px;
  border: 1px solid #6247AA;
  border-radius: 50%;
}

a:hover, a:focus {
  color: #A06CD5;
}

a:hover::before, a:focus::before {
  background: #A06CD5;
  border-color: #A06CD5;
}

But now, let’s enter the :has() pseudo element into the equation and use our default list styles to create pretty much the same thing with less lines of code:

ul {
  list-style: circle;
  margin: 0;
  padding: 0;
}

li {
  margin-block: 6px;
  color: #6247AA;
}

li::marker {
  font-size: 27px;
}

li:has(:hover, :focus-within) {
  list-style: disc;
  color: #A06CD5;
}

a {
  color: currentColor;
  text-transform: uppercase;
  font-weight: 600;
  text-decoration: none;
}

There is a minor drawback here and that is that we won’t be able to add a transition based on the list-style. But it’s still a pretty neat thing to do. I just love the fact that this is possible. If you have followed and read some of my articles before then you know that sometimes I like to make things that aren’t completely practical but just fun to do. (For example: My little container query flappy bird. Below you can see the full example of the lists on hover.

Form validation messaging with :has() to check invalid states

Forms have never been my favorite thing to style but lately they have become less tedious because of all the possibilities out there (accent-color, appearance, …). Also, open-ui is getting a lot more love from the community and that’s a good thing. I’m really looking forward to getting more control over forms eventhough I do understand the accessibility and UX concerns.

But let’s get into the validation of forms. Most of the time we had to rely on JavaScript to give us instant feedback when a user is typing something that isn’t allowed. In the previous two examples I’ve shown we can check for elements, states such as hovering of a link which means we can now check for states of our form elements. Let’s start off with the demo this time:

We created an HTML5 input field with a regex validation that only accepts lowercase text. By using the following we can check if the form is invalid:

fieldset:has(:invalid) .feedback {
  opacity: 1;
}

There is something else we should take care of. Because we added the required flag to the input field, an empty field will also be considered invalid and show the error message. We can fix that by checking for placeholder text:

fieldset:has(:placeholder-shown) .feedback {
  opacity: 0;
}

Note: it might be a bit “hacky”. But you could use an empty placeholder with a space in it if you just don’t want placeholder text inside of the element or hide it with CSS.

Creating a tiger striped table based on the number of rows

Another awesome thing we can do is to check the amount of children our parent selector has by combining :nth-child with the :has() pseudo class. For example, I created a table that only shows a tiger striped pattern when it has more than 5 children (or rows…). I love the fact that we can keep this layout decision in CSS, rather than relying on our templating files to add an extra class. We can achieve this by this little bit of code, it’s that easy:

table:has(tr:nth-child(5)) tr:nth-child(odd) {
  background: hotpink;
  color: #FFF;
}

We’ve only scratched the surface

There are already many examples out there on how to use this new pseudo class and I’m sure many more will follow. This really packs a lot of power and can change the way we handle front-end development in the future.

It :has() been a blast experimenting with this relational pseudo class and I’ll sure be playing around with it a lot more.

Easy Fluid Typography With clamp() Using Sass Functions

Brecht De Ruyte — Wed, 05 Oct 2022 00:00:00 GMT

Read the article at Smashing Magazine

Making a Real-Time Clock With a Conic Gradient Face

Brecht De Ruyte — Mon, 19 Sep 2022 00:00:00 GMT

Read the article at CSS-Tricks

Coding on a Chromebook - part 2

Brecht De Ruyte — Sun, 07 Aug 2022 00:00:00 GMT

Installing Git on ChromeOS

Well, we’re actually in a linux environment here, so all you have to do is add the following command in your terminal, it’s that easy:

sudo apt install ssh git

Installing Node - NVM

Personally, I like to use a node version manager for all my node related things. It allows you to run multiple versions of node. I have some old legacy projects that I will work on occasionally, it just makes things easier.

Node required gnup2, so let’s install this first:

sudo apt install gnupg2

To install NVM, add the following command:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

If your chromebook doesn’t have curl installed, you might need to run the following command first:

sudo apt install curl

When this is installed you can change node versions and install them. Use the following command to see your current version:

node -v

You can install another version by running the command:

nvm install [node version here]

To see the full list of commands available, just type:

nvm --help

Installing Filezilla, some browsers and alternative design tools

Filezilla

ChromeOS recently has gotten some features to make ssh connection a lot easier which I still need to take a look into. However, for most of my smaller projects (which are just some simple coding demo’s or presentations), I just need a bit of FTPing to get the job done.

For this, I like to use Filezilla, just go to your terminal and type:

sudo apt-get install filezilla

Browsers

You might want to test some things on different browsers. One thing that I miss on ChromeOS is a separate Chrome Canary desktop browser and Firefox nightly, but running the ChromeOS in beta mode does the trick for now as it allows me to check flags for container queries and all other goodies.

You can install some dev versions of browsers on the Linux platform, so here is how to install Firefox and Chromium browser:

sudo apt install firefox-esr
sudo apt install chromium

Alternatively you can access the google play store and add some mobile browsers from there. It’s great to have mobile and desktop browsers on the same device to do some testing!

Alternative design tools

There are some alternatives on Linux for your adobe software. They are not quite the same but to do some simple photo editing and making some vectors they seem to work fine. I would recommend Figma for your “real design work” though.

Gimp as an alternative to photoshop to edit images
Inkscape as an alternative to illustrator for vectors
ImageMagick to do some in-terminal editing

sudo apt-get install gimp
sudo apt-get install inkscape
sudo apt-get install imagemagick

Installing Docker

It should be possible to run apache directly on Chrome. I am however not the best PHP developer and mostly rely on Docker for all things PHP. This makes a lot of these tasks a lot easier for me.

Let’s check if everything is up to date, this is just good practice:

sudo apt-get update

Next up add the following command to install the docker dependencies:

sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

Then let’s add the Docker’s official GPG key:

sudo mkdir -p /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Use the following command to set up the repository:

 echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Then we want to update the apt package index again by running:

sudo apt-get update

And finally install our docker engine:

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Let’s verify if these things worked by running the hello-world image:

sudo docker run hello-world

A note on Docker: Docker is quite heavy on ChromeOS and isn’t super fast in booting. However, it seemed to do everything I needed with ease. I just handle a few websites with Docker, but nothing too harsh on the machine. If you plan to do some heavy lifting with it, I would recommend buying a high-end Chromebook.

You can also install the Docker desktop app for Linux here. But it didn’t want to start on my machine. Working purely inside the terminal did work fine.

Oh my zsh

To set up zsh, we need to set a sudo password. By default Linux on Chrome OS doesn’t come with a password for sudo. This is however required to set zsh as the default shell.

sudo su

passwd [your user name]

You will then be prompted to set your password. Enter it, and once again to confirm.

Add the following commands to install zsh and Oh my zsh

Insert the following lines in your terminal, one by one to install Oh my zsh

sudo apt install zsh
chsh -s $(which zsh)
sudo apt install wget git
wget https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | zsh
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
source ~/.zshrc

And now we will edit our config file by adding the following command:

vi ~/.zshrc

Personally, i don’t like editing files that way, so if you have VScode installed, you can use the following command:

code ~/.zshrc

One of my favorite themes is agnoster, I highly recommend it. On line 10 add the following:

ZSH_THEME="agnoster"

Now save and exit the file and add the following command again:

source ~/.zshrc

Next, let’s update the fonts. Open up your default chrome browser and type ctrl+alt+t. This will open up a new tab with crosh, let’s change the default theme settings with ctrl+alt+p

You will get a window with theme settings.

Enter “this url” in front of Custom CSS (URI)
Enter “Hack” before “DejaVu Sans Mono” in front of Text Font Family like: “Hack”, “DejaVu Sans Mono”

My Chromebook (screenshot) is set in Dutch, but it should give you an idea on where to find the correct fields.

And there you have it, You now have a beautiful terminal. If you’re not into the agnoster theme, there is this awesome guide for the powerlevel theme as well.

So much possibilities

As you noticed, installing things on ChromeOS is a breeze and I suggest you look around a bit, I’m sure you’ll find that perfect setup that just works. It took me a bit of time but I had a lot of fun figuring these things out. Also good to know, you can easily backup your Linux via the settings in ChromeOS in case you doubt if you’ll break something. Happy coding!

Coding on a Chromebook - part 1

Brecht De Ruyte — Sun, 31 Jul 2022 00:00:00 GMT

Why did I choose a chromebook?

They are small, lightweight, and most of all affordable. You can get a Chromebook for about 350EUR that has about 8GB of RAM and a good enough processor to do some multitasking. Not being able to buy a pixelbook in Belgium, I chose to buy an ASUS Flip Chromebook.

What I was going to use the device for was quite simple: Write my articles, do some small coding projects, maintain my blog and do all of this as distraction free as possible. For me, It was important to have a Chromebook that wasn’t too heavy or big, because I knew that I wanted to code with it around the house. This also means that battery life was an important feature.

The basic things about ChromeOS that I love

Before writing about the coding process itself and how I created a basic setup, let me tell some of the things that I love about ChromeOS:

Blazing fast in starting and battery life

Yep, unless your Macbook is fresh from the shelf, this difference is really noticeable. The device literally boots in a few seconds and you’re ready to browse or create a document using the Google services. I remember installing my code tools, which took about half a day. I did all of that on battery life…

Great in organizing your workspaces

You can work full screen, barely noticing you’re running things inside of a browser. You can switch between fullscreen and windowed with the press of a dedicated button. There is also the possibility to use different desks on which you can toggle full screen with the simple short key search + [ or search + ].

Works wonderfully with my Android phone

Unlocking the screen by using my phone, using my phone network automatically when there’s no internet available. Instantly having pictures of my phone available or even sending text messages straight out of the laptop. All these little things do wonders. It’s a great experience.

Android apps

Although made for using the browser most of the time, You can easily install Android apps. My Chromebook has a screen that you can flip and use as a tablet. It’s a great addition, although not one that I use a lot.

Linux

This was probably the most important thing to start coding on it. You will have to set up the developer mode and when you do that, you can run most of the things that work on Linux. More about that later on.

Keep those updates coming Google!

Google updates are coming in a lot, and they don’t take long at all. Every little update gave a little smile to my face. It’s great to have an OS where updates feel like fun instead of delaying them because you don’t have the time for it.

The basic things about ChromeOS that take getting used to

Hard disk space

Let’s not delay this any longer and talk about the elephant in the room. ChromeOS should be used with cloud storage unless you want to take an external hard drive with you all the time. Remember I said, I’d use it for “little side projects”.

Not for gaming

Unless you use Stadia, it’s not a great device for gaming, unless you play Android games. Although Steam will get a release on ChromeOS in the future. This didn’t bother me, as this was not the purpose of my purchase.

You will need alternatives for certain programs

If you happen to be a designer that relies on Adobe software, you will be disappointed. Unless you’re happy with using creative software in the browser. Figma works just fine of course.

The keys take some getting used to, and maybe one is missing?

Want to use CAPS LOCK, you’ll have to press ALT+SEARCH. And you only have a ctrl and alt key on the keyboard. Which can make your coding shortcuts a bit out of touch. I think this last one was the biggest bother for me when I started out.

My basic ChromeOS setup

After setting up the wizard, I was pretty much good to go. By going to the personalize section in the settings, I added a background that I like (you can also upload a custom background if you want). The next thing I did was to set up my phone. This gives me direct access to my images or photos I took with my phone. You can also set up that the chromebook unlocks when you unlock your phone with smartlock, very nifty.

To start off, I didn’t add a lot of android apps. Just spotify and the twitter app I use. Fun fact: When listening to music, you get this handy little icon in your toolbar with media controls.

One thing that I like about ChromeOS is the UI. It’s all very easy to set it the way you want for basic usage, and that’s a good thing.

Next up, I added some “desks” for my workflow. I like to work full screen, especially on a laptop screen. So I pre-configured some of the desks I will be using. There is a dedicated key for this and some shortcuts to control them. Google has some good information on windows and desks.

Desks on a chromebook

Last thing I did after a while using it was to join the beta channel. This will add experimental features, so you might not need this, but there were some features that I wanted to try out such as the calendar pane. You can also set up experimental features by adding chrome://flags in your browser. To enter the beta channel, simply go to about ChromeOS > additional details > channel and set the channel to beta.

The calendar with additional settings screen

I won’t go over every shortcut possible with a chromebook but there are quite a few that I use regularly, for taking screenshots or partial screenshots, switching between desks. You can find a handy shortkey list on this page.

When it comes to the shelf, I personally like it at the bottom of the screen but you can switch it to the right or left if you want to.

Setting up the Linux environment

If you want to properly start coding on a ChromeOS, you’ll have to open up the developer mode.

These are the steps you’ll have to take:

On your Chromebook, at the bottom right, select the time. Or press the search button and search for settings.
Select advanced > developers
Next to “Linux development environment,” select Turn On.
Follow the on-screen instructions. You will have to allocate some space for this. I added more than the recommended because I will be coding on this, and my projects will be stored in this allocated space.
A terminal window opens. You have a Debian 10 (Buster) environment. You can run Linux commands, install more tools using the APT package manager, and customize your shell.

In these settings you can also backup your linux environment and save it to google drive. This can be handy if you plan on experimenting a bit as I did. You can also remove the Linux environment again and everything “Linux” will be wiped clean.

Running VSCode on your Chromebook

Now that we have our linux environment running, we can easily set up VSCode. Before we install our editor, let’s run a little update, I had to do this two times, not sure why.

sudo apt-get update

Next, we need to install the gnome keyring:

sudo apt-get install -y gnome-keyring

Once we did this, all we have to do is to download VSCode from the official website.

Ensure you select the correct package for your Chromebook, to avoid falling into errors while installing it on your Chromebook.

If your Chromebook runs on an AMD or Intel chip, select the .deb 64bit variant.
If your Chromebook runs on an ARM64 chip, select the .deb ARM64 variant.

Not sure which version to download? You can check this by adding the following command in your terminal:

dpkg --print-architecture

When you downloaded the installer, just open it in the downloads folder and it will install inside the Linux environment.

Quick tip: You can pin VSCode to you shelf by simply right clicking the icon when it’s open and selecting “pin to shelf”.

That’s it for part 1

This was a quick summary of the things I like about ChromeOS.

In part 2 I am going a bit more in depth by installing a node version manager, filezilla, docker, some browsers, ohmyzsh and other goodies to make things easier.

Introducing a Mini Static Thingy Wingy

Brecht De Ruyte — Thu, 07 Jul 2022 00:00:00 GMT

What is it about?

In a world full of frameworks, packages and guidelines, it’s sometimes a bit of an overkill to use all of these frameworks. Sometimes you just want to create a simple page or a sandbox to play in.

The Mini Static Thingy Wingy was created with just one thing in mind: An easy setup for a simple HTML and CSS driven page. This could be a landing page, a small demo, or an HTML presentation.

By using Twig as a templating engine and PostCSS + SCSS to handle the styling, it’s a very simple setup. The Thingy is not meant to be the next new thing, it’s meant to be mini, and static, to create something on the fly (wing it).

View Mini Static Thingy Wingy on GitHub

Why create this?

It’s definitely not something new, and a lot of things are borrowed. The reason I created this is because it happens occasionally that I just need to create a little landing page. Sometimes I just want to set up something fast to create a page, or maybe two, or make a demo. And at times like that, I just want to get started fast. I used something similar like this before but I cleaned it up, added PostCSS in the mix and thought it would be nice to share.

From my job at iO, I’m used to working in Twig alongside with React. For such a small page, I always found React to be a bit overkill, so I chose Twig as a templating engine. This creates the possibility to create some partials, keep my files clean and transfer some variables between them.

How to run a Mini Static Thingy Wingy

Make sure you have the latest node version installed. Simply get the main directory and run:

npm install

Now you are ready to build! To start watching you files for changes, run the following:

npm run dev

This will start the server at localhost:5000 and you’ll already have a live reload on your index.twig file and your .scss file. In the next part, i’ll go a bit more in-depth, but don’t worry, it’s easy

When you’re happy with your result and want to build this, just add the following command which will create a build folder at the root of you projects, with your HTML, CSS, JS files (and other assets):

npm run build:production

Note: The CSS is automatically injected before the closing of the <head> tag, while JS is automatically added before the closing of the <body> tag.

How to build pages

Ofcourse, just building one file isn’t enough, here are some of the things you can do to build your static website.

Creating template files

In the src folder of your project, you can find a templates.json file. When you first open the project, it will look like this:

[
    {
        "filename": "./index.html",
        "template": "./templates/index.twig"
    } 
]

Whenever you want to create a new html file in your build, you’ll have to add another line. The first line is the output filename, and the second one is the input file.

[
    {
        "filename": "./index.html",
        "template": "./templates/index.twig"
    },
    {
        "filename": "./my-new-file.html",
        "template": "./templates/original-new-file.twig"
    }
]

Other commands

npm run build

Will build the files without minifying or combining CSS. This is a development output.

npm run watch

Will build the files without minifying or combining CSS and watch for changes, will rebuild on change. This is slower than running the dev server.

npm run install:demo

This will install some demo files with examples and start the server.

!!! Be careful, as this WILL overwrite items in your src folder !!!

Why Twig, PostCSS and Vanilla JS?

Twig

Twig is a templating language by Symfony. It’s well known for it’s implementations in Craft CMS and Drupal. Twig felt like the right choice for me because first of all, I’m used to it and second of all, it still feels like writing HTML

Twig also makes it easy to set variables for this Mini Static Thingy Wingy since it allows you to pass variables like so:

{% include "./partials/_navigation.twig", with { active: "home" } %}

PostCSS

I love to play around with PostCSS and all it has to offer. You can add your own custom packages in the postcss.config.js file at the root of the project.

In the production build, I added the purgeCSS and PostCSS Clean plugins, because they make sense to me, but if you’d rather see those go, you can always go into the config file and delete them.

Pure simple Javascript

Because we want to keep it small and clean, besides… Vanilla JS is a lot of fun. I added Babel and some plugins to make life a bit more easy such as dynamic import and transform runtime. You can always add more if you like.

Working with assets and translations

If you want to create something bigger, it’s still possible, however, this little Thingy wasn’t meant to do that. You can play around with subfolders or even add translations files in the form of a json-file.

Assets and subfolders for templates

When using relative paths to your tabs, it can get harder when you want to use subfolders. By default a variable is set in the _base.html which sets the base path of assets to "./assets/".

{% set assets = assets|default("./assets/") %}

When using subfolders it might get handy to update this variable to a new relative path such as:

{% set assets = "../assets/" %}

Using translation files

You can upgrade the webpack config to look for translation files in your folder.

1. In you webpack, add the following line of code

let templatePages = _.map(pages, function(page) {
//new line of code below
let translation = require(path.resolve(__dirname, "src")+'/translations/lang.'+page.lang+'.json');			
// etc

2. When creating a template add a language parameter for example:

[
    {
      	"filename": "./index.html",
      	"template": "./templates/index.twig",
		"lang": "en"
    },
    {
      	"filename": "./index-fr.html",
      	"template": "./templates/index.twig",
		"lang": "fr"
    }
]

Now we will create two pages from the same template, which will look at a different translation file (eg:lang.fr.json and lang.en.json)

3. Let’s create those two translation files in src/translations and add a translation with the same key.

In translations/lang.en.json

{
 "hello": "Hello world"
}

in translations/lang.fr.json

{
    "hello": "Bonjour le monde"
}

4. In our _base.twig template, we can now set a global variable

{% set t =  htmlWebpackPlugin.options.trans %}

5. And in our extended templates we can just refer to those variables as such:

    {{ t.hello }}

You should now get an output with different files in different languages, using the same base template.

Thoughts…

So, I created this mostly for personal use, but I hope maybe someone else can find a benefit in it. It’s an easy setup and I think it could be great for beginners that are just starting to learn HTML and CSS and find a bit of insight in the Twig templating language. I had fun creating it and will probably use it in the future if I need to create a “quick page”. If it is broken, feel free to file an issue on GitHub and I’ll see what I can do. Even if you have an idea on how to upgrade it, feel free to create a pull request. But remember, it has to stay Tiny ;)

CSS Day 2022: A small recap

Brecht De Ruyte — Sat, 11 Jun 2022 00:00:00 GMT

Waking up in the beautiful Amsterdam

Every time I go to a hotel, I seem to struggle the first night with getting some sleep. Waking up way too early to head off to the conference, I decided to go for a morning run, the sun was just starting to peep through the trees, letting me know that today will be a good day.

About the venue of CSS Day

Now being hosted in the Zuiderkerk, a fantastic location. When I arrived, to my surprise, I was welcomed by the clocks of the church. But strangely enough, when you are inside of the church you can barely hear them. I’m not the church-going type of person, let alone, two days in a row. But I do know a bit about acoustics and they really did a lot of effort when it comes to sound, except for the beautiful architecture, you could barely notice that you were sitting in church. After a hard deserved croissant after my morning run, It was time to take places and start the conference.

The speakers at day 1

Jeremy Keith: In And Out Of Style

Quite a known speaker, he’s been around for some time and gave a great keynote about the current and upcoming exciting times for CSS. With a blast from the past, showing us how third party libraries and hacks can become standards, or at least become reasons for standards to be created. I felt a bit of nostalgia listening to that talk, especially when he was talking about rounded corners in the Internet Explorer 6 era. Showing off his work and on the WorldWideWeb NeXT timeline and explaining a few of those points of history and last but not least sharing his love for design systems. A great talk to start the day.

Rachel Andrew: Interop 2022

The so-called “browser wars” are a thing of the past. Nowadays, all browser vendors come together to solve the top browsers compatibility issues identified by developers. This is interop 2022 and if you haven’t checked it out, I advise you to do so. It’s interesting to see the main working areas on browsers and also the dedication to first fix the things already implemented such as the gap property for Flexbox. A lot of the Interop 2022 items would become more clear during the day, but It was interesting to hear how these things get measured, about tests and also that we still have a chance to influence priorities for Interop 2023 by creating and starring issues on Github. The future of CSS is bright.

Lea Verou: CSS Variable Secrets

The first in-depth tech talk of the day. There was clearly a lot to say about using CSS variables. This is so much more than just SASS variables in native CSS. From creating booleans out of variables to some more complex algebra and showing us that CSS Custom Properties can hold just about any value. This was one of those talks that made me say: wait? You can actually do that? Creating space toggles in variables to create progressive enhancement for the new color modes in CSS, now that is a clever hack. Her talk also made me realise how badly I want to play around with the style container queries in the future. I know that this talk made me want to try some things out with variables and custom properties. So much information, so little time.

Bramus Van Damme: The CSS Cascade, a deep dive

It’s nice to see a Belgian up on that stage, as a former lecturer at Odisee you can clearly see the teaching skills of Bramus. With an audience still recovering from a lunch break he was able to keep the attention while going in depth about the cascade. He already wrote a blogpost about this which I read some time ago. But hearing him speak about it in combination with beautiful crafted slides made my enthusiasm grow just that little bit more. Excellent talk about this feature that is rolling out in all major browsers right now. The love for cascade layers is real and from a personal standpoint, I’m really happy about the syntax of this feature, it’s simpel, elegant, and easy to understand, especially after you understand the cascade just that little bit better. Thanks Bramus, keep talking with those hands!

Ana Ferreira: Collaborating without Borders

Ana Ferreira is Head of design at Doist, and has been working remotely for the company for about 8 years. She clearly explained that remote work is not the same as working from home, especially compared to working from home during the Covid pandemic. Asynchronous tools were key here, and such reducing meetings that could’ve been an email or a ticket. A lot of her talk was about trusting employees and taking a human first approach. I felt kind of jealous when she spoke about never having to log hours and just making sure that the work gets done. I can relate to this. An agenda shouldn’t always be stuffed with tasks. When the job gets done a bit more early, it might be interesting to work on personal development and growth, which in the end benefits a company. Because you can present your newly discovered technologies and maybe make the world/company a better place.

“Let’s not use being overworked as a badge of honor. Set boundaries and prioritize your well-being” Anna Ferreira

Chris Lilley: Escaping the sRGB Prison

I was actually looking forward to this talk because it was only a few weeks back since I chose to start reading the color modules 5 draft on the w3c website. And to be completely honest, colors are hard. I had a tough time understanding what was going on. But Chris Lilley delivered big time. Really showing how the gamut works and how different color syntaxes can give us different results was eye opening. One thing is for sure, in the future, gradients will look a lot more pretty. It’s an interesting module but also with a note of caution. Because we are going outside the sRGB prison, colors may become a bit more subjective. I might experience a color to be “greenish”, while another person might find it a bit more blue with a bit of green in it. Very interesting stuff. And for once we can say the following: There is no support for this in any browser, except for Safari, which supports all of those features!

Marcin Wichary: I pressed ⌘B. You wouldn’t believe what happened next

I don’t have a lot of experience when it comes to Figma, so I didn’t know what to expect from this talk. But “OMG”, this was a talk to be remembered. Marcin came on stage with an enthusiasm and a well crafted presentation that blew everyone away. I’ve always loved a good typography talk but this was next level. Talking about the struggles of font uses, the different weights, versions, sup and sub fonts, the struggle it takes to just press cmd+B to make a font bold. This was eye-opening. What is bold? If a font has a base weight of 400, but the bold version has 900, is using cmd+b to make it bold still a good idea? Is it just too bold and should it be considered as something else? And what do you do with all the other modifier keys on the keyboard? What about the legacy of numpads keys in figma to zoom? I personally never really thought of these things when it comes to design files and it was a great way to end the day. This was the surprise of CSS Day 1 for me. You can find an alternate version of the talk, but we got to see a lot more and enjoyed it very much.

The speakers at day 2

Adam Argyle: Oh Snap!

A little snap of the fingers and away we go for day 2. I was really looking forward to this because I had been working on accessible scroll tabs a while back. Adam made a beautiful presentation made with scroll snaps, as it should be ;). Really showing the full potential of scroll snapping beyond your basic slider. Using the scroll snap alignment to place the last item of a chat window at the bottom, so on page load it will always be visible. Using sticky positioning to create an overflow effect, and a lot more. He ended with a few things that they are working on in the scroll snap module 2 which among other things includes a :snapped pseudo element to target the current snapped item. Lovely stuff. Ow yeah, and I might need to revisit my demo just a little bit. Oh, and an interesting sidenote, together with Tab Atkins he’s also working on the CSS nesting module.

Michelle Barker: Creative CSS Layout

Michelle started off with one of the questions that all of the css developers asked themselves before: In this use-cas, would you use Flex or Grid. And the answer can really depend on the use-case, you should always choose what feels right. She also showed some of the strengths in using the aspect-ratio property. For example when using it on a grid itself with images inside of it. A lot more of these nifty grid tricks such as creating fluid padding around your grid and let’s not forget container queries and fluid typography. A great tool for fluid typography named utopia.fyi is something i’ll take a look at very soon

Amit Sheen: Getting Creative with Keyframes

Animations, animations, ANIMATIONS! We are getting spoiled at CSS Day this year with a variety of topics. Amit Sheen creates some of the greatest CSS animations out there. He does note that some of his animations aren’t to be used in a live environment due to the performance issues they could bring. But giving an insight on how he starts working on them was a great thing to see. It sounds simple but he starts with pen and paper, writing multiple graphs to align animations to each other, by writing curves on the graph to indicate the easing of them. Using a negative delay on animations so that you don’t get the “hard start” when an animation begins. Another really clever thing is to use @property to animate multiple transforms at the same time. A lot to take home from and some best practises that i’m sure to use in the future.

Ben Evans: The Joy of CSS

If you don’t know Ben Evens, I strongly suggest you take a look a at his work.
This talk really felt a bit like watching Bob Ross on television, very calming, live painting in CSS. It was very relaxing to see, but to be honest, maybe a bit too relaxing so shortly after the lunch break. Still it was wonderful to see how he starts with creating his CSS paintings and the dedication it takes to make something, a half hour a day, and about a year till completion. But why does he do that? To quote Ben:

“You can’t master something without knowing it’s limits”

It’s fun and relaxing

Maike Klip: Service Design and Front End Interaction

When designing for services, what are the things you need to think about. In the past you had to actually go to a physical place for all your government related issues, nowadays the “government” is more becoming a computer rather than a physical person you can talk to. This brings a lot of frustration. How can you make a computer have a compassionate relation to its users? Maike has documented all her interactions with the government for over an entire month and translated the key values into: desirable, viable, responsible, technological.

She also talked about the earthquakes in Groningen where people could get a subsidy for repairs or strengthening their houses. This resulted in enormous waiting lines, not only in real life, but also on the web. A badly created website, where by changing the URL you could get another spot on the waiting list and another person would be kicked out instead; When you hopefully/eventually got in after hours of waiting you were treated to a very bad crafted form that could even make a tech person scared for filling it in.

Tab Atkins-Bittner: The Future of Organizing Your CSS

Pages have become a lot more complex over time. The time that we used a simple selector is long gone. Now you could give everything a unique class in your CSS or you could nest a lot of levels deep, but in the end, you know you’ll end up with an “!important” slapped on top of it.

You could fix that by just giving up and using a framework such as Tailwind or Bootstrap. But Tab thinks that we can do better. By using the shadow DOM to reduce long pages and scoping CSS inside of little components we could make pages significantly smaller in size. You can import a stylesheet inside of your components but what if you need to style them from the outside. Well, with some variable trickery you can make that happen. I loved how he created a dice-roll component, because he plays D&D.

You can help with the nesting module!

He also talked about the CSS nesting module and they need your help. I wasn’t going to add code in this article because I feel like I should play around with some of the topics instead of just copying code from slides. However, they need our help with the nesting module. You can join the discussion of the nesting module here. And here are the current ideas:

.a {
	color: black;
	& .b {}
	@nest .c & {}
	@nest &.d, .e {}
}

.a {
	color: black;
	@nest & .b {}
	@nest .c & {}
	@nest &.d, .e {}
}

.a {
	color: black;
	{
		& .b {}
		.c & {}
		&.d, .e {}
	}
}

Stephen Hay: When Design Systems Lie

Do design systems alway lead to a good design? From that starting point Stephen Hay was going to start with telling some of the things that we lie about, mostly to ourselves. Design decisions are part of a system and often do not resemble the reality of the full design. It’s a system in a system. What this talk was really about is communication really. We need to talk with designers, show them what is possible in CSS. We don’t do that enough and there are a lot of cool things we can do nowadays which could impact design decisions.

Conclusion

So, why did I not go into detail of all these talks, maybe I wasn’t paying attention at all?

No, that’s not the case. First of all, I’m sure many will write an in-depth review of this event with code examples, links to slides and all of that. But I’m going to hold on to my notes for now, let things sink in, maybe create a few Codepens, try stuff out, re-read some of the things the speakers were talking about and maybe highlight something of it in the coming months.

You can always look some of these speakers up or go to an event yourself. There is a lot of information out there and I encourage you to do so. Because even after hearing them speak, I’ll be doing the same, going in depth, learning.

This was an amazing CSS Day edition, there was so much variety, I had some really interesting conversations as well with some of the speakers. It was a real “brain overload” at the end of it.

And guess what, they’ll be back next year! On the 8th and 9th of june.

The details element, collapsing content without the hassle

Brecht De Ruyte — Mon, 06 Jun 2022 00:00:00 GMT

Support of the details element.

Let’s start with the good news, apart from Internet Explorer and some older Edge browsers from pre-2020, the details element has great support. For simple content it is accessible, has outstanding keyboard navigation and doesn’t require any JS to create a collapse. However, there seem to be some issues when adding interactive elements inside of it such as links or input elements. Read more about this in the article of Geoff Graham

The basic HTML

In case you didn’t know, the basic HTML for this is simple:

<details>
  <summary>Here is a Title</summary>
  And here you can find the content
</details>

The <summary> element lets you give a title on which the extra information will be toggled.
On default, the details element is closed, but can be opened by adding the open attribute:

<details open>
  <summary>Here is a Title</summary>
  And here you can find the content. I am open by default.
</details>

Styling the details element.

Let’s be honest, the default look & feel of the details element looks a bit boring. Let’s create something very known and easy:

<!-- This is repeated 3 times in the example -->
<details>
  <summary>
    A little title or a question
    <svg xmlns="http://www.w3.org/2000/svg" class="icon" viewBox="0 0 20 20" fill="currentColor">
      <path fill-rule="evenodd" d="M5.293 7.293a1 1 0 011.414 0L10 10.586l3.293-3.293a1 1 0 111.414 1.414l-4 4a1 1 0 01-1.414 0l-4-4a1 1 0 010-1.414z" clip-rule="evenodd" />
    </svg>
  </summary>
  <div class="details-info">
    <h2>Lorem ipsum dolor sit amet</h2>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras convallis sodales erat vel accumsan. Nam eget massa nec sem vulputate ullamcorper vel quis justo. Duis rhoncus tempor tempus. Nulla facilisi. Maecenas nulla ante, lacinia ac consectetur non, aliquet sollicitudin libero. Quisque congue odio sodales dui fermentum ac laoreet mauris eleifend. Nulla facilisi. Phasellus vel erat a ante pharetra pharetra.</p>
  </div>
</details>

First we add some basic styling of the element.

:root {
  --collapse-bg: #e5fcff;
  --collapse-color: #1a1a1a;
  --collapse-line-color: #acacde;
  --collapse-icon-color: #b8336a;
  --collapse-box-shadow: rgba(0, 0, 0, 0.16) 0px 10px 36px 0px,
    rgba(0, 0, 0, 0.06) 0px 0px 0px 1px;
}

details {
  background: var(--collapse-bg);
  color: var(--collapse-color);
  border-radius: 8px;
  margin-bottom: 24px;
  box-shadow: var(--collapse-box-shadow);
}

summary,
.details-info {
  padding: 1rem;
}

.details-info {
  border-top: 1px solid var(--collapse-line-color);
}

You might’ve noticed that I wrapped the content inside of a <div>. This is purely for styling reasons. To play around with a border and padding. In the end, I decided to remove the default marker and replace it with my own custom toggle icon.

summary {
  display: grid;
  grid-template-columns: 1fr auto;
  align-items: center;
  cursor: pointer;
  list-style-type: none; /* removes the default arrow */
}

summary .icon {
  display: inline-block;
  width: 24px;
  height: 24px;
  transition: transform 0.26s;
  color: var(--collapse-icon-color);
}

details[open] summary .icon {
  transform: rotate(180deg);
}

So why is it that we still tend to use JavaScript for this?

It’s mostly because of animating the collapse. While the default functionality is good, we like to animate things and that’s where a pure-css solution is hard to do. There are some workarounds to mimic that “bootstrappy collapse feel” but it’s not completely the same. There is a great article about this by Chris Coyier on how to animate the details element.

Creating an accordion with the details element.

Another thing that requires a bit of javascript is when you want to create an accordion. For example, when you have a group of FAQ items and only want one of them open. I’m not the biggest fan of accordions personally. But I created a very simple example on how to create an accordion with the details element.

The HTML of this is simple, I just grouped the elements by wrapping them, and as for the JS it’s as simple as removing the open attribute of the siblings when one of the details elements is clicked. I’m sure more advanced versions are possible, but it does the job.

<section class="accordion-wrapper" data-accordion>
  <details>
    <summary>
      Some title
      <svg xmlns="http://www.w3.org/2000/svg" class="icon" viewBox="0 0 20 20" fill="currentColor">
        <path fill-rule="evenodd" d="M10 3a1 1 0 011 1v5h5a1 1 0 110 2h-5v5a1 1 0 11-2 0v-5H4a1 1 0 110-2h5V4a1 1 0 011-1z" clip-rule="evenodd" />
      </svg>
    </summary>
    <div class="details-info">
    	Some content
   	</div>
  </details>
  <!-- add more details elements below -->
</section>

const accordionItems = document.querySelectorAll("[data-accordion] > details");

const siblings = (el) => {
  if (el.parentNode === null) return [];
  return Array.prototype.filter.call(el.parentNode.children, function (child) {
    return child !== el;
  });
};

accordionItems.forEach((el) => {
  el.addEventListener("click", () => {
    const others = siblings(el);
    others.forEach((sibling) => {
      sibling.removeAttribute("open");
    });
  });
});

And here is the CSS for that:

:root {
  --collapse-bg: #e6ebe0;
  --collapse-color: #1a1a1a;
  --collapse-line-color: #5ca4a9;
  --collapse-icon-color: #ed6a5a;
  --collapse-box-shadow: rgba(0, 0, 0, 0.16) 0px 10px 36px 0px,
    rgba(0, 0, 0, 0.06) 0px 0px 0px 1px;
}

.accordion-wrapper {
  margin-bottom: 2rem;
  box-shadow: var(--collapse-box-shadow);
  border: 3px solid var(--collapse-line-color);
}

details {
  background: var(--collapse-bg);
  color: var(--collapse-color);
}

details:not(:first-child) {
  border-top: 1px solid var(--collapse-line-color);
}

summary {
  display: grid;
  grid-template-columns: 1fr auto;
  align-items: center;
  cursor: pointer;
  list-style-type: none;
}

summary,
.details-info {
  padding: 1rem;
}

.details-info {
  border-top: 1px dashed var(--collapse-line-color);
}

summary .icon {
  display: inline-block;
  width: 24px;
  height: 24px;
  transition: transform 0.26s;
  color: var(--collapse-icon-color);
}

details[open] summary .icon {
  transform: rotate(45deg);
}

Now let’s use this details element a bit more shall we?

There are solutions for animating the collapse feel. It works out of the box and you don’t need to play around with aria attributes to “make it accessible”. Remember that every kilobyte you load on a website impacts the environment and your performance. So let’s at least think about using this instead of adding a complete library just to toggle some FAQ questions.

A lot of power with little JavaScript, the HTML dialog element is here

Brecht De Ruyte — Mon, 25 Apr 2022 00:00:00 GMT

Why we benefit from a dialog element in HTML5

Dialogs, modals, whatever you want to call them, they are everywhere. We use them for different reasons and they can become a hassle from time to time. When using third party libraries we turn to “css hacking” to get the look & feel we want. We load tons of JavaScript into our platforms for even the smallest of dialog use cases and last but not least, a lot of times, the dialogs we implement aren’t even accessible. Let’s get a bit more into detail.

The `<dialog>` element is native

Every major browser has support for this element. They work the same way and have more or less the same user agent styling. There are times when we need support for older browsers or previous releases of the modern ones. When that’s the case we can still rely on a polyfill to take care of this. By adding the “open” attribute to the modal, we can define if it’s visible or not.

The `<dialog>` is styleable

Rounded corners, sticky headers, you name it. We can style everything in a dialog element and from what I read on the w3c interactive elements spec: it supports flow content, this means that most elements that are used in the body of documents and applications can be used inside of it. This opens a lot of possibilities.

The `<dialog>` can have a `::backdrop`

If… you open it with a trigger in JavaScript, you can get a pseudo element ::backdrop which you can style. The backdrop is by default not clickable to close the dialog, however there are some ways that we can do that. I’ll give an example further in the article.

The `<dialog>` is accessible

It automatically shifts your next tabfocus inside the dialog element itself and in Chrome it seems to have some sort of focus trapping, at least in my Codepen examples. VoiceOver also makes it clear when you enter a dialog element.

The `<dialog>` only needs a small amount of JavaScript

Just some easy triggers that you need to call and you’re ready to go. Of Course you can expand on that by adding new click events on the backdrop and things like that. It’s a real front-end performance boost compared to the huge libraries we used to implement.

Playing around with the dialog element.

I created the following codepen if you want to play around with it: Dialog with sticky header in HTML
There are many ways to trigger a dialog but in its purest form, I created the following:

<button class="btn btn-primary" data-target="my-dialog" data-modeltrigger>
  Click me
</button>
<dialog data-name="my-dialog">
  <header>
    <h2>Well hello there!</h2>
    <button class="btn btn-icon" data-target="my-dialog" data-modeltrigger>
      <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke="currentColor" stroke-width="2">
        <path stroke-linecap="round" stroke-linejoin="round" d="M10 14l2-2m0 0l2-2m-2 2l-2-2m2 2l2 2m7-2a9 9 0 11-18 0 9 9 0 0118 0z" />
      </svg>
    </button>
  </header>
  <main>
    <p>I am a lovely dialog with HTML. This is a really awesome HTML feature don't you think? Only requires a bit of javascript and so versatile.</p>
    <p>I even have a great scroll behaviour right outside the box :) check it out by editing this text</p>
  </main>
  <footer>
    <button class="btn btn-primary-outline" data-target="my-dialog" data-modeltrigger>
      close
    </button>
  </footer>
</dialog>

By adding some data attributes I created the following triggers in my Vanilla JS::

data-modeltrigger specifies that this element (button) triggers a modal
data-target gives a reference to the name of the dialog i want to trigger
data-name is added on the dialog which is referred to by the data target. (I chose not the use id’s)

    const triggers = document.querySelectorAll("[data-modeltrigger]");

    triggers.forEach(function (el) {
      el.addEventListener("click", function () {
        const getTarget = el.getAttribute("data-target");
        const target = document.querySelector(`[data-name="${getTarget}"]`);
        if (target.hasAttribute("open")) {
          target.close();
        } else {
          target.showModal();
        }
      });
    });

Inside the javascript I added a little check to see if the modal is already open or not, this way, creating buttons that open or close the modal are made easy.

To wrap it up, I added a bit of custom styling to the modal as well, here is the main part of it:

/* Styling the modal and backdrop */
dialog {
  width: 100%;
  max-width: 600px;
  padding: 0;
  background: #fff;
  border-radius: 8px;
  border: 1px solid #dedede;
  box-shadow: rgba(99, 99, 99, 0.2) 0px 2px 8px 0px;
  animation: scale-in 0.4s ease-out;
}

dialog::backdrop {
  background: radial-gradient(
    circle,
    rgba(216, 209, 116, 0.5) 0%,
    rgba(182, 196, 84, 0.7) 100%
  );
}

/* bouncy animation because i can */
@keyframes scale-in {
  0% {
    opacity: 0;
  }
  50% {
    opacity: 1;
    transform: scale(0.9);
  }
  100% {
    transform: scale(1);
  }
}
/* Styling inside of the modal in the demo */

And so, a first <dialog> demo has been made.

I haven’t really found a beautiful way to handle this. It seems that at the moment the easiest way to do this is to use the getBoundingClientRect() to check if a person is clicking outside of the modal and when doing so, trigger a close() on the dialog element.

Update: On LinkedIn, someone showed me a more elegant solution for closing the dialog based on the following tweet by Adam Argyle. This is much cleaner than calculating the mouse position.

This is the JS I added (updated):

    const dialogs = document.querySelectorAll("dialog");

    /* Check for click in backdrop */
    dialogs.forEach(function (el) {
      el.addEventListener("click", ({target:dialog}) => {
        if (dialog.nodeName === 'DIALOG') {
          dialog.close('dismiss')
        }
      });
    });

See the codepen: Dialog with backdrop click close

Taking things overboard: A dialog in a dialog in a dialog…

If you read a few of my “trying out” posts before, you know that I like to play around with things, maybe break them, or just create something crazy. This is just me doing that. I created a little demo which nested the dialog elements inside of each other, this should be valid, remember: “flow content” is possible in dialog elements.

In the end it’s just a bunch of dialogs triggering each other and a newly added data-parenttrigger attribute which force closes all the other dialogs on the page. By adding this little bit of JavaScript on it:

/* 
...
inside the trigger click event..
*/

if (el.getAttribute("data-parenttrigger") !== null) {
  dialogs.forEach(function (el) {
    el.close();
  });
}

See the demo A dialog inside a dialog inside a dialog if you want a little laugh.

One important thing I noticed here: The backdrops of these dialogs seem to stack upon each other because they’re not pseudo elements to the dialog and not dependant on the page, so if you feel inspired by that, you might create something “visually interesting”.

Final `<monologue>` on the `<dialog>`

Being a developer for quite some time, I had my fair share of dialogs. Hacking in JS and CSS to do something special with them that wasn’t supported by the library which provided them. Accessibility issues that just didn’t seem to find a right answer. I’m really happy with this addition and I hope it gets implemented by web developers around the world in the future. I’ve also been playing a lot of Elden Ring in my spare time, so “praise the message” (Elden Ring players will get this ;) )

Using best practices to create CSS scroll snapping tabs

Brecht De Ruyte — Thu, 31 Mar 2022 00:00:00 GMT

The basic scroll snapping idea with CSS.

It started out as a simple test. By having a container with 2 lists. The lists would be next to each other and by scrolling left and right, you could toggle between them.

The HTML setup was very simple:

<section className="scroll-snap-panel">
    <div className="scroll-container container">
        <ul className="scroll-list people">
            <!-- some list items here -->
        </ul>
        <ul className="scroll-list groups">
            <!-- some list items here -->
        </ul>
    </div>
</section>

The .scroll-container would become a grid with 2 items that have the full width of their container. The scroll container would have an overflow-x and some smooth scroll snapping options.

Here is the basic CSS for this:

:root {
  --container-width: 480px;
}

.container {
  display: grid;
}

.scroll-snap-panel {
  width: 100%;
  margin: 30px auto;
  box-shadow: rgba(0, 0, 0, 0.3) 0px 10px 50px;
  max-width: var(--container-width);
}

/* the scroll magic */
.scroll-container {
  position: relative;
  grid-template-columns: repeat(2, var(--container-width));
  -webkit-overflow-scrolling: touch;
  overflow-x: scroll;
  scroll-snap-type: x mandatory;
  scroll-behavior: smooth;
  max-height: 85vh;
  border: 1px solid #CCC;
  border-top: 0;
}

.scroll-list {
  display: block;
  width: 100%;
  height: 80vh;
  margin: 0;
  padding: 0;
  list-style: none;
  scroll-snap-align: start;
  scroll-snap-type: y proximity;
  overflow-y: scroll;
}

.scroll-list li {
  display: grid;
  grid-template-columns: 80px 1fr;
  gap: 20px;
  align-items: center;
  padding: 15px 20px;
  border-bottom: 1px solid #aaa;
  scroll-snap-align: start;
}

The first example

(codepen for the first step here

A fun little component, but not accessible at all.

There are a two main problems with this little component:

It can only be navigated by using a mouse / trackpad
There is no indication that it can be scrolled horizontally if you don’t have your scrollbars visible at all times.

In short, not accessible at all and it got me thinking. What if I made a hybrid component where you can use this awesome scroll snapping functionality in combination with tabs. This would:

Create a fun mobile experience
Still have the functionality of tabs
Would fix some accessibility issues along the way

First things first, fixing the UX.

(Visual representation of this step

The first thing on the agenda was making an indication of the hidden content simply by adding some tabs to our HTML:

    <section class="scroll-snap-panel">
      <div class="tabs-container container">
        <button data-target="people-tab" class="people tab active">People</button>
        <button data-target="groups-tab" class="groups tab">Groups</button>
      </div>
      <div class="scroll-container container">
    	<ul class="scroll-list people" id="people-tab">
    	  <!-- List items here -->
        </ul>
        <ul class="scroll-list groups" id="groups-tab">
    	  <!-- List items here -->
        </ul>
      </div>
    </section>

The next thing I did was adding a bit of CSS for the active tabs and adding some JS, which will use the tabs to scroll to the right position. You can view the CSS in the demo, but the basic idea of the JS was the following:

const tabs = document.querySelectorAll(".tab");
const scrollContainer = document.querySelector(".scroll-container");
const scrollLists = document.querySelectorAll(".scroll-list");

/* check for clicks and update scroll position based on target offset */
tabs.forEach((tab) => {
  tab.addEventListener("click", () => {
    const target = document.getElementById(tab.dataset.target).offsetLeft;
    scrollContainer.scrollLeft = target;
  });
});

/* 
when the scrollcontainer is scrolled horizontally, 
check the current scrollposition is the same as the left offset, 
and set the tab active when that's the case 
*/
scrollContainer.addEventListener("scroll", () => {
  let scrollPos = scrollContainer.scrollLeft;
  scrollLists.forEach((list) => {
    let listId = list.id;
    let listButton = document.querySelector(`.tab[data-target="${listId}"]`);
    if (scrollPos === list.offsetLeft) {
      [...listButton.parentElement.children].forEach((sib) => {
        sib.classList.remove("active");
      });
      listButton.classList.add("active");
    }
  });
});

And for a moment, I thought it was perfect:

It has an indication of multiple panes
You can use tab and shift-tab to switch between tabs and enter to activate them.

But I still wasn’t happy. There was no indication of tabs when using voice over, The list is not vertically scrollable with a keyboard. So when it came to accessibility. I still had ways to go.

The final improvement to make it accessible.

(Visual representation of this step

I knew I had some reading to do. So I started looking at the documentation of tabs at the aria working group website. A quick summary of how tabs should behave:

Using TAB

The first TAB should enter the tab component on the first (active) button.
The second TAB should change the focus inside the active tabpanel.
The third TAB should leave the tabbed component

Arrow keys

While focussing on the tab button, the arrows should switch between them.
The tabpanels can either be activated automatically while using the arrow or manually by pressing the enter key (for this example, I chose automatically)

Special case

Because I’m working with scroll behaviour, I wanted the arrow keys to work inside the tabpanel itself. By pressing the left or right arrow key while scrolling through the list, I want it to switch the active panel and focus on the new active tab as an indication of what happened.

They have some great examples at the ARIA working group, so based on their example of automated tabs, I started by changing my HTML to the following:

<section class="scroll-snap-panel" role="tablist" aria-label="users and groups">
  <div class="tabs-container container">
    <button data-target="people-tab" role="tab" aria-selected="true" class="people tab active" aria-controls="people-tab">People</button>
    <button data-target="groups-tab" role="tab" aria-selected="false" class="groups tab" aria-controls="groups-tab" tabindex="-1">Groups</button>
  </div>
  <div class="scroll-container container">
    <div class="scroll-list people" role="tabpanel" tabindex="0" id="people-tab" aria-label="people">
      <ul>
        <!-- list items here -->
      </ul>
    </div>
    <div class="scroll-list groups" role="tabpanel" tabindex="-1" id="groups-tab" aria-label="groups" hidden="hidden">
      <ul>
        <!-- list items here -->
      </ul>
    </div>
  </div>
</section>

Something to note here. You might notice that I wrapped my lists inside another <div>. This is because a role=”tabpanel” should not be used on an unordered list.

By adding a bit of JS from the ARIA working group and infusing it with my own code. I was able to create something interesting and accessible. I learned a lot from this experience and the goal of this post was to take you on a little thought journey. Accessibility is very important, and we might not get it perfect all the time, but a bit of effort can go a long way.

The final example, with kudos to people who create examples in the ARIA working group.

The final example

A love letter to the CSS-developer

Brecht De Ruyte — Mon, 14 Feb 2022 00:00:00 GMT

My dearest CSS-developer, o how the times are a-changin’. You’re probably writing more JavaScript in your life, more than you’d want to, you might even have picked up some frameworks such as React or Vue. How can you keep your identity as a CSS-developer, how can you keep expressing your love for that perfect layout in the language you’ve mastered so well…

It’s not the first time that jobs get mixed up

You might have started out as a designer, expressing your artistic skill to create beautiful websites on a 960px grid in Photoshop and later on learning to code a bit of HTML and CSS, using the power of floats, it was a skill only a few could master.

At a certain point, you chose to give up the designing aspect and started to just code other people’s artwork into interactive elements. You did this pixel-perfect and even threw in some JavaScript in the form of jQuery into the mix, making you that person who was awesome. Back-end developers loved how their database-scheme was shown so beautifully on a website and designers high-fived you because their creativity just turned into a masterpiece.

So then you became a front-end developer

Times are changing again, you learned a bit of PHP and could use different templating languages such as Twig, you could perfectly create your own Wordpess blog and play around in so many environments, you could create a beautiful website on almost every platform out there. But even that was not enough, there was something on the rise, the wonderful world of JavaScript. And before you knew it, you were starting to write a bit of React or a bit of Vue, you were creating Webpacks after already mastering a bit of Gulp or even Grunt. You were already writing CSS in a SASS or Less environment to reduce time, you might even be using Bootstrap because it just made everything go smooth and efficient.

Don’t forget about accessibility and technical SEO

A lot of times people seem to forget that you are the first technical person in taking the first step to creating something accessible that is perfectly readable for search engines. You take the first steps into technical SEO by adding microdata and using correct semantics to please all users and robots alike. A lot of times, you are the first one to spot inconsistencies and you have no problem reporting something user-unfriendly when you are creating your templates.

But now you are starting to feel a loss, and I hear you…

You have learned to be efficient, you make websites at the speed of light, but you get the feeling that a lot of things are starting to feel the same. Using the same visual styles over and over again because they are “like that in the framework”. You miss using a part of the skill you’ve mastered before, creating something amazing with just the power of CSS and great semantics. I’m telling you, you are not alone and many front-end, or should I say CSS-developers, feel that way. And I do believe that it’s time that the term front-end development shouldn’t be so generalised as it is now. But I’m telling you, the future is bright because there is a shift in the web, something that had to happen a long time ago.

The clients want more creativity and visual identity

Especially with the pandemic, a lot of webshops have sprouted and now we have a lot of websites that kinda look the same, and a lot of brands are starting to notice that as well. They want something to remember, they want something visually different while still maintaining accessibility, great UX and search-engine optimisation. You have the power to do that, with the more evolving CSS language and browsers that update automatically, you have a toolset for this, a toolset you love and master.

JavaScript includes more and more “back-end” work

A lot of the projects you encounter are getting really technical and there are a lot of JavaScript developers out there. Those people are great and a lot of them don’t have those visual skills that you’ve mastered, they will help you out, and you can work together as a team. They will be happy to see their JavaScript code on such a beautiful layout and you will be happy to see everything work so snappy and strong.

Let’s call you the client-side developer

Because in the end, that is where you shine, creating something visually pleasing, responsive, accessible. Something with powerful semantics that is scalable, expendable, lightweight and performant. By adding a bit of client-side JS you can do wonders that please the eye. You integrate animation where needed and tweak all the things until they are picture perfect. Believe in your craft and never forget that even in “just writing CSS” you can grow, explore and have a lot of fun. Take it from me, even though I write a bit of React, know a bit of PHP, the heart is where the CSS lies and that’s perfect. Follow your passion and become a master of all things visual and client-side.

You are the one, who gets the layout made
The one who loves perfect semantics
and mastered the cascade
You know how a design should flow
Making all things interactive
Creating projects, with room to grow
You are a master when it comes to CSS
The one who loves the web
and makes sure everyone has access
You translate the design, it’s where you prosper
Other skills might be bonus
But you are, by far, my favourite developer.

Fun things you can do with CSS Grid besides your basic layout

Brecht De Ruyte — Sat, 22 Jan 2022 00:00:00 GMT

First things first: The problem with the CSS Grid module

Using CSS grid is a blast, and I have been playing around with it from time to time, but for some reason, I never found the time to actually take a deep dive in it and it never felt like a natural thing to use. The main problem with it is that it never got the hype that Flexbox had a few years back. People were able to use grids, Bootstrap and many other libraries had a brilliant integration of a Flex grid and so, a lot of developers just didn’t find the need for it.

I am one of those developers, the syntax seemed a bit hard, I didn’t find a reason to make the switch. But from the start of 2021 till now, I started doing a bit of effort to use it from time to time and suddenly, it just clicked. I noticed my code getting shorter, my HTML more read-able and before i knew it, I was hooked. So now I’m using the CSS grid layout for more things and here are some of the fun ones I played around with. After all, sharing is caring.

Buttons with CSS Grid

I created a few buttons with the module. The idea was to keep my HTML as short as possible. By using pseudo elements, we can actually make them a part of the grid and style them. So here is the HTML we start with.

<button>This is my button</button>

Very simple indeed, what we need next is a bit of styling of our button. So here the trickery starts, let’s make our button a grid and add some basic styling to it.

button {
  display: grid;
  grid-template-columns: 1fr auto 1fr;
  align-items: center;
  padding: 5px;
  font-family: 'Lato', sans-serif;
  font-size: 1rem;
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: .08em;
  line-height: 1.5;
  color: #FEFEFE;
  background: #C200FB;
  border: 0;
  border-radius: 30px;
  cursor: pointer;
}

We now have a button that is a three column grid, and the center column has an auto width. We can now start adding our pseudo elements and create those “punch out holes” or dots.

/* style the button to have holes in it, the pseudo element is a part of the grid */
button::before, button::after{
  content: '';
  width: 15px;
  height: 15px;
  margin: 0 10px;
  box-shadow: inset rgba(0, 0, 0, 0.2) 0px 0px 3px;
  border-radius: 50%;
  box-shadow: 0;
  background: var(--container-background);
}
/* to make sure the right "column" stays aligned to the end */
button::after {
  justify-self: end;
}

And there you have it, a very simple button that looks like it has a lot more HTML going on, but in fact, it’s so clean and simple. You might have noticed that in the teaser image above, the punch out holes have the same color as the background. This is by using a little CSS variable trick based on the container. By adding a variable color to the container background and using that same variable on the pseudo element’s background.

You can see the full example on codepen.

Styling a title with lines on both sides

Chances are big that during your career you had to style a title that kind of looks like the one above. You might remember having a hard time with this, maybe writing some extra spans or other tags just to get the desired result. The technique used for this, is pretty much the same one as the button example but now we just keep it simple with a simple <h1> tag:

<h1>My super awesome title</h1>

And once again, we use our grid and pseudo elements to create the lines and the column gap for the spacing.

h1 {
  display: grid;
  grid-template-columns: 1fr auto 1fr;
  align-items: center;
  column-gap: 20px;
  margin: 10px 0;
  font-family: 'Merriweather', serif;
  font-size: 2.2rem;
  color: #000;
  line-height: 1.2;
  letter-spacing: .05em;
  text-transform: uppercase;
  text-align: center;
}

h1::before, h1::after {
  height: 1px;
  background: #000;
  content: '';
}

This way of working really helps the workflow and keeps your HTML nice and clean. You can also use grid rows to create other effects. Click here to see the other examples.

Using Grid to make a list span over multiple columns

This is a neat little trick I found out recently. When you want a list (<ul> or <ol>) to jump to another column after a few items, you can use the grid-auto-flow property to make this dynamic. It’s not a 100% failsafe when content is being entered by a CMS because it will keep creating columns until infinity. However, if you have a little bit of control, this might be the perfect solution for you.

<ul role="list">
  <li>If you're not hurting you're not winning</li>
  <li>Swim with sharks</li>
  <li>Thinking outside the box</li>
  <li>Really threw me under the bus</li>
  <li>Let's not solutionize this</li>
  <li>That's mint</li>
  <li>We don't need to boil the ocean here</li>
  <!-- add a bunch more here -->
</ul>

ul {
  display: grid;
  grid-template-rows: repeat(5, auto);
  grid-gap: 30px;
  grid-auto-flow: column;
}

By using a combination of rows and auto-flow, we created something that would’ve cost us a lot more hassle in the past. This of course is just the basics of this integration, the fully styled example can be found on my codepen.

Angry manga face

I won’t place the css of this on the blog because truth be told, it’s a little bit messy. I don’t have any awesome drawing skills but I always wanted to “paint” a cartoon with CSS. However, instead of using position absolute to style the little manga face, I decided to use CSS grid to align the eyes, nose and mouth. Click here for the demo :)

Bonus round: Masonry

I’ve already written a blogpost about using masonry in CSS and I’m still hoping for this to roll out on all major browsers somewhere in 2022. As for now, there are tricks on how you can achieve a lightweight solution by using a CSS grid.

At the moment this is only available in Firefox Nightly after a flag. By using the following syntax:

.grid {
  display: grid;
  gap: 5px;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: masonry;
}

I Hope some of these demo’s helped you out. I plan to play around with this a lot more and am looking forward to learning many new techniques. Happy Gridding!

5 future HTML tags on my wishlist that could benefit accessibility

Brecht De Ruyte — Mon, 20 Dec 2021 00:00:00 GMT

Accessibility starts with good HTML

Forget about ARIA and roles for a moment, The best accessibility is achieved without specific shenanigans and a strong foundation in your HTML. Too many times we’re “fixing” things for accessibility while in reality, it’s not the hardest thing to do. Perfection might be hard, I can agree to that, but a basis for an accessible web, shouldn’t be.

We get too many comments about this such as:

Our CMS or framework won’t let us output HTML that way
The client doesn’t care anyway
It just takes too much time
I can’t convince my boss

When you get your basic HTML right from the start, it shouldn’t take too much time and if your CMS or framework won’t let you output the HTML the way you want, you might want to start thinking of using something else, because in the end: it all comes back to the basic building blocks.

So why create more HTML tags?

The ideas I gained over the years are mainly based on a course that I followed at the AnySurfer office. They help to spread the word about accessibility, give courses and “Anysurfer labels”. They even test your website for a price. Belgium doesn’t score well in the accessibility field, there is a lot of room for improvement, but times are changing.

When following the course there is one thing that intrigued me. Screen Readers are smarter than you might think. They can give a list with “all H2 tags on the page” or “all the links on this page” by using the rotor function. Which made me think on how we can improve accessibility for people using this kind of aid. I strongly believe that if we start adding useful new HTML tags, a good practice in accessibility could be more consistent because they are easy to learn and maintain. Creating good accessibility isn’t that hard, but it would be better if it’s easy.

Also, never forget the first rule of ARIA

If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Before I make this list, I want to point out that this is purely about some ideas that I heard, or read online and that they’re purely fictional (for now). I will include information on where I found the idea if applicable. They are by no means a “top 5”, just five in total.

1 `<banner>` tag for banner USP’s & promotions

Especially with the pandemic, webshops started to rise as the skyline of New York in 1900. Imagine a native html tag for the role=”banner” to add promotions on a webshop. A rotor might show “all the banners on this page” and get results such as “buy 2, get one for free” on the current product page.

<banner>
	Buy two products, get one for free!
</banner>
<!-- or maybe the following? as it might be interesting to combine images and text inside the tag -->
<banner aria-labelledby="banner-title">
	<h3 id="banner-title">Buy two products, get one for free!</h3>
	<img src="some-image.jpg" alt="Promobanner: Buy two products, get one for free" />
</banner>

2 `<price>` tag

Staying in the webshop story, this one could be handy as well. Especially for the way aiding devices would pronounce prices. However, I do think this would need a bit of extra, maybe a type attribute to define what kind of price we’re printing out such as “discount” or “total”. It could reduce the amount of hidden texts. We might even benefit from a currency attribute to specify that as well. One side note here is that I do feel there is a bit of danger involved in this when it comes to scamming people. We have “price tags“ in stores, now let’s add them to HTML? It kind of makes sense to me.

    <!-- some wild ideas here, but in this idea the price should only contain numbers -->
    <price currency="euro">20,00</price>
    -<price currency="euro" type="discount">5,00</price>
    +<price currency="euro" type="addition">3,00</price>
    <price currency="euro" type="total">18,00</price>

3 `<alert>` tag

Truth be told, this might be my favourite of this list and let me tell you why. It seems very easy to implement in new websites or to add on older websites. This one would be great for websites who already have a bad score. Many times, forms and especially error handling can be frustrating for users with a reader. They notice something went wrong, but it’s hard to tell where the problem is located, or which field gave an error. It’s not the hardest thing to get right for those users, but if there was a way that they could “view all alerts on this page” and then read which field gave an error (and why). It could make the frustrating journey a bit better.

So yes, this might sound like a “fixer upper” and it probably is. But I feel this is something we can benefit from when adding a small update on a website that never had decent accessibility to begin with. Every little bit helps for that matter. If this would complicate things with a JavaScript alert(); I could settle for a <notice> tag.

    <alert type="error">
    	<p>There was an error submitting the form</p>
    	<ul>
    		<li>Email field has invalid characters</li>
    	</ul>
    </alert>

    <alert type="success">
    	Product xxxx was added in your basket.
    </alert>

4 `<search>` tag

This one caused a bit of commotion on the web this year, some liked it, others were against it. But I personally think Sara Soueidan has some excellent points when it comes to adding the search tag as a sectioning element. I think that many people use the search first, whether it be in documentation or webshops. The search is often a go-to place when a user gets lost as well and could be a savior for keeping people on your website.

It could be used for the default search forms with or without options, but maybe we could even take it a step further for when it comes to filtering a large catalog.

Update 2023: this is no longer completely fictional as there is a go for the HTML search element.

5 `<chart>` tag

Charts are always hard for accessibility, mostly because they are a visual representation of data. When the “visual” gets removed from the representation, there isn’t much left.

There are many ways we can tackle this by adding Screen Reader only text or captions, but having a built-in feature would be a very nice to have. I see this as an alternative to the <figure> element where the <figcaption> isn’t shown by default and contains a descriptive representation of the chart.

<chart>
	<!-- some canvas or other html that creates the visual representation -->
	<chartcaption>
		A description of the chart, could also be a
		<table></table> element maybe?
		Is visually hidden by default.
	</chartcaption>
</chart>

It’s time for HTML to rise again

It’s been 7 years since HTML5 was released and I think it’s about time the language gets a bit of extra love. We’re writing ARIA helpers all the time and sometimes end up doing more damage than good. These are just some wild ideas and I’m far from an expert when it comes to the legacy of browsers.

It’s important that we “don’t break the web” by adding new tags that might have some history behind them in older browsers. But that concludes my wishlist, who knows, maybe Santa will bring some of those presents in 2022.

Is it time to stop pre-processing CSS and use post-processing instead?

Brecht De Ruyte — Mon, 06 Dec 2021 00:00:00 GMT

What’s the difference between pre- and post-processing CSS?

As the name might suggest, pre-processing happens before and post-processing happens after, but there is a little more to it. When we do pre-processing it always involves another language, such as Sass/SCSS (which I’m most familiar with) but also LESS and Stylus. When pre-processing we’re writing our styles in another language and turning it into CSS.

Post-processing happens later on, we already write CSS but add plugins to enhance it such as automatically adding prefixes, purging unused styles or add fallbacks for older browsers that don’t understand certain features.

The main benefits of using pre-processing

It has a lot of things that make our life a little easier such as mixins, nesting and variables. The reason I started working with them 8 years ago was just for that: nesting and variables. Also the automatic prefixing was very needed at the time. The good thing is that it continues to evolve, we can write a lot of functions now, and use arrays in our variables. One thing is for certain: it makes writing (S)CSS a lot faster.

Anno 2022, can we drop pre-processing and only post-process our CSS?

Yes we can! But there are a few things that we need to keep in mind and I will explain why I think preprocessors are becoming a thing of the past. As mentioned before, I started playing around with this in my spare time and later on I got some time to figure things out on how to do it on a team-level for my job. I will try and explain my findings for both of these cases. And the answer will differ between the two. Let’s start with the basics:

Variables are native CSS now

We can write variables, it’s native to CSS. With the exclusion of array variables we can pretty much add every color, font, measuring unit in our CSS variables. There is one thing missing though and that’s adding media query variables. It’s a work in progress but it will be available as it’s currently a working draft by the W3C.

If only there was a way we could write them now (spoiler alert: there is).

Nesting has been a work in progress for a long time by the W3C

Currently, this is a first public working draft, which is a soft way of telling you that this is far from a final idea and it might get thrown away. It might still be dangerous to see this as a final syntax, but I noticed that a lot of people started working with it in combination with some PostCSS plugins. It works a bit different than nesting in Sass and it takes some getting used to.

Nesting in Sass/Scss:

.container {
	max-width: 1024px;
	margin: 0 auto;
	h1 {
		color: green;
	}
}

Nesting with the nesting module enabled in PostCSS:

.container {
	max-width: 1024px;
	margin: 0 auto;
	& h1 {
		color: green;
	}
}

It seems that this is not an easy draft to work on with many questions and fallback issues, in the end: “we can’t break the web”. It’s something that is high on my list for the future of CSS and I hope it will see the light in some development browsers such as Canary and Nightly somewhere in 2022.

My basic setup for using custom media queries, importing files, auto-prefixing and nesting was the following

const postcssPresetEnv = require('postcss-preset-env');
module.exports = {
    plugins: [
        require("postcss-import"),
        postcssPresetEnv({
            stage: 3,
            browsers: 'last 2 versions, > 0.2%, not dead',
            features: {
                'custom-media-queries': true,
                'nesting-rules': true
            }
        })
    ],
};

Conclusion of basic features

Yes, there are ways to tackle the nesting and custom media queries in PostCSS. There are many plugins for that, the postcss-preset-env plugin seems to be the most popular one for this as it also includes a browser list support. However, this is only a small part of why we use Sass. The strength is mainly in the functions and mixins that we can write. Although I do believe mixins usually create a lot of code that doesn’t end up in the final product, they are beneficial when used correctly.

There is a plugin for that!?

PostCSS is full of handy plugins that can turn our CSS to a more Sass-like environment. There are plugins for:

Adding imports to a single file
Writing for loops in your css
Adding Sass-like variables

You might understand that this feels a bit strange, we’re actually creating our own environment now, and although it works like a charm, you might be thinking “why not just use Sass then?”. This is a fair point. I personally enjoy PostCSS because it lets me think about my code, and by using future CSS with the (probably) correct syntaxes, I strongly believe it makes me a better developer. I won’t get into detail on these just yet, but it’s important that you know that we can tweak our environment using PostCSS as well.

PostCSS should not be considered as purely an alternative for Sass. I look at them as separate things. Want to write Sass, then by all means do so. But if you want to write CSS, consider dropping Sass completely for a little project and be amazed by what we can do without using it. Personally, I found it eye-opening to step out of that comfort zone.

Extra benefits of PostCSS or postprocessing in general

With post-processing we can do a bit more. There are a few plugins I would like to highlight:

PurgeCSS

The plugin looks at your files (html, js, twig,…) and only adds the CSS based on the classnames found in them. A really nice way to optimise your final CSS-file just a little further. Read more about purging css.

CSSNANO

Minifies your files and has many options to choose from. There are a lot of alternatives for this, but I was quite happy about how this handled my files. Read more about CSSNano here.

Sort media queries

Automatically combines the media queries and adds them to the end of the CSS file, quite handy when nesting to lower the file size.

I’m actually a bit angry because of my own SCSS comfort zone

A few months back, there was a tweet from Sass that made me think quite a lot:

Tweet from Sass on 17th of september 2021

Although writing in SCSS for some time now, this actually made the purist in me a little angry. There is an unofficial draft in CSS about using @when native. However, a few members of the working group wanted to change this to an “if” statement, which would clash with the current implementation in Sass. To be honest, I know Sass has supported this for a long time, but a tool should never dictate what a product looks like, especially if the tool is dependent on the product itself. This is harsh and I don’t feel like changing all my SCSS files as well, but it’s a simple truth. You don’t make a wrench for an 8-sided nut and complain that when the 8-sided nut releases, it has a slightly different size. In that world, machines would be made differently as well, so the tool would dictate a little too much. This is mainly why I finally started looking into PostCSS.

We live in a fantastic time with browsers that automatically update, the progression of CSS is going much faster now and should be given the room to do so, in a way that makes sense.

Grab some popcorn and read the full discussion here.

Final thoughts

I have the feeling that having a setup in PostCSS somehow forces me to write better CSS, using future modules is a nice to have since it makes me study while I’m working on a project and keeps me in the loop of evolutions on the W3C part of it. As a personal tool to ditch SCSS all together I really love it. Especially when features get rolled out to a browser, it’s easy to just remove a plugin since it isn’t needed anymore. What’s even better is that with tools such as browser lists, this will happen automatically.

When it comes to bigger teams, I think there could be more issues: a lot of people know how to write in SCSS so everything you configure is a custom setup and good defaults will need to be discussed. This might be easy with a 2-3 person team, but in larger teams things could get a bit overwhelming. If you use this in a big team: I’d really love to hear your thoughts on it through linkedIn or twitter.

In the end, I think a Hybrid model is still the best way to go, using SCSS together with PostCSS might give you the best of two worlds.

Styling based on container width made possible with CSS container queries.

Brecht De Ruyte — Tue, 02 Nov 2021 00:00:00 GMT

It all started with a proposal by a few people including Miriam Suzanne who drew the first ideas into how containment should behave. With a lot of upvotes on the topic and more people backing it as a highly-needed feature, it’s finally available with a flag on Chrome Canary with many more browsers to follow soon.

We’ve all been there, you have a beautifully styled call to action in the main content section of a website, after some A/B testing or client feedback, there is a decision that the call to action would be better off in the sidebar. Most of the time we start adding some classnames to the card or its parent and change their look based on the media queries. It does the trick, we’ve done it for some while now, but what if we can make all of this a little bit more dynamic, readable and maintainable.

I created a little example to illustrate the mass use of media queries to get to a certain result. I’m pretty sure I could write this example with less code, but if we’re honest, when working with deadlines and project rushing, this isn’t far away from the truth.

I created this article when the container queries were still behind a flag. However. I updated the article on 30 september 2022 to be a bit more up to date with stable releases in Chrome and Safari

How will container queries with CSS help us?

First of all, if you want to view the demo’s provided in this blogpost, you will have to use chrome canary for now, go to chrome://flags and search for Enable CSS Container Queries and enable it.

Container queries are getting a lot of support lately. Check if your browser can handle this new feature.

Rather than relying on the viewport, we will be able to change the behaviour of our component based on the way it’s contained. This basically means that we won’t have to provide extra classes and will be able to style component based, rather than viewport based. In short: CSS container queries will add many benefits to the fluid web.

How does it all work?

First of all we’ll need to specify the container for the parent(s) of our elements. This is done with the container property. The container property is a shorthand for the following:

container-type
Defines an element as a query container. Descendents can query aspects of its sizing, layout, and style.

container-name
Specifies a list of query container names for @container rules to use to filter which query containers are targeted.

container:
A shorthand property to set both container-type and container-name.

The container-type can have the following values:

size
Establishes a query container for dimensional queries on the block and inline axis. Applies layout, style, and size containment to the element.

inline-size
Establishes a query container for dimensional queries on the inline axis of the container. Applies layout, style, and inline-size containment to the element.

normal
The element is not a query container for any dimensional queries on the block and inline axis.

More information on this can be found on the MDN Web Docs.

Basic example of the container property.

Let’s say we want to style a card differently based on the width of its current container. In this example our sidebar is at least 400px wide and we want to style the card in a horizontal grid when it’s bigger than the sidebar’s width. We want to create the following:

So the HTML might look something like this:

<section class="grid container">
  <main class="content">
    <article class="card">
      <img src="https://picsum.photos/800/600?random=1" alt="" />
      <div class="card-body">
        <h2>Some rondom title in here</h2>
        <p class="card-description">
          Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras
          convallis sodales erat vel accumsan.
        </p>
        <a href="">Read more</a>
      </div>
    </article>
    <article class="card">
      <img src="https://picsum.photos/800/600?random=2" alt="" />
      <div class="card-body">
        <h2>Some rondom title in here</h2>
        <p class="card-description">
          Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras
          convallis sodales erat vel accumsan.
        </p>
        <a href="">Read more</a>
      </div>
    </article>
  </main>
  <aside class="sidebar">
    <article class="card">
      <img src="https://picsum.photos/800/600?random=3" alt="" />
      <div class="card-body">
        <h2>Some rondom title in here</h2>
        <p class="card-description">
          Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras
          convallis sodales erat vel accumsan.
        </p>
        <a href="">Read more</a>
      </div>
    </article>
  </aside>
</section>

And then we handle the CSS container query:

/* Basic card styling */
.card {
  margin-bottom: 24px;
  border: 1px solid #444;
  background: rgba(25, 35, 51);
}

.card-body {
  padding: 15px;
}

/* container magic, make cards change look & feel based by their container width instead of the viewport */

.grid > * {
  container: card/inline-size;
}

@container card (min-width: 401px) {
  .card {
    display: grid;
    gap: 15px;
    grid-template-columns: 100px 1fr;
    padding: 15px;
    align-items: center;
  }

  .card-body {
    padding: 0;
  }

  .card-description {
    display: none;
  }
}

All done! I created an example which goes a bit more in-depth:

A few things to note

When this feature was still behind a flag, giving a name to the container was an extra option. After a lot of discussions at the W3C working group it has been made mandatory.

Inline-size vs block-size containment.

In the example above, I used the inline-size because I only needed to change the behaviour based on the container’s width. There has been talk about the possibility to use block-size as well, so that we can change the behaviour based on the height. Unfortunately, this is not yet supported. But the possibilities of this will be amazing. I already created a little template to start working on it as soon as it’s available.

Benefits of “contain” with content provided by a CMS.

When writing and experimenting with new CSS features I always try to imagine real-life problems I had to deal with in the past. And this one is very common and something that others have experienced as well.

The case: When creating a homepage for a client, there might be a “in the picture” section. The client is allowed to add up to three items in the CMS. But from time to time they just want to add one big banner, or maybe two items. When this happens, we mostly rely on counting the items (through PHP or JS maybe?) so that we can add different class names based on the length of an array. Sounds familiar?

By using container queries such as the following we can handle this behaviour perfectly without relying on extra class names by providing a fluid CSS grid in combination with CSS container queries:

<!-- When the CMS gives 2 items as an output (feel free to change the amount of items) -->
<h2 class="subtitle">CMS outputs 2 items</h2>
<section class="container grid-cta">
  <div class="grid-cta-item">
    <article class="card-cta">
      <img src="https://picsum.photos/1600/900?random=1" alt="" />
      <div class="card-body">
        <h2>Call to action nr 1</h2>
        <p class="card-description">
          Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras
          convallis sodales erat vel accumsan.
        </p>
        <a href="">Read more</a>
      </div>
    </article>
  </div>
  <div class="grid-cta-item">
    <article class="card-cta">
      <img src="https://picsum.photos/1600/900?random=2" alt="" />
      <div class="card-body">
        <h2>Call to action nr 2</h2>
        <p class="card-description">
          Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras
          convallis sodales erat vel accumsan.
        </p>
        <a href="">Read more</a>
      </div>
    </article>
  </div>
</section>

/* basic styling of our card */
.card-cta {
  margin-bottom: 24px;
  border: 1px solid #444;
  background: rgba(25, 35, 51);
}

.card-body {
  padding: 1.4rem;
}

/* Setting up our cta grid */
.grid-cta {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(320px, 1fr));
  grid-gap: 1.4rem;
}

.grid-cta-item {
  container: cta/inline-size;
}

/* change style of our cards based on their container width */
@container cta (min-width: 560px) {
  .card-cta {
    display: grid;
    gap: 1.4rem;
    grid-template-columns: 215px 1fr;
    padding: 1.4rem;
  }

  .card-body {
    padding: 0;
  }
}

@container cta (min-width: 700px) {
  .card-cta {
    position: relative;
    display: block;
    padding: 0;
    border: 0;
  }

  .card-cta::after {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    background: rgba(0, 0, 0, 0.2);
    z-index: 1;
    content: "";
  }

  .card-body {
    position: absolute;
    top: 50%;
    left: 50%;
    max-width: 500px;
    text-align: center;
    transform: translate(-50%, -50%);
    z-index: 2;
  }
}

This really shows the strength of the container queries.The end results gives us something like this:

The CMS provides 3 items.

The CMS provides only one item:

Using container queries with polyfills.

Yes, you can start using this awesome feature right now with a polyfill if you need to support older browsers. Personally I would advice using it with PostCSS. I won’t go in-depth on this because it’s very well documented. However I might add a demo of this on github in the near future.

Check out the polyfill for container queries here.

Are container queries performant?

There isn’t a final metric on this. However, there are certain benchmarks on which these new features are tested and as many more browsers are starting the development of it, I’m pretty sure it won’t be a problem.

Further experimentation and reads.

There are many codepens already showing this feature and even I can’t help myself adding a little experiment. Such as this 5-frame animation based on container width (Really, don’t use this kind of thing in your live projects, it’s just me having a bit of fun with CSS).

Want to go more in depth? Here are some reads for you:

Note: I updated the examples on september 30, 2022 with the new specification

Sticky headers: a solution with UX pitfalls?

Brecht De Ruyte — Tue, 19 Oct 2021 00:00:00 GMT

Ask yourself the question: why do we need a sticky header?

This question might sound a bit silly but actually, we don’t ask it enough. We always assume we made the right call by using them because: who can say no to it? “It just works”. And you’re right! It probably does.

If you would look at the essence of the question you might get the following answers:

We want to be able to navigate the whole time
We want to know which part of the website is active at the moment
We want the logo / branding to be visible over the entire website

All of these are fair points, but I could still ask you the same question: do you need a sticky header to achieve this or is it just an easy solution? I’m not calling a “death to the sticky header” in this article, but the idea is to make you think and try to find creative solutions.

It’s important to notice the different media when we talk about sticky headers. We have a different screen size and generally have a different aspect ratio as well. We usually take a mobile first approach but to make my point, let’s start with the big screens.

Desktop sticky headers.

When designing with the desktop in mind, sticky headers are usually not much of a problem. We have enough vertical space for the header, but even in this case, some pitfalls can be found. If you’re a weirdo like me who doesn’t always use his browser full-screen, a sticky header might be a bit too much. There are some factors that come into play here:

What is the height of the sticky header?
How do we decide if there is enough room for a sticky header?
Do we expect the user to rely on the main navigation?

Let’s get the last bullet point out of the way, because this is subjective to the kind of application.**
I see this far too many times:** I’m visiting a webshop, the main navigation consists out of the following:

Home (or a logo click)
Products
FAQ
About us
Contact

Let me say this bluntly: I’m here to buy some stuff and I couldn’t care less about your organisation. The only kind of contact I want is the handover of my ordered goods on my doorstep. I really hope that your homepage doesn’t have the most important information and is rather a collection of items. I’m sure it’s a beautiful homepage with a great intro and a huge banner with your promotions, but I just want to buy this product I found while searching on google.

When it comes to the FAQ, I’m not interested in finding that in the main navigation. If I have a question about delivery or products, I’m probably already browsing a product or even in the checkout process. Why not add a link from one of those pages? Or even better, show the answers right away.
What’s even worse, is that in a lot of cases, the navigation gets removed while I’m checking out: Where did my FAQ-link go? Is this some shady trick to make me follow the process anyway? There might have been some important information there such as: “why doesn’t this ship to my country? Why is the delivery going to take so long?
So maybe the FAQ related to the checkout process should be found on those pages instead of the main navigation where I’ll have to go to an overview and click deeper until I find delivery information. Do not assume your users will just open the FAQ link in a new tab, they probably won’t.

If you have a main navigation that includes your shopping categories, in that case: i’m all for that. But if it’s just random information, let’s fill the screen with some more products, ok?

Maybe the metrics are wrong?

Let’s get a bit more technical and talk about sizes. A lot of sticky headers are just too big and first of all I want to suggest to either keep them small and tidy or at least create a smaller version when scrolling the page. For desktop screens try to keep it around 120px in height.

Another problem we face are those weirdo’s such as myself who like to put their browser windows in a strange aspect ratio. Usually, the metric for keeping a sticky header large or small is based on the viewport width, automatically assuming that a person is browsing at a 16:10 (ish) ratio. A simple solution for that is to also check your header based on the aspect ratio and height, not just the width.

@media (min-aspect-ratio: 16/8) {
  /* A minimum aspect ratio */
}

@media (min-height: 800px) {
  /* A minimum height */
}

Mobile sticky headers.

This is the part where we tend to get a bit lazy. The most common mobile menu on websites looks like this:

Just add the navigation in the sticky header, and done…

So, this is a sticky header with a logo and a hamburger icon to access the navigation. The benefit is that we are now scrolling on a mobile page, so a quick flick of the scroll wheel might not bring us to the top of the page. The sticky header is actually a good practice for this. However, there is something fundamentally wrong in this example.

When it comes to phones, the user is usually holding it with one hand and navigating with his/her thumb. In this case, we might have a hard time reaching the button by using our thumb and we also blocked a bit of space for our content on a device that could benefit from it. It also depends on the phone. For smaller phones, the top right is actually quite accessible, but for those big phones, it might be a bit tougher. Same goes here: Media queries based on height are a possible solution.

A great fix for those ultra large phones would be putting the navigation icon on the bottom of the page and creating a sticky hamburger icon.

There is a great article about this by Scott Hurff. This article is a few years old, but it’s still applicable, maybe even more than when it released with phones getting bigger and bigger.

However, there are a few more challenges that occur here.

1) We want our branding to be visible all the time
This is a hard one for me to tackle. Personally, I know which website I’m visiting while scrolling through the content and I believe that there should be more interesting ways to make your brand pop inside of the page instead of using the logo. It’s not just a UX challenge here, it’s a design challenge. A very interesting challenge if you ask me…

2) We want people to return to an overview when entering on a detail page
Maybe we can do something else: a sticky breadcrumb or a sticky return to overview? It might take less space than a logo.

3) What about tablets?
Interesting question, because users with a tablet usually use their index finger to navigate around. I can see that placing the hamburger in the header might be a better idea there. There is also a lot more height, so it could remain sticky as well.

4) What about left-handed people? Aha, you got me there! Although the majority of people are right handed. When holding the phone with your left hand, it might be harder to reach a navigation button on the bottom right. Still, it’s easier than the top right.

You could put it in the center, but then it might be the worst (or the best?) of both worlds. Which brings me to this crazy idea I had:

Left handed media queries.

We have preferences and media queries for so many things these days. In the settings of your device you might find something called dark mode. We can target this with CSS by using:

@media (prefers-color-scheme: dark) {
  /* Targets user preference dark mode */
}

So we are actually styling our website based on the user preference. That’s great!

With accessibility (finally) getting more attention each day, why not introduce a left handed setting, we already do this when setting up our mouse.

I actually did some research about this and noticed there is already an issue logged on the csswg-drafts.

I think this could be a great addition to CSS so I upvoted it! The suggested syntax is the following:

@media prefers-hand: right {
  .mySuperCTA {
    right: auto;
    left: 0;
  }
}

I agree that this isn’t a setting on mobile devices at the moment, but who knows, maybe we’ll see a marketing campaign soon “The first phone for lefties!”.

My conclusion on sticky headers.

I think there is a lot to think about here. It’s all very subjective and choices have to be made. Always think about your user first and what is beneficial. Do we need the sticky header? Or is it just to show off our logo? Do we want the menu at the top all the time, or do we want to show more content? I’m certainly not saying that sticky headers are a bad thing, they get misused and we probably should think about why we want them before we implement them as an easy solution.

Bootstrap & Tailwind: the current state of popular CSS libraries

Brecht De Ruyte — Sun, 10 Oct 2021 00:00:00 GMT

Bootstrap & Tailwind seem to be all the craze.

Most of the time when using a framework and library, I usually worked with Bootstrap or at least some variant of it. Even after working with a library for many years, I still believe that beautiful code, written from scratch, is more pleasing, exciting and can give your project that extra bit of “oomph” (I’ll get back to that). The second most popular one seems to be Tailwind, which differentiates itself by being more “utility based”.

Both of these libraries seem to have their ups and downs, and most importantly: they learn from each other. Bootstrap is gaining more utility classes and new “tailwind component websites” are fired into webspace every week or so.

But let’s not forget, even though these are popular libraries, it doesn’t mean they are here to stay. A lot of frameworks and libraries seem to fade over time, but because of the popularity of these two, I’m pretty sure we’re good for a while. Material-UI is also one of the bigger ones but it doesn’t seem to get the big “hype” and usage as the other popular ones.

What’s good about CSS libraries in general?

No matter how you look at it, one thing both of these have in common is a decent documentation. If you start a job in a company that uses one of these libraries, you could be a billable developer in no-time. From an economic point of view they are great because they’re easy to learn, fast and let’s be honest, clients really don’t care if you use a library or framework.

These libraries have updates and some of them take too long (yes, I’m talking about Bootstrap 5). But the good thing about it is that many people work on these, whether it’s just giving feedback or active development. They are tested and they work when they get a major release.

Another thing that works their magic are utility classes. I’ll be honest, I love these kinds of things as long as they’re not over-used. They make it easy to show a quick change inside the browser or to make a quick prototype.

As a final thought I’d like to add that many good methods for writing CSS were created for them. Some of the styling ideas they have are just plain clever.

Let’s talk about the bad things.

First of all, when you’re building a website using Bootstrap or Tailwind, you’re not actually writing CSS. Some people don’t have a clue what they’re doing, it just works and they’re happy. Yes, you will mostly add a bit of custom CSS to make the website a bit more unique but that’s still not the same as truly taking matters into your own hands. The libraries do get a bit outdated over time and if you like to use those awesome new CSS features, you’ll have to write them yourself anyway. In the end, you’re getting a bit lazy when using them all the time.

One major issue I had when the first Bootstrap release was that I could see that something was made with that particular library without even inspecting the code. But thankfully that isn’t the case anymore. But from time to time, you still see a lot of websites that make you think: “yep, that’s Bootstrap”.

Libraries include way too much CSS in your project. There are ways to counter that, for example, you could use PurgeCss for production releases. In a world where performance matters, you should see every kb stripped from your files as a win no matter how hard you’re caching.

Bootstrap specific.

Bootstrap has a lot of components and utilities, you are almost certain to never use even half of them. Even when you load the Sass files and start commenting out the component specific imports, it will still be too much. When you’re making use of the built-in components you’re probably making things too complicated as well. A very basic example is the following. Imagine, you just want a simple card with some text in it:

In bootstrap, you might write something like this:

<div class="card">
  <div class="card-body">
    This is a simple card, i don't need a header or footer in it, but when using
    a framework, i'm using way too much css for the simple thing i want to
    create...
  </div>
</div>

Which gives you the following output in your css:

.card {
  position: relative;
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-box-orient: vertical;
  -webkit-box-direction: normal;
  -ms-flex-direction: column;
  flex-direction: column;
  min-width: 0;
  word-wrap: break-word;
  background-color: #fff;
  background-clip: border-box;
  border: 1px solid rgba(0, 0, 0, 0.125);
  border-radius: 0.25rem;
}

.card-body {
  -webkit-box-flex: 1;
  -ms-flex: 1 1 auto;
  flex: 1 1 auto;
  padding: 1.25rem;
}

This is a lot of CSS for such a little bit of layout. Of course it is handy when you want to add a header later on, or an image, or a footer. It has a multi-purpose. But if you just need something like the example above. you can just write the following and it will save you a lot of output:

<div class="card">
  This is a simple card, i don't need a header or footer in it, but when using a
  framework, i'm using way too much css for the simple thing i want to create...
</div>

.card {
  padding: 1.25rem;
  background-color: #fff;
  background-clip: border-box;
  border: 1px solid rgba(0, 0, 0, 0.125);
  border-radius: 0.25rem;
}

You might be thinking that this doesn’t change all that much. Well, this little difference just removed 372 bytes from your CSS file-size (unminified for both). Not bad for a simple card, imagine how much more you could save.

Tailwind specific.

Tailwind is utility-based and personally, I like the idea of it. The problem is that many people just write HTML with so many utility class names that it becomes unreadable and hard to maintain. Tailwind suggests that if you have something repeatable that you write it in CSS instead but a lot of people seem to ignore that. Here is an example of a bad situation:

<button
  class="h-12 px-6 m-2 text-lg text-indigo-100 transition-colors duration-150 bg-indigo-700 rounded-lg focus:shadow-outline hover:bg-indigo-800"
>
  Large
</button>

Seriously, this is just an overkill. Just write a general “.btn” class for your buttons so you can maintain them well in the future.

The future of CSS.

Let’s not forget that CSS specs are updated all the time. Frameworks and libraries have given us a lot to work with. Now, we can use variables in CSS, easy grids with the grid system, nesting CSS is starting to become a thing as is layering. It’s becoming such a strong language that can even handle masonry layouts while in the past we had to use JavaScript. We have so much to choose from, we can make a battle plan for every type of layout we want to tackle and talk about our choices in a beautiful discussion. It’s great, you can’t do that when working with a library.

There are so many things we can do now that aren’t available in the libraries. We have to make a fallback from time to time, but maybe we should ask the question: Is it better to “hack a library”, or to add a fallback and be future proof?

So, am I saying CSS frameworks and libraries are bad?

When comparing this, I always picture a colouring book versus a sketch book. When working with a library, you’re actually just colouring a predefined drawing and maybe adding a little picture of a flower in it. While working from scratch, you’re making little pieces of art in your sketchbook, let’s call it, “working from sketch” from now on?

I believe in libraries… As a corporate developer for many years, I know they work their magic. They can set up a project in no-time. Budgets get a bit lower because we’re colouring between the lines and you get told you did a great job using someone else’s code. We can be faster when using them and browser issues are less bound to happen. In the end, when working for a company, money and time are the big factors. When you’re from Belgium, you learn that good front-end development is a hard sell. It’s a shame but a simple truth.

Even working on side projects makes me want to use a library from time to time. I have a kid, hobbies and friends. Choices in time have to be made for all of us.

The biggest problem is that they provide too much comfort. Remember when you started out using CSS and how happy you were that something magically worked? You just knew you did something special and you loved it! You would go home with a smile on your face. Those feelings are much harder to find when you’re just using the library.

So, use your libraries within your favourite framework but remember to try something different from time to time. Whether it’s a little codepen or a little project on the side. Because between all these libraries, frameworks and pre-defined sets there is a little thing that made us want to do this for a living, and it’s called CSS.

Masonry with CSS Grid, finally a solution without JavaScript

Brecht De Ruyte — Tue, 28 Sep 2021 00:00:00 GMT

Attention: This article, dated 2021, presents information from its experimental phase. The masonry feature has garnered increased attention of late. I intend to produce a fresh article once the trajectory of this CSS feature becomes definitive. My aim is to ensure readers avoid outdated information. In May 2023, consider the following articles for updated insights:

For now, this article is kept the same as originated for historic reasons:

Recently, I read this article by Rachel Andrew. When I see that Rachel posts something about new CSS features, I tend to bookmark the article so I can read it later with my full attention. If you haven’t heard of her, I strongly encourage you to do some research as she is one of the best speakers when it comes to everything HTML and CSS.

I’m not going to copy / paste her article on my blog. But when reading it, I couldn’t wait to try out the CSS Grid Masonry feature. Here are some of the things I tried and some thoughts that came to mind. I encourage you to read her article nevertheless.

Masonry, is that still a thing?

The term “Masonry” probably came from the o-so-popular jQuery plugin that I worked with in the early days. It has come a long way since then with native JS support and a lot of alternative libraries to choose from. I’m truly happy that they chose the name “Masonry” for this CSS based version as well. The name has become something so defining that we use it to describe this type of layout, no matter which library is used.

Let’s be honest here. Although the Masonry layout with CSS is an amazing feature, it comes a little too late. The huge hype isn’t what it used to be anymore, a lot of designers have the “it’s been done” feeling when designing a grid.

But who knows, there are a lot of things that come back like 80’s music had a revival in the 2000’s, so I’m sure that we might get a Masonry revival if we don’t need to load a big JavaScript library for it. And really, it’s easy.

Support for Masonry in CSS-only.

For now, we’ll have to try it out with Firefox nightly with the layout.css.grid-template-masonry-value.enabled flag enabled. To find out if it’s enabled go to about:config in the browser. All installed? Flag enabled? Ok, let’s go and see how to achieve this.

How to get a Masonry grid in CSS?

Let’s add some basic HTML for our grid.

<section class="grid">
  <main class="text-box">
    <h2>Just a test with firefox nightly</h2>
    <p>
      Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras convallis
      sodales erat vel accumsan.
    </p>
  </main>
  <figure>
    <img src="https://unsplash.it/800/600/" alt="" />
  </figure>
  <figure><img src="https://unsplash.it/800/600/" alt"" /></figure>
  <figure>
    <img src="https://unsplash.it/900/600" alt="" />
  </figure>
  <figure>
    <img src="https://unsplash.it/800/600/" alt="" />
  </figure>
  <figure><img src="https://unsplash.it/800/600/" alt"" /></figure>
  <figure>
    <img src="https://unsplash.it/900/600" alt="" />
  </figure>
</section>

Now let’s add the CSS.

.grid {
  display: grid;
  gap: 5px;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: masonry;
}

figure {
  margin: 0;
  display: block;
  line-height: 1;
}

figure > img {
  display: block;
  max-width: 100%;
}

There it is, a 3 column CSS Masonry grid, now isn’t that easy? :)

Playing around with CSS Grid order.

One of the things that always was a hassle when using the Masonry JavaScript was changing the order based on a viewport. So naturally, this was one of the first things I wanted to try out. I added a bit of text at the start of my grid to have it at the top of my screen when watching on mobile. However, when viewing it on a large viewport, I wanted the text to sit nicely in the middle. So I tried the following:

figure:first-of-type {
  order: 1;
}

.text-box {
  order: 2;
}

figure {
  order: 3;
}

It worked as expected and I love it!

Adding some grid-column spans.

This is where it got a bit more tricky. I wanted to highlight some images by making them 2/3th of the size inside the grid. Doing that works like a charm but for some reason I wanted the grid to nicely close the items together and make it so that the masonry always gets a good fit. Of course this might be taking things too far.

I created a lot of gaps this way

Just an idea to make the items fit.

Maybe we could have a property that makes it so that the order isn’t necessarily respected, but it respects the gutter instead. I know this might be taking things a little too far, but imagine how cool it would be if we could do something like this:

.grid {
  grid-template-rows: masonry-fit;
}

It’s nice to make the grid work with every type of content.

As sort of a final little test, I wanted to try it out with different cards, sort of like a news overview and add different sizes of images. We all have been there… Getting content by a third-party API where you have no control whatsoever.

Using it now with a fallback (@supports).

You can actually use it right now in any browser if you add a decent fallback. It’s a little bit of a hassle but it will pay off when more browsers start to support it. I might update my own photography pages as well to have decent support with fallback later on.

You can test support by putting this in your CSS or JavaScript with the following:

    @supports (grid-template-rows: masonry) {
    	/* Masonry content here */
    }


    const supportGrid = CSS.supports("grid-template-rows", "masonry");

    if (!supportGrid) {
    	//add the js fallback here
    }

I added a small example of this on my codepen, I loaded Masonry with jQuery and only initialised it when CSS Masonry is not supported. Would be even better if you didn’t include the libraries in that case. You can optimise this a lot better.

Conclusion and concerns.

Just as Rachel describes in her article: Masonry is a great tool to visualise content but it should be handled with care, especially when it comes to accessibility and screen readers. When we start changing orders, things might get messy so tread carefully. That aside, I think this type of layout is still beautiful for photography / design portfolios. It might not be the best choice for news overviews, but that’s up to you.

Another concern I have is browser differences when it starts to roll out and partial support. Even though websites do not need to look exactly the same in every browser, it’s still hard to explain to a client why image A is in another location (yes, I’m looking at you Safari…).

I think this feature might bring a revival of the Masonry layouts, I can only hope they get implemented with correct accessibility and don’t get over-used. Because in the end: there is nothing wrong with a basic beautiful grid.

I haven’t found any issues with the implementation so far, but if I find any…

If you run into problems or can’t do something you were able to do in your previous implementation, please let the CSSWG know by raising an issue.

Another one enters the webspace!

Brecht De Ruyte — Thu, 16 Sep 2021 00:00:00 GMT

Who are you, what do you do?

My name is Brecht, I’m a front-end developer living in Belgium with a wide interest in the “internet of things”. At the moment I work for an international company: iO.

So why did you start this blog?

Many reasons! The most important one is sharing some of the things I learn along the way. I love to explore outside of the typical “front-end world” and touch topics such as UX, marketing, work methods and many more.

Don’t get me wrong though, it will mostly be front-end related. But don’t judge me if I write something about other program languages or an awesome new game I tried along the way.

Why write in English even though you’re not a native speaker?

There are two main reasons for this:

A bigger audience.
As practice, because languages get rusty over time.

So, I might make a (few) mistake(s) from time to time. But practice makes perfect. I’m a strong believer of that.

What will you do differently than thousands of other blogs?

Honestly, not much. I’m a pretty normal guy. One thing that I might do differently is the subject of developer happiness. We live in a world, where everything is rushed, clients expect more and they want it fast. How can we stay sane in a fast world, combined with studying new technologies, staying healthy, bringing your kid to school and finding some “me-time” in the middle of it.

You mention a kid, do you have kids?

I have a wonderful healthy 2-year-old daughter who I love unconditionally. Her name is Eva and her favourite words at the moment are: “Watch Frozen!”, “I’ll do it!” and “no!”. She can be a handful at times, but all the laughs and giggles make up for that in no-time. She’s the joy of my life, as is her mother, my wife Renée.

What do you want to achieve with your blog?

If I could help out a handful of people, I would be more than happy. I’m not using some crazy marketing strategy for this, nor am I planning to put my pages full of ads. The only tracking tool is my analytics. You might notice that I didn’t add a comment section. It’s not because I don’t want to interact, but there are other channels where people can contact me. Please do, happy to help or maybe start a little brainstorm or healthy discussion.

Any special hobbies?

Absolutely, I’m a strong believer in a good work-life balance. My main hobbies are card- and board games, nature photography and I play a bit of guitar as well. I added some pages with photography on my website if you want to view them. When I’m alone in a beautiful landscape, time seems to stop for a moment, it’s great therapy after a busy week. The images aren’t the main thing of this website and I’m not a “professional photographer”, but they’re a part of my identity so they deserved a place here.

And the final question, why the name “utilitybend”?

When I post something on the web, I usually take on another name. The main reason is that my name is typical Flemish and it’s hard for people to pronounce or remember.

The name utilitybend was just an idea that grew over time. When I started as a front-end developer, people referred to my job as “pixel bending”. These days, we aren’t really using pixels for everything, however, we are using more utility classnames in HTML/CSS than ever before. So I guess a lot of us are bending utilities now.

As a final word, I do hope my future articles can help you out a bit. Cheers!

utilitybend

Putting my money where my mouth is: a redesign built on progressive enhancement

It started with typography

From SCSS to plain CSS, and organizing the project

Corner-shape: squircles and scoops

View transitions: direction-aware navigation

The orbs: @property meets scroll-driven animations

Navigation: :has() and anchor positioning

Scroll-state queries, the progress bar, and CSS carousels

The header

The article progress bar

CSS carousels with scroll markers and scroll buttons

The table of contents

The photography corner

Same HTML, different paint job

Slowly moving to container queries

Other things

Wrapping up

CSS Animation Triggers: Playing animations on scroll without scrubbing. It's a match!

The difference between scroll-driven and scroll-triggered

Creating a first scroll-trigger

Step 1: Define the trigger on the trigger element

Step 2: Connect the animation to the trigger

Enter and exit ranges: controlling the timing

Animation actions when using triggers

Going in-depth with the scroll-trigger + scroll-driven Valentine demo

The basic setup, fixed stuff + scroll trigger + driven

Two animation systems, combined!

Scaling up: making it DRY

The attr() one-liner

Reusable keyframes with CSS variables

Centralizing your “scroll choreography”

Debugging: visualizing your triggers

Browser support

Conclusion

Is it scrolled? Is it not? Let's find out with CSS @container scroll-state() queries

A Quick Recap: How Do Scroll-State Queries Work?

The power trio: stuck, snapped, and scrollable

Is it stuck?

Is it snapped?

Is it scrollable?

The new kid: @container scroll-state(scrolled) arrives in Chrome 144!

The Future is State-ful

Further reading

An update on customizable selects: the multiple select

The multiple select

But more is changing than just looks,…

Mouse navigation

Keyboard navigation

The ability to style the customizable select

Why this could be a win for accessibility

The size attribute on a multiple select element

Future ideas with selectedcontent?

Conclusion

CSS corner-shape, books, talks, and happy holidays

Conferencing

Reading

Struggles

Other Good things

So, next year?

CSS holidays card and corner-shape

State, Logic, And Native Power: CSS Wrapped 2025

Why Tailwind is great, why you might be missing out, and why it isn't for me

Clearer vs easier?

But! Welcome to the age of AI

Naming conventions, Debugging & copy pasta

You are missing out, but maybe that’s ok

It isn’t for me, and that’s ok as well

So, should you Tailwind or not

5 CSS debugging features I want to see in Chrome DevTools - Holidays list

1. More positioning debugging.

Anchoring

General positioning

2. Hide overruled styles with a simple toggle

3. Guides, rulers, and more quick looks on my webpage

4. Sticky panels

5. Scroll-stuff animations panel

Bonus: Fast features and a clear focus shift towards AI

A native way of having more than one thumb on a range slider in HTML

The proposal: <rangegroup>

The proposal: `<rangegroup>`