[css-conditional] Layout State Container Queries: `column-position` feature for flex/grid/multi-column layouts

[devi-prsd]

Problem Statement

There is no CSS-only way to style elements based on their position within a layout column (first, last, only, nth) in multi-column flex, grid, or columns layouts. This is a common need for:

• Decorative fill patterns in masonry-style layouts (filling remaining column space)
• Bottom-border removal on the last card per column to avoid double borders
• Spacing adjustments (removing margin-bottom from the column-terminal item)
• Column-start decorations (drop-cap-like effects, top-border treatment)

Authors are forced to use significant JavaScript involving ResizeObserver, IntersectionObserver, and getBoundingClientRect() to compute column membership and toggle classes — a substantial amount of code for what is fundamentally a presentational concern.

Why Not a Pseudo-Class Selector?

The CSSWG FAQ on layout-dependent selectors explains that selectors cannot depend on layout because they create circular dependencies:

:last-in-column { display: none; } — now a different element is last-in-column, the selector unapplies, the original reappears, infinite loop.

Restricting applicable properties is rejected because developers can chain rules across multiple selectors to recreate circularity indirectly.

However, this class of problem has already been solved by Scroll State Container Queries (CSS Conditional 5, shipped Chrome 133). The pattern: the container holds the layout-resolved state, only descendants can query it, and the querying element cannot be the container itself — breaking circularity by construction.

This proposal extends that proven pattern to column-position states.

Proposed Solution

New Container Type: layout-state

A new container-type value that makes an element a layout-state query container. The UA resolves the element's column position during layout and exposes it to descendant queries.

.masonry-item {
  container-type: layout-state;
}

layout-state can be combined with existing container types:

.masonry-item {
  container-type: inline-size layout-state;
}

New Container Feature: column-position

A discrete container feature queryable via @container, with the following values:

Value	Matches When
first	Element is the first item laid out in its column
last	Element is the last item laid out in its column
only	Element is the sole item in its column
interior	Element is neither first nor last (at least 3 items in column)

Syntax

@container layout-state(column-position: last) {
  /* styles for descendants of the last item in each column */
}

Real-World Example

Consider a horizontally-scrolling editorial board with a flexbox column-wrap masonry layout where decorative fill patterns (diagonal hatching, dot matrices, etc.) should appear after the last card in each column:

/* Container: the masonry wrapper provides the column context */
.masonry-wrapper {
  display: flex;
  flex-direction: column;
  flex-wrap: wrap;
  height: 100%;
  gap: 2rem;
}

/* Each item is a layout-state container */
.masonry-item {
  container-type: layout-state;
  width: 320px;
}

/* Descendants of the last item in each column get styled */
.masonry-item > .entry-card {
  @container layout-state(column-position: last) {
    /* Grow to fill remaining column space */
    flex-grow: 1;

    &::after {
      content: "";
      flex-grow: 1;
      min-height: 48px;
      background: repeating-linear-gradient(
        -45deg, currentColor, currentColor 1px,
        transparent 1px, transparent 8px
      );
      opacity: 0.15;
    }
  }
}

/* First item in each column gets a top accent */
.masonry-item > .entry-card {
  @container layout-state(column-position: first) {
    border-top: 3px solid AccentColor;
  }
}

Today this requires ~80 lines of JavaScript:

// Simplified version of what production apps actually ship:
const entryState = new Map();
let resizeObserver, intersectionObserver;

// 1. IntersectionObserver to track visibility
intersectionObserver = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    entryState.set(entry.target.dataset.id, {
      visible: entry.isIntersecting,
      height: entry.boundingClientRect.height
    });
  });
  scheduleUpdate();
}, { root: scrollContainer, rootMargin: '0px 2560px' });

// 2. ResizeObserver to watch container changes
resizeObserver = new ResizeObserver(() => scheduleUpdate());
resizeObserver.observe(wrapper);

