- From: Kurt Catti-Schmidt via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Jun 2023 17:57:08 +0000
- To: public-css-archive@w3.org
KurtCattiSchmidt has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-grid-2] Resolving padding in indefinite intrinsic size calculation and using that to resolve indefinite size? == [Spec](https://www.w3.org/TR/css-grid-2/#intrinsic-sizes) I'm looking at [grid-auto-repeat-max-size-001.html](http://wpt.live/css/css-grid/grid-definition/grid-auto-repeat-max-size-001.html) in order to fix [this Compat 2023 bug in Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=1449940) ...however, it appears that both Blink and WebKit make more sense to me than what Gecko is doing, although Gecko's behavior is marked as passing. Note that this is in relation to sub-cases 16 and 19, which Blink and WebKit are marked as failing and Gecko is marked as passing. The other cases are all in agreement. I'll explain what Blink and WebKit are doing, and why I think that is the proper behavior. No width or height are specified on the grid, so for sizing purposes, we fall back to the default intrinsic size of 300px by 150px. However, with this fallback, we are able to determine a final size of the grid by the end of the grid layout algorithm that differs from 300px by 150px. Padding is 10%, on an indefinite inline axis, which falls back to 300px, so we land at 30px padding. This is agreed upon in all implementations. Grid-template is set to `repeat(auto-fill, 50px) / repeat(auto-fill, 100px);` which we can resolve to two repetitions in both directions to fill the indefinite 300px width and 150px indefinite height (it can't be 3 repetitions in either axis due to the padding). This is also agreed upon in all implementations. This is where things diverge in Gecko. For the inline size, Blink/Webkit add up the 30px padding on each side, along with 2 repetitions of 100px for each column, and land at 260px. Gecko sticks with the default 300px intrinsic size, even though it is possible to calculate an intrinsic size based on the fixed column sizes. There seems to be some extra padding *after* the grid items in Gecko, which is how it lands at 300px. I can't find any reference to this in the grid spec. For block size, interestingly, Blink/WebKit/Gecko all agree on adding up padding-top and padding-bottom (30px + 30px) along with two rows of 50px, landing at 160px. It's not clear to my why Gecko is inconsistent between the inline and block direction here. The grid spec implies that if fixed sizes are specified on track sizes (as is happening here), that those will be used for intrinsic size calculation. If there is something I'm missing here, and that Gecko is indeed doing this correctly, I'd be happy to update Chromium's implementation. Otherwise, I'll update the expected sizes in the test case. @bfgeek created a reduced case that demonstrates the extra padding Gecko is adding: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11785 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8963 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 June 2023 17:57:10 UTC