Repository navigation
[css-gaps-1] Introduction of auto for rule-break properties. #13127
Description
We would like to introduce an auto keyword for the rule-break properties.
The goal is for auto to become the initial value for all rule-break longhands, with its resolved value depending on the layout type and axis. This makes the behavior future-extensible across layout models, and allows us control the default behavior to preserve reading behavior across different layout types.
Proposed resolution behavior
Grid containers
For grids, the default behavior would align naturally with how spanning items interrupt gap decorations:
rule-break: autocolumn-rule-break: auto→spanning-itemrow-rule-break: auto→spanning-item
Flex containers
Flex layouts do not have spanning behavior, so auto resolves to no interruptions:
rule-break: autocolumn-rule-break: auto→nonerow-rule-break: auto→none
Multicol containers
For multicol layouts, auto would currently resolve the same as Flex (pending resolutions in related issues):
rule-break: autocolumn-rule-break: auto→none
(subject to change depending on future multicol decisions)row-rule-break: auto→none
Even though today many of these resolved values would look similar across layout types, defining auto now makes the model extensible if new break behaviors or layout models are added in the future.
Activity
[gap-decorations] Introduce rule-break: auto
[gap-decorations] Introduce rule-break: auto
[gap-decorations] Introduce rule-break: auto
Bug 2004107 [wpt PR 56494] - [gap-decorations] Introduce rule-break: …
kbabbitt commentedon Jan 19, 2026
I think we should add this. Different container types have different sensible defaults, and this gives us the flexibility to do that. Proposal is to have an
autokeyword that computes to itself and selects a per-container default at used-value time as @jav099 suggested.css-meeting-bot commentedon Jan 28, 2026
The CSS Working Group just discussed
[css-gaps-1] Introduction of `auto` for `rule-break` properties., and agreed to the following:RESOLVED: rename 'spanning-item' to 'normal'RESOLVED: Allow rule-break: none to draw through spanners in multicolThe full IRC log of that discussion
<TabAtkins> javierct: currently default value for rule-break is spanning-item<TabAtkins> javierct: we were considering introducing an "auto" value, which resolves differently based on container
<TabAtkins> javierct: in grid, "spanning-item" in both axis. in flex, "none" in both. In multicol, spanning-item in cols and none in rows
<TabAtkins> javierct: so since different containers can have different sensible defaults, makes sense to have the flexibility to adjust that
<TabAtkins> florian: so in current impls they'd all be consistent, though?
<astearns> ack fantasai
<astearns> q+
<TabAtkins> javierct: yeah, in flex and Multicol there aren't spanning items, so spanning-item is identical to 'none'
<dholbert> q+
<TabAtkins> fantasai: then I don't see the reason to add a new value yet. we can add it in the future.
<oSamDavis> q+
<astearns> ack astearns
<fantasai> astearns: But spanning-item is a confusing keyword because it doesn't mean anything in the other modes than grid
<astearns> ack dholbert
<TabAtkins> fantasai: we could rename "spanning-item", then. call it "normal"
<astearns> ack oSamDavis
<TabAtkins> dholbert: yeah kinda weird to have two values that mean the same thing, then
<TabAtkins> oSamDavis: Multicol kinda has spanners, so...
<TabAtkins> fantasai: but you want the gap to break there
<TabAtkins> fantasai: the initial behavior both for grid and Multicol is to skip over spanning items
<TabAtkins> fantasai: I don't care whether we call it "normal" of "spanning-item", but it seems clear we can't use "none" for column-rule in multicol by default
<TabAtkins> oSamDavis: with "none" in multicol we don't go all the way thru the spanner.
<fantasai> oSamDavis: Those are two different gaps, one above and one below
<fantasai> fantasai: I don't understand why it needs to be different from grid
<fantasai> TabAtkins: I'm confused. under same impression as fantasai, can't be 'none' in the vertical direction
<fantasai> florian: Different notions of gaps. Their notion is that the gap isn't continuous through the spanner, they are two different gaps
<fantasai> florian: So nothing to skip or not skip
<fantasai> TabAtkins: Feels like exactly the same situation as Grid
<fantasai> Ian: For grid, if you have a spanner, you are explicitly spannning over a gap
<fantasai> Ian: But in multicol, you're creating two containers conceptually, so there isn't a continuous gap
<fantasai> Ian: So there aren't any column gaps under the spanner. There's no columns.
<fantasai> florian: For multicol that let's you select rows of multicol, and in my first row we have 3 columns, and in next row we have 2 columns
<fantasai> florian: They happen to line up, but they don't necessarily need to
<fantasai> florian: so wouldn't have a single continuous gap
<fantasai> TabAtkins: So currently multicol is grid-like, but could become more flex-like in the future
<fantasai> TabAtkins: I forget how junctions work with these properties, but now get the mental model.
<astearns> ack fantasai
<fantasai> javierct: spanning-item would be confusing in any case, so let's rename to normal
<fantasai> astearns: Me to
<fantasai> s/to/too
<astearns> s/javierct/oSamDavis/
<alisonmaher> q+
<TabAtkins> fantasai: okay, so true, the Multicol rows are like flex lines
<TabAtkins> fantasai: i'm not sure that authors will see it like that today, since it definitely looks grid-like
<TabAtkins> fantasai: for a spanner, I can see an author wanting a line continuous thru a spanning items. like if the spanner is an image, where the line is meant to be seen underneath it
<florian> q?
<florian> q+
<TabAtkins> fantasai: we could say if, in the future, Multicol rows aren't linked, then it becomes discontinuous (flex-like)
<TabAtkins> fantasai: but given the model we currently have, I think making it work like grid will make a more consistent mental model
<TabAtkins> fantasai: for authors at least
<TabAtkins> fantasai: and allow some cases you can't do if we insist the rule is broken at spans
<dholbert> q+
<TabAtkins> fantasai: and remember that while we currently have all-spanners only, we previously had spanners that only occupied a few columns
<TabAtkins> florian: and it's probably reasonably likely we will get different columns per Multicol row, but not per Multicol *line*, which is what the spanners separate
<astearns> ack alisonmaher
<TabAtkins> alisonmaher: in multicol, can a spanner go into more than one row
<TabAtkins> alisonmaher: with fragmentation, say
<TabAtkins> fantasai: ohhh, hm
<TabAtkins> astearns: if the spanner Fragments the containers
<TabAtkins> fantasai: for fragmentation, *all* of the modes have some interesting cases
<TabAtkins> alisonmaher: for the "normal" keyword we're proposing, would we also have "none" still?
<astearns> ack florian
<TabAtkins> florian: I think we're basically renaming the current spanning-item keyword to "normal". for Flexbox, "normal" and "none" would do the same thing
<TabAtkins> florian: so I think we're moving to the rename, grid has a different "none" behavior but flex's normal is the same as "none"
<oSamDavis> q+
<TabAtkins> florian: and maybe have another issue about the use-cases for a rule punching thru a span
<astearns> ack dholbert
<TabAtkins> dholbert: for "none" punching thru a spanner. it's already the case you can have different numbers of columns on either side. they're just guaranteed to be the same width
<TabAtkins> dholbert: because you might not create all the columns for the latter
<astearns> ack oSamDavis
<TabAtkins> fantasai: we have another property that controls whether rules are drawn between "empty" cols, so they do all exist for the perspective of these rules at least
<TabAtkins> oSamDavis: if we do want decos to punch thru a spanner, there has be a gap behind the spanner. the spec text would have to change to create e a gap there
<TabAtkins> fantasai: yeah, we could change how we describe that
<TabAtkins> fantasai: make a "virtual" gap behind the spanner
<astearns> ack fantasai
<Zakim> fantasai, you wanted to comment on fragmentation
<TabAtkins> fantasai: fragmentation creates separate row container
<TabAtkins> fantasai: Multicol on two pages is two row containers. different from the explicit splitting that spanners do
<TabAtkins> fantasai: three things, pagination, spanners, and now column-height
<TabAtkins> fantasai: I dunno the right answer, but if you define a gap deco that has some... say it's a dotted line. which of these splitting things would cause us to restart drawing the line, and which are continuous with the previous?
<TabAtkins> florian: I think there's two categories. splitting by column-height and pages is the same, that's "column rows"
<oSamDavis> q+
<TabAtkins> florian: across rows we'd restart painting
<TabAtkins> florian: but spanner is in a single "column row" so it would be continuous
<astearns> ack oSamDavis
<TabAtkins> fantasai: okay. same situation happens in grid, if it's split in the middle of a row
<TabAtkins> oSamDavis: i'm thinking about this as, whatever break doesn't add a virtual gap will start painting fresh
<alisonmaher> q+
<astearns> ack alisonmaher
<TabAtkins> alisonmaher: makes sense to me. I think there was an issue... a spanner could be split across two "column rows". unsure how we decided to resolve that
<TabAtkins> florian: I think this is double fragmentation. you're fragmenting the Multicol, *and* fragmenting the spanner
<TabAtkins> florian: first half is spanning in the first column row fragment, the second half is spanning in the second column row fragment
<TabAtkins> alisonmaher: okay, so it would cause a break in the painting there
<TabAtkins> TabAtkins: agree
<TabAtkins> astearns: okay, so it seems we have a consensus to rename default value from "spanning-item" to "normal"
<TabAtkins> javierct: is that also resolving to paint behind spanners?
<TabAtkins> astearns: talk about it later
<TabAtkins> dholbert: "normal", not "auto"?
<TabAtkins> fantasai: yeah, it's not magic based on stuff, it's just "the normal behavior"
<fantasai> fantasai: always skips spanning items
<TabAtkins> RESOLVED: rename 'spanning-item' to 'normal'
<TabAtkins> astearns: should we have a new issue for Multicol spanners, or resolve on it now?
<TabAtkins> fantasai: proposed resolution is, if you set column-rule-break:none on Multicol, it'll go thru a spanner just like in grid
<fantasai> PROPOSED: rule-break: none goes through multicol spanners just like in grid it goes through spanners
<TabAtkins> dholbert: slight concern with this. if you have less columns in the second row, what happens to the rest?
<fantasai> TabAtkins: in the missing columns they by default don't have rules drawn through them
<oSamDavis> q+
<TabAtkins> fantasai: I think same question in grid
<fantasai> fantasai: So we do the same thing. And if we don't like that thing, we should change it in both places.
<astearns> ack oSamDavis
<fantasai> oSamDavis: There is a way to control the visibility of decorations where it's beside empty areas
<fantasai> oSamDavis: which we have in grid and multicol
<fantasai> oSamDavis: So we can lean more into that property to control that behavior
<fantasai> oSamDavis: So we can use that to control where they draw in multicol
<fantasai> dholbert: If not drawing, then just stopping before the spanner makes sense. If you go through the spanner connecting to nothing, feels weird
<fantasai> fantasai: Depends what you're doing, but same question applies in Grid and should do the same thing.
<fantasai> alisonmaher: Grid has cells there. But Multicol doesn't create structures.
<fantasai> TabAtkins: If you have the control turned on, you will draw rules as if those columns existed.
<fantasai> alisonmaher: but not above
<fantasai> TabAtkins: Yes, above also.
<fantasai> dholbert: When it's not turned on though? Seems reasonable to stop at the spanner
<fantasai> TabAtkins: Should be the same thing as in Grid.
<astearns> ack fantasai
<TabAtkins> fantasai: we might want a control over whether "none" still goes thru a spanner when the other side is empty
<TabAtkins> fantasai: might in fact want it to be continuous thru the spanner in some cases
<dholbert> this is the example I'm looking at: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/14470
<TabAtkins> fantasai: I think it could go either way, but your proposal looks like a reasonable default
<fantasai> astearns: Yes, we need to consider the case. But does it affect this resolution, of making rule-break: none work on multicol
<fantasai> astearns: For now, any objections to allowing rule-break: none in multicol?
<fantasai> RESOLVED: Allow rule-break: none to draw through spanners in multicol
<dholbert> better link (removed inactive css): https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/14471
<TabAtkins> fantasai: at a higher level, between Multicol and grid, we have a lot of internal concepts in the spec that make Multicol and grid very different as impls, but from an author perspective it's a grid of lines with some spanners.
<TabAtkins> fantasai: so whether or not *we* think there's content there or not between the cases, *they* think about them more consistently. we should defer to that consistency even if it's extra work on our case
[gap-decorations] Rename rule-break value 'spanning-item' to 'normal'
[gap-decorations] Rename rule-break value 'spanning-item' to 'normal'
[gap-decorations] Rename rule-break value 'spanning-item' to 'normal'
Bug 2013628 [wpt PR 57449] - [gap-decorations] Rename rule-break valu…
kbabbitt commentedon Feb 12, 2026
WPT changes: web-platform-tests/wpt#57449
[css-gaps-1] Change `rule-break: spanning-item` to `rule-break: normal`