[css-anchor-position]: Question: Why is anchor-size() only valid in a sizing property?

[coderfin]

Can you help me understand why the anchor-size() function is limited to being used in a sizing property? It would be useful outside of these properties.

https://www.w3.org/TR/css-anchor-position-1/#anchor-size-valid
https://github.com/web-platform-tests/wpt/blob/master/css/css-anchor-position/anchor-size-parse-invalid.html#L10C4-L10C55

I have a use case where I don't know the height or width of the Anchor but I would like to apply a clip-path to the Target that basically creates a notch in Target.

  --anchor-height: anchor-size(--anchor height);
  --anchor-width: anchor-size(--anchor width);
  
  clip-path: polygon(
    0 0,
    0 100%,
    calc(50% - var(--anchor-width) / 2) 100%,
    calc(50% - var(--anchor-width) / 2) var(--anchor-height),
    calc(50% + var(--anchor-width) / 2) var(--anchor-height),
    calc(50% + var(--anchor-width) / 2) 100%,
    100% 100%,
    100% 0
  );

[tabatkins]

Talking with @bfgeek, we should be able to relax this restriction somewhat, to match the set of properties that are allowed to be used in @position-try. Applying it to a wider set of properties is somewhat problematic, as the properties need to be compatible with "style/layout interleaving".

This would rule out usage in clip-path, tho. We'll have to discuss this further.

[tabatkins]

Okay, so two topics:

• Allow anchor-size() in any (relevant) "accepted @position-try properties". I think this is fine mechanically, and there are reasonable use-cases for using anchor-size() in inset properties, etc.

  (anchor() needs to remain valid only in inset properties, since it's defined relative to the inset it's used in.)

• Do we want to add 'clip-path' to "accepted @position-try properties"? It's a paint-time operation, so should be safe impl-wise I think, and the use-cases for allowing anchor-size() in it make sense. We want to keep the set of properties minimal, but I think clip-path makes a lot of sense for the list. (We could also just push this to later; I anticipate us occasionally adding new props to the list in the future, and that's safe to do.)

[kizu]

Linking the #8586 that proposed a similar thing, alongside a wish to use both anchor() and anchor-size() for things like background-position, transform etc.

With anchor() being an offset, it is understandable that it is weird to have it be present in other properties. But thinking about the use cases I had for this, almost always what we want is a difference between some offsets of any two elements.

Are there any implementation issues in allowing it for properties like background-position/-size, transform, clip-path and others where it can make sense, or it just feels odd to have a not useful offset there, usually not making sense by itself outside of calculating with other offsets?

[css-meeting-bot]

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

The full IRC log of that discussion

<emeyer> TabAtkins: An author asked why the anchor-size() functions were only allowed in sizing functions
<emeyer> …It was the obvious restriction at the time, but there are use cases to allow it elsewhere
<emeyer> …At minimum, we should be able to relax this to match the list allowed in position-try
<emeyer> …Ian can talk more about the reasoning in that restriction
<kizu> q+
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<astearns> q+ kizu
<emeyer> …Roma had questions, but I don't understand them
<emeyer> …anchor-size is a size, but the function has to stay specific to the inset properties
<astearns> ack kizu
<emeyer> …Let's talk about what properties should allow anchor-size()
<emeyer> kizu: In my experiments, I often wanted to use not just the anchor size, but the anchor itself
<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
<emeyer> fantasai: We should take that as a separate issue
<emeyer> TabAtkins: Ian, could you talk about this?
<emeyer> iank_: I think it's basically the same as if we start messing around with the bits of abspos elements
<emeyer> …It starts to break a lot of optimizations
<emeyer> …I think the insets are fine, with no issues
<emeyer> futhark: I would assume this has the same limiations
<emeyer> TabAtkins: The restriction on not touching the any bits is related to not using it in padding
<emeyer> …I presume it's acceptable to do for paint-time properties like clip-path and background properties
<emeyer> …Is that accurate?
<emeyer> iank_: I'm not sure
<emeyer> …There are some things we think of paint things that do bleed into layout and I'm a little concerned about
<emeyer> TabAtkins: Example?
<emeyer> iank_: There's stuff in inlines and stuff for when we calculate overflow contributions, and then all the table internals may influence layout
<emeyer> …That's a small smattering; I'd need to talk with folks
<astearns> ack fantasai
<emeyer> fantasai: Having it apply only with the properties of position-try is a nice consistent thing to understand
<emeyer> …I think for now, starting with those properties is reasonable
<emeyer> iank_: Anders, any reason that would be bad?
<emeyer> futhark: That seems sensible, yes
<emeyer> TabAtkins: Yeah, we could start with that list and then look to see what we might add to that
<emeyer> fantasai: I don't want to add to that because position-try doesn't participate in the cascade properly
<una> q?
<ydaniv> q+
<emeyer> …If we want to style more properties conditionally, we need a more generic solution to that problem
<una> q+
<fantasai> s/add to that/add properties to @position-try/
<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
<emeyer> iank_: I think we're all in agreement about adding anchor-size to the set in position-try
<emeyer> …I think there's a different solution space for the wider problem
<emeyer> ydaniv: What about transforms? Is it possible to include them?
<astearns> ack ydaniv
<emeyer> TabAtkins: That falls into the wider problem, but I agree this would be useful for transitions
<astearns> ack una
<emeyer> …Add it to the list of future discussion
<emeyer> una: Is there a plan forward for generic styling properties?
<emeyer> …There are so many things authors want to adjust based on position and other things
<emeyer> …This general problem keeps coming up in various contexts, of which this is one
<emeyer> …Would really like to have a place to talk about the wider problem instead of hitting it in smaller problems
<emeyer> fantasai: Tab wanted to do that in level 2
<emeyer> iank_: I don't think we should do that with position-try
<florian> q?
<florian> q+
<emeyer> fantasai: We all do want to solve the problem, but it's not going into level 1
<emeyer> una: So we'd do that in 2?
<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
<iank_> q?
<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
<fantasai> s/onto a pile/onto a pile one by one/
<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?
<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_.
<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
<emeyer> astearns: Any comments or objections?
<emeyer> (silence)
<emeyer> RESOLVED: add anchor-size() into the values of properties that take lengths on the list of position-try