Intent to Implement and Ship: Update behavior of CSS Grid Layout percentage row tracks and gutters

[Manuel Rego Casasnovas]

**Contact emails**

re...@igalia.com

**Summary**

The CSS Working Group (CSSWG) has been discussing for a long time
about the behavior of percentage row tracks and gutters
when the grid container's height is indefinite.
There have been resolutions on different meetings about these topics
and it seems things are now settle down.
The relevant GitHub issues are:
* Percentage row tracks: https://github.com/w3c/csswg-drafts/issues/1921
* Percentage row gutters: https://github.com/w3c/csswg-drafts/issues/509

The current spec texts for each of these topics are:
*
https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-length-percentage
* https://drafts.csswg.org/css-align-3/#propdef-row-gap

So far percentage rows (both tracks and gutters) were behaving
like percentage heights in regular blocks when the container's height
is indefinite. So they were basically treated like an "auto" height
(for gutters that means 0px gap).
The intention of the CSSWG is to make Grid Layout as symmetric
as possible, for that reason they resolved to change the behavior
of percentage row tracks and gutters, to work similar to
percentage column tracks and gutters.

For columns the percentage is ignored during intrinsic widths
computation, and later it's resolved against that intrinsic width
during layout.
The idea is to do something similar for rows, but we don't have
an intrinsic heights computation phase. So we'd need to layout the grid
ignoring percentages to calculate the intrinsic height,
and use that height we have just computed to resolve
the percentages rows later (this could lead to a double-pass
in the track sizing algorithm to get proper results).

**Motivation**

It seems web authors prefer to have this kind of symmetric behavior
for percentages in both columns and rows in CSS Grid Layout.
Also the CSSWG has had long discussions about the topic
and it seems everyone is now on the same page regarding this topic.

In addition, Firefox has already implemented this change
for row gutters. So we'd start to have interoperability issues
if we don't do it too. Note that Firefox hasn't implemented it
for row tracks yet, but they seem to align with the current resolution.

**Risks**

**Interoperability and Compatibility**

