Re: [csswg-drafts] [css-grid-2] resolving line names in subgrids

Thanks for filing all these detailed issues, @matspalmgren!
Here's some quick responses from me and @tabatkins; we'll look at these in more detail in the coming weeks. I want to also get @jensimmons and @rachelandrew digging into them before we resolve.

ISSUE 1: Agreed, clearly a bugfix change.

ISSUE 2: Agreed, this is consistent with item f in https://www.w3.org/TR/2018/WD-css-grid-2-20180427/#subgrid-items

ISSUE 3: I think in this case explicit names in the outer grid that are outside the subgrid’s bounds should not match. The only parent line names in scope are the ones where the parent and the subgrid share the line name. This was the intention of item c, “the subgridded lines automatically receive the line names specified on the parent grid” and is consistent with the idea of scoping the subgrid's line references per item b, “The grid-placement properties of the subgrid’s grid items are scoped to the lines covered by the subgrid.”

(It's not clear from your examples whether this is what you meant, or you meant the opposite. As it happens, either choice gives the results you specified. ^_^  Here's a more explicit example:

```
<div style="display:grid; grid: auto / [a] 50px 50px [a] 50px 50px [a]">
  <div style="display:grid; grid:auto/subgrid; grid-column: span 3">
    <x style="grid-column: span a / a -1">x</x>
  </div>
</div>
```

Here, the parent grid's line 1, 3, and 5 are named "a". The subgrid spans from lines 1-4.

If the parent grid's lines outside the subgrid's bounds are visible, then the item will anchor its grid-column-end to line 5, which is clamped to 4. Then it will seek startwards and find line 3 as the next "a" line, for a final position of 3 / 4.

If they're not visible, it'll anchor its grid-column-end to line 3 (the last visible "a" line), then span to line 1, for a final position of 1 / 3.  This is the correct/intended behavior.)

ISSUE 4: This is an interesting case, I hadn't really thought about it. Named areas don't really "exist" in Grid; they're just a shorthand syntax for adding *-start and *-end line names to the grid.  (Note that you can use `grid-area: a` solely by manually adding `a-start`/`a-end` lines to the grid, avoiding `grid-template-areas` entirely.) So I would have expected that we'd just inherit the -start/-end line names that happen to cross into the subgrid, without doing anything special.

If we resolve by simply ignoring the line names outside the subgrid’s spanning area, then the -start/-end lines outside the subgrid area would just get dropped. The item would then position against the subgrid's fake-implicit grid lines, and subsequently get clamped to the actual bounds of the subgrid, yielding the same behavior you propose.

ISSUE 5: If we take the position that areas generate line names which are treated just like any other line names (the current Grid 1 specified behavior), then there's no order dependence (other than the order-dependence inherent in resolving named lines). Then there can be some confusing results if names conflict, but then, that's true for inheriting line names in general.

ISSUE 6: Again, if areas just define lines to match against, and have no further independent existence, then there's no ambiguity here - the `a-start` and `a-end` lines are defined by the parent grid, and inherit down to the child (in a way that happens to give a slightly confusing result here, spanning from 1 / 2 in the outer grid).

Note that if you'd said `grid-column: a`, it would match the `a-start` and `a-end` lines defined by the parent grid, and then because they're in the wrong order, it would just swap them, and properly position the item in the parent's "a" area. The confusing result here is from the fact that the item is only anchoring to *one* of the `a-*` lines, and is just `span 1` for the other position.

ISSUE 7: Agreed; this is already edited into the spec, I believe: https://drafts.csswg.org/css-grid-2/#subgrid-per-axis “Excess `<line-names>` are ignored.”

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2564#issuecomment-390039066 using your GitHub account

Received on Thursday, 17 May 2018 22:57:15 UTC