W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2016

[csswg-drafts] [css-grid] Percentages and intrinsic size

From: Manuel Rego Casasnovas via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Sep 2016 11:00:43 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-178313901-1474455640-sysbot+gh@w3.org>
mrego has just created a new issue for 

== [css-grid] Percentages and intrinsic size ==
There were some discussion on the TPAC but [we didn't arrive any 
conclusion regarding how percentages should be resolved during 
intrinsic size 
The only [resolution was that both tracks and gutters should resolve 
percentages in the same 

Basically we've some different options that I'll try to explain here 
and also compare with what we've on regular blocks and tables.

## 1. Percentage resolution for width on regular blocks

Let's start by the most basic stuff, how a percentage is resolved in a
 simple case like this:
  <div style="float: left; border: thick solid magenta;">
    <div style="width: 150%; background: cyan; font: 25px/1 Ahem;">XX 

![Percentage resolution on regular 

The behavior here is the same in any browser, and the 150% is resolved
 against the intrinsic size of the element (100px), in this case the 
result is 150px.
And the element overflows as the size of the container is 100px.

## 2. Percentage resolution for margins

However the discussion is now was triggered by the difference between 
Firefox and the rest of browsers resolving percentage on 
padding/border/margin (see issue #347 ).

A very simple example showcasing this:
  <div style="float: left; border: thick solid magenta;">
    <div style="margin-left: 20%; font: 25px/1 Ahem;">XXXX</div>

![Comparison between Chromium and Firefox resolving percentage 

Here Firefox does something different to the rest of the browsers in 
order to resolve the 20% margin. It uses the 100px intrinsic size, to 
compute back the percentages, so the final size of the container is 
125px and the 20% is resolved to 25px. To calculate the size the 
formula is basically: 100px / (1 - 0.2). The really good thing is that
 the element doesn't overflow the container.

The rest of the browsers resolve the 20% percentage against the 
intrinsic size of the element 100px. So they consider it as 20px. And 
the element overflows.

## 3. Percentage resolution for grid tracks

So now the question is what to do on grid tracks and gutters regarding
 how to resolve percentages on these situations.

Let's start by percentage tracks:
  <div style="display: inline-grid; grid: 100px / 50% 100px; border: 
thick solid magenta;">
    <div style="background: cyan;"></div>
    <div style="background: yellow;"></div>

![Grid with percentage 

Right now all the implementations have the same behavior here. The 50%
 track is resolved against the intrisic size of the grid container, 
which is 100px (the fixed track). So the percentage track has a 50px 
width. And the tracks overflow the grid container.

The idea was to check if we could do something similar to what Firefox
 does for margins on a regular block or not in the grid cases. If we 
follow that idea in this case the percentage track would be resolved 
to 100px and the the grid container will have 200px width so the 
tracks won't overflow.

![Back computing percentage tracks on a 

This is actually the same the behavior of tables in all browsers:
  <div style="display: table; border: thick solid magenta;">
    <div style="display: table-cell; width: 50%; height: 100px; 
background: cyan;"></div>
    <div style="display: table-cell; width: 100px; height: 100px; 
background: yellow;"></div>

However when you add content to the table, the behavior is different 
as the 2nd column grows more than the 100px width we set:
  <div style="display: table; font: 25px/1 Ahem; border: thick solid 
    <div style="display: table-cell; width: 50%; height: 100px; 
background: cyan;">XXXXXX</div>
    <div style="display: table-cell; width: 100px; height: 100px; 
background: yellow;"></div>

![Percentage tracks on a table with 

As you can see the first column is 150px (due to the content) and the 
2nd one is grown up to 150px, in order that the the intrinsic size of 
the table is 300px and the 50% of the first track is matches the 50% 
This shows the issues with back computing the percentages if the 
elements have contents.

Probably this doesn't make sense if we think on grid layout tracks, 
it'd be weird that a fixed track grows over their specific size. If we
 do a similar example with grid:
  <div style="display: inline-grid; grid: 100px / 50% 100px; font: 
25px/1 Ahem; border: thick solid magenta;">
    <div style="background: cyan;">XXXXXX</div>
    <div style="background: yellow; opacity: 0.8;"></div>

![Grid with percentage tracks and 

The percentage is resolved against the intrinsic size, which in this 
case is 150px (due to the contents on the first column) + 100px = 
250px. So the 50% of the column is resolved as 125px (the content 
would overflow), and the 2nd column keeps being 100px.
Again this is the current behavior in all the implementations.

And I believe the same would happen for both tracks and gutters. As a 
grid gap is not more than a fixed track with the given size from the 
track sizing algorithm point of view, but it can have contents if an 
item is spanning several tracks. So we might have similar issues 
regarding back computing percentage gaps.

## 4. Options

I think the options we've right now are:
A) Compute percentage tracks & gutters the same than we do in regular 
B) Compute percentage tracks & gutters as 0px for intrinsic size 
C) Back compute percentage tracks & gutters.

IMHO, I'd discard option C) due to the issues explained before when a 
percentage track has contents.
B) would mean a completely different behavior to the one in regular 
blocks. It could be ok as a specific behavior only for grid.
A) matches the current implementations.

What do you think? Opinions, feedback, corrections, etc. are welcomed.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/509 using your GitHub 
Received on Wednesday, 21 September 2016 11:00:57 UTC

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