- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Oct 2024 16:36:04 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <fantasai> https://drafts.csswg.org/css-anchor-position-1/#valid-anchor-function<br> <emilio> fantasai: [summarizes the issue]<br> <emilio> fantasai: some of the invalid cases we can figure out at parse time<br> <emilio> ... like whether it's used in an inset property or what not<br> <emilio> ... the spec is not very clear on whether we're allowed to validate at parse time vs. used value time<br> <emilio> ... question is, do we want to do parse-time validation insofar as possible, or doing everything at computed-value time?<br> <emilio> q+<br> <fantasai> 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?<br> <emilio> astearns: if we do as much at parse time, are we concerned about cases where they can't being confused?<br> <emilio> fantasai: that's the common case<br> <emilio> ... because things like the thing not being an abspos are more likely to trip authors<br> <kizu> +q<br> <emilio> ... I think it'd be easier for devs if we can validate what we can at parse time<br> <astearns> ack emilio<br> <emilio> ... but computed-value time is going to be common too<br> <fantasai> emilio: it doesn't seem that we can take this very far, e.g. parsing invalidation would be limited<br> <fantasai> emilio: e.g. custom property can't be validated even if registered<br> <fantasai> emilio: I think it's only wrong sides that can be parse-time validated?<br> <fantasai> 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<br> <astearns> ack kizu<br> <fantasai> kizu: another perspective, not sure if I see a big difference<br> <fantasai> 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<br> <fantasai> kizu: but no strong opinion<br> <fantasai> astearns: if we do have these two modes, roman will take advantage of them somehow<br> <emilio> 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<br> <ydaniv> more likely devs will use `@supports`<br> <fantasai> s/it could be/roman would find it/<br> <emilio> 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...<br> <emilio> fantasai: right but those are a condition on the box<br> <emilio> q+<br> <astearns> ack emilio<br> <fantasai> emilio: feels weird that adding a registered property could change the fallback behavior<br> <fantasai> emilio: can you even drop an anchor function on a ??<br> <fantasai> emilio: but then syntax of left/top becomes subtly different, which is not amazing but maybe fine<br> <fantasai> emilio: no strong opinion either way<br> <fantasai> emilio: not super useful, and maybe a headache for interactions with other feature<br> <fantasai> fantasai: that's fair<br> <astearns> ack dbaron<br> <fantasai> dbaron: Assume everyone agrees, but you mentioned one of the conditions is what property it's used in<br> <fantasai> dbaron: that piece should be parse-time no matter what<br> <fantasai> dbaron: so assuming we're debating the other cases<br> <emilio> q+<br> <astearns> ack emilio<br> <fantasai> ACTION: Editors to clarify (by adjusting the legacy wording) that anchor() is invalid outside inset properties<br> <fantasai> emilio: Given that, my concern about custom properties goes away<br> <fantasai> emilio: the only weird thing is having different inset properties having slightly different syntax<br> <dbaron> The spec currently says "It is only valid to be used in the inset properties."<br> <fantasai> emilio: what if you do inset: anchor(top); Is that valid or not?<br> <fantasai> emilio: but if we validate at parse time it would expand to something invalid<br> <astearns> ack fantasai<br> <emilio> fantasai: I think that convinced me<br> <emilio> ... that and we can't validate in logical properties<br> <emilio> ... so it'd be very weird to validate in a very small number of cases<br> <emilio> ... I think we clarify by removing the mention of it being in an `inset` properties<br> <emilio> ... the rest of these are computed-value time<br> <emilio> astearns: so close no change (only editorial tweaks?)<br> <fantasai> PROPOSED: All conditions listed (other than which property it's used in) are computed-value time.<br> <fantasai> RESOLVED: All conditions listed (other than which property it's used in) are computed-value time.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10955#issuecomment-2402802226 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 October 2024 16:36:05 UTC