Re: [csswg-drafts] [css-align-3][css-position-3] Better interaction of auto insets and self-alignment properties? (#9124)

The CSS Working Group just discussed `[css-align-3][css-position-3] Better interaction of auto insets and self-alignment properties?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> miriam: this was discussed yesterday in the anchor-positioning breakout session<br>
&lt;emilio> ... when both insets on an axis are auto we currently use the static positioning box<br>
&lt;emilio> ... roughly where the element would've been<br>
&lt;emilio> ... question is: when you change alignment via justify-/align-/place-self, should we zero those out?<br>
&lt;emilio> ... or is it weird to change it based on alignment<br>
&lt;emilio> ... the question is (1) is it web compatible to make this change, and (2) if it is, is there anyone who agrees with fantasai that we still shouldn't do it<br>
&lt;emilio> florian: the implications take a while to process<br>
&lt;emilio> miriam: when you set alignment should that refer to the static position box or the otherwise positioning context<br>
&lt;TabAtkins> And to be clear, for compat: currently, impls only respect the current spec (aligning in the staticpos rect) for a flex/grid parent. Other parent display types, it's not implemented yet, so doing *either* behavior is *potentially* a compat problem.<br>
&lt;emilio> emilio: not sure if we can get to resolve this in 9 minutes<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to explain this<br>
&lt;emilio> fantasai: [whiteboard time]<br>
&lt;emilio> fantasai: you got the abspos cb, the regular cb, and then the child you position<br>
&lt;emilio> ... right now with insets auto you stay within the regular cb<br>
&lt;emilio> ... if you set insets to 0 then we don't care where this box lives, we lay it out inside the abspos cb and ignore everything else<br>
&lt;emilio> ... question is when we go back to being auto<br>
&lt;emilio> ... flex/grid pretend that you are aligned as the single kid<br>
&lt;emilio> ... what TabAtkins and iank_ are saying is that if you set the alignment props to a value other than normal then we align to the abspos cb<br>
&lt;emilio> ... you could think it as setting insets to 0<br>
&lt;emilio> ... so question is, is that more intuitive that remaining in the regular cb (and thus you need to set insets to 0 to get positioned in your abspos cb)<br>
&lt;emilio> ... that's the fundamental issue we're disagreeing on<br>
&lt;TabAtkins> q+<br>
&lt;emilio> ... the existing behavior on grid / flex is a compat constraint, though iank_ is willing to implement / ship this and see if it's not<br>
&lt;emilio> ... the other thing is that alignment on block are not easy to emulate with anchor positioning<br>
&lt;fremy> based on the explainer, slightly favoring auto-zeroing, I think<br>
&lt;emilio> TabAtkins: the behavior you described for block is not what's in the spec<br>
&lt;emilio> ... the spec is saying a 0-width behavior<br>
&lt;emilio> fantasai: it's not, it's full-width<br>
&lt;emilio> TabAtkins: so in this case if you did align-self: end would be higher than align-self: start<br>
&lt;emilio> ... in an inline context you have 0-width, 1lh-height so you get that weird behavior for justify<br>
&lt;emilio> ... my argument is that nobody implements this behavior for inline / block yet<br>
&lt;emilio> ... so there's compat impact either way<br>
&lt;emilio> ... we don't believe there's compat impact on changing the grid / flex behavior<br>
&lt;miriam> q?<br>
&lt;miriam> ack TabAtkins<br>
&lt;emilio> ... ignoring compat the argument is still that the behavior defined here is very limited and weird<br>
&lt;florian> q+<br>
&lt;emilio> ... we want to do less of this static positiony stuff<br>
&lt;emilio> ... given its power is largely replaced by anchor positioning<br>
&lt;florian> q-<br>
&lt;emilio> miriam: we're at time<br>
&lt;emilio> astearns: we'll get compat data and come back<br>
</details>


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


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

Received on Thursday, 14 September 2023 09:02:59 UTC