Multicol is a much older spec, and column-gap was pretty fundamental to it; removing it would maybe be confusing, especially since other parts of css-align also apply to multicol but are not implemented yet. Maybe we should just put a note?

It could be argued that leaving it is more confusing to future readers of the spec however given that we define column-gap elsewhere, and this a chance to sort that out.

Either way there should be a note explaining what happened, but it seems neater to have that note explaining the current situation, column-gap is now defined in box alignment and so we moved it, than explaining that column-gap is defined in box alignment but we also left it hanging around here because of history.

This came up because I was reading the spec with a group of authors in a workshop, and it seemed odd to explain this - their expectation was that this would be defined alongside the gap property for grid and flex.

In addition, the break properties were moved from the spec at some point so we already have one situation where we have done this.

I think handling https://drafts.csswg.org/css-multicol-1/#cg exactly the same way https://drafts.csswg.org/css-multicol-1/#break-before-break-after-break-inside is handled makes sense.

I agree. This change creates a single point of reference for column-gap, in the modern context of other gap properties – both big wins as an author. With linked notes from all the related specs, I don't see a down side.

Another option here is to:

• leave the definition in both places
• add a note in css-multicol-1 that in future levels, the property will be defined in CSS Box Alignment, starting with the definition in Box Alignment Level 1.

The idea of this would be to essentially have the first level of this property in css-multicol-1, the second level of this property in css-align-1, and then future evolution of it in css-align-*.

Don't we have the same situation here that we already had with justify-content and align-* properties defined in both [css-flexbox-1] and [css-align-3] simultaneously? IMHO, that precedent already showed some problems of such approach: it's really confusing, for both authors and implementors, and this confusion might lead to things like the infamous incomplete (Grid-only) implementation of new box alignment values in Blink.

What currently prevents moving the definition and replacing it with reference, as @meyerweb suggests? Is it the fact that [css-align-3] hasn't reached the CR status yet, unlike [css-break-3]? If so, maybe it would be better to speed up promoting [css-align-3] to CR and then moving the definition to it?

To be clear: moving as @rachelandrew suggests. I was just agreeing with her.

I have the same concerns about multiple points of definition. It risks divergence.

The CSS Working Group just discussed where do we define column-gap, and agreed to the following:

• RESOLVED: add an heading to explain how column-gap works in multicol, but define in box-alignment only