[css-anchor-position] Should anchor() be validated at parse time when it is known invalid?

[weinig]

There are some uses of anchor() that can be determined invalid() at parse time. For instance,

left: 10px;
left: anchor(--x top);

Should left resolve to 10px here, or the default value?

The spec is a little unclear on when this "valid anchor function" concept is evaluated and/or if it is something that gets evaluated at each stage.

[fantasai]

I suspect we should validate whatever we can at parse time. It allows for better fallback behavior. Agenda+ to discuss.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] Should anchor() be validated at parse time when it is known invalid?, and agreed to the following:

• ACTION: Editors to clarify (by adjusting the legacy wording) that anchor() is invalid outside inset properties
• RESOLVED: All conditions listed (other than which property it's used in) are computed-value time.

The full IRC log of that discussion

https://drafts.csswg.org/css-anchor-position-1/#valid-anchor-function
fantasai: [summarizes the issue]
fantasai: some of the invalid cases we can figure out at parse time
... like whether it's used in an inset property or what not
... the spec is not very clear on whether we're allowed to validate at parse time vs. used value time
... question is, do we want to do parse-time validation insofar as possible, or doing everything at computed-value time?
q+
astearns: if we do as much invalidation as we can at parse time, are you concerned that the edge cases where we can't invalidate at parse time would be confusing to authors?
astearns: if we do as much at parse time, are we concerned about cases where they can't being confused?
fantasai: that's the common case
... because things like the thing not being an abspos are more likely to trip authors
+q
... I think it'd be easier for devs if we can validate what we can at parse time
ack emilio
... but computed-value time is going to be common too
emilio: it doesn't seem that we can take this very far, e.g. parsing invalidation would be limited
emilio: e.g. custom property can't be validated even if registered
emilio: I think it's only wrong sides that can be parse-time validated?
emilio: I agree in principle that validating as much at parse time as possible is better, but in this case might not be worth it
ack kizu
kizu: another perspective, not sure if I see a big difference
kizu: if we can do it at parse time it would be nice, but in practice don't think I ever wanted to use a fallback in this case
kizu: but no strong opinion
astearns: if we do have these two modes, roman will take advantage of them somehow
fantasai: actually... I was thinking the opposite, if we go with the two modes, then in the future you could set left in the top side and I bet it could be eventually useful
more likely devs will use `@supports`
s/it could be/roman would find it/
astearns: they'd be able to use @supports for specific cases but then might try to do that for cases we can't determine at parse time...
fantasai: right but those are a condition on the box
q+
ack emilio
emilio: feels weird that adding a registered property could change the fallback behavior
emilio: can you even drop an anchor function on a ??
emilio: but then syntax of left/top becomes subtly different, which is not amazing but maybe fine
emilio: no strong opinion either way
emilio: not super useful, and maybe a headache for interactions with other feature
fantasai: that's fair
ack dbaron
dbaron: Assume everyone agrees, but you mentioned one of the conditions is what property it's used in
dbaron: that piece should be parse-time no matter what
dbaron: so assuming we're debating the other cases
q+
ack emilio
ACTION: Editors to clarify (by adjusting the legacy wording) that anchor() is invalid outside inset properties
emilio: Given that, my concern about custom properties goes away
emilio: the only weird thing is having different inset properties having slightly different syntax
The spec currently says "It is only valid to be used in the inset properties."
emilio: what if you do inset: anchor(top); Is that valid or not?
emilio: but if we validate at parse time it would expand to something invalid
ack fantasai
fantasai: I think that convinced me
... that and we can't validate in logical properties
... so it'd be very weird to validate in a very small number of cases
... I think we clarify by removing the mention of it being in an `inset` properties
... the rest of these are computed-value time
astearns: so close no change (only editorial tweaks?)
PROPOSED: All conditions listed (other than which property it's used in) are computed-value time.
RESOLVED: All conditions listed (other than which property it's used in) are computed-value time.

[kizu]

Re: inset: anchor(--foo bottom, 10px), quickly tested: https://codepen.io/kizu/pen/VwomaVG?editors=1100

currently Chrome accepts it, and when applying them to the sides that do not accept the value, uses the fallback value provided to the anchor() function (10px in this case), which might be a useful behavior.