We have a use counter for percentage row tracks in grid containers
with indefinite heights. These cases would be the ones
that will change their behavior.
The use counter
(https://www.chromestatus.com/metrics/feature/timeline/popularity/2248)
right now shows that a 0.0318% of websites
would be affected, the number is increasing as Grid Layout
is being adopted.
If we check the usage of CSS Grid Layout
(https://www.chromestatus.com/metrics/feature/timeline/popularity/1693)
we see that 0.9019%
of websites use it right now.
Doing a simple calculation we can say that 3.53% of websites
using Grid Layout would be affected by this change.

The plan would be to land this at the beginning of the cycle
after the branch for M69 (during next weeks) and then we'd have time
to revert if many of these sites report issues with the new behavior.

BTW, we don't have a use counter for percentage row gutters.

* Edge: Public support. Rossen Atanassov was always supporting
the idea of making CSS Grid Layout as symmetric as possible.
He mentioned in some of the CSSWG discussions that Microsoft
would update their implementation once Chromium does it.
* Firefox: Shipped/Public support. As mentioned previously Firefox
has already implemented this change for percentage row gutters,
as part of that work they modified some WPT tests that are now failing
on Blink. Regarding percentage row tracks Mats Palmgren
seems happy with the resolution although he is asking
for some clarifications on the spec, but not behavior changes.
As a related note it's important to highlight that Firefox
is adding gutters support for Flexbox and they'll be following
this new behavior in that case too.
* Safari: No signals. As Igalia is maintaining CSS Grid Layout in WebKit
we'd take care of updating the implementation there (once this is done
in Chromium).
* Web developers: Jen Simmons and Rachel Andrew have been following
the CSSWG issues and they both seem to be fine with
the current resolutions.

All these can be checked in the two Github issues linked before.

**Ergonomics**

Nothing to highlight here.

**Activation**

We don't think anything special it's needed here.

**Debuggability**

Again nothing special, the percentage would be resolved to some
different amount of pixels, that's all.

**Will this feature be supported on all six Blink platforms (Windows,
Mac, Linux, Chrome OS, Android, and Android WebView)?**

Yes.

**Is this feature fully tested by web-platform-tests?**

As part of the CL that implements this we'll be adding the required
web platform tests to ensure compatibility with other implementations.
Regarding percentage row gutters there are already WPT tests that
we're currently failing (since Firefox implemented the new behavior):
* http://w3c-test.org/css/css-grid/alignment/grid-gutters-009.html
* http://w3c-test.org/css/css-grid/alignment/grid-gutters-010.html

For percentage row tracks we're adding two tests covering the cases
where a 2nd pass of the track sizing algorithm is required too.
Check the new WPT tests in the CL implementing this change:
https://chromium-review.googlesource.com/c/chromium/src/+/1142409

**Link to entry on the feature dashboard**

https://www.chromestatus.com/feature/6708326821789696

**Requesting approval to ship?**

Yes.

[Yoav Weiss]

LGTM1

Seems like this change runs a risk of breaking a good chunk of early adopters. Also seems like that risk will only get bigger as time goes on.

The plan would be to land this at the beginning of the cycle
after the branch for M69 (during next weeks) and then we'd have time
to revert if many of these sites report issues with the new behavior.

Having time to revert in case of excessive breakage sounds like a good plan.

 

BTW, we don't have a use counter for percentage row gutters.

* Edge: Public support. Rossen Atanassov was always supporting
  the idea of making CSS Grid Layout as symmetric as possible.
  He mentioned in some of the CSSWG discussions that Microsoft
  would update their implementation once Chromium does it.
* Firefox: Shipped/Public support. As mentioned previously Firefox
  has already implemented this change for percentage row gutters,
  as part of that work they modified some WPT tests that are now failing
  on Blink. Regarding percentage row tracks Mats Palmgren
  seems happy with the resolution although he is asking
  for some clarifications on the spec, but not behavior changes.
  As a related note it's important to highlight that Firefox
  is adding gutters support for Flexbox and they'll be following
  this new behavior in that case too.

OK, so we need to change behavior if we want to "have their back" from a compat perspective...

 

* Safari: No signals. As Igalia is maintaining CSS Grid Layout in WebKit
  we'd take care of updating the implementation there (once this is done
  in Chromium).

Good to hear you'll follow this change with WebKit changes.

 

* Web developers: Jen Simmons and Rachel Andrew have been following
  the CSSWG issues and they both seem to be fine with
  the current resolutions.

Seems like we'll need some outreach help here to make sure Grid early adopters are aware of this change. Having Jen and Rachel on board will be very helpful on that front.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/30aaeaf6-a447-ce27-4cc3-318e363e5ccb%40igalia.com.

[Philip Jägenstedt]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhMC6gPzixVFcbzmoT5Lco%3DX1Xgg5W72Wqw0Bt4y%2Br_ew%40mail.gmail.com.

[Chris Harrelson]

LGTM3, with caveat:

1. Please check the top sites that hit the use counter for breakage and report back to this thread with findings.

2. There should be an outreach/article effort from the Chrome devrel team to make developers aware. Is this already in progress? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYe2Pn4K9O9LgqbPWTsuShp8SkVFkhmoOfM18NUkLthWwA%40mail.gmail.com.

[Manuel Rego Casasnovas]

On 19/07/18 19:16, 'Chris Harrelson' via blink-dev wrote:
> 1. Please check the top sites that hit the use counter for breakage and
> report back to this thread with findings.

I'm not sure if non-googlers have access to this kind of information.
If that's the case please tell me how to get it (as I don't know how it
works), otherwise please someone from Google check the info and share it
in this thread.

The use counter is:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2248