// 3. Manual column detection via getBoundingClientRect()
function updateLastInColumn() {
  const items = scrollContainer.querySelectorAll('.masonry-item');
  const visible = [];
  for (const el of items) {
    if (entryState.get(el.dataset.id)?.visible) {
      visible.push({ id: el.dataset.id, left: el.getBoundingClientRect().left });
    }
  }
  // Detect column breaks by checking inline-axis offset jumps
  const lastIds = [];
  for (let i = 0; i < visible.length; i++) {
    const next = visible[i + 1];
    if (!next || next.left > visible[i].left + 100) {
      lastIds.push(visible[i].id);
    }
  }
  // Toggle class on matching elements
  for (const el of items) {
    el.classList.toggle('is-last-in-column', lastIds.includes(el.dataset.id));
  }
}

// 4. Debounced re-computation
let timeout;
function scheduleUpdate() {
  clearTimeout(timeout);
  timeout = setTimeout(updateLastInColumn, 50);
}

// 5. Event listener wiring
window.addEventListener('resize', scheduleUpdate);
// 6. Cleanup on unmount...

Circular Dependency Avoidance

This proposal inherits the same circularity-breaking mechanism as Scroll State Container Queries:

1. The container holds the state. The .masonry-item element's column position is resolved during layout and recorded as container state.

2. Only descendants can query. The @container layout-state(...) rule can only style elements inside the container, not the container itself.

3. The querying element cannot affect column assignment. Since the container's own width, height, display, position, flex-grow, and other layout properties cannot be modified by the query (they belong to the container, not a descendant), column assignment remains stable.

This is structurally identical to how @container scroll-state(stuck: top) works — the sticky element is the container, and only its children respond to the state change.

Note: The example above shows flex-grow: 1 on .entry-card (a descendant), not on .masonry-item (the container) — so the container's column membership is unaffected.

Extended Feature: column-index() (Future)

A functional form for targeting specific column ordinals or An+B patterns:

/* Style items in the first column */
@container layout-state(column-index(1)) {
  /* ... */
}

/* Style items in even columns */
@container layout-state(column-index(2n)) {
  /* ... */
}

This is deferred to a future level to keep the initial proposal focused.

Which Layout Modes Apply

Layout Mode	Column Determination
flex-direction: column; flex-wrap: wrap	Items sharing the same column line in the wrapping axis
columns (multi-column layout)	Items in each column fragment
grid with explicit/implicit columns	Items sharing the same grid-column track
flex-direction: row	N/A — could define a symmetric row-position feature
Block flow	Always only (single column)

Relationship to Existing Specifications

CSS Conditional 5 (Scroll State Container Queries)

This proposal is a direct extension of the container query mechanism in CSS Conditional 5. Where scroll-state queries expose scroll/sticky/snap states, layout-state queries expose column-position states. The circularity-avoidance mechanism is identical.

CSS Containment 3

Layout-state containers would require the UA to track column assignment metadata, similar to how size containers track inline/block dimensions. This is a bookkeeping addition — the UA already computes column assignment during layout; it simply needs to expose it.

CSS Grid Level 3 (Masonry)

The masonry layout proposal will create additional demand for per-column selection. column-position would work natively with masonry tracks.

Selectors Level 4

This proposal deliberately avoids adding pseudo-class selectors, respecting the CSSWG's position that selectors must not depend on layout. Container queries are the sanctioned mechanism for layout-dependent styling.

Alternatives Considered

Alternative	Why It Falls Short
Pseudo-class selectors (:last-in-column)	Rejected by CSSWG — circular dependency
JavaScript (IntersectionObserver + classList)	Performance cost, fragile, not declarative, SSR-hostile
:nth-child(An+B) with known column count	Column count changes with viewport; requires JS or @media ladder for every breakpoint
break-after: column	Only works in multi-column layout, not flex or grid
Container Size Queries	Can query dimensions but not positional layout role
CSS masonry layout (Grid L3)	Only addresses one layout mode; flex column-wrap masonry exists today

Implementation Considerations

• No new layout computation. The UA already determines column assignment during flex/grid/multi-column layout. This proposal asks the UA to record and expose that information, not compute anything new.
• Containment model. layout-state containers would not require layout containment — column position is determined by the parent's layout algorithm, not the element's own subtree.
• Composability. layout-state composes with scroll-state and size containment: container-type: inline-size scroll-state layout-state.
• Polyfill path. A polyfill using ResizeObserver + getBoundingClientRect() + [data-column-position] attributes is straightforward — production applications already ship this exact pattern.

Open Questions

