[css-grid] Percentage tracks and indefinite sizes

[mrego]

This is an issue extracted from #509 (so we can leave #509 only for percentage gaps/gutters).

The behavior of percentage rows has been modified back in September to reflect a resolution from Seatle F2F meeting on January.
The new text of the spec says:

If the size of the grid container depends on the size of its tracks, then the <percentage> must be treated as auto, for the purpose of calculating the intrinsic sizes of the grid container and then resolve against that resulting grid container size for the purpose of laying out the grid and its items.

All the implementations have shipped the previous behavior (percentage rows are treated as auto and never resolved) and are interoperable regarding this. In addition, AFAIK nobody has updated them to follow the new behavior described in the spec.

At the same time we believe that implementing the new behavior might not be that easy, mainly because of the height is usually an output of the width, and you cannot do the same operations in both axis.

I've wrote a codepen trying to explain one of the issues which is the fact that we might need an extra pass of the track sizing algorithm to properly follow this resolution.

The problem is a combination of spanning items with percentage tracks.

• Columns grid-template-columns: auto 10% auto
  We don't find issues here, during the intrinsic width computation the percentage is treated as auto. In the example the columns have 84px 324px 84px, so the intrinsic width is 492px.
  
  Then during the layout phase we resolve the percentage column against the intrinsic width, 10% of 492px which would be 49px, and the 1st and 3rd column are still auto so they grow as needed to fit the spanning item (final sizes are 221.5px 49px 221.5px).
  

• Rows grid-template-rows: auto 10% auto
  This is the tricky part as there isn't a phase to compute the intrinsic height.
  So during layout we initially treat the percentage row as auto. In the example the rows are 20px 100px 20px.
  
  Then if we decide to use that as intrinsic height (140px) the 2nd row should be resolved as 10% of 140px which is 14px. At this point we'll have the following rows 20px 14px 20px, if we don't do an extra pass we'll have overflow with auto rows which doesn't make sense.
  
  To get a good result we'd need to do an extra pass of the track sizing algorithm considering a fixed size for the percentage row, something like grid-template-rows: auto 14px auto. In that case the auto tracks will grow as needed to accommodate the sapping item (the final sizes are 63px 14px 63px).
  

The purposes of this issue are 2:

1. Verify that this is the expected behavior, and probably modify the spec accordingly to explain these extra pass (and maybe how all this can be combined with orthogonal spanning items if that brings or not more issues).
2. Check with other implementors if they're willing to support this new behavior for percentage rows (CC @atanassov and @MatsPalmgren).

Thanks for your time and sorry for the neverending story. 😇

[css-meeting-bot]

The Working Group just discussed Percentage tracks, and agreed to the following resolutions:

• RESOLVED: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases

The full IRC log of that discussion

<frremy> Topic: Percentage tracks
<fantasai> Github: https://github.com//issues/1921
<Rossen> github:https://github.com//issues/1921
<frremy> lajava: To keep things symmetric, we tried to add cases to resolve percentages for height of rows
<frremy> lajava: But we don't have min-content phase in the block direction, like we do for width
<frremy> lajava: So we would need to duplicate a second pass to make this work
<frremy> lajava: So 1st we would like this recorded clearly in the spec if that is required
<frremy> lajava: And all browsers would have to change their implementation
<frremy> florian: and why not just follow what browsers already have implemented?
<frremy> Rossen: the change would be relatively straighforward, it's no big deal
<frremy> florian: but we would possibly break content, right?
<frremy> Rossen: everything we do ends up breaking someone's content, I don't think this would be an issue here
<frremy> lajava: well, we are still unsure about what would happen in more complex cases like in orthogonal flows
<frremy> lajava: but at the very least it would require a second pass, once you know the intrinsic height
<frremy> Rossen: any opinion from Mozilla?
<frremy> Rossen: there is still time to fix, but window is closing
<frremy> dholbert: I don't have a strong opinion, and Matt hasn't commented on the issue
<frremy> dholbert: I don't like adding new layout steps usually
<frremy> Rossen: but it's easy to know if you need to do it before hand
<frremy> Rossen: only do it if you have percentage-sized row tracks
<frremy> dholbert: but if it is an orthogonal flow, you have to relayout entirely right?
<frremy> lajava: yes, but this already happens anyway
<dholbert> s/Matt/Mats/
<frremy> Rossen: any objection?
<frremy> RESOLVED: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases

[fantasai]

