/
Published on 28.01.2026
TLDR: CSS Grid Lanes (masonry layouts in CSS) is landing across browsers faster than expected. Safari Technology Preview has the finalized syntax, and Chrome, Edge, and Firefox are all making significant progress. You can start using it now with progressive enhancement.
Summary:
The WebKit team has published an excellent guide on when CSS Grid Lanes will arrive and how to use it today through progressive enhancement. The finalized syntax is available in Safari Technology Preview, and all major browser engines are making progress on their implementations.
The history is interesting: Firefox's team wrote the original CSS Working Group Editor's Draft back in 2019-2020, and it shipped in Firefox Nightly in early 2020. Safari's WebKit team picked up the pace in 2022, and Chrome/Edge landed their implementation behind a flag in July 2025. With key syntax decisions now finalized, we're closer than ever to widespread support.
But the real value of this article is the three approaches for progressive enhancement right now. Option 1: use a JavaScript library like Masonry.js as a polyfill, conditionally loading it only when Grid Lanes isn't supported. Option 2: don't use Grid Lanes yet — CSS Multicolumn might solve your use case today. Option 3: use Grid Lanes with a CSS fallback, relying on the fact that browsers ignore CSS they don't understand.
The third option is particularly elegant. You can declare display: grid followed by display: grid-lanes, and browsers without support will simply ignore the second declaration. Use feature queries (@supports not (display: grid-lanes)) to provide fallback styling like forcing images to the same aspect ratio with object-fit: cover.
For teams and architects, this is a masterclass in progressive enhancement thinking. You don't have to wait years for full browser support — you can structure your code today so that it automatically improves as browsers catch up, with zero additional work required from your team.
Key takeaways:
Link: When will CSS Grid Lanes arrive? How long until we can use it?
TLDR: The HTML Invoker Commands API has achieved baseline support across all major browsers, allowing declarative button controls for popovers and dialogs without JavaScript. Safari 26.2 completed the rollout following Chrome 135 and Firefox 144.
Summary:
This is significant news for the "use the platform" crowd. HTML Invoker Commands have reached baseline support in all major browsers, meaning you can now create interactive popovers and dialogs using just HTML attributes — no JavaScript event listeners required.
The API adds two attributes to button elements: commandfor (which takes the ID of the element to control) and command (which specifies the action). Built-in commands include toggle-popover, show-popover, hide-popover, show-modal, close, and request-close.
Here's the beautiful simplicity of it:
<button commandfor="mypopover" command="toggle-popover">Toggle</button>
<div id="mypopover" popover>Popover content</div>
No JavaScript. No event listeners. The browser handles it declaratively.
The API also supports custom commands prefixed with double dashes (like --change-bg), which fire a command event you can listen for. This allows component authors to create declarative APIs for their web components without requiring consumers to write JavaScript.
The rule of least power on the web has always encouraged using HTML before CSS, and CSS before JavaScript. Every time we can shift implementation upstream in the stack, we reduce complexity, improve accessibility, and make the web more robust. This is that principle in action.
Key takeaways:
commandfor and command attributesLink: HTML Invoker Commands Achieve Baseline Support across All Major Browsers
TLDR: A comprehensive deep-dive into CSS layout fundamentals — from normal flow to positioning to Flex and Grid — explaining the mental models that make CSS predictable rather than mysterious.
Summary:
Kilian Valkhof from Polypane has published what might be the definitive guide to understanding CSS layout fundamentals. The premise is simple but important: CSS syntax is simple compared to JavaScript, which leads people to assume they can learn CSS just by knowing properties and values. That's not true.
The article builds from first principles. Everything in CSS is a box. Normal flow is the default layout algorithm where block elements stack vertically and inline elements flow horizontally. Anonymous boxes get created for text outside of elements. Margins collapse vertically. All inline elements sit on the baseline.
The box model section clarifies the content-box vs border-box distinction and why every modern CSS reset includes box-sizing: border-box. The margin behavior section explains margin collapse — including the often-confusing parent-child margin collapse — and how to prevent it with overflow: auto or display: flow-root.
Positioning schemes get thorough coverage: relative keeps elements in flow but allows offset, absolute takes elements out of flow and positions them against the offset parent, fixed positions against the viewport, and sticky is the hybrid that gets stuck during scroll.
The stacking context section is particularly valuable. The "folder" analogy is perfect: once an element is inside a stacking context folder, its z-index only matters within that folder. A z-index of 9999 inside a folder with z-index 1 will still appear below an element in a folder with z-index 2.
For architects and teams, this is essential reading for anyone who finds CSS layout unpredictable. The concepts aren't complex individually — they're just rarely taught systematically.
Key takeaways:
Link: Understanding the fundamentals of CSS Layout
TLDR: Chrome Canary now supports a new <meta name="text-scale"> tag that respects the user's OS-level text size preference on mobile devices — a feature 34-37% of mobile users have changed from default.
Summary:
Josh Tumath has been working on something important: making the web respect mobile users' text size preferences. Research shows around 37% of Android users and 34% of iOS users have changed their system-level text scale from the default. On the web? That setting has no effect.
The new <meta name="text-scale" content="scale"> tag tells the browser that your website is designed to work when users increase their OS text size. Once you add it, text will respect the user's preference.
But why opt-in? Because enabling this everywhere would break most websites. Just like the viewport meta tag was necessary when smartphones arrived, this tag signals that you've tested and designed for text scaling.
The three practical tips are valuable: (1) Don't override the initial font size — if you set font-size: 16px on :root, the text-scale meta tag has no effect. (2) Only use font-relative units for content, not for margins, padding, or gaps — this gives more room for content on mobile. (3) Test at 320px viewport width with 200% text scale to see problem areas.
For teams, this is an accessibility feature hiding in plain sight. The relevant WCAG guidelines (1.4.4 Resize Text and 1.4.10 Reflow) already require 200% text scaling support. This just makes it easier for users to access it.
Key takeaways:
<meta name="text-scale" content="scale"> enables the featureLink: Try text scaling support in Chrome Canary
TLDR: Modern CSS now handles complex interactions that previously required JavaScript — customizable <select> elements, scroll-triggered animations, and data-driven styling are all becoming possible with pure CSS.
Summary:
This LogRocket article showcases the genuinely exciting direction CSS is heading. The headline demo is a fully customizable <select> element with staggered animations and data-driven colors — all without JavaScript.
The key features demonstrated: appearance: base-select opts a select into customizable mode while preserving native accessibility. The ::picker(select) pseudo-element lets you style the dropdown surface. Tree counting functions like sibling-index() enable staggered animations without hard-coding delays. The typed attr() function reads data attributes as actual CSS values.
The comparison is striking: the CSS-only version handles all the complexity that previously required 150+ lines of JavaScript for keyboard navigation, focus management, positioning, and overflow handling. The browser does it automatically.
Other features landing in CSS: ::scroll-button() for generated scroll buttons, ::scroll-marker for pagination dots, :target-current for matching scroll-active elements, and container queries for scroll state.
For teams considering this, the progressive enhancement story is good — browsers that don't support customizable selects just render the native select. But these features aren't production-ready yet; they're rolling out across browsers. The advice is to revise one JavaScript-heavy UI component (carousels, tooltips, dropdowns) to see where these features can simplify your code.
Key takeaways:
appearance: base-select enables customizable native selectssibling-index() enables dynamic staggered animationsattr() reads data attributes as colors, lengths, etc.Tradeoffs:
Link: CSS in 2026: The new features reshaping frontend development
TLDR: A detailed guide to using mobile device motion sensors (DeviceMotion and DeviceOrientation APIs) to create interactive animations that respond to physical device movement — bringing desktop hover effects to mobile.
Summary:
This Frontend Masters article tackles a real problem: we build beautiful mouse-tracking effects for desktop, but on mobile they just... disappear. The solution is using the accelerometers and motion sensors already in users' pockets.
The technical implementation is thorough. First, detect the environment by checking for both motion support and touch capabilities — some laptops have accelerometers, so you need both. Second, handle permissions — iOS requires explicit consent triggered by user gesture, while Android often provides data immediately.
The DeviceMotion API provides rotationRate (alpha, beta, gamma for tilt/flip/turn) and acceleration (x, y, z for movement). Map these to CSS custom properties and you get responsive 3D effects. The article shows how to apply both rotation and translation to create truly immersive experiences.
There's an important distinction between DeviceMotion and DeviceOrientation. Motion tracks change — when you stop moving, the effect returns to neutral. Orientation tracks absolute position — like the mouse, it stays tilted when you hold the phone still. The article explains when each approach makes sense.
For teams building rich interactions, this opens up mobile experiences that were previously impossible. The key insight is that these sensors have been in every smartphone for years — we've just been ignoring them.
Key takeaways:
Link: Beyond the Mouse: Animating with Mobile Accelerometers
TLDR: The long-standing accessibility advice to trap focus within modals is now deprecated when using the native <dialog> element's showModal() method. Users can tab to the address bar, and that's intentional.
Summary:
This CSS-Tricks article surfaces an important update to accessibility best practices. If you're using the native <dialog> element with showModal(), you don't need to trap focus — and attempting to do so would be incorrect.
The historical context from Scott O'Hara explains why: WCAG never normatively required focus trapping. The advice came from informative documentation written before inert or <dialog> were available. The APG examples trapped focus because it was easier than managing tabindex on every element outside the dialog.
Léonie Watson explains the user experience rationale: in a page context, users can tab to the address bar, open menus, or close tabs. It's logical for the same options to be available in a dialog context. The W3C's Accessible Platform Architectures Working Group confirmed this: keyboard users should be able to open new tabs to look something up or change browser settings.
For teams, this is a meaningful simplification. If you're properly using showModal(), the browser handles inert state for background content. You don't need focus trapping libraries or custom keyboard handling. The native element just works.
Key takeaways:
showModal() makes background content inert automatically<dialog> supportLink: There is No Need to Trap Focus on a Dialog Element
TLDR: A comprehensive guide to understanding and debugging CSS stacking contexts — the "folders" that determine which elements appear on top of others, regardless of z-index values.
Summary:
This Smashing Magazine article provides the mental model that finally makes z-index predictable. The key insight: stacking contexts are like folders on a desk. When the browser decides what goes on top, it stacks folders first, not the individual papers inside them.
Once an element is inside a stacking context folder, it can never escape. A z-index of 9999 inside a folder with z-index 1 will still appear below an element in a folder with z-index 2. The browser calculates (1, 9999) as less than 2. This is "The Golden Rule" that many developers miss.
The article walks through three common scenarios: the trapped modal (modal in a header with low z-index), the submerged dropdown (navbar with lower z-index than main content), and the clipped tooltip (overflow: hidden blocking z-index escape).
The debugging checklist is practical: inspect the problem element, verify its z-index, climb the DOM tree checking each parent's styles, hunt for properties that create stacking contexts (position with z-index, opacity, transform, filter, contain, isolation).
Solutions vary by scenario: restructure HTML to move elements outside the trap, increase the parent's z-index to lift the whole folder, or use Portals in React/Vue to render outside the DOM hierarchy entirely. For intentional stacking contexts, isolation: isolate is the cleanest option with no side effects.
Key takeaways:
isolation: isolate creates stacking context without side effectsLink: Unstacking CSS Stacking Contexts
TLDR: The ultimate minimal favicon set is just five files: favicon.ico (32x32), icon.svg with dark mode support, apple-touch-icon.png (180x180), and two PWA icons (192x192, 512x512). Stop the 20+ PNG madness.
Summary:
This updated Evil Martians guide cuts through the favicon generator complexity. Instead of 20+ static PNG files, you need five icons and one JSON file.
The essentials: favicon.ico at 32x32 for legacy browsers (some tools just request /favicon.ico and don't look elsewhere). A single SVG icon with @media (prefers-color-scheme: dark) for light/dark theme support — this is clever since SVG can contain CSS media queries. An apple-touch-icon.png at 180x180 for iOS home screen shortcuts (other devices downscale fine).
For PWAs, add a manifest with 192x192 for home screen, 512x512 for splash screen, and a 512x512 maskable icon with bigger padding (safe zone is a 409×409 circle — check at maskable.app).
The article debunks obsolete formats: Windows Tile Icon isn't needed for modern Windows, Safari Pinned Icon isn't needed since Safari 12, rel="shortcut" was never valid, and Opera Coast left the App Store in 2017.
The step-by-step build process is thorough: prepare SVG with dark mode styles, create ICO in GIMP or via ImageMagick, create PNG exports at each size, optimize with SVGO and Squoosh, add HTML links with proper sizes attribute (use sizes="32x32" to fix Chrome SVG/ICO bug), and create the web manifest.
The bonus tip about different favicons for staging vs production is genuinely useful — invert colors for dev so you never confuse environments.
Key takeaways:
sizes="32x32" on ICO link to fix Chrome bugLink: How to Favicon in 2026: Three files that fit most needs
TLDR: Documenso releases LibPDF, a modern TypeScript PDF library with lenient parsing, incremental saves (preserving existing signatures), and native digital signatures — finally deleting their Rust signing library.
Summary:
Documenso has released what they needed to build for their document signing platform: a PDF library that actually works on real-world documents.
The problem with existing options: pdf.js is excellent for rendering but requires a browser for editing features. pdf-lib has a beautiful API but hits edge cases at scale — quirky headers, malformed xref tables. pdfkit is generation only. None could handle the full lifecycle of parse, fill, sign, save while preserving existing signatures.
LibPDF's differentiators: Lenient parsing borrowed from pdf.js and PDFBox that falls back to brute-force recovery when standard parsing fails. Incremental saves that append changes instead of rewriting, keeping previous signatures valid. Native digital signatures with PAdES B-B through B-LTA support, including timestamps, OCSP responses, and CRLs. Complete encryption support (RC4, AES-128, AES-256).
The signing story is compelling. They maintained a separate Rust codebase with N-API bindings just for PDF signatures. Platform-specific binaries, CI pipeline complications, Node.js version gambles. Now it's just TypeScript — one dependency, one language, runs in Node.js, Bun, and browser.
The library acknowledges its foundations: pdf-lib's API design, pdf.js's battle-tested parsing, and Apache PDFBox's implementation details. The font subsystem is actually a TypeScript port of PDFBox's fontbox under Apache 2.0.
For teams building document workflows, this is worth evaluating. It's in beta but running in Documenso's production.
Key takeaways:
Link: Introducing LibPDF: The PDF Library TypeScript Deserves
TLDR: ReliCSS scans CSS for historical browser hacks — clearfix, doubled float margin bug fixes, vendor prefixes — helping you audit legacy codebases and understand why old code exists before removing it.
Summary:
Stuart Robson has built a tool for "Front-End Archaeology" — the practice of excavating years of decisions, technological limitations, and creative workarounds from legacy codebases.
When you encounter a clearfix hack, you're looking at a time when layout engines couldn't contain floated elements. A "doubled float margin bug" fix is a scar from Internet Explorer 6. Every vendor prefix tells a story of a developer fighting against browser constraints to ship a working product.
ReliCSS parses CSS and identifies these historical artifacts, showing browser targets, context, and modernization suggestions. It assigns severity levels: High for true fossils targeting unsupported browsers (IE6/7), Medium for older unsupported browsers (IE8-10), and Low for modern artifacts like vendor prefixes that should be handled by Autoprefixer.
Importantly, it runs entirely in the browser — no code gets sent to servers. Contractors and consultants working with sensitive client code can safely paste CSS.
For teams inheriting legacy codebases, this turns the daunting task of refactoring old CSS into a learning experience. Instead of blindly deleting what you don't understand, you can see why it existed and make informed decisions about what to keep, refactor, or remove.
Key takeaways:
Link: Introducing ReliCSS: A Tool for Front-End Archaeology
TLDR: A practical guide to embedding Bluesky replies as a comment section on a static site — letting Bluesky handle account verification, hosting, storage, spam, and moderation while you display the conversation.
Summary:
Micah Cantor has implemented something many static site owners want: a comment section that doesn't require maintaining a dynamic web service.
The approach is elegant: Bluesky handles all the difficult work of social media — account verification, hosting, storage, spam, moderation. Meanwhile, because Bluesky is an open platform built on AT Protocol, you can fetch and display replies directly on your site.
The implementation uses the Bluesky TypeScript SDK with the getPostThread endpoint. Each blog post's metadata includes a bskyPostId that references the corresponding Bluesky post. When the page loads, fetch the replies, parse the content, and display in a simple comment section UI.
The author considered adding OAuth to let users post directly from the site but abandoned it — building a good posting UI leads to essentially building a custom Bluesky client, and the auth flow isn't much easier than just posting on Bluesky directly.
Why Bluesky over alternatives? It's built on AT Proto, an open protocol that can't easily be captured by hostile actors. It's a full social platform, making it better for conversations than GitHub Discussions. And it's not the platform formerly known as Twitter.
For teams with static sites wanting engagement, this is a practical pattern. The entire implementation is ~200 lines between UI components and API functions.
Key takeaways:
getPostThread endpoint to fetch repliesbskyPostId in post metadata to link articles to Bluesky postsLink: I added a Bluesky comment section to my blog
This article was generated from a newsletter summary. The content reflects the source material's perspective and may not represent complete analysis of all aspects of the topic.