W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2018

Re: [csswg-drafts] [css-grid] Percentages gaps and intrinsic size

From: Manuel Rego Casasnovas via GitHub <sysbot+gh@w3.org>
Date: Tue, 09 Jan 2018 11:22:39 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-356256873-1515496958-sysbot+gh@w3.org>
@mstensho The last discussion about what to do with percentage gaps was focused on the [following options from a previous comment](https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096):
* **B** = contribute zero, resolve as percent
* **D** = contribute zero, resolve as zero
* **F** = contribute zero, resolve as percent (for column-gap) or zero (for row-gap)

**F** is what currently is implemented in Chromium, Safari and Edge. Firefox has a different implementation to back-compute percentage gaps that was discarded for other issues.
This is following more or less the same line than what happens for percentage widths and heights on regular blocks.

During the discussion a clear goal was to make both `grid-column-gap` and `grid-row-gap` symmetric.
For that reason **F** was discarded and the options were **B** and **D**, and finally **D** was the selected one.

I agree with you that being able to resolve `grid-template-columns: 40% 40%;` in a floated grid container but not `grid-column-gap: 10%;` is somehow strange and not very intuitive.

Also knowing that for tracks it was decided to change the percentage rows behavior (see #1921) to be symmetric with what happens for percentage columns; maybe the choice for gaps should have been **B** instead of **D**.

GitHub Notification of comment by mrego
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/509#issuecomment-356256873 using your GitHub account
Received on Tuesday, 9 January 2018 11:22:42 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:22 UTC