- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Sep 2023 13:32:06 +0000
- To: public-css-archive@w3.org
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> <ntim> TabAtkins: before the spec existed there is no interaction between the 2, we would use the CSS 2.1 behavior<br> <ntim> TabAtkins: The remaining tension is what to do in the double auto case<br> <fantasai> My positions:<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9124<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1679487628<br> <ntim> TabAtkins: my preference is to have double autos resolve the same way so they resolve to zeros when you have non-default alignments<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1678174879<br> <ntim> TabAtkins: main reason for this, there is one alignment keyword where this is necessary, the anchor-center keyword needs the space to be able to align.<br> <ntim> TabAtkins: the larger thing behind my reasoning, static pos as defined in CSS 2.1 is just a poor version of anchor positioning<br> <ntim> TabAtkins: it wasn't great, but it did do the job<br> <ntim> TabAtkins: but we don't need this anymore, since we have anchor positniing<br> <ntim> TabAtkins: we don't need to do this anymore, unless we are constrained by compat<br> <astearns> q+ masonf<br> <astearns> ack fantasai<br> <iank_> q+<br> <ntim> fantasai: It would be useful to focus on the case where anchor positioning is happening, because we probably have agreement on that one<br> <fantasai> PROPOSED: If only one inset in an axis is auto, and self-alignment in that axis is not normal, then auto computes to zero<br> <ntim> astearns: lets try to resolve on it<br> <TabAtkins> ack masonf<br> <fantasai> TENTATIVELY RESOLVED: If only one inset in an axis is auto, and self-alignment in that axis is not normal, then auto computes to zero<br> <ntim> fantasai: my proposal is in the double auto case if there is a default anchor, set the alignment rect to be the anchor's element's bounds<br> <ntim> iank: there are a few cases where this breaks down:<br> <ntim> iank: let's say my left is based on one anchor, and my right on another based on another<br> <ntim> TabAtkins: having the behavior being significantly different between the single and double auto cases is confusing<br> <fantasai> fantasai: We already have two different modes in abspos: static positoining or not<br> <fantasai> ... all this is doing is saying, instead of anchoring to your hypothetical box in the staticpos case, you anchor to the explicit anchor from anchor-default<br> <fantasai> ... I think it's more consistent with how CSS already works<br> <ntim> TabAtkins: i don't want it to be based on whether there's a default anchor or not, I want it to be based on the alignment value<br> <ntim> fantasai: we already have these 2 modes<br> <ntim> fantasai: alignment doesn't change what you layout relative to<br> <ntim> TabAtkins: I think it would be nice to have a consistent alignment model,<br> <ntim> we no longer need the static positioning, it would be nice to have alignment use a single consistent model<br> <ntim> fantasai: you're proposing to change existing behavior on web pages<br> <ntim> TabAtkins: no I'm not<br> <ntim> TabAtkins: my argument is not that we should change based on some arbitrary prop, for the single auto case, we turn the auto into 0<br> <fantasai> i/fantasai:/fantasai: Just becaue you dislike staticpos, because inferior to anchorpos, doesn't mean we should use the opportunity of any non-default property value to switch us out of it/<br> <ntim> TabAtkins: we should be consistent in the double auto case and resolve both to auto<br> <fantasai> s/auto/0<br> <TabAtkins> and since the staticpos behavior is subsumed by anchor pos, we don't actually lose anything by dropping it in this case, so we can ahve a better, more ocnsistent behavior by having autos always become 0 when alignment is happening<br> <ntim> TabAtkins: re: changing existing behavior, no one implements alignment properties on abspos<br> <ntim> fantasai: they do impl alignment properties for the static pos of the abspos<br> <ntim> iank: not really<br> <ntim> iank: it's implemented in grid / flexbox<br> <ntim> iank: but flexbox only implements in one axis<br> <astearns> q?<br> <ntim> iank: we're willing to take that compat risk and take that back to the group<br> <astearns> ack iank_<br> <ntim> iank: the proposed behavior is super useful<br> <ntim> iank: today if you need to center somnething in the containing block<br> <ntim> iank: there's about 2-3 ways people use, they are very clunky<br> <ntim> iank: you need to set multiple props<br> <ntim> iank: one way is setting insets to 0<br> <ntim> iank: the other way is using calc<br> <fantasai> iank: They're all super clunky<br> <ntim> iank: being able to set place-content: center and get centered alignment is very neat<br> <fantasai> scribe+<br> <fantasai> fantasai: I'm not arguing that being able to use alignment props in abspos is bad. I specced it out, obviously I think we should have it<br> <fantasai> fantasai: The hacks iank mentions are indeed all terrible and should be replaced with alignment<br> <fantasai> fantasai: that doesn't mean that alignment should change the behavior in auto-auto case<br> <fantasai> fantasai: just means you set 'inset: 0' to switch to useing the abspos containing block<br> <miriam> q+<br> <fantasai> fantasai: I don't think this his hard or confusing<br> <emeyer> scribe+<br> <iank_> q+<br> <xiaochengh> q+<br> <miriam> ack fantasai<br> <Zakim> fantasai, you wanted to say that adding 'inset: 0' is not that much to add<br> <emeyer> miriam: inset 0 isn’t a lot to add, but I as an author have never found abspos particularly useful<br> <emeyer> …I’m wondering what we gain by maintaining it<br> <dbaron> s/abspos/static positioning of abspos/<br> <emeyer> …What is the use case where I want to maintain it while adding alignment?<br> <emeyer> fantasai: Two things about adding alignment to static pos<br> <emeyer> …Static pos is like if you have an element in the document and then flip on abspos<br> <emeyer> …If you apply alignment properties in block mode (for example), then it will jump to somewhere else<br> <emeyer> …What I’m arguing for is, when you define an anchor, then static positioning becomes relative to the anchor bow<br> <emeyer> …That gets you the ability to be centered inside another box very easily<br> <emeyer> …I think for the non-anchor case, it’s about consistency with the way static positioning works<br> <emeyer> miriam: I understood you were proposing that when you switch to abspos, that would change your alignment, but in a different way<br> <emeyer> fantasai: If you want to be anchored to an element, I think it makes sense your automatic position moves to that element<br> <emeyer> …I think alignment changing your containing block to change is confusing<br> <emeyer> …Right now, alighment shifts you within the container to which you’re sizing<br> <emeyer> …anchor-default does move you; that’s its intention<br> <emeyer> …Why not have it do something as soon as it’s set?<br> <emeyer> TabAtkins: I think your argument is that current behavior is useful, and I want to argue with that<br> <emeyer> …We know that flexbox rules aren’t very useful; we watered them down on purpose<br> <emeyer> …In the one case that isn’t well implemented yet, the inline-block case, aligning goes into degenerate rectangles<br> <emeyer> …It would do something, but usually the opposite of what you expect it to do<br> <emeyer> …align: start would put you more end-ward and align: end would put you more start-word, in certain cases<br> <emeyer> …I think we were okay with that confusion when we defined the behvavior because we didn’t have anything better<br> <emeyer> …Now that we have better, we don’t have to offer authors this confusing behavior<br> <emeyer> fantasai: I think it’s great to offer a better way to do this; I’m not convinced this is the way to do it<br> <emeyer> iank_: I don’t think there’s been strong use cases presented for the double-auto case<br> <emeyer> …The behavior being proposed does solve developer pain quite well<br> <emeyer> …It does something very useful for center, stretch, a bunch of other things<br> <emeyer> …This is outside of anchor positioning<br> <vmpstr> q?<br> <emeyer> TabAtkins: I’m not sure how to resolve this, Elika<br> <iank_> ack iank_<br> <miriam> q+<br> <emeyer> …My argument is that the default behavior wasn’t useful, perhaps when it was defined, but not now<br> <emeyer> xiaochengh: For center, resolving double-auto to zero seems more useful<br> <emeyer> …THe inset modified containing block isn’t just used for alignm,ent, but also for position fallback<br> <ntim> q+<br> <emeyer> …The only containing block to test is the original containing block<br> <emeyer> …For alignment, we could use a different containing block than for fallback, but I’d like to avoid that<br> <astearns> ack xiaochengh<br> <astearns> ack miriam<br> <emeyer> miriam: Already we have a behavior where apply insets changes your reference, you’re no longer using the static position box<br> <emeyer> …To me, changing the alignment is exactly the same concept, so in my mind it aligns better with current behavior<br> <emeyer> …Alignment is an auto-inset sort of thing, so if one changes, why not the other?<br> <astearns> ack ntim<br> <vmpstr> q+<br> <astearns> ack vmpstr<br> <emeyer> vmpstr: Is there a web compatibility risk with this resolution?<br> <emeyer> TabAtkins: For some layout modes, we do implement the double-auto case<br> <emeyer> …We’re willing to take the compat risk<br> <emeyer> iank_: We’re also willing to take the risk<br> <emeyer> …We don’t think there will be much<br> <emeyer> astearns: Is there anyone who wants to show solidarity for Elika’s position?<br> <emeyer> emilio: Elika’s position is safest<br> <emeyer> iank_: If we show it’s web compatible, would that change your mind?<br> <emeyer> emilio: I don’t feel too strongly about preserving the current behavior<br> <emeyer> fantasai: Part of my point is you can get the behavior Tab and Ian want by setting inset to 0<br> <emeyer> astearns: Having a property that does nothing until you set another property isn’t good design<br> <emeyer> emilio: That’s already positioning, right?<br> <emeyer> iank_: I think our argument is that what we want is more useful and more what devs expect<br> <fantasai> astearns, that's a good argument for anchor-default having an effect without setting 'inset: anchor(..)'!<br> <emeyer> emilio: How is it more useful if the behavior Ian and Tab want can be achieved<br> <emeyer> …The current behavior cannot<br> <astearns> fantasai: I am OK with needing two properties when two things need to be connected<br> <fantasai> s/fantasai:/fantasai,/<br> <emeyer> TabAtkins: Current behavior can be achieved via anchor position<br> <fantasai> astearns, they are connected already, why not have an effect<br> <emeyer> iank_: I think also, there hasn’t been strong use cases for the existing behavior<br> <noamr_> q+<br> <emeyer> TabAtkins: Curernt staticpos behavior is in many cases unintuitive and inconsistent between layout modes<br> <emeyer> …Given it was mostly defined to give you certain powers that anchor positioning can give in better ways, we think authors are better served by having the old behavior be gone<br> <emeyer> emilio: I still th ink Elika’s position is safer but I wouldn’t object to removing it if you can get away with it<br> <astearns> ack noamr_<br> <fantasai> I'm not convinced you can do the same as staticpos for block and inline layout, at least not easily or without injecting additional things into the DOM<br> <emeyer> noamr_: If you want to achieve this non-useful behavior, you’d have to name everything<br> <emeyer> TabAtkins: You’d have to write a name, but it could be a locally s coped name (according to another proposal)<br> <emeyer> astearns: Does that meet your concern, Elika?<br> <emeyer> fantasai: Replicating for grid and flexbox is not too hard<br> <emeyer> …You have to assign a name to the contain and then tell the item to anchor itself to that<br> <emeyer> …For block and inline, you can’t just slap a name on a containing block<br> <emeyer> …You have to reference where the item would have been<br> <emeyer> …You’d have to add an empty element to the DOM to act as a placeholder<br> <TabAtkins> (not correct; you're always positioning relative to the prev/following element, and those can receive a name)<br> <emeyer> astearns: We’re out of time; not hearing consensus, but<br> <emeyer> …can we take a resolution?<br> <emeyer> fantasai: I think I’d object unless everyone else in the WG disagrees<br> <emeyer> TabAtkins: Thank you all for coming!<br> <emeyer> topic-<br> <fantasai> Tab, that doesn't work for "here's some text <span class=abspos></span> more text"<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-1717644193 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 September 2023 13:32:09 UTC