[css-grid] Non-existent line names in abspos grid items

[mrego]

Imagin the following example we have a grid container with 2 rows and 2 columns (the grid container has position: relative so it's the containing block of the baspos descendants).
A regular item is placed with grid-column: 3 / foo; grid-row: 3 / foo;, thus an implicit grid line (4) is created and considered to have foo as name.
Then if we have an abspos item with grid-column: 3 / bar; grid-row: 3 / bar; how we should resolve the bar line?

• 8.3. Line-based Placement (https://drafts.csswg.org/css-grid/#grid-placement-int):

  all implicit grid lines are assumed to have that name for the purpose of finding this position.

Only checking this part of the spec it seems pretty clear that bar line should point to the implicit line (4) (that matches Firefox/Edge behavior, note that Blink/WebKit consider that line to be auto for the abspos item).

• 9.1. With a Grid Container as Containing Block (https://drafts.csswg.org/css-grid/#abspos-items):

  If a grid-placement property refers to a non-existent line either by explicitly specifying such a line or by spanning outside of the existing implicit grid, it is instead treated as specifying auto (instead of creating new implicit grid lines)."

However reading this part I have more doubts about if it should be considered a non-existent line or not. If bar is not a non-existent line because we have an implicit line and we assume it could have any name, shouldn't we clarify a little bit this last sentence?

This issue is related to bug #915551 reported by @MatsPalmgren on Chromium.

[fantasai]

I think it makes sense to clarify the spec, but also that the Firefox/Edge behavior is correct. We end up spanning to the 'auto' line for non-existent lines only because abspos can't add lines. Either way it's a strange error case. :) Agenda+ in case anyone has a different opinion.

[MatsPalmgren]

thus an implicit grid line (4) is created and considered to have foo as name.

I think the "and considered to have foo as name" is a bit misleading. There is no such thing as an implicit line that only matches a single name. Since that implicit line exist it also matches any other name, so it also matches "bar".

Given that an implicit line does exist in this case, and that implicit lines match all names, the spec text from 9.1 that you quote does not apply since the line is neither "non-existent" nor outside the existing implicit grid.

[mrego]

BTW, I agree with Firefox/Edge behavior, I just wanted the note on the spec to make things clearer (at least for me).
I don't believe we need Agenda+ for this one as it seems we all agree on the topic.
Thanks for the quick feedback!

[css-meeting-bot]

The CSS Working Group just discussed Non-existent line names in abspos grid items, and agreed to the following:

• RESOLVED: close this issue and accept the clarification note

The full IRC log of that discussion

<dael> Topic: Non-existent line names in abspos grid items
<dael> github: https://github.com//issues/3445
<tantek> fantasai, no, you're cherry picking lol. Appendices A, B, C, E, F etc. are all informative in CSS 2.1
<dael> fantasai: Wanted to confirm everything with WG since it's CR
<dael> Rossen: Can you summarize?
<tantek> s/ E,/ D,/
<myles> s/i'd like to implement these/i'd like to implement these someday eventually/
<dael> fantasai: Issue was about the refence for line name. Currently define implicit lines have all the names. Abspos referring to line name not in explicit grid. Had been a case where someone referenced a non existant line in inflow grid and caused a line to be created and now abspos is looking for a different line name. We defined it's looking for implicit line. Added a note to clarify, everyone seems in agreement
<fantasai> tantek, A says it's informative explicitly
<dael> florian: Close no change or close with clarification note?
<tantek> Yeah, Appendix E stacking contexts in CSS 2.1 should have been made a chapter, not an Appendix. All other appendices are informative.
<dael> fantasai: Close with clarification note
<lajava> I've been discussing this with rego and we agree that the note clarifies the issue
<fantasai> tantek, B has to be normative because it contains the normative references
<dael> Rossen: Objections to close this issue and accept the clarification note?
<dael> RESOLVED: close this issue and accept the clarification note
<fantasai> tantek, C says it's informative explicitly