> 2. There should be an outreach/article effort from the Chrome devrel
> team to make developers aware. Is this already in progress?

I guess this would be covered in the blog post announcement of M70 (I'd
probably write a post in my personal blog but I guess that's irrelevant
regarding this). Dunno if I have to contact someone from Chrome devrel
team regarding this.

JFTR, I added some basic examples in the chromestatus entry:
https://www.chromestatus.com/feature/6708326821789696

BTW, the workaround would be as simple as using "auto" for tracks and
"0px" for gutters.

Thanks,
Rego

[Philip Jägenstedt]

On Fri, Jul 20, 2018 at 1:07 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:
>
>
> On 19/07/18 19:16, 'Chris Harrelson' via blink-dev wrote:
> > 1. Please check the top sites that hit the use counter for breakage and
> > report back to this thread with findings.
>
> I'm not sure if non-googlers have access to this kind of information.
> If that's the case please tell me how to get it (as I don't know how it
> works), otherwise please someone from Google check the info and share it
> in this thread.
>
> The use counter is:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/2248

UKM for use counters is opt-in here:
https://cs.chromium.org/chromium/src/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc?l=12&rcl=0c9d655b01a1318b221f818c96ce944cb4230daf

Since this use counter isn't listed there, we'd have to wait for 6
weeks or something to get data if it's added now, so we probably
shouldn't do that unless we think it's necessary in order to identify
sites that we need to reach out to in order to drive down usage. The
increasing trend of
https://www.chromestatus.com/metrics/feature/timeline/popularity/2248
means that delaying comes with a risk too.

We could have a look in httparchive, but I'm not sure what we'd learn
from that, except that some sites will need to be updated.

> > 2. There should be an outreach/article effort from the Chrome devrel
> > team to make developers aware. Is this already in progress?
>
> I guess this would be covered in the blog post announcement of M70 (I'd
> probably write a post in my personal blog but I guess that's irrelevant
> regarding this). Dunno if I have to contact someone from Chrome devrel
> team regarding this.
>
> JFTR, I added some basic examples in the chromestatus entry:
> https://www.chromestatus.com/feature/6708326821789696
>
> BTW, the workaround would be as simple as using "auto" for tracks and
> "0px" for gutters.

If these workarounds always work, then it seems we're in a pretty good
place if it's communicated on chromestatus.com and other places where
web devs look for guidance. +Joe Medley generally keeps track of
new/removed features in each Chrome version.

Over to you, Chris.

[Joe Medley]

There will be a brief mention in the Beta post and more detail in a Deprecations/Removals post.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Chris Harrelson]

On Fri, Jul 20, 2018 at 5:14 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Fri, Jul 20, 2018 at 1:07 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:
>
>
> On 19/07/18 19:16, 'Chris Harrelson' via blink-dev wrote:
> > 1. Please check the top sites that hit the use counter for breakage and
> > report back to this thread with findings.
>
> I'm not sure if non-googlers have access to this kind of information.
> If that's the case please tell me how to get it (as I don't know how it
> works), otherwise please someone from Google check the info and share it
> in this thread.
>
> The use counter is:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/2248

UKM for use counters is opt-in here:
https://cs.chromium.org/chromium/src/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc?l=12&rcl=0c9d655b01a1318b221f818c96ce944cb4230daf

Since this use counter isn't listed there, we'd have to wait for 6
weeks or something to get data if it's added now, so we probably
shouldn't do that unless we think it's necessary in order to identify
sites that we need to reach out to in order to drive down usage. The
increasing trend of
https://www.chromestatus.com/metrics/feature/timeline/popularity/2248
means that delaying comes with a risk too.

We could have a look in httparchive, but I'm not sure what we'd learn
from that, except that some sites will need to be updated.

Right, I was referring to httparchive. For a Googler it's not very hard to do this, probably harder for you. Please send me an email if you need assistance with this.

We need to see just how broken the sites are, and know what a few of them are so we can possibly reach out.

