- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Aug 2023 23:36:42 +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?`, and agreed to the following: * `RESOLVED: Define this new auto behavior for anchor-center. Bring this issue back with examples for the rest` <details><summary>The full IRC log of that discussion</summary> <dael_> TabAtkins: This is a generalization of one detail on anchor-center. When defining it, I realized if we didn't change anything about auto insets it wouldn't work very well. To make anchor-center work you need to set left and right to 0.<br> <dael_> TabAtkins: This is b/c current behavior is designed around certain assumptions and lacks of functionality CSS 2 had but we've since filled in. If you have a single auto it tightly wraps you element to align in the obvious way. This type of behavior made sense in css 2.<br> <dael_> TabAtkins: We now have better. The behaviors with rough approximations no longer make sense. anchor-center spec that double auto insets resolves one to 0 and the other to the same distance in other direction so you get largest possible non-overflow<br> <dael_> TabAtkins: In the other case, makes sense to do something similar and set auto insets to 0. If there's not 0 then alignment doesn't do something useful. Right now double auto makes you'd align static pos not abspos.<br> <dael_> TabAtkins: In the presense of an affermative signal you want alignment, meaning you set an alignment to non-intial, we probably want to change<br> <dael_> TabAtkins: Pro: for any non-initial value for self alignment properties we resolve auto to 0. We keep current for default, can't change that. but if you say something like start-align it makes sense to give them an inset CB you can position into<br> <dael_> TabAtkins: For abspos elements if self-alignment property is non-default we resolve auto to 0. I want to leave possibility to do more subtle things. For example anchor-center is a little smarter, but similar in spirit<br> <dael_> TabAtkins: I don't believe anyboy impl yet. We are about to in chrome. If anyone does, hopefully reasonable change.<br> <dael_> TabAtkins: thoughts?<br> <astearns> ack fantasai<br> <iank_> q+<br> <dael_> fantasai: I'm not 100% sure that's compat with flexbox and grid which are spec to honor alignment properties for staticpos<br> <fantasai> https://www.w3.org/TR/css-position-3/#abspos-insets<br> <dael_> fantasai: There is behavior in positioning spec for these values where alignment is with respoect to static pos. I disagree nothing useful to be done without setting to 0<br> <dael_> TabAtkins: Compat isn't an issue b/c chrome at least doesn't support there. It's a change in spec, but not a change in actual behavior. not sure on other browsers<br> <dael_> iank_: Small change for up, but I don't think it would be web compat issue<br> <dael_> TabAtkins: I also believe for single non-auto case it's pretty straight forwardly bad if you're indicating you want to align<br> <dael_> fantasai: In grid or flexbox you'r aligning to the container that's your parent<br> <dael_> TabAtkins: Single auto, not double<br> <dael_> TabAtkins: Single i think this is clearly right<br> <dael_> fantasai: Oooh, okay.<br> <iank_> +1 that its a better behaviour for the general case.<br> <dael_> TabAtkins: In the double case, the new behavior aligns you in abspos CB. I believe that's better. anchor-center definitely wants it and I suspect better in the general case. Often it's similar.<br> <dael_> TabAtkins: The staticpos rect doesn't seem the most useful<br> <dael_> fantasai: In flexbox align-self to does and effect when you're staticpos. Same for grid.<br> <dael_> fantasai: Also you're losing functionality by doing that b/c then you can't align in staticpos which in grid/flexbox is your parent and in block it's left/right which has some uses. You want to be in static but align to end for example<br> <dael_> fantasai: I don't mind changing for single auto where other end is anchor b/c you're not doing static at that point. So saying treat the other side as 0 doesn't seem unreasonable. Id on't think we should change spec<br> <fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20grid%3B%20border%3A%20solid%3B%20width%3A%20100px%3B%20height%3A%20100px%22%3E%0A%20%20%3Cdiv%20style%3D%22position%3A%20absolute%3B%20border%3A%20solid%20orange%3B%20align-self%3A%20end%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A<br> <dael_> TabAtkins: Main counter is all static pos behavior is a weak approx of what you can do with anchor pos. Anything you can do with static you can do better with anchor. So preserving isn't that relevant<br> <dael_> astearns: iank_ has been on the queue for a bit<br> <astearns> ack iank_<br> <dael_> iank_: Generally, I don't think people rely on static pos often.<br> <dael_> iank_: With self alignment I don't think we'll have compat issue<br> <chrishtr> q+<br> <dael_> iank_: When I played with it seemed like an upgrade for authors<br> <dholbert> q+<br> <dael_> iank_: Getting to compat, staticpos was already weird b/c align-self would impact both axes. I think this is an upgrade for double-auto. We're prepared to take web compat hit to see if this is compat<br> <astearns> ack chrishtr<br> <dael_> chrishtr: iank_ question on flexbox/grid. Are tehre use cases there?<br> <dael_> iank_: Not paticularly. You have the case where your CB is the parent. When the abspos they make the parent relpos. When mostly using abspos no behavior change. I agree with TabAtkins anything needing staticpos can be done better with anchor<br> <astearns> ack dholbert<br> <chrishtr> q+<br> <dael_> dholbert: Better to separate repaced and non-replaced elements. Replaced elements have intrinsic width. Actively giving it left:0 right:0 will stretch and I don't think that's the intent<br> <dael_> iank_: Intent would be we don't stretch when we resolve to 0. We keep shrink to fit. We're changing used not computed value. So you look at computed when determining to stretch<br> <dael_> TabAtkins: We're not changing initial value behavior. Only if you set the self alignment property to specific<br> <dael_> dholbert: Default doesn't have something, you set align-self:center and then it stretched<br> <dael_> TabAtkins: Center doesn't trigger stretch<br> <dael_> dholbert: Even if it's top/bottom set to 0<br> <dael_> TabAtkins: I think so. It would be a spec bug if it does, I think<br> <astearns> ack chrishtr<br> <dael_> chrishtr: My understanding is this substantialy simplifies engine. Correct?<br> <dael_> dholbert: I think so from when I tried to impl the grid change. Simplier not to have to compute the auto offset if you don't have to<br> <dael_> iank_: It's a straight up simplification and matches what devs expect<br> <dael_> astearns: I wonder if we could resolve to define this for anchor-center for now and keep this open and have fantasai look at flex/grid use cases and come up with here is what we'll lose with examples?<br> <dael_> TabAtkins: We've already significantly chopped down staticpos behavior for flex and grid. If fantasai wants to spend time, happy to keep open<br> <dael_> iank_: Presense of anchor being there is an important caveat<br> <dael_> fantasai: Yeah, I think that you don't lose as much with anchor positioning. I think the areas I'm more concerned is block layout<br> <dael_> TabAtkins: Haven't thought about block yet so happy to discuss there.<br> <dael_> iank_: I don't think you lose anything with block b/c if you need to you make the static parent an anchor and target the edges you're interested in<br> <dael_> fantasai: How would you do that?<br> <dael_> TabAtkins: I think we should go into the details in issue<br> <fantasai> s/that/that automatically/<br> <dael_> astearns: Prop: add this new bevaior for anchor-center and leave the issue open for if this is extended to the rest of the non-initial values<br> <una> so will there be a new issue open for that?<br> <dael_> fantasai: I think for anchor-center this does make sense<br> <dael_> astearns: [reads una] I think we leave this one open since it's not an anchor-position specific issue<br> <dael_> dholbert: And anchor-center is a bit more magical than this proposal<br> <dael_> astearns: Is that okay una?<br> <dael_> una: Sounds good<br> <dholbert> This is the testcase that I was looking at for "what are the effects of the used value being auto vs 0", fwiw: https://jsfiddle.net/dholbert/15y3dqu2/<br> <dael_> iank_: Can we try and get back within the month?<br> <dael_> astearns: Prop: Define this new auto behavior for anchor-center. Bring this issue back with examples for the rest<br> <dael_> astearns: Obj?<br> <dael_> RESOLVED: Define this new auto behavior for anchor-center. Bring this issue back with examples for the rest<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-1663098232 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 August 2023 23:36:44 UTC