To clarify, the spec is currently written in conformance with the above resolution (see https://drafts.csswg.org/css-grid-1/#valdef-grid-template-columns-length-percentage and https://drafts.csswg.org/css-grid-1/#intrinsic-sizes). But overall what's happening doesn't seem to be very clearly described.

Afaict, we could describe what is happening as the following (which is then implemented differently in UAs in order to optimize the number of passes):

1. Size the Grid Container (per axis, for both axes)

• If it is definite, just get that size.
• If it is indefinite, run the grid sizing algorithm under min/max-content constraints, treating percentages as auto, in order to find the indefinite size.

2. Size the Grid

• Run the grid sizing algorithm under normal constraints: auto behaves as auto, and percentages resolve against the size of the grid container as calculated in step [css-syntax] Add a Previous Version link to the CR. #1.

Does this seem correct, or are there shortcuts under #1 that aren't reflected here?

[mrego]

Does this seem correct, or are there shortcuts under #1 that aren't reflected here?

Yes, probably that would be fine, despite Blink/WebKit implementation don't do that. So for us it'll imply an extra pass as described in #1 but probably that's just an implementation detail that shouldn't be considered in the spec.

Regarding this change, I've been checking it again and all browsers (Chromium, Firefox, Edge and Safari) have the old behavior (percentage rows are treated as auto and never resolved), so we currently have interoperability here.
We're not planing to change Blink/WebKit implementations until other browsers do it, so please @dholbert, @MatsPalmgren, @atanassov notify here when you update this.
At the same time we're going to add a use counter, as this has been working like this for a long time (3 Chromium versions, 4 Firefox versions, 1 Edge version and 2 Safari versions) and height: auto is the default, so we want to know how many websites will be affected if we implement this change.

[css-meeting-bot]

The Working Group just discussed [css-grid] Percentage tracks and indefinite sizes.

The full IRC log of that discussion

<dael> Topic: [css-grid] Percentage tracks and indefinite sizes
<dael> github: https://github.com//issues/1921#issuecomment-347993853
<dael> astearns: We decided on a change, but it was pointed out impl have interop.
<dael> fantasai: We discussed that at tpac. We re-resolved to do the thing impl don't do. THis is the are you sure you meant the thing.
<dael> florian: We took impl into account when we decided, yes?
<dael> fantasai: We did.
<dael> TabAtkins: We just want to be able to mark WG is cool with this.
<dael> astearns: I'm looking at tpac discussion and I see Rossen_ said this is fine, not a big deal.
<dael> TabAtkins: He jsut didn't want to do it alone b/c it's a breaking change.
<dael> Rossen_: That's true. That's still my point. I'm still okay as long as others do the change as well.
<dael> Rossen_: We're still cool. Others?
<dael> astearns: webkit or gecko?
<dael> dbaron: It's a question for Mats or dholbert
<dael> astearns: dholbert deferred to Mats
<dael> astearns: Given we have two impl willing to make the change and no obj from the others, shall we reaffirm we want this change?
<dael> astearns: Objections?
<dael> dbaron: Who will change first?
<dael> dbaron: If no one will do that we shouldn't do it.
<dael> fantasai: Rossen_ it looks like webkit and blink will follow if you lead.
<fantasai> mrego said “We're not planing to change Blink/WebKit implementations until other browsers do it”
<dael> Rossen_: I won't do it the same way we tried with control characters. I will allow the market leader to lead and we will happily follow. The change is straight forward, but I don't want to introduce interop change.
<dael> Rossen_: For technical decision I'm fine. For scheduling and who when, we won't be first.
<dael> fantasai: Rego said they won't change until other broswers do it. Igalia folks are good about following up so I don't think it'll get lost. But it will require MS to go first or at least say it's impla ndwill release on a date as long as WB and blink will also trigger.
<dael> Rossen_: How about we table scheduling discussion. If it's as easy for Rego and Igalia as it is for us, let's stop the discussion and we'll discuss timing. As far as spec decision is concerned we'll ship first as long as there are assurances others will follow.
<dael> rego: We checked how many chases will go through this. We first want to gather data on how many websites will break with this change.
<dael> Rossen_: You want us to change to see breakage?
<dael> rego: No, we added a use counter in chromium to gather data. So we want to wait to gather some data before doing anything.
<dael> Rossen_: Sounds good. Let us know that data and what it shows.
<dael> rego: Sure.
<dael> astearns: So anything more on this issue?
<dael> Rossen_: Is take away everyone is still okay pending some data collection from Igalia folks?
<rego> astearns, good summary :-)
<dael> astearns: Yes, pending data collection, impl complexity, and timing of all engines getting change done.