1. Should layout-state be a separate container type or folded into scroll-state? Both are post-layout states. A unified state container type could encompass both, but separating them allows independent adoption.

2. Should row-position be included symmetrically? For flex-direction: row; flex-wrap: wrap, the equivalent need is "last item in each row." The same mechanism applies with s/column/row/.

3. Should column-position: last on a container also set flex-grow: 1 on the container itself? This would be convenient but violates the principle that queries don't affect the queried container. A separate flex-grow: last-in-column value or masonry-fill property might be more appropriate.

---

Suggested Labels: css-conditional-5, css-flexbox, css-grid, css-multicol

Related Issues/Specs:

• CSS Conditional 5 — Scroll State Container Queries
• CSS Grid Level 3 — Masonry
• CSSWG FAQ — Selectors That Depend on Layout
• CSS Containment 3

Original Proposal (Psuedo selectors)

Previous Psuedo Selector Proposal

## Problem Statement

There is currently no CSS-only way to select the last item in each column of a multi-column flex or grid layout. This is a common need for:

• Decorative fill patterns in masonry-style layouts (filling remaining column space with hatching, dot patterns, accent borders, etc.)
• Bottom-border removal on the last card per column to avoid double borders
• Spacing adjustments (removing margin-bottom from last items per column)
• Visual indicators like column-end dividers, fade-outs, or ornamental elements

Authors are forced to use significant JavaScript to achieve what is fundamentally a presentational concern.

Real-World Use Case

Consider a horizontally-scrolling editorial/zine-style board with a flexbox column-wrap masonry layout:

.masonry-wrapper {
  display: flex;
  flex-direction: column;
  flex-wrap: wrap;
  height: 100%;
  column-gap: 2rem;
}

.masonry-item {
  width: 320px;
  margin-bottom: 2rem;
}

The design calls for decorative fill patterns (diagonal hatching, dot matrices, crosshatching, etc.) applied via ::after pseudo-elements on whichever item happens to land last in each column. These patterns fill the remaining vertical space, creating a polished editorial aesthetic.

Today's workaround requires ~80 lines of JavaScript:

// 1. IntersectionObserver to track which items are visible
// 2. ResizeObserver to watch for container size changes
// 3. getBoundingClientRect() to determine column positions
// 4. Manual computation of which items are last per column
// 5. Toggling an `.is-last-in-column` class on matching elements
// 6. Debounced re-computation on scroll, resize, and content changes

This approach is:

• Fragile — breaks on scroll, resize, dynamic content, and container queries
• Expensive — forces layout recalculation and DOM reads on every reflow
• Non-composable — cannot be combined with other selectors or used in @media/@container contexts without additional JS wiring
• Inaccessible to CSS-only contexts — server-rendered pages, CSS-only prototypes, and declarative design systems cannot use it at all

Proposed Solution

New Pseudo-Classes

:last-in-column

Matches every element that is the last sibling laid out in its respective column within a multi-column flex container (flex-direction: column; flex-wrap: wrap), a CSS columns layout, or a grid container with implicit column tracks.

/* Decorative column-end fill */
.masonry-item:last-in-column {
  flex-grow: 1;
}

.masonry-item:last-in-column::after {
  content: "";
  flex-grow: 1;
  background: repeating-linear-gradient(
    -45deg, currentColor, currentColor 1px,
    transparent 1px, transparent 8px
  );
  opacity: 0.15;
}

:first-in-column

Matches every element that is the first sibling laid out in its respective column. Useful for column-start decorations, drop-cap-like effects, or top-border treatment.

.masonry-item:first-in-column {
  border-top: 3px solid accent-color;
}

:nth-in-column() / :nth-last-in-column()

Functional pseudo-classes accepting An+B notation, scoped to the column the element is placed in.

/* Style every 2nd item within each column */
.masonry-item:nth-in-column(2n) {
  background: var(--zebra-stripe);
}

/* Style the second-to-last item in each column */
.masonry-item:nth-last-in-column(2) {
  margin-bottom: 0;
}

Which Layouts Apply

