[css-multicol] Should we refer to definition of `column-gap` in Box Alignment?

[rachelandrew]

In the multicol spec we define column-gap: https://drafts.csswg.org/css-multicol-1/#cg

The use of column-gap in multicol is also defined in Box Alignment: https://www.w3.org/TR/css-align-3/#column-row-gap

Should we deal with this in the way that gaps are dealt with in grid (https://www.w3.org/TR/css-grid-1/#gutters). Removing the table and then mentioning anything specific to this layout method?

[fantasai]

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?

[rachelandrew]

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.

[meyerweb]

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.

[mirisuzanne]

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.

[dbaron]

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-*.

[SelenIT]

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?

[meyerweb]

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.

[css-meeting-bot]

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

The full IRC log of that discussion

<fremy> Topic: where do we define column-gap
<astearns> github: https://github.com//issues/3641
<fremy> rachelandrew______: we define column-gap in multicol and box alignment
<fremy> rachelandrew______: authors were discussing how confusing that was
<fremy> rachelandrew______: I'd rather define column-gap in alignment, and just mention the specificities of column-gap for columns in multicol
<fremy> florian: we kinda did the same thing for break properties, where they usually were defined in multiple places, and now we consolidated in css-break and we added notes to the other places
<fremy> AmeliaBR: we should consider REC progress though, so we don't get stuck
<fremy> fantasai: css-align is really close to REC, so I don't think that would be an issue
<fantasai> s/REC/CR/
<fremy> fantasai: the only remaining issue is baseline alignment
<fremy> fantasai: and we could move that to the next level
<fantasai> s/issue/significant source of issues/
<fremy> AmeliaBR: then that seems fine
<fremy> astearns: suggested edit is to add an heading to explain how column-gap works in multicol, but define in box-alignment only
<fremy> astearns: any objection?
<fremy> RESOLVED: add an heading to explain how column-gap works in multicol, but define in box-alignment only
<fremy> (and link between them)
<AmeliaBR> s/astearns: suggested/rachelandrew______: suggested/