Article Post (Editorial)

A complete blog post for an editorial or magazine site. Hero image, formal byline, longform prose with footnotes, and a publication-style footer.

Core: .flow, .cluster, .media, .frame, .divider, .prose

Extras: .avatar

Custom Styles

A few custom styles are included in the page style block used by some of the patterns.

<style>
    .article-kicker {
        font-size: var(--step--1);
        font-weight: var(--font-weight-semibold);
        color: var(--color-primary);
        text-transform: uppercase;
        letter-spacing: 0.06em;
    }
    .article-byline {
        display: flex;
        align-items: center;
        gap: var(--space-2xs);
        font-size: var(--step--1);
        color: var(--color-text-muted);
    }
    .author-links {
        display: flex;
        gap: var(--space-sm);
        font-size: var(--step--1);
    }
</style>

Full post

Feature

The Quiet Revolution in Browser Rendering

How a series of incremental changes to layout engines fundamentally altered what's possible in CSS -- and why almost nobody noticed.

Abstract architectural detail showing layered concrete forms

In 2019, if you wanted to build a responsive layout that adapted to its container rather than the viewport, you couldn't. The idea had been discussed for a decade, prototyped in JavaScript polyfills, and rejected by browser vendors as too expensive to implement. Container queries were the feature that CSS developers wanted most and the one they were told they couldn't have.1

By 2023, every major browser shipped them. The feature that was impossible became the feature that was everywhere, and the transition was so smooth that most developers barely registered the magnitude of what had changed.

The constraint that shaped everything

To understand why container queries took so long, you have to understand how browser layout works. The rendering engine makes a single pass through the document tree, calculating each element's size based on its parent's constraints. A container query inverts this: the child's styles depend on the parent's computed size, which depends on the child's styles. It's circular.2

The breakthrough wasn't algorithmic cleverness. It was a constraint: containment. If an element declares container-type: inline-size, it promises the browser that its children cannot affect its inline size. The circularity breaks. The engine can compute the container's size first, then resolve the query.3

The best features are the ones that work within the engine's existing model rather than fighting it. Containment didn't change how layout works -- it gave authors a way to make promises that the engine could exploit.

Miriam Suzanne, CSS Working Group

What containment unlocked

Container queries were the headline feature, but containment itself turned out to be more important. Once browsers had a robust containment model, other features became possible:

  • Container query units (cqi, cqb) let you size type and spacing relative to a container rather than the viewport
  • Style queries let children respond to a container's custom property values, not just its dimensions
  • Content visibility uses containment to skip rendering for off-screen content, dramatically improving initial paint times

Each of these was a separate specification effort, but they all depended on the same underlying primitive. Containment was the foundation that made a decade of wishlist features suddenly achievable.4

The adoption curve nobody expected

New CSS features typically follow a long adoption curve. Flexbox took five years from first browser support to widespread use. Grid took three. Container queries took less than one.

The reason was component libraries. Design systems teams had been waiting for container queries specifically because they solved the "component in an unknown context" problem that had plagued every responsive design system since 2012. When the feature shipped, these teams adopted it immediately and pushed it through their organizations.5

What comes next

The containment model is still evolving. The CSS Working Group is exploring ways to relax the constraints -- allowing queries on block size, for instance, which is currently forbidden because it reintroduces circularity in vertical writing modes. There's also work on "toggle" and "switch" functions that would bring conditional logic into CSS values without requiring a container context at all.

But the larger shift is cultural. For twenty years, CSS developers learned to think in terms of the viewport. Media queries trained us to ask "how wide is the screen?" Containment is training us to ask a better question: "how wide is the space I've been given?" That shift in mental model may matter more than any individual feature.


  1. The 2019 State of CSS survey listed container queries as the most-wanted feature for the third consecutive year.

  2. Tab Atkins described this as the "infinite loop problem" in a 2018 blog post that became the canonical reference for why container queries were considered impossible.

  3. The CSS Containment specification (Level 2) was the enabling work. Miriam Suzanne's container queries proposal built directly on its primitives.

  4. Chrome's implementation of content-visibility: auto showed rendering time improvements of 7x on long pages in internal benchmarks. Real-world results varied but were consistently positive.

  5. Shopify's Polaris and Salesforce's Lightning both adopted container queries within three months of full browser support, affecting millions of deployed components.


