Re: [csswg-drafts] [css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent (#7661)

The CSS Working Group just discussed `[css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> TabAtkins: We discussed a few weeks ago and took it back to the issue<br>
&lt;emeyer> …Question is, how to we calculate the static position of absolutely positioned children of grid containers?<br>
&lt;emeyer> …Option 1: keep spec as-is, where we apply grid properties to find a containing block<br>
&lt;emeyer> …(more details that the scribe lost in terminology)<br>
&lt;emeyer> Option 2: Simplify in this case and use the containing box of the parent<br>
&lt;fantasai> s/containing/content/<br>
&lt;fantasai> s/containing block/staticpos containing block only if the parent is the abspos containing block/<br>
&lt;Rossen_> q?<br>
&lt;fserb> q-<br>
&lt;fantasai> scribe+<br>
&lt;TabAtkins> EN-us-csswg<br>
&lt;fantasai> Option 3: apply grid properties to find staticpos containing block always (when the parent is a grid)<br>
&lt;Rossen_> ack fantasai<br>
&lt;emeyer> fantasai: I opened this originally because the spec as is, is not a behavior we have anywhere else<br>
&lt;emeyer> …If you have a static position, that’s your position regardless<br>
&lt;Rossen_> q?<br>
&lt;emeyer> …Between the other two behaviors, we can use the content box edge like in flexbox, or use grid positioning to contain the static position containing block<br>
&lt;TabAtkins> q+<br>
&lt;emeyer> …I think the second options is more powerful and closer to the intent of static positioning<br>
&lt;emeyer> …I think we should honor the grid positioning properties<br>
&lt;emeyer> …Ian did raise that the spec uses padding box as a parent, which is weird and unusual<br>
&lt;emeyer> …Regardless of what we do, we shoul use the content box and not the padding box<br>
&lt;emeyer> iank_: The way the spec is phrased, it gets invoked when auto is in play<br>
&lt;emeyer> TabAtkins: My main objection here is grid positioning proeprties are semantically a unit, giving a position in 2D<br>
&lt;emeyer> …If we go with options 1 or 3, you can be invoking grid-row to figure a position, but grid-column in a different grid<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;emeyer> …It no longer becomes a simple 2D, it’s not semantically coherent<br>
&lt;emeyer> …I don’t think there’s a reasonable way to resolve this<br>
&lt;emeyer> …I think static positioning should ignore grid properties and be simpler<br>
&lt;emeyer> …Anchor positioning is the better solution here anyway; I don’t think there’s a strong use case for static positioning of grid pieces in a works where anchor positioning exists<br>
&lt;emeyer> …I think we should simplfy the model and call it a day<br>
&lt;emeyer> fantasai: I don’t think we can resolve today; what I’d like to get is author feedback here<br>
&lt;emeyer> iank_: This is somewhat blocking our subgrid implementation, so we’d like to resolve this soon<br>
&lt;emeyer> …Don’t want this to drag out for months<br>
&lt;emeyer> Rossen_: We’ll start with this next week<br>
&lt;TabAtkins> Note that I will not be here next week, I'll be over the Pacific ocean during the call.<br>
&lt;emeyer> …Hopefully we can get a resolution next week<br>
&lt;Rossen_> Topic end<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7661#issuecomment-1570595824 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 31 May 2023 17:02:51 UTC