> > 2. There should be an outreach/article effort from the Chrome devrel
> > team to make developers aware. Is this already in progress?
>
> I guess this would be covered in the blog post announcement of M70 (I'd
> probably write a post in my personal blog but I guess that's irrelevant
> regarding this). Dunno if I have to contact someone from Chrome devrel
> team regarding this.
>
> JFTR, I added some basic examples in the chromestatus entry:
> https://www.chromestatus.com/feature/6708326821789696
>
> BTW, the workaround would be as simple as using "auto" for tracks and
> "0px" for gutters.

If these workarounds always work, then it seems we're in a pretty good
place if it's communicated on chromestatus.com and other places where
web devs look for guidance. +Joe Medley generally keeps track of
new/removed features in each Chrome version.

If the workaround is that simple then some clear explanation in the Deprecations/Removals post seems fine.

[Manuel Rego Casasnovas]

On 20/07/18 17:24, Chris Harrelson wrote:
> Right, I was referring to httparchive. For a Googler it's not very hard
> to do this, probably harder for you. Please send me an email if you need
> assistance with this.
> We need to see just how broken the sites are, and know what a few of
> them are so we can possibly reach out.

So I didn't have permissions but Chris (thanks!) run a query [1] for me
that returns 178 websites hitting the use counter.

Out of them 8 websites get broken with the change. Some with important
issues (huge blank spaces between rows or some content overlapping),
other with small things (some backgrounds not covering the whole items
like before.
In all of them removing "grid-template-rows" or "grid-auto-rows"
depending on what they were using is enough to fix them and have the
same behavior with and without the patch. Also replacing the percentages
by "auto" in these properties has the same effect.
For all these 8 websites I sent a mail (or a direct message on twitter
or a facebook message depending on the case) with screenshots showing
the problem and instructions about how to update them to avoid the
breakage in future Chromium versions.

There are 5 websites with minor issues, some small pixels difference in
the position of the elements due to the usage of percentages in
indefinite height containers that were until now resolved as "auto".
I didn't contact those as the differences were minor.

The rest of websites (165) are working fine with the patch.

Most of them 132 are only using percentages for columns which behavior
is unchanged. There was a mistake in the use counter that I just fixed
recently that were hit by these sites [2].

Many websites (31) have the same behavior after the change. That's when
the percentage rows resolve to the same value than an "auto" row.
Half of them have just a single 100% row, so the behavior is the same
than not setting it.
Others have for example two 50% rows and the final result ends up being
the same.

Finally 2 sites didn't load nowadays, so I couldn't test them.

I don't know what's the usual process in this cases, but I believe it's
a good timing to land the patch to avoid more people hitting the issue
in the future.
I guess we can re-ping the "broken" websites in a few weeks if there are
still issues there.

Please let me know if we should do something different.

Bye,
Rego

[1] The query run in
https://bigquery.cloud.google.com/table/httparchive:pages.2018_07_01_desktop:
SELECT
url,
JSON_EXTRACT(payload,
'$._blinkFeatureFirstUsed.Features.GridRowTrackPercentIndefiniteHeight')
AS feature
FROM
[httparchive:pages.2018_07_01_desktop]
HAVING
feature IS NOT NULL
LIMIT
500

[2] https://chromium-review.googlesource.com/c/chromium/src/+/1124840

[Philip Jägenstedt]

That's some excellent research and out outreach, in keeping with our
"Minimizing web developer impact" [1] compat principle, thank you
Manuel! With 8 websites broken I think we should expect there to be
more similar cases out there, but 8, or even 178, is not a huge number
in the scope of httparchive, and I think that makes the compat cost
acceptably low.

It would be ideal to have a deprecation period for this, but with
Firefox already having made this change, delaying has its own cost.
Manuel, do you know if the Firefox change has already reached stable,
or when it will? Could we add a deprecation message and merge it back
to M69?

[1] https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=sharing

[Chris Harrelson]

Also: do those broken site also appear broken in Firefox already? Or are they broken due to the additional changes proposed that Firefox has not yet implemented?

[Manuel Rego Casasnovas]

On 26/07/18 15:14, Philip Jägenstedt wrote:
> It would be ideal to have a deprecation period for this, but with
> Firefox already having made this change, delaying has its own cost.
> Manuel, do you know if the Firefox change has already reached stable,
> or when it will? Could we add a deprecation message and merge it back
> to M69?

So just to clarify things, Firefox implements only the change for
percentage row gutters and that change will be included in Firefox 62
that will be released in September.
Percentage row gutters are usually a small number <10% and don't have a
big impact if they behavior change. None of the sites I checked is
broken due to that, so they're not broken in Firefox nightly.

However the change on how percentage row tracks work is not implemented
by Firefox yet, that's the change causing most of the breakages.
Still after fixing the websites they'll work fine in old versions (or in
Firefox without that patch yet) and in new versions too.

