Bugzilla

I think one key note from the github discussion is in https://github.com/w3c/csswg-drafts/issues/6905#issuecomment-1026346391 :
> The important part to me was the clarification that resolving the number of explicit tracks in a subgrid can't happen until placement of the subgrid item in the parent has been done.

Right now, we do things in the opposite order; we resolve the number of explicit tracks in the subgrid first, and then place the subgrid items (constrained to those tracks).  That happens by virtue of passing `subgridRange` here, before we place the subgrid items:
https://searchfox.org/mozilla-central/rev/3bd65516eb9b3a9568806d846ba8c81a9402a885/layout/generic/nsGridContainerFrame.cpp#4613,4624-4625
```cpp
  subgridRange = &subgrid->SubgridCols();
...
LineNameMap colLineNameMap(gridStyle, mAreas, aState.mColFunctions,
                           parentLineNameMap, subgridRange,
```

In my attached `testcase 2`, when current Firefox tries to place the item, we already know that the subgrid has 4 lines (3 tracks) and can't create implicit lines, so we clamp `foo 6` to be line #4 in the outer grid, and we look backwards (non-inclusive) from that line to resolve `span a`, and we go all the way to the beginning of the subgrid.

But it sounds like the test is requiring that we place the item in a less-constrained way, such that we're able to resolve `line a` as the 4th line, somehow... and then I guess we size the subgrid after that, and slide the item inwards to constrain it after-the-fact, or something?

(That seems to be what Chromium/WebKit are doing with `testcase 2`, at least -- they're recognizing that `grid-column-start:a` is a known line-name, but they end up using the previous line as the start line, and they use `a` i.e. line#4 as the end line...)

I think one key note from the github discussion is in https://github.com/w3c/csswg-drafts/issues/6905#issuecomment-1026346391 :
> The important part to me was the clarification that resolving the number of explicit tracks in a subgrid can't happen until placement of the subgrid item in the parent has been done.

(I don't yet see where that insight comes from in the spec text, but it's entirely likely I just haven't found it yet.)

Right now, we do things in the opposite order; we resolve the number of explicit tracks in the subgrid first, and then place the subgrid items (constrained to those tracks).  That happens by virtue of passing `subgridRange` here, before we place the subgrid items:
https://searchfox.org/mozilla-central/rev/3bd65516eb9b3a9568806d846ba8c81a9402a885/layout/generic/nsGridContainerFrame.cpp#4613,4624-4625
```cpp
  subgridRange = &subgrid->SubgridCols();
...
LineNameMap colLineNameMap(gridStyle, mAreas, aState.mColFunctions,
                           parentLineNameMap, subgridRange,
```

In my attached `testcase 2`, when current Firefox tries to place the item, we already know that the subgrid has 4 lines (3 tracks) and can't create implicit lines, so we clamp `foo 6` to be line #4 in the outer grid, and we look backwards (non-inclusive) from that line to resolve `span a`, and we go all the way to the beginning of the subgrid.

But it sounds like the test is requiring that we place the item in a less-constrained way, such that we're able to resolve `line a` as the 4th line, somehow... and then I guess we size the subgrid after that, and slide the item inwards to constrain it after-the-fact, or something?

(That seems to be what Chromium/WebKit are doing with `testcase 2`, at least -- they're recognizing that `grid-column-start:a` is a known line-name, but they end up using the previous line as the start line, and they use `a` i.e. line#4 as the end line...)

I think one key note from the github discussion is in https://github.com/w3c/csswg-drafts/issues/6905#issuecomment-1026346391 :
> The important part to me was the clarification that resolving the number of explicit tracks in a subgrid can't happen until placement of the subgrid item in the parent has been done.

(I don't yet see where that insight comes from in the spec text, but it's entirely likely I just haven't found it yet.)
(EDIT: Found it, see comment 6.)

Right now, we do things in the opposite order; we resolve the number of explicit tracks in the subgrid first, and then place the subgrid items (constrained to those tracks).  That happens by virtue of passing `subgridRange` here, before we place the subgrid items:
https://searchfox.org/mozilla-central/rev/3bd65516eb9b3a9568806d846ba8c81a9402a885/layout/generic/nsGridContainerFrame.cpp#4613,4624-4625
```cpp
  subgridRange = &subgrid->SubgridCols();
...
LineNameMap colLineNameMap(gridStyle, mAreas, aState.mColFunctions,
                           parentLineNameMap, subgridRange,
```

In my attached `testcase 2`, when current Firefox tries to place the item, we already know that the subgrid has 4 lines (3 tracks) and can't create implicit lines, so we clamp `foo 6` to be line #4 in the outer grid, and we look backwards (non-inclusive) from that line to resolve `span a`, and we go all the way to the beginning of the subgrid.

But it sounds like the test is requiring that we place the item in a less-constrained way, such that we're able to resolve `line a` as the 4th line, somehow... and then I guess we size the subgrid after that, and slide the item inwards to constrain it after-the-fact, or something?

(That seems to be what Chromium/WebKit are doing with `testcase 2`, at least -- they're recognizing that `grid-column-start:a` is a known line-name, but they end up using the previous line as the start line, and they use `a` i.e. line#4 as the end line...)