Layout Mode	Applies?	Column Determination
flex-direction: column; flex-wrap: wrap	Yes	Items in the same column share the same inline-axis offset
columns (multi-column layout)	Yes	Items in each column fragment
grid with explicit/implicit columns	Yes	Items sharing the same grid-column track
flex-direction: row	No	N/A (items flow in rows, not columns)
Block flow	No	N/A (single column by definition)

Definition of "Column"

A column is defined as a set of sibling elements that share the same column track (grid) or column fragment (multi-column, column-wrap flex). Two flex items are in the same column if they occupy the same column line in the wrapping axis.

The UA already computes this information during layout; the selector simply exposes it.

Interaction with Existing Specifications

Selectors Level 4/5

These pseudo-classes extend the structural pseudo-class family (:first-child, :last-child, :nth-child()). The key difference is that structural pseudo-classes operate on DOM order, while :*-in-column pseudo-classes operate on layout position — making them layout-dependent selectors.

Precedent: Layout-Dependent Selection

CSS already has layout-aware pseudo-classes and selectors:

• :empty — depends on content (though not layout)
• ::column (proposed in CSS Pseudo-Elements 4) — selects column boxes in multi-column layout
• The proposed masonry layout (CSS Grid Level 3) will need similar per-column selection

Circular Dependency Avoidance

To prevent circular dependencies (where selecting :last-in-column changes sizing, which changes which item is last), column assignment must be resolved before these selectors are evaluated — similar to how :first-line resolves after line breaking. The selector matches based on the layout computed in the previous layout pass; if matching causes a layout change, the UA performs at most one additional pass (analogous to fit-content resolution).

Alternatively, these selectors could be restricted to properties that do not affect column assignment (e.g., color, opacity, background, border, outline, box-shadow, transform, filter) — similar to how ::first-line restricts applicable properties.

Alternatives Considered

Alternative	Why It Falls Short
JavaScript (IntersectionObserver + classList)	Performance cost, fragile, not declarative, SSR-hostile
:nth-child(An+B) with known column count	Column count changes with viewport; requires JS or @media ladder for every breakpoint
break-after: column	Only works in multi-column layout, not flex or grid
Container Queries	Can query dimensions but cannot select based on positional layout role
CSS masonry layout (Grid L3)	Only addresses one layout mode; flex column-wrap masonry exists today and is widely used

Implementation Considerations

• The UA already knows column assignment after layout; exposing it to selectors is a matter of bookkeeping, not new computation.
• Restricting applicable properties (as with ::first-line) avoids circular dependency without additional layout passes.
• These selectors compose naturally with existing pseudo-classes: .card:last-in-column:not(:first-in-column) targets columns with more than one item.

Syntax Summary

:first-in-column        /* first item laid out in its column */
:last-in-column         /* last item laid out in its column */
:only-in-column         /* sole item in its column */
:nth-in-column(An+B)    /* nth item in its column */
:nth-last-in-column(An+B) /* nth from end in its column */

Polyfill Path

A polyfill can be implemented today using ResizeObserver + getBoundingClientRect() to compute column membership and toggle data attributes ([data-last-in-column]). This is exactly what production applications are already doing — see the real-world example above.

Related Issues / Specs

• CSS Grid Level 3 (Masonry) — masonry layouts will have the same need
• CSS Pseudo-Elements 4 ::column — column-level pseudo-elements
• Selectors Level 4 — structural pseudo-classes

---

Labels: selectors-5, css-flexbox, css-grid, css-multicol

[Loirooriol]

https://wiki.csswg.org/faq/#selectors-that-depend-on-layout

[devi-prsd]

@Loirooriol Thanks for flagging the layout circularity issue. I'm aware of the FAQ position on layout-dependent selectors — pseudo-classes like :last-in-column are a non-starter.

But hasn't this exact class of problem already been solved by Scroll State Container Queries? The pattern there — container holds post-layout state, only descendants query it, container's own layout properties are untouched — seems directly applicable here.

What if column-position were a layout-state container feature rather than a selector?

.masonry-item {
  container-type: layout-state;
}

.masonry-item > .card {
  @container layout-state(column-position: last) {
    /* styles descendants, not the container — no circularity */
  }
}

The UA already computes column assignment during flex/grid/multicol layout — this would just expose it through the existing @container mechanism, with the same circularity guarantees as scroll-state(stuck).