We don't think that changing the behavior of percentage row gutters (so
they resolve on indefinite height grid containers) but not for tracks,
what Firefox did so far, is a good idea. That's why we're proposing to
change both at the same time in this intent.


Regarding the deprecation, this is not like we're deprecating a property
or something like that. This is that we're changing the behavior of
percentage row tracks and gutters on grid containers with indefinite height.
The message would be something like a warning: "Percentages row tracks
and gutters for indefinite height grid containers will be resolved
against the intrinsic height instead of being treated as auto and zero
respectively."

I don't know if it's common to add this kind of deprecation messages,
but if you think this could be a good idea I guess we can add something
like that.

Bye,
Rego

[Manuel Rego Casasnovas]

On 26/07/18 19:53, Chris Harrelson wrote:
> Also: do those broken site also appear broken in Firefox already? Or are
> they broken due to the additional changes proposed that Firefox has not
> yet implemented?

I've just replied with more detail in the previous mail, but not sites
are not broken in Firefox because it only implements the change for
percentage row gutters and not for percentage row tracks.

Anyway the fix won't break the sites in previous versions as it's
backwards compatible.

Bye,
Rego

[Chris Harrelson]

Maybe what we should do is publish a deprecation in the M69 release docs Joe will publish, then land this feature in M70 (i.e. land it now). This will give developers 6+ weeks to test on Canary, etc and hear about the change, including via outreach like what Rego sent.

LGTM1 to ship with the above plan.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4abbf461-ca99-db60-9932-0208ff5b881d%40igalia.com.

[Philip Jägenstedt]

LGTM2 to that

Rego, a deprecation message like "Percentages row tracks and gutters for indefinite height grid containers will be resolved against the intrinsic height instead of being treated as auto and zero respectively." sounds good, but you'll probably have to craft the bits about the milestones manually, as it's not being removed in M70, which is what the template messages are about.

[Philip Jägenstedt]

Oops, we're repeating the numbers here. There were already LGTMs upthread, let's call it LGTM3 now.

[Manuel Rego Casasnovas]

Just a quick update on this topic.

The deprecation warning is present in Chromium 69, and a comment was
done in the blog post announcing it:
https://blog.chromium.org/2018/08/chrome-69-beta-av1-video-decoder-css.html

This week the patch changing the behavior has landed in Chromium 70.
On top of that we landed it in WebKit too, and we hope it'll be included
in the next Safari Technology Preview releases.
And we notified other browsers in the CSSWG issue so they are aware
we're doing the change and the tests are available in WPT.

Last, as promised I published a blog post on the topic:
https://blogs.igalia.com/mrego/2018/08/10/changes-on-css-grid-layout-in-percentages-and-indefinite-height/

It actually covers too many things apart from this particular change,
but we hope it can be useful to get examples and instructions about how
to solve the possible breakages caused by this change.

Cheers,
Rego