- 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> ``` ![Percentage resolution on regular blocks](https://cloud.githubusercontent.com/assets/11602/18707334/744bbe40-7fed-11e6-8729-4362283ea8c3.png) 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> ``` ![Comparison between Chromium and Firefox resolving percentage margins](https://cloud.githubusercontent.com/assets/11602/18707391/c5fb4012-7fed-11e6-9087-8fe432b99739.png) 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> ``` ![Grid with percentage tracks](https://cloud.githubusercontent.com/assets/11602/18707475/24cb42ea-7fee-11e6-8b2f-81c1c95ed00b.png) 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 grid](https://cloud.githubusercontent.com/assets/11602/18707523/6c3b2cd0-7fee-11e6-8a89-8b68141a4151.png) 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> ``` ![Percentage tracks on a table with content](https://cloud.githubusercontent.com/assets/11602/18707509/53c1940a-7fee-11e6-8d9f-e5f312d2a515.png) 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> ``` ![Grid with percentage tracks and contents](https://cloud.githubusercontent.com/assets/11602/18707758/5cf3864a-7fef-11e6-86c3-ed66f9c382a1.png) 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