Is there a reason this approach wouldn't work here? Would love to hear if there are gotchas I'm missing with extending container queries to layout-position states.

[tabatkins]

Yes, a CQ could potentially allow children of the item to respond to the item's position in the grid. We should probably discuss this in the WG slightly more generally, to see what the appetite is for more of these style-querying sorts of conditions. (Luckily, next week is a f2f meeting, tho we'll have to see if we have space to fit this in.)

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional] Layout State Container Queries: `column-position` feature for flex/grid/multi-column layouts, and agreed to the following:

• RESOLVED: Start working on spec for grid and tables in css-conditional-5

The full IRC log of that discussion

<emilio> TabAtkins: container queries let us ask about lots of things in the container
<kizu> q+
<emilio> ... due to the restrictions we put
<emilio> ... one thing people ask for is column / rows
<emilio> ... it'd be fine for a child to ask the grid which column is it in
<emilio> ... main idea would be to allow us to query a few more layout aspects
<emilio> q+
<sgill> q+
<kbabbitt> q+
<iank_> q+
<lea> +1 yessssss
<emilio> ... main thing would be column / row positions in the various layout modes
<astearns> ack kizu
<emilio> kizu: yes +1 to the ask
<emilio> ... long-standing request
<lea> this is huge
<emilio> ... grid is probably one of the simpler ones
<emilio> ... until we introduce spanning
<lea> q+
<emilio> ... for other things like multicol or flex it's a lot more complicated
<emilio> ... would be nice to have
<emilio> ... regular containment would help
<emilio> ... size containment maybe then we can query the position of the flex item
<kizu> https://kizu.dev/position-driven-styles/#edge-detection (best viewed™️ in Chrome; I'll need to investigate why Safari is not doing the same; might be a problem in my code, but maybe something to report)
<emilio> ... right now it is possible to do * position animations because you can detect in view-timeline and so on
<emilio> ... this is something people want
<florian> q+
<emilio> ... would be nice to be able to pursue this in some way
<emilio> TabAtkins: for some layout modes children can affect your row, for those we'd need to have size containment
<kbabbitt> q-
<astearns> ack emilio
<TabAtkins> emilio: is the idea that the CQ now doesn't match just on the econtainer state, but also on the element it's querying from
<TabAtkins> TabAtkins: I don't understand
<TabAtkins> emilio: there's an example: column-position:last
<fantasai> TabAtkins: container is the grid item
<fantasai> emilio: ah, not the grid container
<fantasai> TabAtkins: otherwise it's circular
<fantasai> emilio: ok, that explains
<kizu> It could be something like a “layout query” with containment on items/etc being something that enables it maybe
<fantasai> emilio: so for grid in particular, there's no way that a layout change inside the item would change what column it ends up in
<fantasai> TabAtkins: correct
<fantasai> emilio: then that seems fine
<fantasai> TabAtkins: only grid can do that
<fantasai> fantasai: also table
<fantasai> TabAtkins: table cells don't care about their size
<fantasai> emilio: ok, seems doable...
<fantasai> emilio: a bit sketchy to ask based on state of ancestor ... but conceptually about the element ...
<astearns> ack sgill
<fantasai> sgill: I was just going to cover the last point
<fantasai> sgill: it works in grid, and maybe tables
<fantasai> sgill: but not in grid-lanes
<fantasai> TabAtkins: flexbox, grid-lanes, multicol, would need size containment so that children can't affect size
<astearns> ack iank_
<fantasai> iank_: Same concern wrt grid-lanes. Maybe carve out exception for explicit placement
<fantasai> iank_: for other layout modes, would need strict containment almost
<fantasai> iank_: because you would lay out often before you place them
<fantasai> iank_: to determine hypothetical size etc.
<fantasai> iank_: so it needs to be quite restrictive there
<fantasai> TabAtkins: I know it needs size containment. Idk about others
<fantasai> iank_: It needs style. Because it can affect the counters around it.
<fantasai> TabAtkins: if we need more containment, sure
<astearns> ack lea
<astearns> ack florian
<fantasai> florian: If we can get this to work in multicol, can we also get it to work on pages?
<fantasai> TabAtkins: detect what page?
<fantasai> TabAtkins: I think so
<fantasai> florian: there are uses for that
<fantasai> iank_: You'd need size containment
<fantasai> iank_: problem with fragmentation is that you also need to be monolithic
<kizu> q+
<fantasai> iank_: otherwise what happens if you're in 2 pages or 2 columns
<fantasai> florian: but not worse for pages than columns, so if can do for one do for both
<astearns> ack kizu
<fantasai> kizu: for multicol and grid and some other layout, might be one separate feature which would be very useful
<fantasai> kizu: if you have a grid inside multicol (!!!!) it would be very nice when it were fragmented to be able to switch the order of columns in different columns of multicol
<fantasai> kizu: Example: print-like page layout where you have gutters and page-spread with images on the outside of each page
<fantasai> kizu: It wouldn't change layout, just change the order
<kbabbitt> q+
<fantasai> florian: Yeah, flipping sides is a very common case.
<astearns> an+b column selectors might be a better fit for this?
<astearns> ack fantasai
<emilio> fantasai: for fragmentation, knowing something what page something is in
<emilio> ... requiring monolithic stuff is not going to get you what you want
<alisonmaher> q+
<emilio> ... being able to respond to the question would be useful even if fragmented
<emilio> ... you can tell which page you start on
<fantasai> TabAtkins: grid and table, simple and easy
<fantasai> TabAtkins: flexbox requires at least style and size containment, because size determines where you sit
<fantasai> TabAtkins: but can't fragment so can't live across lines
<Kurt> q+
<fantasai> TabAtkins: multicol and page layout, can live in multiple columns
<fantasai> TabAtkins: what if we do the easy ones first?
<fantasai> TabAtkins: grid + table
<fantasai> TabAtkins: then figure out flexbox
<fantasai> TabAtkins: then figure out design for fragments
<fantasai> TabAtkins: So for now would just add the grid and table version
<astearns> ack kbabbitt
<fantasai> kbabbitt: For fragmentation, wondering if we get into weird cases if e.g. left pages and right pages have different margins
<sgill> q+
<fantasai> florian: it's a giant can of worms, but I'm hoping that the containment constraints can help
<fantasai> florian: the Vivliostyle engine had features for this
<fantasai> florian: when you use these features, layout is not guaranteed to terminate
<TabAtkins> Ah, Flexbox and grid-lanes, rather. that's the second category. (layout-dependent but well-defined singular position)
<fantasai> florian: but we've solved that here, so can we extend to these use cases
<astearns> ack alisonmaher
<fantasai> florian: There really are a bajillion use cases
<fantasai> alisonmaher: In Grid you can have spanners, so you can be in multiple columns or rows. Is that not the same quest?
<fantasai> TabAtkins: you're right
<astearns> ack Kurt
<iank_> and that happens with tables as well.
<fantasai> Kurt: We wouldn't want the container query to set the grid area because then you have circularity
<iank_> (e.g. `<td colspan=2>`
<fantasai> TabAtkins: you don't have that because this only allows styling children of the grid item.
<astearns> ack sgill
<fantasai> sgill: Is there one caveat here with grid, where if you have several levels of nested subgrids, and then you change how it spans or something like that?
<fantasai> TabAtkins: I don't believe so?
<fantasai> TabAtkins: At least, rules for what is a valid container for you can make sure it's acceptable
<fantasai> iank_: I think you need "establishes an independent formatting context"
<fantasai> iank_: same as we do for container queries. subgrid can't participate in outer grid if it's a size container
<iank_> conditional-5 ?
<fantasai> https://www.w3.org/TR/css-conditional-5/
<astearns> ack fantasai
<iank_> conitional-6 !
<TabAtkins> fantasai: we do need to work on the spanning problem
<emilio> fantasai: re. spanning maybe you just return true on any?
<TabAtkins> TabAtkins: yeah figure out what queries we want
<TabAtkins> fantasai: also the syntax suggested is a bit complex, can do simpler than that
<TabAtkins> TabAtkins: agreed
<fantasai> astearns: Initial problems to chew over. Any objections to start working on this?
<fantasai> PROPOSED: Start working on spec for grid and tables in css-conditional-5
<fantasai> arronei: with likelihood that it goes to L6
<fantasai> RESOLVED: Start working on spec for grid and tables in css-conditional-5