- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Jun 2024 11:33:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position] Resolution of percentages: area or track?`, and agreed to the following: * `RESOLVED: Close with no change` <details><summary>The full IRC log of that discussion</summary> <emeyer> fantasai: (goes to chalkboard)<br> <emeyer> fantasai: This is about percentage resolution on inset properties<br> <emeyer> …Here's an acnhor, inside a container<br> <emeyer> …For the inset area, we create a 3x3 grid<br> <emeyer> …You can address this by saying in which grid box an anchor should live<br> <emeyer> …Let's say we put the anchor positioned element in `bottom span right`<br> <astearns> s/bottom span right/bottom span-right/<br> <emeyer> …Let’s say I want to draw a box in that area that's positioned with its left at 50% minus some amount, say 30px<br> <emeyer> …We could create an anchor centerline, but that's only narrowly useful<br> <emeyer> …When we designed the inset area, we said 100% left would align with the right edge of the anchor<br> <emeyer> …For the inset properties, the percentage is relative not to the container, but to the track on that side<br> <astearns> s/say 30px/say 30px. The issue is that the 50% is relative to the entire span, when I want it only to be the center/<br> <emeyer> …That gives you an easy way to do a lot of positions<br> <andruud> q+<br> <nicole> q+<br> <miriam> q+<br> <astearns> ack florian<br> <TabAtkins> q+<br> <emeyer> …Tab pointed out this is inconsistent with inset elsewhere, which is relative to the containing block instead of the tracks<br> <una> q?<br> <una> q+<br> <fserb> q+<br> <kbabbitt> fantasai's proposal: left: calc(50% - 30px) where percentage is relative to the track on that side<br> <emeyer> una: In this case, 100% doesn't mean the whole containing area, just the track?<br> <emeyer> fantasai: Yes<br> <astearns> ack andruud<br> <emeyer> andruud: Did you consider a unit like container size query?<br> <kbabbitt> alternate proposal: left: calc(anchor-size() * 0.5 - 30px) where percentage is relative to the entire size of the positioned element's containing block<br> <emeyer> fantasai: No, percentages seemed natural here<br> <TabAtkins> (I have a specific rebuttal for that point)<br> <emeyer> andruud: It seems weird that this changes meaning for different sides<br> <emeyer> …You said you could solve this with anchor-size()?<br> <emeyer> fantasai: That was Tab's proposal<br> <kbabbitt> s/alternate/TabAtkins/<br> <emeyer> andruud: A unit would give you that<br> <emeyer> TabAtkins: I'm more strongly on, this is not how percentages work anywhere else in CSS<br> <bramus> q?<br> <emeyer> …The consistency of always going off the containing block means you can use them and have an idea of what they will mean<br> <bramus> q+<br> <florian> q+ to comments on units vs percent<br> <emeyer> …Changing this in left and right in this situation and making them distinct from all other percentage uses in incredibly confusing<br> <astearns> q+<br> <emeyer> …Using anchor-size() or coming up wihth a new unit are more preferable for me<br> <astearns> ack nicole<br> <ydaniv> q+<br> <kbabbitt> q+<br> <emeyer> nicole: Clarification about the diagram: the direction of the arrows is meaningful<br> <emeyer> s/meaningful/meaningful?/<br> <emeyer> fantasai: Yes, it inidicate the left property refers to the leftmost track and right to the rightmost<br> <astearns> ack miriam<br> <emeyer> miriam: I kind of like the unit idea<br> <emeyer> …If you're spanning all, does left give you left and right give you right and there's no access to the middle?<br> <emeyer> fantasai: Yes<br> <emeyer> miriam: And 150% would be consistent to the track, not the container?<br> <emeyer> fantasai: Yes<br> <astearns> ack TabAtkins<br> <miriam> (is there a way to use cq* units here?)<br> <emeyer> TabAtkins: The proposal means left: 100%; right: 100%; would fill the containing block, but left: 150%; right: 150% would not<br> <emeyer> s/right: 150%/right: 50%/<br> <astearns> ack una<br> <emeyer> una: I feel like as an author, I prefer consistency<br> <emeyer> …I probably wouldn't use span-right here<br> <emeyer> …If I did 100%, I would expect it span across both tracks<br> <emeyer> …This adds complexity if I change positions<br> <emeyer> …Because this conflicts with my understanding of percentages, it would be harder than using anchor-size() or some other approach<br> <emeyer> …This feels like it simplifies some use cases and complexifies other use cases<br> <astearns> ack fserb<br> <emeyer> fserb: Was thinking about what would happen if the choice was the other one<br> <miriam> q+ to ask about % on width/height/margin/padding properties<br> <emeyer> …So if it was bottom span-left, you could only percent from the right?<br> <emeyer> …Or if you spanned the whole thing, what would happen?<br> <emeyer> fantasai: left: 50% would be halfway across the left track, and right: 50% would be halfway across the right track<br> <masonf> In that example, with 50%, the tooltip isn't centered.<br> <TabAtkins> More on the "this is inconsistent" drumbeat: this means you can't invert the property you're using with the `calc(100% - N)` math<br> <emeyer> fserb: And in other proposals, percentages would be relative to the whole area?<br> <emeyer> fantasai: Yes<br> <astearns> ack bramus<br> <una> Also would this break/behave differently than translate: 50%?<br> <emeyer> bramus: Looking at the data between the code you have at the bottom of the drawing, and then comparing to the other code, I don't see a big delt between them<br> <TabAtkins> translate: 50% is relative to the item, not the CB, so that's already different<br> <emeyer> …If you do the thing on the left, then you aren't changing the meaning of percentages<br> <emeyer> …The proposal seems very confusing<br> <emeyer> …If percentages were used here, I would expect them to resolve against the inset area<br> <TabAtkins> more inconsistency: this means that `inset: 0; inset-area: bottom span-right;` is different from `left: anchor(right); right: 0; top: anchor(bottom); bottom: 0;` - right now there is no difference between these (save for a bit of error-correction when the anchor is outside the CB)<br> <emeyer> fantasai: To take a simpler example, if I wanted to put a pin over the anchor with its base in the middle of the anchor, it would be `inset-area: center span-top; bottom: 50%`<br> <emeyer> bramus: You could also do inset size * 0.5<br> <florian> q?<br> <emeyer> fantasai: The alternative would be `inset-area: center span-top; bottom: calc(anchor-size()*0.5)`<br> <bramus> s/inset size * 0.5/anchor size * 0.5<br> <astearns> ack florian<br> <Zakim> florian, you wanted to comments on units vs percent<br> <emeyer> florian: At least in the two-column case, we can get what we want without new stuff using verbose syntax<br> <emeyer> …Maybe we could use it for the three-column cases?<br> <emeyer> …But if we want a compact syntax, we need something new<br> <emeyer> …The proposal for a new unit makes me feel strange<br> <emeyer> …You'd end up with a unit that's easy to understand why you don't want it<br> <emeyer> …It wouldn't mean anything in most properties<br> <TabAtkins> q+ about the usage<br> <emeyer> …It's odd to have percentage meaning change, but it's useful<br> <emeyer> …In sets of related properties, percentages don't always do the same thing<br> <TabAtkins> q+<br> <astearns> q+ TabAtkins to comment about the usage<br> <emeyer> …It's stronger here, but it's not completely new<br> <emeyer> …It takes getting used to, but there's no alternative usage of percentage that makes sense, and explaining what a new unit does in situations where it doesn't apply also seems confusing<br> <emeyer> astearns: Is this analagous to positoining something inside a grid unit that spans tracks?<br> <emeyer> fantasai: Yes, but in that case I think it's a lot less clear what you want to result<br> <emeyer> astearns: I disagree, with my chair hat off<br> <emeyer> florian: Even if it's going to cause inconsistency?<br> <miriam> q-<br> <florian> qq+<br> <emeyer> astearns: I don't think it's any less inconsistent than the alternative<br> <astearns> ack florian<br> <Zakim> florian, you wanted to react to florian<br> <astearns> ack astearns<br> <emeyer> florian: I don't see it as an inconsistnecy because we already define per-property what it means<br> <florian> s/what it means/what percentages means<br> <astearns> ack ydaniv<br> <emeyer> ydaniv: Agree with Florian; we already define percentages differently in different contexts<br> <una> q+<br> <emeyer> …We made some things simple with ranges, but lost some things that way as well<br> <emeyer> fantasai: If you did end up with a use case where you needed to resolve against the whole inset area, you could use the anchor functions and do a lot of math<br> <emeyer> …So we do have an escape hatch<br> <bramus> q+<br> <emeyer> …In the set of things people are going to do, are the use cases of the using whole inset area more or less common than using tracks<br> <emeyer> …I suspect the whole inset area would be extremely rare<br> <emeyer> …I'd ask people to come up with examples and then decide what you feel more comfortable with<br> <TabAtkins> Also left:anchor(50%) already centers on the anchor, fwiw.<br> <TabAtkins> You need some more effort to center on the side tracks<br> <astearns> ack kbabbitt<br> <emeyer> kbabbitt: For the use case presented here, I don't understand why you need bottom span-right<br> <emeyer> …Couldn't you just set the left at 50% - 30px and then let the positioned element overflow?<br> <emeyer> fantasai: You can do that, but by default, if you're in the center track you're aligned with respect to the center track<br> <emeyer> …So if you overflow, you'd overflow in both directions<br> <fserb> q+<br> <emeyer> miriam: This would also impact position-fallback, right?<br> <emeyer> fantasai: Yes<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <emeyer> kbabbitt: In a case where you are spanning all the bottom tracks, how do you hit the case where you want to be 50% of the center track?<br> <emeyer> fantasai: You wouldn't try to do that<br> <emeyer> kbabbitt: So your goal is to grow both directions, or to grow one direction or the other, and that informs your choices?<br> <emeyer> fantasai: Right<br> <astearns> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to comment about the usage<br> <nicole> q+<br> <emeyer> TabAtkins: Two things from me…<br> <emeyer> …Any argument about left and right percentages being not useful to the whole containing block I think apply exactly equally to margin-left and -right<br> <emeyer> fantasai: I'm not sure I would use percentage margins here<br> <emeyer> …I suppose you'd want something more consistent<br> <emeyer> …It's worth noting all margins resolve against the inline axis<br> <emeyer> TabAtkins: Second note, the main obvious use case is positioning with relation to the center of the center track<br> <emeyer> fantasai: Yes<br> <emeyer> TabAtkins: If you put a percentage in the anchor() function, you get the placement you want<br> <emeyer> …`left: anchor(50%)` puts an edge right in the middle of an anchor<br> <emeyer> fantasai: Would that work with the inset properties?<br> <emeyer> TabAtkins: Yeah, it doesn't care about that<br> <emeyer> …It should automatically work<br> <emeyer> …In the cases you need something more precise, leaning on math is fine<br> <emeyer> …For the center ones, we can already do it<br> <emeyer> fantasai: So you're saying `left: anchor(50%)` would address this situation<br> <emeyer> astearns: Is that simplfication enough for you to withdraw the option you were presenting, Elika?<br> <emeyer> fantasai: I think so<br> <astearns> ack una<br> <emeyer> astearns: Provisionally we might resolve this a closed, no change, but let's go to the queue<br> <emeyer> una: My main question is, are we seeing cases where developers run into percentage confusion?<br> <emeyer> fantasai: I don't think so, the question is more how easy can we make it to do the common cases?<br> <emeyer> una: I get that, but what if you want something that spans 90% of both tracks?<br> <emeyer> fantasai: You could put margin: 10%<br> <emeyer> s/margin: 10%/margin: 5%/<br> <emeyer> una: So that wouldn't apply to the margins, just the insets<br> <emeyer> fantasai: Yes<br> <astearns> ack bramus<br> <emeyer> bramus: I like the anchor() fix, but the main thing is you want access to the anchor block and inline sizes, so maybe in the future a unit would be useful; no need to resolve now<br> <astearns> ack fserb<br> <emeyer> fserb: I think having usint that behave differently on the same axis are weirder<br> <emeyer> s/usint/units/<br> <masonf> lol<br> <emeyer> …I question that I cannot find a use case for the total size<br> <emeyer> …If you don't change, they aren't good for expressing anything<br> <emeyer> …For folks who don't like the percentages, is that a use case fo 30% of the total thing?<br> <emeyer> una: If you had a big block of text inside the positioned element, and you want to make it readable with a percentage margin, this is an example that you wouldn't have something small like this<br> <emeyer> fantasai: So something like a really long footnote<br> <emeyer> una: Yeah<br> <emeyer> fantasai: I think if you want spacing, margin is appropriate<br> <emeyer> una: Right, but if the percentages are different between margins and insets, that's weird<br> <emeyer> Nicole Sullivan: Having a lever over how things grow, that would be useful<br> <emeyer> fantasai: I think we have the right controls, but I'm willing to talk that through<br> <emeyer> astearns: Can we resolve close, no change?<br> <emeyer> fantasai: I think that works<br> <emeyer> RESOLVED: Close with no change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10314#issuecomment-2160527775 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 June 2024 11:33:38 UTC