Elena Vasquez

Elena Vasquez

Senior Editor, Platform & Infrastructure

Elena covers browser internals, rendering engines, and the web platform. Previously at Mozilla and the W3C. She has strong opinions about specificity.


Published · Updated

14 min read

<docs-resize>
    <article class="flow flow-space-lg" style="max-inline-size: 65ch">

        
        <header class="flow flow-space-sm">
            <p class="article-kicker">Feature</p>
            <h1 class="text-4 text-bold leading-tight">The Quiet Revolution in Browser Rendering</h1>
            <p class="text-1" style="max-inline-size: 55ch">
                How a series of incremental changes to layout engines fundamentally altered what&#39;s possible in CSS -- and why almost nobody noticed.
            </p>
            <div class="article-byline">
                <div class="avatar is-sm">
                    <img src="https://picsum.photos/seed/ed-author1/64/64" alt="Elena Vasquez"/>
                </div>
                <span class="text-medium" style="color: var(--color-text)">Elena Vasquez</span>
                <span>·</span>
                <time datetime="2026-04-10">April 10, 2026</time>
                <span>·</span>
                <span>14 min read</span>
            </div>
        </header>

        <div class="frame" style="--frame-ratio: 21 / 9; border-radius: var(--radius-md)">
            <img src="https://picsum.photos/seed/editorial1/960/400" alt="Abstract architectural detail showing layered concrete forms"/>
        </div>

        
        <div class="prose">
            <p>
                In 2019, if you wanted to build a responsive layout that adapted to its container rather than the viewport, you couldn&#39;t. The idea had been discussed for a decade, prototyped in JavaScript polyfills, and rejected by browser vendors as too expensive to implement. Container queries were the feature that CSS developers wanted most and the one they were told they couldn&#39;t have.<sup><a href="#fn:1" id="fnref:1">1</a></sup>
            </p>
            <p>
                By 2023, every major browser shipped them. The feature that was impossible became the feature that was everywhere, and the transition was so smooth that most developers barely registered the magnitude of what had changed.
            </p>

            <h2>The constraint that shaped everything</h2>
            <p>
                To understand why container queries took so long, you have to understand how browser layout works. The rendering engine makes a single pass through the document tree, calculating each element&#39;s size based on its parent&#39;s constraints. A container query inverts this: the child&#39;s styles depend on the parent&#39;s computed size, which depends on the child&#39;s styles. It&#39;s circular.<sup><a href="#fn:2" id="fnref:2">2</a></sup>
            </p>
            <p>
                The breakthrough wasn&#39;t algorithmic cleverness. It was a constraint: containment. If an element declares <code>container-type: inline-size</code>, it promises the browser that its children cannot affect its inline size. The circularity breaks. The engine can compute the container&#39;s size first, then resolve the query.<sup><a href="#fn:3" id="fnref:3">3</a></sup>
            </p>

            <blockquote>
                <p>The best features are the ones that work within the engine&#39;s existing model rather than fighting it. Containment didn&#39;t change how layout works -- it gave authors a way to make promises that the engine could exploit.</p>
                <cite>Miriam Suzanne, CSS Working Group</cite>
            </blockquote>

            <h2>What containment unlocked</h2>
            <p>
                Container queries were the headline feature, but containment itself turned out to be more important. Once browsers had a robust containment model, other features became possible:
            </p>
            <ul>
                <li><strong>Container query units</strong> (<code>cqi</code>, <code>cqb</code>) let you size type and spacing relative to a container rather than the viewport</li>
                <li><strong>Style queries</strong> let children respond to a container&#39;s custom property values, not just its dimensions</li>
                <li><strong>Content visibility</strong> uses containment to skip rendering for off-screen content, dramatically improving initial paint times</li>
            </ul>
            <p>
                Each of these was a separate specification effort, but they all depended on the same underlying primitive. Containment was the foundation that made a decade of wishlist features suddenly achievable.<sup><a href="#fn:4" id="fnref:4">4</a></sup>
            </p>

            <h2>The adoption curve nobody expected</h2>
            <p>
                New CSS features typically follow a long adoption curve. Flexbox took five years from first browser support to widespread use. Grid took three. Container queries took less than one.
            </p>
            <p>
                The reason was component libraries. Design systems teams had been waiting for container queries specifically because they solved the &#34;component in an unknown context&#34; problem that had plagued every responsive design system since 2012. When the feature shipped, these teams adopted it immediately and pushed it through their organizations.<sup><a href="#fn:5" id="fnref:5">5</a></sup>
            </p>

            <h2>What comes next</h2>
            <p>
                The containment model is still evolving. The CSS Working Group is exploring ways to relax the constraints -- allowing queries on block size, for instance, which is currently forbidden because it reintroduces circularity in vertical writing modes. There&#39;s also work on &#34;toggle&#34; and &#34;switch&#34; functions that would bring conditional logic into CSS values without requiring a container context at all.
            </p>
            <p>
                But the larger shift is cultural. For twenty years, CSS developers learned to think in terms of the viewport. Media queries trained us to ask &#34;how wide is the screen?&#34; Containment is training us to ask a better question: &#34;how wide is the space I&#39;ve been given?&#34; That shift in mental model may matter more than any individual feature.
            </p>

            <section class="footnotes">
                <hr/>
                <ol>
                    <li id="fn:1">
                        <p>The 2019 State of CSS survey listed container queries as the most-wanted feature for the third consecutive year. <a href="#fnref:1">↩</a></p>
                    </li>
                    <li id="fn:2">
                        <p>Tab Atkins described this as the &#34;infinite loop problem&#34; in a 2018 blog post that became the canonical reference for why container queries were considered impossible. <a href="#fnref:2">↩</a></p>
                    </li>
                    <li id="fn:3">
                        <p>The CSS Containment specification (Level 2) was the enabling work. Miriam Suzanne&#39;s container queries proposal built directly on its primitives. <a href="#fnref:3">↩</a></p>
                    </li>
                    <li id="fn:4">
                        <p>Chrome&#39;s implementation of <code>content-visibility: auto</code> showed rendering time improvements of 7x on long pages in internal benchmarks. Real-world results varied but were consistently positive. <a href="#fnref:4">↩</a></p>
                    </li>
                    <li id="fn:5">
                        <p>Shopify&#39;s Polaris and Salesforce&#39;s Lightning both adopted container queries within three months of full browser support, affecting millions of deployed components. <a href="#fnref:5">↩</a></p>
                    </li>
                </ol>
            </section>
        </div>

        <hr class="divider"/>

        
        <footer>
            <div class="flow flow-space-md">
                <div class="media" style="--media-gap: var(--space-md)">
                    <div class="avatar is-xl">
                        <img src="https://picsum.photos/seed/ed-author1/200/200" alt="Elena Vasquez"/>
                    </div>
                    <div class="flow flow-space-2xs">
                        <p class="text-1 text-semibold">Elena Vasquez</p>
                        <p class="text--1 text-muted">Senior Editor, Platform &amp; Infrastructure</p>
                        <p class="text--1" style="max-inline-size: 45ch">
                            Elena covers browser internals, rendering engines, and the web platform. Previously at Mozilla and the W3C. She has strong opinions about specificity.
                        </p>
                        <div class="author-links">
                            <a href="#">Archive</a>
                            <a href="#">Mastodon</a>
                            <a href="#">RSS</a>
                        </div>
                    </div>
                </div>
                <hr class="divider" style="--divider-spacing: 0"/>
                <div class="cluster is-apart text--1 text-subtle">
                    <p>
                        Published <time datetime="2026-04-10">April 10, 2026</time>
                        · Updated <time datetime="2026-04-11">April 11, 2026</time>
                    </p>
                    <p>14 min read</p>
                </div>
            </div>
        </footer>

    </article>
</docs-resize>

Accessibility