New issue
Advanced search Search tips

Issue 756859 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

[css-grid] grid item grid's item doesn't inherit the 1fr height from parent grid, overflows

Reported by utasirob...@gmail.com, Aug 18 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce the problem:
1. https://jsfiddle.net/utasir/gkx927wo/
2. load this reduced testcase on firefox and on chromium 
3. 

What is the expected behavior?
Whilst the overflow:auto defined on the child-grid's item, only that can be scrollable, not the whole parent grid.

What went wrong?
wrong height calculation when the item overflows

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 60.0.3112.90  Channel: canary
OS Version: 10.0
Flash Version: 

It's an overflow issue on 1fr height item.
Motivation: https://jsfiddle.net/utasir/kxy06m6b/
At this testcase I use tabbing layout and plan to use as fullscreen stuff, and only the tab-content is scrollable, not the whole tab-stuff. It works properly on Firefox, check testcases in both browsers. Checked on Canary channel as well, still affected. Verzió: 62.0.3189.0
 
Labels: Needs-Triage-M60

Comment 2 by shans@chromium.org, Aug 21 2017

Components: -Blink>CSS Blink>Layout
grid-template-rows doesn't inherit (https://www.w3.org/TR/css-grid-1/#track-sizing), but I'm guessing you want the layout size of the parent grid to be applied to the child. The CSS engine seems to be working correctly here so I'm redirecting to layout.

(As an aside: Which version of Firefox are you testing against? The version I have doesn't support grid, so doesn't seem valid as a comparison.)


> Which version of Firefox are you testing against?
FF 54.0.1
FF 55.0.2

Comment 4 by e...@chromium.org, Aug 21 2017

Components: -Blink>Layout Blink>Layout>Grid
Owner: svil...@igalia.com
Status: Assigned (was: Unconfirmed)
Cc: jfernan...@igalia.com
Cc: r...@igalia.com

Comment 7 by svil...@igalia.com, Aug 30 2017

This is totally unrelated to inheriting or flexible units. This is about how we handle percentages in heights, something that has been traditionally very controversial and not very well defined in specs.

You can check how removing the max-height:100%; in the .div class makes FF behave as Chromium does.

I'll take a look.

Comment 8 Deleted

Comment 9 by svil...@igalia.com, Sep 4 2017

OK, so I've investigated this issue and I concluded that it is not a bug but the expected behaviour. In order to get what you need you just need to replace in your example:

grid-template-rows: auto 1fr; 

by

grid-template-rows: auto minmax(0px, 1fr);

It looks like the difference is almost none but it's actually very important from the track sizing algorithm POV. The thing that leads to confusion is the meaning of 1fr. This used to be the same as minmax(1fr, 1fr) but as 1fr makes no sense as min track sizing function it was replaced by minmax(auto, 1fr). This is very important because it means that grids with fr units will first be sized to the min-content contribution size of the item and then they will grow till 1fr.

In your case, as you have a lot of text in the <div>, will cause <main> to grow a lot. I know that <main> is 100% height, and it looks like it's resolvable as the row (from the body element) is 1fr which can be directly translated to 100vh. The thing is that the algorithm that computes the tracks needs to resolve first the size of <main> in order to compute the minimum size of the track (because 1fr = minmax(auto,1fr)). So the size of the <main> grid is computed *before* 1fr is resolved. This means that the height:100%; from <main> is interpreted as auto because 1fr cannot be resolved yet.

This is not the first report we get about fr units. I think I'm raising an issue to the CSSWG because it's really confusing for authors.
Status: WontFix (was: Assigned)
BTW I've just raised the issue to the CSS WG https://github.com/w3c/csswg-drafts/issues/1777

Sign in to add a comment