- 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
mrego has just created a new issue for
https://github.com/w3c/csswg-drafts:
== [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
computation](https://logs.csswg.org/irc.w3.org/css/2016-09-20/#e724669).
The only [resolution was that both tracks and gutters should resolve
percentages in the same
way](https://logs.csswg.org/irc.w3.org/css/2016-09-20/#e724644).
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:
```html
<div style="float: left; border: thick solid magenta;">
<div style="width: 150%; background: cyan; font: 25px/1 Ahem;">XX
X</div>
</div>
```
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:
```html
<div style="float: left; border: thick solid magenta;">
<div style="margin-left: 20%; font: 25px/1 Ahem;">XXXX</div>
</div>
```
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:
```html
<div style="display: inline-grid; grid: 100px / 50% 100px; border:
thick solid magenta;">
<div style="background: cyan;"></div>
<div style="background: yellow;"></div>
</div>
```
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.
This is actually the same the behavior of tables in all browsers:
```html
<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>
</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:
```html
<div style="display: table; font: 25px/1 Ahem; border: thick solid
magenta;">
<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>
</div>
```
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%
computation.
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:
```html
<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>
</div>
```
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
blocks.
B) Compute percentage tracks & gutters as 0px for intrinsic size
computations.
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
account
Received on Wednesday, 21 September 2016 11:00:57 UTC