- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Jun 2024 10:44:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position]: Question: Why is anchor-size() only valid in a sizing property?`, and agreed to the following: * `RESOLVED: add anchor-size() into the values of properties that take lengths on the list of position-try` <details><summary>The full IRC log of that discussion</summary> <emeyer> TabAtkins: An author asked why the anchor-size() functions were only allowed in sizing functions<br> <emeyer> …It was the obvious restriction at the time, but there are use cases to allow it elsewhere<br> <emeyer> …At minimum, we should be able to relax this to match the list allowed in position-try<br> <emeyer> …Ian can talk more about the reasoning in that restriction<br> <kizu> q+<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <astearns> q+ kizu<br> <emeyer> …Roma had questions, but I don't understand them<br> <emeyer> …anchor-size is a size, but the function has to stay specific to the inset properties<br> <astearns> ack kizu<br> <emeyer> …Let's talk about what properties should allow anchor-size()<br> <emeyer> kizu: In my experiments, I often wanted to use not just the anchor size, but the anchor itself<br> <emeyer> TabAtkins: Given that anchor size is a difference between two anchors, being able to provide two anchors and get the distance between them sounds doable<br> <emeyer> fantasai: We should take that as a separate issue<br> <emeyer> TabAtkins: Ian, could you talk about this?<br> <emeyer> iank_: I think it's basically the same as if we start messing around with the bits of abspos elements<br> <emeyer> …It starts to break a lot of optimizations<br> <emeyer> …I think the insets are fine, with no issues<br> <emeyer> futhark: I would assume this has the same limiations<br> <emeyer> TabAtkins: The restriction on not touching the any bits is related to not using it in padding<br> <emeyer> …I presume it's acceptable to do for paint-time properties like clip-path and background properties<br> <emeyer> …Is that accurate?<br> <emeyer> iank_: I'm not sure<br> <emeyer> …There are some things we think of paint things that do bleed into layout and I'm a little concerned about<br> <emeyer> TabAtkins: Example?<br> <emeyer> iank_: There's stuff in inlines and stuff for when we calculate overflow contributions, and then all the table internals may influence layout<br> <emeyer> …That's a small smattering; I'd need to talk with folks<br> <astearns> ack fantasai<br> <emeyer> fantasai: Having it apply only with the properties of position-try is a nice consistent thing to understand<br> <emeyer> …I think for now, starting with those properties is reasonable<br> <emeyer> iank_: Anders, any reason that would be bad?<br> <emeyer> futhark: That seems sensible, yes<br> <emeyer> TabAtkins: Yeah, we could start with that list and then look to see what we might add to that<br> <emeyer> fantasai: I don't want to add to that because position-try doesn't participate in the cascade properly<br> <una> q?<br> <ydaniv> q+<br> <emeyer> …If we want to style more properties conditionally, we need a more generic solution to that problem<br> <una> q+<br> <fantasai> s/add to that/add properties to @position-try/<br> <emeyer> TabAtkins: That is a thing we can deal with later, we can use the list from position-try for now and open a new issue to discuss further onward<br> <emeyer> iank_: I think we're all in agreement about adding anchor-size to the set in position-try<br> <emeyer> …I think there's a different solution space for the wider problem<br> <emeyer> ydaniv: What about transforms? Is it possible to include them?<br> <astearns> ack ydaniv<br> <emeyer> TabAtkins: That falls into the wider problem, but I agree this would be useful for transitions<br> <astearns> ack una<br> <emeyer> …Add it to the list of future discussion<br> <emeyer> una: Is there a plan forward for generic styling properties?<br> <emeyer> …There are so many things authors want to adjust based on position and other things<br> <emeyer> …This general problem keeps coming up in various contexts, of which this is one<br> <emeyer> …Would really like to have a place to talk about the wider problem instead of hitting it in smaller problems<br> <emeyer> fantasai: Tab wanted to do that in level 2<br> <emeyer> iank_: I don't think we should do that with position-try<br> <florian> q?<br> <florian> q+<br> <emeyer> fantasai: We all do want to solve the problem, but it's not going into level 1<br> <emeyer> una: So we'd do that in 2?<br> <emeyer> fantasai: This isn't actually that problem, and I'd rather have a solution rather than confusing authors by throwing properties onto a pile<br> <iank_> q?<br> <emeyer> …We need to have some kind of an answer that makes sense as to why a thing can be used for one property but not another<br> <fantasai> s/onto a pile/onto a pile one by one/<br> <emeyer> florian: We all want to solve the bigger problem some day, so the question is, does this immediate solution depend on the longer-term solution?<br> <florian> s/depend on the longer-term solution?/depend on the longer-term solution? if not (and it seems not), then let's not discuss the bigger problem _now_.<br> <emeyer> TabAtkins: propose to add anchor-size() into the values of properties that take lengths on the list of position-try, and tackle the wider problem later<br> <emeyer> astearns: Any comments or objections?<br> <emeyer> (silence)<br> <emeyer> RESOLVED: add anchor-size() into the values of properties that take lengths on the list of position-try<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9827#issuecomment-2160430157 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 10:44:27 UTC