New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
Closed: Jan 2018
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue 761904

Sign in to add a comment

Issue 799413: [css-multicol] Support percentages in column-gap

Reported by, Jan 5 2018 Project Member

Issue description

Edge is the only browser supporting percentages in "column-gap" at this point.
However all browsers support percentage in "grid-column-gap", which will be renamed to "column-gap" ( issue #761904 ).
So it seems it'd be a nice moment to add support in Multicolumn too.

The Multicolumn spec has not any special text regarding this (,
however it's worth noticing the text in css-align spec (
  "Percentages resolve to zero when specified against a content-based size
   (such as the logical width of a float or the auto logical height of a block-level grid container)."

Note that there's some ongoing discussion with the CSS WG to clarify it:

I believe the text in the spec needs to be changed for "column-gap",
as the width is always definite during layout, so we have to resolve the percentages.
At least I don't see how in Blink/WebKit we could detect the cases that try to cover the new text in the spec,
things like the width of a floated element is only indefinite during intrinsic size computation
(when the percentages are treated as 0)
but during layout we've a definite width to resolve percentages against it.
IMHO this should work like percentages widths work on regular blocks.

Comment 1 by, Jan 5 2018

Blocking: 761904

Comment 2 by, Jan 5 2018

Is it really blocking, though? Can't we just allow percentages in the CSS parser and store it as a Length (and not a float) in ComputedStyle? Multicol can just treat % as 0 until it gets implemented.

Comment 3 by, Jan 5 2018

We could do that, but IMHO it'd be strange that the paring is ok and then nothing happens when you use a percentage.

We're not in a hurry to unprefix the other properties that's why I marked the dependency, but it's more a nice to have than a real block as you said.
Also we could help implementing this, but first we need the input from the CSS WG.

Other option would be to implement it just like we think it should be, resolving the percentages always (like for regular blocks).
That's what Edge is currently shipping for example, and what Chromium, Safari and Edge are currently shipping for grid-column-gap too.
And at some point in the future update the implementation if the CSS WG clarifies things and a different behavior is agreed.

Comment 4 by, Jan 5 2018

Yeah, parsing percents but not acting upon it in multicol would be a bug (this bug), but a short-lived one. I promise. :) If somebody wants to do the plumbing in css/ and style/ , I should be able to fix it quickly for multicol (as long as I have a ComputedStyle::ColumnGap() that can return percents).

Comment 5 by, Jan 7 2018

Status: Available (was: Untriaged)

Comment 6 by, Jan 19 2018

Status: Started (was: Available)

Comment 7 by, Jan 23 2018

Project Member
The following revision refers to this bug:

commit 0eb06307382a59b1d66afa66703cdc95a2b7ca2e
Author: Manuel Rego Casasnovas <>
Date: Tue Jan 23 21:29:40 2018

[css-multicol] Support percentages in column-gap

This patch adds percentage support to column-gap property.

Most of the changes are related to the parsing logic,
the column-gap property now accepts both length and percentages,
on top of the "normal" initial value.
A new utility class GapLength has been added, as it'll be useful
to implement row-gap in the future.

Apart from that the muticolumn layout code has been modified
to resolve the percentage gaps (treating them as zero while computing
preferred widths) and resolving them during layout.
This doesn't follow the current text on the spec, but there is an
ongoing discussion that might cause the text is changed:
We could update the implementation once we have a definitive answer
from the CSS WG.

Added a new WPT test to check the behavior under different
sizing conditions.

BUG= 799413 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Icccd046e913353b6f525481046a41ad125aea5ff
Reviewed-by: meade_(do not use) <>
Reviewed-by: Darren Shen <>
Reviewed-by: Christian Biesinger <>
Reviewed-by: Morten Stenshorne <>
Commit-Queue: Morten Stenshorne <>
Cr-Commit-Position: refs/heads/master@{#531356}

Comment 8 by, Jan 23 2018

I'm closing this, if finally we need to do some changes due to CSSWG discussions we could create a new bug to track that work.

Comment 9 by, Jan 23 2018

Status: Fixed (was: Started)

Sign in to add a comment