Every few years, CSS quietly absorbs something we used to need a JavaScript library for. This year, three big ones are landing at once: masonry layouts, scroll-driven animations, and styleable <select> elements. All three have a long history of clunky workarounds (Masonry.js, scroll event listeners, div-based fake dropdowns) and watching them become native CSS features is genuinely surprising progress for a single year.
Here’s what each one does.
\nPinterest-style grids, where items of varying heights pack together without awkward vertical gaps, used to require Masonry.js or one of its cousins. Those libraries measure every element, calculate positions, and use absolute positioning to slot things in. The result works but is expensive, fragile on resize, and hard to make truly responsive.
\nThe native version is display: grid-lanes:
.masonry-grid {\n display: grid-lanes;\n grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));\n gap: 16px;\n}\nSet up your columns the way you would for any responsive grid, switch the display value to grid-lanes, and the browser handles packing. There’s also a flow-tolerance property that controls how aggressively items can shift to fill gaps.
The naming has a history. The CSS Working Group debated for years between an earlier grid-template-rows: masonry proposal (which would have layered onto existing Grid) and a separate display: masonry value. The resolution, in early 2026, was a third option: a new grid-lanes display value that’s distinct from Grid but borrows its column/row sizing. So if you read older articles showing grid-template-rows: masonry, that syntax did not ship.
Safari was first to ship grid-lanes (Safari 26). Chrome and Firefox have it behind experimental flags as of early 2026.
Reading progress bars, fade-ins as elements enter the viewport, parallax effects. All of these used to require listening to the window’s scroll event and updating styles in JavaScript. Scroll events fire dozens of times per second, and if your main thread is busy doing literally anything else, the animation stutters. It’s the most common source of jank on the modern web.
animation-timeline: scroll() ties a standard CSS keyframe animation to scroll position instead of a time duration. The browser runs it on the compositor thread, completely independent of your JavaScript. Buttery smooth, even when the main thread is on fire.
Here’s a reading progress bar in pure CSS:
\n@keyframes grow-progress {\n from { transform: scaleX(0); }\n to { transform: scaleX(1); }\n}\n\n.progress-bar {\n position: fixed;\n top: 0;\n left: 0;\n width: 100%;\n height: 8px;\n background: linear-gradient(to right, #ff416c, #ff4b2b);\n transform-origin: 0 50%;\n animation: grow-progress linear;\n animation-timeline: scroll(root block);\n}\nNo event listeners. No requestAnimationFrame. No throttling logic. The animation is just bound to scroll position and the browser figures out the rest.
<select>This is the one with the longest backstory. The native <select> element is rendered by the operating system, which means whatever the OS decides to give you is what you get. The dropdown picker, option styling, hover states inside the list, none of it has been styleable from CSS.
The workaround was div-based fake dropdowns built with JavaScript. Most of them broke keyboard navigation, screen reader support, or both. Accessibility regression in exchange for visual polish, every time.
appearance: base-select opts you out of the OS-rendered version and into a fully styleable structure with new pseudo-elements for the popup. To opt the popup itself in, you also apply appearance: base-select to ::picker(select):
.custom-dropdown {\n appearance: base-select;\n padding: 10px;\n border-radius: 8px;\n border: 1px solid #ccc;\n}\n\n.custom-dropdown::picker(select) {\n appearance: base-select;\n background-color: #1e1e1e;\n border-radius: 12px;\n box-shadow: 0 4px 12px rgba(0,0,0,0.2);\n padding: 8px;\n}\n\n.custom-dropdown option:hover {\n background-color: #333;\n cursor: pointer;\n}\nThe ::picker(select) pseudo-element is the headline feature. The popup container is the thing every custom dropdown library was reinventing from scratch, and now it’s a styleable part of a real <select>, so native keyboard and accessibility behavior comes along for free.
Browser support is Chromium-only as of early 2026 (Chrome, Edge, Opera 135+). Firefox and Safari haven’t shipped it yet.
\nSupport varies by feature. Scroll-driven animations are the most settled, with stable support in Chrome and Safari and a flag-gated implementation in Firefox. display: grid-lanes shipped first in Safari 26 and is behind flags in Chrome and Firefox. appearance: base-select is Chromium-only, with no Firefox or Safari implementation yet. For all three, a @supports block with a sane fallback is the right pattern. Check caniuse.com before you ship.
But the direction is clear. Three of the most common reasons we used to pull in JavaScript are becoming native CSS features. Better performance, less code, and accessibility you don’t have to rebuild from scratch.
\nI’ll take that trade.
\n<select> element can now be customized with CSS — Chrome for Developers\n\n", "date_published": "2026-05-12T10:00:00-05:00", "url": "https://llbbl.blog/2026/05/12/three-css-features-that-finally.html", "tags": ["Web development","Css","Front-end"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n