- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 22:14:05 +0000
- To: public-css-archive@w3.org
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 multicol` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> javierct: currently default value for rule-break is spanning-item<br> <TabAtkins> javierct: we were considering introducing an "auto" value, which resolves differently based on container<br> <TabAtkins> javierct: in grid, "spanning-item" in both axis. in flex, "none" in both. In multicol, spanning-item in cols and none in rows<br> <TabAtkins> javierct: so since different containers can have different sensible defaults, makes sense to have the flexibility to adjust that<br> <TabAtkins> florian: so in current impls they'd all be consistent, though?<br> <astearns> ack fantasai<br> <astearns> q+<br> <TabAtkins> javierct: yeah, in flex and Multicol there aren't spanning items, so spanning-item is identical to 'none'<br> <dholbert> q+<br> <TabAtkins> fantasai: then I don't see the reason to add a new value yet. we can add it in the future.<br> <oSamDavis> q+<br> <astearns> ack astearns<br> <fantasai> astearns: But spanning-item is a confusing keyword because it doesn't mean anything in the other modes than grid<br> <astearns> ack dholbert<br> <TabAtkins> fantasai: we could rename "spanning-item", then. call it "normal"<br> <astearns> ack oSamDavis<br> <TabAtkins> dholbert: yeah kinda weird to have two values that mean the same thing, then<br> <TabAtkins> oSamDavis: Multicol kinda has spanners, so...<br> <TabAtkins> fantasai: but you want the gap to break there<br> <TabAtkins> fantasai: the initial behavior both for grid and Multicol is to skip over spanning items<br> <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<br> <TabAtkins> oSamDavis: with "none" in multicol we don't go all the way thru the spanner.<br> <fantasai> oSamDavis: Those are two different gaps, one above and one below<br> <fantasai> fantasai: I don't understand why it needs to be different from grid<br> <fantasai> TabAtkins: I'm confused. under same impression as fantasai, can't be 'none' in the vertical direction<br> <fantasai> florian: Different notions of gaps. Their notion is that the gap isn't continuous through the spanner, they are two different gaps<br> <fantasai> florian: So nothing to skip or not skip<br> <fantasai> TabAtkins: Feels like exactly the same situation as Grid<br> <fantasai> Ian: For grid, if you have a spanner, you are explicitly spannning over a gap<br> <fantasai> Ian: But in multicol, you're creating two containers conceptually, so there isn't a continuous gap<br> <fantasai> Ian: So there aren't any column gaps under the spanner. There's no columns.<br> <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<br> <fantasai> florian: They happen to line up, but they don't necessarily need to<br> <fantasai> florian: so wouldn't have a single continuous gap<br> <fantasai> TabAtkins: So currently multicol is grid-like, but could become more flex-like in the future<br> <fantasai> TabAtkins: I forget how junctions work with these properties, but now get the mental model.<br> <astearns> ack fantasai<br> <fantasai> javierct: spanning-item would be confusing in any case, so let's rename to normal<br> <fantasai> astearns: Me to<br> <fantasai> s/to/too<br> <astearns> s/javierct/oSamDavis/<br> <alisonmaher> q+<br> <TabAtkins> fantasai: okay, so true, the Multicol rows are like flex lines<br> <TabAtkins> fantasai: i'm not sure that authors will see it like that today, since it definitely looks grid-like<br> <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<br> <florian> q?<br> <florian> q+<br> <TabAtkins> fantasai: we could say if, in the future, Multicol rows aren't linked, then it becomes discontinuous (flex-like)<br> <TabAtkins> fantasai: but given the model we currently have, I think making it work like grid will make a more consistent mental model<br> <TabAtkins> fantasai: for authors at least<br> <TabAtkins> fantasai: and allow some cases you can't do if we insist the rule is broken at spans<br> <dholbert> q+<br> <TabAtkins> fantasai: and remember that while we currently have all-spanners only, we previously had spanners that only occupied a few columns<br> <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<br> <astearns> ack alisonmaher<br> <TabAtkins> alisonmaher: in multicol, can a spanner go into more than one row<br> <TabAtkins> alisonmaher: with fragmentation, say<br> <TabAtkins> fantasai: ohhh, hm<br> <TabAtkins> astearns: if the spanner Fragments the containers<br> <TabAtkins> fantasai: for fragmentation, *all* of the modes have some interesting cases<br> <TabAtkins> alisonmaher: for the "normal" keyword we're proposing, would we also have "none" still?<br> <astearns> ack florian<br> <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<br> <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"<br> <oSamDavis> q+<br> <TabAtkins> florian: and maybe have another issue about the use-cases for a rule punching thru a span<br> <astearns> ack dholbert<br> <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<br> <TabAtkins> dholbert: because you might not create all the columns for the latter<br> <astearns> ack oSamDavis<br> <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<br> <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<br> <TabAtkins> fantasai: yeah, we could change how we describe that<br> <TabAtkins> fantasai: make a "virtual" gap behind the spanner<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to comment on fragmentation<br> <TabAtkins> fantasai: fragmentation creates separate row container<br> <TabAtkins> fantasai: Multicol on two pages is two row containers. different from the explicit splitting that spanners do<br> <TabAtkins> fantasai: three things, pagination, spanners, and now column-height<br> <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?<br> <TabAtkins> florian: I think there's two categories. splitting by column-height and pages is the same, that's "column rows"<br> <oSamDavis> q+<br> <TabAtkins> florian: across rows we'd restart painting<br> <TabAtkins> florian: but spanner is in a single "column row" so it would be continuous<br> <astearns> ack oSamDavis<br> <TabAtkins> fantasai: okay. same situation happens in grid, if it's split in the middle of a row<br> <TabAtkins> oSamDavis: i'm thinking about this as, whatever break doesn't add a virtual gap will start painting fresh<br> <alisonmaher> q+<br> <astearns> ack alisonmaher<br> <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<br> <TabAtkins> florian: I think this is double fragmentation. you're fragmenting the Multicol, *and* fragmenting the spanner<br> <TabAtkins> florian: first half is spanning in the first column row fragment, the second half is spanning in the second column row fragment<br> <TabAtkins> alisonmaher: okay, so it would cause a break in the painting there<br> <TabAtkins> TabAtkins: agree<br> <TabAtkins> astearns: okay, so it seems we have a consensus to rename default value from "spanning-item" to "normal"<br> <TabAtkins> javierct: is that also resolving to paint behind spanners?<br> <TabAtkins> astearns: talk about it later<br> <TabAtkins> dholbert: "normal", not "auto"?<br> <TabAtkins> fantasai: yeah, it's not magic based on stuff, it's just "the normal behavior"<br> <fantasai> fantasai: always skips spanning items<br> <TabAtkins> RESOLVED: rename 'spanning-item' to 'normal'<br> <TabAtkins> astearns: should we have a new issue for Multicol spanners, or resolve on it now?<br> <TabAtkins> fantasai: proposed resolution is, if you set column-rule-break:none on Multicol, it'll go thru a spanner just like in grid<br> <fantasai> PROPOSED: rule-break: none goes through multicol spanners just like in grid it goes through spanners<br> <TabAtkins> dholbert: slight concern with this. if you have less columns in the second row, what happens to the rest?<br> <fantasai> TabAtkins: in the missing columns they by default don't have rules drawn through them<br> <oSamDavis> q+<br> <TabAtkins> fantasai: I think same question in grid<br> <fantasai> fantasai: So we do the same thing. And if we don't like that thing, we should change it in both places.<br> <astearns> ack oSamDavis<br> <fantasai> oSamDavis: There is a way to control the visibility of decorations where it's beside empty areas<br> <fantasai> oSamDavis: which we have in grid and multicol<br> <fantasai> oSamDavis: So we can lean more into that property to control that behavior<br> <fantasai> oSamDavis: So we can use that to control where they draw in multicol<br> <fantasai> dholbert: If not drawing, then just stopping before the spanner makes sense. If you go through the spanner connecting to nothing, feels weird<br> <fantasai> fantasai: Depends what you're doing, but same question applies in Grid and should do the same thing.<br> <fantasai> alisonmaher: Grid has cells there. But Multicol doesn't create structures.<br> <fantasai> TabAtkins: If you have the control turned on, you will draw rules as if those columns existed.<br> <fantasai> alisonmaher: but not above<br> <fantasai> TabAtkins: Yes, above also.<br> <fantasai> dholbert: When it's not turned on though? Seems reasonable to stop at the spanner<br> <fantasai> TabAtkins: Should be the same thing as in Grid.<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: we might want a control over whether "none" still goes thru a spanner when the other side is empty<br> <TabAtkins> fantasai: might in fact want it to be continuous thru the spanner in some cases<br> <dholbert> this is the example I'm looking at: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/14470<br> <TabAtkins> fantasai: I think it could go either way, but your proposal looks like a reasonable default<br> <fantasai> astearns: Yes, we need to consider the case. But does it affect this resolution, of making rule-break: none work on multicol<br> <fantasai> astearns: For now, any objections to allowing rule-break: none in multicol?<br> <fantasai> RESOLVED: Allow rule-break: none to draw through spanners in multicol<br> <dholbert> better link (removed inactive css): https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/14471<br> <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.<br> <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<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13127#issuecomment-3814200432 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 22:14:06 UTC