Stop Rushing to Single-Column Layouts: CSS Anchor Positioning, Shrinkwrap Solutions, and the New Geolocation Element
Published on 04.02.2026
The Too Early Breakpoint
TLDR: Switching to single-column mobile layouts too early wastes screen real estate and signals poor attention to responsive design details. There are often intermediate layout states that work better than jumping straight to the smallest design.
You know that moment when you resize your browser just a bit, and suddenly the entire page collapses into a mobile layout even though you still have plenty of horizontal space? That is what Ahmad Shadeed calls "the too early breakpoint" problem, and honestly, it is everywhere once you start looking for it.
The issue is straightforward but frequently ignored: designers and developers set breakpoints that trigger mobile layouts far too early in the viewport shrinking process. When a hero section with a nice two-column layout suddenly becomes a stacked single-column design at 900 pixels wide, you have to ask yourself why. There is still plenty of room to work with. The author highlights real examples from Time.com and TechCrunch where this exact problem creates awkward intermediate states that look worse than either the desktop or mobile versions.
What is missing from many responsive implementations is the acknowledgment that users actually do resize their browsers. They split screens. They use tablets. They use iOS link preview. The assumption that viewport widths only come in "desktop" and "mobile" flavors is fundamentally flawed. The author suggests having more breakpoints, designing with container queries in mind, and making designs dynamic based on content rather than fixed widths.
The deeper issue here is that many developers treat responsive design as a checkbox rather than a continuous spectrum. The article hints at an upcoming course, but the core insight is free: if you have space, use it. Do not surrender to single-column layouts until you genuinely need to.
Key takeaways:
- Too early breakpoints create awkward intermediate designs that look worse than either extreme
- Users resize browsers, split screens, and use tablets more than you might think
- Container queries and flexible grid layouts can eliminate the need for arbitrary breakpoints
- The goal should be designs that adapt fluidly, not designs that jump between fixed states
Solving Shrinkwrap: A New Experimental CSS Technique
TLDR: Roman Komarov presents a novel technique using anchor positioning and scroll-driven animations to achieve true shrinkwrapping of elements with auto-wrapped content, something CSS has never been able to do natively.
This is one of those articles that makes you realize just how limited CSS still is in certain areas. The "shrinkwrap problem" has plagued developers since the beginning of web design: when content wraps automatically, CSS calculates the final width by expanding the element to fill all available space rather than hugging the actual wrapped content.
The technique Roman presents is genuinely clever, though it comes with the disclaimer that it is highly experimental and has caused occasional Safari crashes. The core idea involves using anchor positioning to measure inline content and scroll-driven animations to communicate those measurements back to the parent element. By creating what he calls a "probing element" that anchors to the source content, he can calculate the actual wrapped dimensions and apply them to the outer container.
What makes this significant is not just the hack itself but what it represents: a workaround for a problem that has frustrated developers since 2015 when it was first formally described. The article includes an extensive list of prior attempts and discussions, showing just how persistent this issue has been. Text with text-wrap: balance looks terrible when combined with standard shrink-to-fit behavior because you get a nicely balanced block of text sitting in a container with massive empty space on one side.
The technique works in stable Chrome and Safari with graceful degradation for other browsers, but the author is clear this is not production-ready. The real value is demonstrating that a solution is possible, which should push browser vendors toward implementing native support.
Key takeaways:
- True shrinkwrapping of wrapped content has been impossible in CSS until now
- The technique combines anchor positioning, scroll-driven animations, and container queries
- Use cases include chat bubbles, fieldset legends, tooltips, and any balanced text with backgrounds
- Browser support is experimental; Safari occasionally crashes with certain configurations
- This should be treated as a proof of concept pushing for native CSS support
Tradeoffs:
- Requires specific HTML structure with multiple wrapper elements
- Cannot work with elements whose width depends on siblings
- Limited to phrasing content (inline elements only) in the base technique
Solving Shrinkwrap: New Experimental Technique
No-Hassle Visual Studio Code Theming: Building an Extension
TLDR: Creating a VS Code theme is far easier than it appears, especially with AI assistance for TextMate scope mapping. The author went from "never going to make a theme" to finished product in under six hours.
Sometimes the biggest barrier to creating something is the assumption that it will be difficult. The author started with a simple goal: better syntax highlighting for code blocks on a personal website redesign. That seemingly small task snowballed into building a complete VS Code theme, but the surprise was how manageable the process actually was.
The journey began with Shiki's CSS variable theming, which requires only about ten color variables for basic syntax highlighting. That simplicity provided enough confidence to push further into TextMate tokens, which offer more granular control but have historically been intimidating. The key insight was using AI to scaffold the initial theme structure, look up scope tokens from existing themes like Moonlight 2, and consolidate colors into semantic keywords.
The debugging workflow is particularly useful: VS Code's "Developer: Inspector Editor Tokens and Scopes" command lets you click on any text to see exactly which TextMate scopes apply and in what priority order. This removes much of the guesswork from theme development. The author also points out that VS Code's Extension Host allows real-time theme testing without server restarts.
The color selection philosophy draws from Sarah Drasner's and Tonsky's writings on syntax highlighting. The core principle is restraint: if everything is highlighted, nothing is. Functions get strong colors because they are important. Keywords can be muted. Variables stay mostly neutral to avoid the "Christmas lights" effect. These decisions require thinking about what actually matters when reading code, not just what looks pretty in a screenshot.
Key takeaways:
- Shiki CSS variable theming provides a simple entry point with about ten colors
- AI can effectively scaffold TextMate scopes using existing themes as references
- VS Code's scope inspector eliminates guesswork when debugging token styling
- Color selection should prioritize readability over visual novelty
- The Extension Host enables real-time theme testing during development
No-Hassle Visual Studio Code Theming: Building an Extension
New to the Web Platform in January 2026
TLDR: CSS Anchor Positioning and the Navigation API are now Baseline Newly available with Firefox 147. Chrome 144 brings the Temporal API, the new geolocation element, and find-in-page styling with ::search-text.
January was a significant month for web platform features reaching broader availability. CSS Anchor Positioning hitting Baseline means you can now position elements relative to other elements without JavaScript across all major browsers. This is enormous for tooltips, menus, and popovers where positioning logic has traditionally required either fragile CSS calculations or JavaScript libraries.
The Navigation API becoming Baseline is equally significant for single-page application developers. It provides a modern, standardized way to intercept and manage navigations, replacing the hodgepodge of history manipulation techniques that have accumulated over the years.
Chrome 144 introduces the Temporal API, which is arguably the most important JavaScript addition in years. The Date object has been a source of bugs and frustration for decades, and Temporal provides a robust, modern replacement with proper timezone handling and immutable date objects.
The geolocation element is an interesting experiment in declarative HTML. Instead of writing JavaScript to request location permissions and handle the various states, you get a button element that manages the entire flow. Whether this pattern extends to other permissions remains to be seen, but it represents a philosophical shift toward HTML doing more heavy lifting.
Firefox 147 also adds view transition types for single-page applications, though cross-document transitions are not yet supported. The beta releases preview text-justify controls and improvements to multi-column layout with column-wrap and column-height properties.
Key takeaways:
- CSS Anchor Positioning is now Baseline Newly available across all major browsers
- The Navigation API provides modern navigation interception for SPAs
- Temporal API finally replaces the problematic Date object in Chrome
- The geolocation element represents a new pattern for permission-requiring features
- View transition types add animation control based on navigation type
New to the web platform in January
Introduction to the New HTML Geolocation Element
TLDR: Chrome 144 introduces a declarative geolocation element that handles permission flows and location retrieval without requiring separate JavaScript API calls. It includes built-in styling constraints to prevent deceptive design patterns.
The new geolocation element is Chrome's first single-purpose permission element, born from a broader permission element proposal that browser vendors deemed too complex. When a user clicks the button, it either prompts for permission, allows undoing a previous denial, or refreshes the location if permission was already granted.
The element comes with several useful attributes. The accuracymode attribute toggles between approximate and precise location, with the UI automatically adjusting to show a crosshair icon for precise mode. The autolocate attribute attempts to retrieve location on page load if permission was previously granted. The watch attribute fires continuous events as the user moves.
What is particularly interesting is the styling constraints. You cannot make the element invisible with opacity, distort it with transforms, or shrink it to unusable sizes. Letter spacing and word spacing are limited. These constraints exist to prevent deceptive UI patterns where developers might try to trick users into granting location access. The button also localizes automatically based on the page's lang attribute.
The JavaScript API is straightforward: listen for the location event and access the position property containing the GeolocationPosition object with coords and timestamp. Progressive enhancement is possible by nesting a fallback button that uses the traditional navigator.geolocation API.
The article notes you can only use up to three geolocation elements on one page, which seems like an arbitrary limitation worth keeping in mind. Mozilla and WebKit have positive positions on the element, so cross-browser support should eventually arrive.
Key takeaways:
- The geolocation element handles permission flows declaratively without JavaScript
- Styling constraints prevent deceptive design patterns that could trick users
- Attributes control accuracy mode, auto-location on load, and continuous watching
- The :granted pseudo-class enables styling for the permission-granted state
- Currently Chrome 144 only, but other browsers have expressed positive intent
Introduction to the new HTML element geolocation
Drawing Connections with CSS Anchor Positioning
TLDR: CSS Anchor Positioning enables drawing visual connections between elements using pure CSS, eliminating JavaScript positioning logic for patterns like comment threads, tooltips, and callouts.
Roland Franke's experiment demonstrates anchor positioning's power by creating a visual connection between a comment and its reply using only CSS. Traditionally, visually connecting related UI elements meant either extra markup for drawing lines, JavaScript calculating positions, or simply giving up on the effect entirely.
The technique involves naming elements as anchors and using the anchor function to reference their geometry. A comment gets an anchor-name, and a pseudo-element on the reply uses anchor functions to position itself relative to both elements. The anchor function resolves to actual layout values: anchor with comment end gives you the block-end edge of the comment, while anchor with reply center gives you the vertical center of the reply.
What makes this exciting is that mixing anchor references with logical properties means the connections adapt automatically to writing mode and layout changes. No magic numbers. No recalculation when content grows. The line simply follows the elements wherever they go.
The article acknowledges that while the anchor function has reached Baseline Newly available, related features like anchor-name and anchor-scope may still be rolling out gradually depending on the browser. This makes anchor positioning a good candidate for progressive enhancement where the visual connection is nice to have but not essential.
Key takeaways:
- Anchor positioning enables visual element connections without JavaScript
- The anchor function resolves to real layout values from referenced elements
- Combining with logical properties provides automatic RTL and writing mode support
- Currently best suited for progressive enhancement due to varied browser support
- Eliminates DOM assumptions and wrapper elements for positioning logic
Drawing Connections with CSS Anchor Positioning
Performance-Optimized Video Embeds with Zero JavaScript
TLDR: Using the native details and summary elements, you can lazy-load embedded videos on user interaction without any JavaScript, achieving better performance than lite-youtube-embed while maintaining full accessibility.
Every embedded video, whether YouTube, Vimeo, or something else, carries a real performance cost. The player loads resources whether anyone watches or not. The common solution is lite-youtube-embed, which works well but still involves JavaScript and can cause cumulative layout shift when videos appear in the initial viewport.
The technique here uses details and summary as a native lazy-loading mechanism. The summary displays a thumbnail with a play button overlay, and the actual iframe only loads when the user clicks to expand. Because the video iframe is not considered part of the initial viewport until expansion, lazy loading works without the performance penalties Google's research found for excessively lazy-loaded content.
The styling transforms the default accordion appearance into something that looks like a video player. The summary uses a grid to center an SVG play button over the thumbnail image. When the details element opens, CSS hides the summary and reveals the iframe, which is positioned absolutely to cover the same space.
The performance comparison is striking: compared to lite-youtube-embed, this pattern is 14 percent faster on load time, has 6.4 times faster First Contentful Paint, requires 2.5 times less transfer size, and loads half as many resources. Most importantly, it uses zero JavaScript, so the only thing that can fail is the embedded content itself.
The pattern works for any heavy embed: YouTube, Vimeo, CodePen, maps, animated GIFs. Native keyboard accessibility and toggle behavior come free from the browser implementation.
Key takeaways:
- Details and summary provide native lazy-loading without JavaScript
- Video loads only when user explicitly clicks, not when scrolling into viewport
- Performance exceeds lite-youtube-embed on all metrics
- Pattern works for any heavy embed, not just YouTube
- Native accessibility comes free from browser implementation
Performance-Optimized Video Embeds with Zero JavaScript
Nice Select: Pushing Customizable Select to the Extreme
TLDR: Adam Argyle demonstrates the full potential of the new appearance: base-select with spring animations, scroll-driven reveals, anchor positioning, and comprehensive theming, all while maintaining native accessibility.
This is less of an article and more of a showcase of what becomes possible when native select customization finally lands. The demo combines nearly every cutting-edge CSS feature: superellipse corners, scroll-driven animations, scroll-state queries for detecting sticky headers and scrollable containers, spring easing, anchor positioning with fallbacks, and automatic light and dark theme support.
The architecture uses appearance: base-select to unlock full customization while retaining browser-controlled accessibility and keyboard navigation. Progressive enhancement ensures the custom experience only loads on capable devices with hover and fine pointers, falling back to native select on mobile.
The positioning logic is particularly clever. Anchor positioning places the picker near the trigger button, but JavaScript calculates an offset to align the currently selected option with the button text. This creates a morphing effect where opening the dropdown feels connected to the selection rather than just appearing below it.
The theming system uses light-dark functions, system colors like Canvas and CanvasText, and color-mix for semi-transparent overlays. Forced colors support ensures high-contrast mode works correctly. The scroll-state queries detect when content is scrollable and when sticky headers become stuck, adjusting styles accordingly.
The article freely admits this is Chrome-only for now and intentionally keeps mobile on native select. Firefox is working on support. The code is available on CodePen for forking, and the author explicitly requests feedback on improving the animation and positioning logic.
Key takeaways:
- Appearance base-select enables full customization while preserving accessibility
- Spring easing and scroll-driven animations create polished interaction feedback
- Scroll-state queries enable dynamic responses to scrolling and sticky states
- System colors and forced-colors support ensure broad accessibility
- Currently Chrome-only with Firefox support in development
Combobox vs. Multiselect vs. Listbox: How To Choose The Right One
TLDR: While all these UI components work with lists, they serve different purposes based on the number of options, visibility requirements, and single versus multiple selection needs.
Vitaly Friedman breaks down the terminology confusion around list-based UI components. A dropdown hides its list until triggered. A combobox combines text input filtering with single selection. A multiselect allows multiple selections, typically displayed as pills. A listbox shows all options visible by default with scrolling. A dual listbox (transfer list) moves items between two visible lists.
The choice comes down to two factors: how many options exist and whether they need to be visible by default. For fewer than five items, radio buttons or checkboxes usually work best. For large lists over 200 items, combobox and multiselect shine because of filtering. Listboxes suit situations where users need to see and choose from many options simultaneously.
Dual listbox is often overlooked but excels at bulk selection and assignment tasks. It is the only pattern allowing side-by-side review of selection and source lists before committing. For assigning roles, tasks, or permissions, it often outperforms drag-and-drop on speed, accuracy, and accessibility.
The practical advice is to never hide frequently used options. If users rely on particular selections, show them as pre-selected or as visible chips rather than buried in a dropdown. Keyboard navigation support is essential for all list types.
Key takeaways:
- Dropdowns hide lists; comboboxes filter; multiselects allow multiple selections; listboxes show all options
- Dual listbox excels at bulk selection and assignment workflows
- Never hide frequently used options regardless of which pattern you choose
- All list patterns require keyboard navigation for accessibility
- For lists over seven items, include Select All and Clear All functionality
Combobox vs. Multiselect vs. Listbox: How To Choose The Right One
Astro 5.17: Configurable Dev Toolbar and Async Parsing
TLDR: Astro 5.17 adds project-wide dev toolbar placement configuration, async parser support in the file loader, partitioned cookies for embedded contexts, and new image optimization options.
The dev toolbar placement configuration solves a real annoyance. Previously, toolbar position was stored in localStorage, meaning every team member had to manually adjust it, and settings were lost when clearing browser data. Sites with bottom-center UI elements like chat widgets had no way to avoid conflicts. Now you can set a project-wide default in the Astro config that acts as a baseline while still allowing individual overrides.
The async parser support in the file loader enables more complex data processing workflows. You can now perform asynchronous operations during content loading, such as fetching additional data or making API calls to enrich content before it reaches your templates.
Partitioned cookies are part of the Privacy Sandbox initiative, isolating cookies per top-level site. This matters when your Astro application is embedded in an iframe, allowing session state maintenance while respecting modern privacy standards.
The image optimization additions are practical: a background property controls background color when converting to formats without transparency support, and Sharp kernel selection enables fine-grained control over resize quality. The glob loader gains a retainBody option to reduce data store size for large content collections by omitting raw file contents.
Key takeaways:
- Dev toolbar placement can now be configured at the project level
- Async parsing enables API calls and data enrichment during content loading
- Partitioned cookies support modern privacy requirements for embedded contexts
- Image background color prevents black backgrounds on transparency-free formats
- The retainBody option addresses JSON size limits for very large content collections
Building an RSS Aggregator with Astro
TLDR: Raymond Camden built a personal RSS aggregator using Astro with client-side feed management in localStorage, server-side parsing with caching via Netlify Blobs, and native HTML dialog elements for the UI.
The project demonstrates Astro's server-side capabilities with remarkably little friction. The entire application consists of two routes: a home page with the UI and a server-side endpoint for fetching and parsing feeds. Feed URLs are stored in the browser's localStorage, keeping everything personal to each user without authentication complexity.
The server-side route uses the rss-parser Node package for feed parsing and Netlify Blobs for caching. The caching strategy stores parsed feed items per URL with a one-hour TTL, meaning multiple users requesting the same feed benefit from the cache. The author notes this could be much longer given typical blog posting frequencies.
What surprised Raymond was how well everything "just worked" with Astro on Netlify. Adding the Netlify adapter required one command. Making routes server-rendered meant changing one config line. Blob support worked automatically in both production and local development without any explicit configuration.
The client-side code uses native dialog elements for managing feeds, which was the author's first time using them with web platform technology rather than a framework abstraction. The UI is styled with Simple.css for a clean look with minimal effort.
Key takeaways:
- Astro server routes enable backend functionality without separate API infrastructure
- Netlify Blobs provide simple caching without database setup
- LocalStorage keeps user data personal without authentication
- Native dialog elements work well for modal UI patterns
- The Astro plus Netlify developer experience requires minimal configuration
Building an RSS Aggregator with Astro
Building a Scroll-Revealed WebGL Gallery with GSAP, Three.js, Astro and Barba.js
TLDR: A comprehensive tutorial on creating an animated multi-page gallery where images reveal with WebGL shaders on scroll and animate seamlessly between pages using GSAP Flip for transitions.
This tutorial tackles several interconnected challenges: syncing WebGL planes with DOM elements, smooth scrolling that works with render loops, scroll-triggered shader animations, and seamless page transitions where clicked images visually travel between pages without jumps.
The architecture uses Astro for lightweight multi-page structure, Barba.js for controlling navigation and transition logic, and GSAP plugins (ScrollSmoother, ScrollTrigger, SplitText, Flip) for motion. Three.js handles the WebGL rendering with custom shaders for the reveal effect.
The sync challenge is interesting: native scrolling and the requestAnimationFrame render loop are not guaranteed to update together. The solution uses GSAP's ticker instead of raw requestAnimationFrame, ensuring scroll position and rendering stay in lockstep. Each image gets a corresponding Three.js mesh scaled and positioned to match its DOM element exactly.
The page transition uses Barba.js hooks to orchestrate a complex sequence: save the clicked image's state with GSAP Flip, animate out non-selected images and text, navigate to the detail page, append the saved image to its new container, and animate the state transition. The result is a clicked image that appears to fly from the gallery to the detail view without visual discontinuity.
The code examples are extensive but the article acknowledges it is simplified for explanation. Cleanup between navigations is emphasized: GSAP plugins and Three.js resources must be explicitly disposed to prevent memory issues across transitions.
Key takeaways:
- GSAP ticker provides synchronized scroll and render loop updates
- Three.js meshes must be scaled and positioned to exactly match DOM elements
- Barba.js hooks enable access to both old and new page DOM during transitions
- GSAP Flip animates parent changes by capturing state before and after
- Explicit cleanup of GSAP instances and WebGL resources prevents memory leaks
Building a Scroll-Revealed WebGL Gallery with GSAP, Three.js, Astro and Barba.js
How AI is Redefining the Way We Find Content
TLDR: AI search synthesizes information from multiple sources into direct answers rather than ranked links, requiring optimization focused on technical integrity, quality content, and clear authority signals.
The shift from traditional search to AI-powered search changes the game fundamentally. Traditional search engines index pages and send users to your site. AI search gathers information live, runs it through a language model, and returns a synthesized response. Your content might inform the answer without users ever visiting your page.
Optimizing for AI visibility, sometimes called Generative Engine Optimization, still relies on SEO fundamentals: fast accessible websites, clear heading structures, descriptive alt text, and structured data. The difference is that structured data helps AI move beyond text matching into semantic understanding of context.
Content quality matters more than ever. AI aims to cut through noise and deliver human-ready responses, so your content needs to deliver core messages directly with authority. Show expertise, cite reliable sources, and link internally to demonstrate deep subject knowledge. Freshness signals matter too: update existing content rather than creating new versions to maintain accumulated authority.
The article notes that clicks may decrease since AI can deliver answers directly. This shifts metrics away from page views toward conversions, brand authority from being cited as a source, and unique value propositions that AI summaries cannot provide.
If you want to exclude content from AI results, blocking AI crawlers in robots.txt is the current best option, though not all crawlers respect it. Be aware this may impact visibility in search engines increasingly using AI to enhance results.
Key takeaways:
- AI search synthesizes live content into answers rather than ranking indexed pages
- Technical SEO fundamentals remain important for AI visibility
- Content authority signals like expertise, citations, and internal links matter more
- Metrics should shift from page views to conversions and brand authority
- Blocking AI crawlers may reduce visibility in AI-enhanced search engines
How AI is redefining the way we find content
Bringing CSS Clipping to React Native
TLDR: Three PRs are currently under review to bring CSS clip-path support to React Native through the StyleSheet API, implementing clipping for basic shapes across both iOS and Android platforms.
The article walks through what it takes to add a new CSS property to React Native's new architecture. Unlike the web where the browser handles everything, React Native acts as a coordinator translating styles into instructions that native UI kits execute. Adding clip-path requires touching JavaScript types, C++ core layer, and platform-specific implementations for iOS and Android.
The journey starts at the JavaScript layer with TypeScript or Flow types, then moves to parsing functionality. The C++ layer provides the shared core between platforms through Shadow Nodes representing the React Shadow Tree. The clip-path data structure supports circles, ellipses, insets, polygons, rects, and xywh shapes with optional geometry box specification.
On iOS, every View inherits from RCTViewComponentView, so adding clip-path logic there covers all components. The implementation creates a CAShapeLayer mask from the clip-path definition and applies it to the view's layer.
Android requires overriding the draw method and using Canvas clipPath and clipRect functions. Since there is no single base View class, the implementation uses BackgroundStyleApplicator to make the clipping logic available to all view types.
The implementation respects CSS specifications including stacking context creation. Each shape type requires platform-specific path creation functions, but the logic maps conceptually between platforms.
Key takeaways:
- Adding CSS properties to React Native requires JavaScript, C++, iOS, and Android changes
- The new architecture uses C++ as a shared core between platforms
- iOS uses CALayer masks; Android uses Canvas clipping
- Shape definitions include circle, ellipse, inset, polygon, rect, and xywh
- The PRs are under review and should land in a future React Native release