1627347 - getComputedStyle() should return implicit grid tracks

Status: RESOLVED FIXED

(Core :: DOM: CSS Object Model, defect)

Description

[geddski]

Attachment: ff-grid-track-bug.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

(using Firefox Developer Edition)

1. create any CSS grid layout that contains more items than explicit tracks, causing new implicit tracks to be created.

2. query that element's styles:
   const styles = window.getComputedStyle(element);

3. check the grid-template-columns or grid-template-rows properties:
   const columns = styles.getPropertyValue("grid-template-columns");

Actual results:

the columns returned only accounts for the explicit columns, and does not return the implicit columns that have been created.

This inaccuracy makes it impossible for user-land Grid Inspector/overlay tools to be accurate. Tools like my Grid Critters game, Webflow's Grid Inspector etc. are affected by this.

Firefox has a built-in Grid Inspector that is able to remain accurate because it doesn't use these values, but rather the privileged element.getGridFragments() method, which does account for both explicit and implicit values.

Expected results:

the grid-template-columns should return all the columns, not just the explicit ones. That is the behavior in Chrome, Edge, and Safari.

The same applies to the grid-template-rows value.

Comment 1

[geddski]

Attachment: screenshot of the bug in Webflow's grid inspector

here is a screenshot of this bug affecting Webflow's Grid Inspector

Comment 2

[Mike Taylor [:miketaylr]]

Emilio, is this a known issue?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This is intentional and other browsers should match us, see bug 1599206, https://bugs.chromium.org/p/chromium/issues/detail?id=1024927 / https://bugs.webkit.org/show_bug.cgi?id=204588 / https://github.com/w3c/csswg-drafts/issues/4475#issuecomment-553525609.

We have this behind a pref (layout.css.serialize-grid-implicit-tracks).

Oriol, do you know which Chromium version is this shipping with?

Reporter, can you confirm that you see the expected behavior if you change that about:config flag in dev edition?

Comment 4

[geddski]

Indeed, changing layout.css.serialize-grid-implicit-tracks to true fixes the problem.

I believe that change would be a mistake. Without it, how will anyone in user-land create accurate Grid overlay tools?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

On the other hand, doing element.style.gridTemplateColumns = getComputedStyle(element).gridTemplateColumns would not roundtrip, which seems really bad too.

Comment 6

[geddski]

what do you mean by roundtrip? I'm not familiar with that.

Comment 7

[Oriol Brufau [:Oriol]]

In Chromium it's shipping in 81: https://www.chromestatus.com/feature/5958076270116864

Reporter: is there any reason for not defining your columns explicitly? Like adding some auto values at the end of grid-template-columns.

This inaccuracy makes it impossible for user-land Grid Inspector/overlay tools to be accurate.

Was the previous behavior really accurate, though? How did you handle leading implicit tracks? How did you know which one was the last leading implicit track and which one was the first explicit one?

The idea was to expose a much more flexible and reliable API, but it hasn't been designed yet https://github.com/w3c/csswg-drafts/issues/4511

what do you mean by roundtrip? I'm not familiar with that.

See bug 1599206

Comment 8

[geddski]

Our grid inspectors don't have much say over our users' grids/content, but rather try to display an accurate representation of what's occurring in the DOM. If the user's grid has implicit grid tracks, our inspectors/overlays show that to them so they can understand how things are working. Without the implicit track information we won't be able to help users understand what's actually going on with their grid.

Was the previous behavior really accurate, though? How did you handle leading implicit tracks? How did you know which one was the last leading implicit track and which one was the first explicit one?

In my case I have the user's grid-template-columns code available. Webflow too has the explicit tracks the user has defined. But in practice what we really care about is the final/actual grid which potentially includes generated implicit tracks.

I see how including implicit tracks in getComputedStyle could be problematic, but we do need some way of getting the actual computed style information for grids.

Comment 9

[Oriol Brufau [:Oriol]]

In my case I have the user's grid-template-columns code available. Webflow too has the explicit tracks the user has defined.

Precisely, what I mean is that the 1st track specified in grid-template-columns may not be the 1st one that you get in getComputedStyle()!
So basically this breaks the matching between specified track sizing functions and final track sizes.

Would it be possible for you to just define more explicit tracks?

Comment 10

[geddski]

Would it be possible for you to just define more explicit tracks?
Our grid tools are used by thousands of different users, who can build a grid and populate it however they want. If implicit tracks weren't part of the spec, we wouldn't need to visualize them when they occur. But as they are part of the spec and do occur, we need a way to know about it so we can help them see what's happening. Telling folks not to use implicit tracks isn't a good solution, as implicit tracks often occur on accident (too many grid items, or items positioning pushing the flow of new items etc.) We need a reliable way to get the actual grid information like we have before this change.

Comment 11

[geddski]

Would it be possible for you to just define more explicit tracks?

Our grid tools are used by thousands of different users, who can build a grid and populate it however they want. If implicit tracks weren't part of the spec, we wouldn't need to visualize them when they occur. But as they are part of the spec and do occur, we need a way to know about it so we can help them see what's happening. Telling folks not to use implicit tracks isn't a good solution, as implicit tracks often occur on accident (too many grid items, or items positioning pushing the flow of new items etc.) We need a reliable way to get the actual grid information like we have before this change.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

[Tracking Requested - why for this release]: Behavior change which we may or may not want to revert in 75.

(Tagging the right bug as the bug that flipped the pref)

I suspect this should be really decided in the CSS Working Group, though all browsers are going to behave like we do, so... Seems like there's some discussion going on in https://github.com/w3c/csswg-drafts/issues/4475.

Comment 13

[Oriol Brufau [:Oriol]]

BTW, Chromium will revert, https://bugs.chromium.org/p/chromium/issues/detail?id=1069866#c8

Comment 14

[Emilio Cobos Álvarez (:emilio)]

hmmpf, ok... That's a bit unfortunate, but yeah let's give some time to discuss in the working group.

Sheriffs, can I get bug 1619538 backed out from both central and beta?

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Ok, fixed for now via the revert of bug 1619538. Let's use that and the csswg issue to keep discussing.

Comment 16

[Julien Cristau [:jcristau]]

How much breakage are we talking about here? If it's worth a remote pref flip we can get that going...

Comment 17

[Emilio Cobos Álvarez (:emilio)]

It's probably not huge but the risk isn't high either, and it'd be nice to have a lone release with the "new" behavior, so if you could do that it'd be great! I hadn't noticed that the patch snuck into 75.

Comment 18

[geddski]

Thanks so much for listening everyone. <3

Comment 19

[Julien Cristau [:jcristau]]

Bug 1630202 tracks the remote pref rollout, which is now live. I'll track this to land the backout on mozilla-release in case we have a dot release.