Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-grid-2] Mapping implicit line names from grid areas to orthogonal subgrids #9418

Open
sammygill opened this issue Sep 27, 2023 · 4 comments
Labels
css-grid-2 Subgrid; Current Work

Comments

@sammygill
Copy link

sammygill commented Sep 27, 2023

This stemmed from a discussion about a particular subtest in a subgrid WPT: web-platform-tests/wpt#41831

https://github.com/web-platform-tests/wpt/blob/master/css/css-grid/subgrid/orthogonal-writing-mode-005.html

TLDR: WebKit disagrees with Blink and Gecko regarding the following example:

<!DOCTYPE HTML>
<html>
<head>
<style>
.grid {
  display: inline-grid;
  grid-auto-columns: 15px;
  border: 1px solid;
}

.subgrid {
  display: grid;
  writing-mode: vertical-lr;
  grid-template-rows: subgrid;
  grid-column: 1 / span 4;
  background: grey;
  grid-auto-columns: 8px;
  grid-auto-flow: column;
}

.areas-1a { grid-template-areas: 'x x x x' }

.subgrid >  :nth-child(2n)   {  background: black; }
.subgrid >  :nth-child(2n+1) {  background: pink; }
.subgrid >  * { writing-mode: horizontal-tb; }

</style>
</head>
<body>
<div class="grid areas-1a">
  <div class="subgrid">
    <div style="grid-row:x-start"></div>
    <div style="grid-row:x"></div>
    <div style="grid-row:x-start / x-end"></div>
    <div style="grid-row:x-end"></div>
  </div>
</div>
</body>
</html>
Screenshot 2023-09-20 at 10 02 32 AM

It sounds like Blink is performing some sort of mapping of the outer grid's implicit line names to the subgrid where they overlap (which I think I agree with), but there is potentially a discrepancy with orthogonal subgrids.

Could we get some sort of clarification about how the mapping should occur in this scenario? My understanding is that the named lines should keep their physical positions and an orthogonal subgrid should be able to reference them but in the opposite axis. In this particular example since the grid area completely overlaps the subgrid it should be able to reference all of the implicit lines and potentially giving the WebKit output.

@sammygill
Copy link
Author

CC @fantasai

@fantasai
Copy link
Collaborator

fantasai commented Oct 3, 2023

The relevant spec section is https://www.w3.org/TR/css-grid-2/#subgrid-area-inheritance

Analyzing the testcase:
Diagram of the testcase

  1. The master grid has a 4-column 1-row area called "x", which creates "x-start" and "x-end" lines in both axes.
  2. The subgrid covers this same area, adopting the "x-start" and "x-end" line names in the subgridded axis (i.e. for its vertical tracks, which are in fact its rows since it has a vertical writing mode).
  3. The subgrid items are placed into the subgrid, starting with its start-start (top left) corner. They have explicit row placement, but automatic column placement, so each one ends up in a different column:
    1. The first item's row placement is "x-start", implicit span of 1, so it starts at the first (x-start) vertical line and spans to the second vertical line. It remains in the first horizontal track (first column) of the subgrid.
    2. The second item's row placement is "x", so it stretches from the x-start vertical line to the x-end vertical line, and occupies the second horizontal track of the subgrid.
    3. The third item's row placement is "x-start / x-end", so it also occupies all the vertical tracks, and the third horizontal track of the subgrid.
    4. Te fourth item's row placement is "x-end", implicit span of 1. It wants to be placed at vertical lines 5 (x-end) and 6, but it gets clamped to lines 4 and 5, occupying the grid cell at the intersection of the 4th horizontal and 4th vertical tracks in the subgrid.

This, afaict, yields the rendering in WebKit. CC @tabatkins for sanity check.

(I noticed that in https://www.w3.org/TR/css-grid-2/#subgrid-area-inheritance we didn't specify that only the subgridded axes inherits names, but that doesn't affect the results here anyway.)

@fantasai
Copy link
Collaborator

fantasai commented Oct 3, 2023

I think the important idea to keep in mind is that subgridding an axis creates a physical-axis correspondance, not a logical one. (A logical one wouldn't make any sense, if you think about it.) Like if a subgrid subgrids its horizontal tracks, then its horizontal tracks match up to the parent grid's horizontal tracks, and horizontal parent grid line names get adopted as names for the coinciding horizontal subgrid lines.

@tabatkins
Copy link
Member

tabatkins commented Oct 5, 2023

Yes, my read agrees with fantasai. The line names are definitely physical, and thus will swap logical axises if the writing mode axis changes (and indeed, nothing else even remotely makes sense; the only other behavior we could theoretically do is block line inheritance entirely when the writing mode rotates).

And with that established, each element forces itself to auto-flow into a fresh column, so they should occupy four column, and have the sizes that WebKit gives them.

webkit-commit-queue pushed a commit to sammygill/WebKit that referenced this issue Oct 10, 2023
…riting-mode-005.

https://bugs.webkit.org/show_bug.cgi?id=262912
rdar://116685783

Reviewed by Tim Nguyen.

There was a CSSWG discussion regarding some of the subtests within
this test: w3c/csswg-drafts#9418

Based off of the discussion, the subtests should be updated to reflect
the current WebKit rendering.

* LayoutTests/TestExpectations:
* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/orthogonal-writing-mode-005-expected.html:
* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/orthogonal-writing-mode-005-ref.html:

Canonical link: https://commits.webkit.org/269141@main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-grid-2 Subgrid; Current Work
Projects
None yet
Development

No branches or pull requests

4 participants