Re: [csswg-drafts] [css-anchor-position] Is `anchor()` fallback used when outside of inset properties? (#10950)

The CSS Working Group just discussed ``[css-anchor-position] Is `anchor()` fallback used when outside of inset properties?``, and agreed to the following:

* `RESOLVED: anchor() functions are only valid in inset properties, clarify spec`
* `RESOLVED: anchor-size() only allowed in properties allowed in @position-try. Clarify spec.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: so there's a question of where anchor() is "valid"<br>
&lt;TabAtkins> fantasai: there's parse validity, and there's "does it have a value, or does it use the fallback"<br>
&lt;kizu> q+<br>
&lt;TabAtkins> fantasai: I think what we mean is that it's only parse-valid in the inset properties<br>
&lt;TabAtkins> fantasai: but some of the text in the spec is confusing on that point<br>
&lt;TabAtkins> fantasai: so want to double check that's the intention<br>
&lt;fantasai> fantasai: and if so, we need to clarify spec<br>
&lt;fantasai> TabAtkins: yes that was the intention<br>
&lt;astearns> ack kizu<br>
&lt;TabAtkins> TabAtkins: they fundamentally don't make sense outside of the inset property<br>
&lt;TabAtkins> kizu: in my exploration i found some use-cases for using them outside of those<br>
&lt;TabAtkins> kizu: wonder if we could say that an explicit side like "left" is okay outside?<br>
&lt;TabAtkins> kizu: there are use-cases both for anchor() and anchor-size() where you might wnat to compute something intersting based on them<br>
&lt;TabAtkins> kizu: right now it's very limited. there are workarounds<br>
&lt;fantasai> TabAtkins: The reason they're not usable outside 'inset' properties is because they compute to the value that the 'inset' property needs to hit a paricular position<br>
&lt;fantasai> TabAtkins: so you need to know which inset property you're in (e.g. left vs top)<br>
&lt;fantasai> TabAtkins: and outside the inset properties, we have no context<br>
&lt;fantasai> s/top/right/<br>
&lt;iank_> `right: anchor(left)` != `left: anchor(left)`<br>
&lt;fantasai> TabAtkins: so if you could elaborate on use cases ..?<br>
&lt;TabAtkins> kizu: really i just wanted ot use the difference between two anchor positions<br>
&lt;TabAtkins> kizu: the acutal value doesn't amtter, just he difference<br>
&lt;fantasai> TabAtkins: What you described, diff between two position, is not contextual<br>
&lt;bkardell> s/mtter, just he difference/matter, just the difference<br>
&lt;fantasai> TabAtkins: if we wanted to do that, we could address it via new function<br>
&lt;fantasai> TabAtkins: anchor-distance() or something<br>
&lt;fantasai> TabAtkins: similar to anchor-size()<br>
&lt;fantasai> TabAtkins: So i think we should reject using anchor() outside insets, but could explore using another anchor function<br>
&lt;fantasai> fantasai: separate issue<br>
&lt;fantasai> kizu: anchor-size() ?<br>
&lt;fantasai> TabAtkins: anchor-size() is already usable more widely<br>
&lt;dshin> I think the main reason for rejecting general-use is https://github.com/w3c/csswg-drafts/issues/9827<br>
&lt;fantasai> iank_: it's allowed on the size properties, whereas anchor() isn't<br>
&lt;TabAtkins> anchor-size() is allowed in a sizing property, an inset property, or a margin property<br>
&lt;fantasai> kizu: Background size shadow on the ground would be very useful<br>
&lt;TabAtkins> (aka the properties you can adjust in position-try, iirc)<br>
&lt;fantasai> kizu: but not allowed currently<br>
&lt;fantasai> astearns: not expanding where it's valid, but could add a different function for those use cases<br>
&lt;fantasai> astearns: anyone who would object to resolving that the anchor() function is not applicable elsewhere than insets?<br>
&lt;fantasai> RESOLVED: anchor() functions are only valid in inset properties, clarify spec<br>
&lt;fantasai> astearns: original post here asks about anchor-size()<br>
&lt;fantasai> astearns: Is that something to discus snow<br>
&lt;fantasai> TabAtkins: Limitation on anchor-size() was due to some processing pipeline timing restrictions<br>
&lt;fantasai> TabAtkins: limited to properties allowed in position-try<br>
&lt;fantasai> TabAtkins: I should check that lists are synced<br>
&lt;fantasai> TabAtkins: I think that's the restriction<br>
&lt;fantasai> iank_: We want to avoid stuff that changes element in general<br>
&lt;fantasai> iank_: e.g. border isn't allowed, has substantial effects on e.g. tables<br>
&lt;fantasai> iank_: margins and size properteis are fine<br>
&lt;astearns> ack fantasai<br>
&lt;fantasai> PROPOSED: anchor-size() only allowed in properties allowed in @position-try. Clarify spec.<br>
&lt;fantasai> astearns: any objections?<br>
&lt;fantasai> RESOLVED: anchor-size() only allowed in properties allowed in @position-try. Clarify spec.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10950#issuecomment-2776675522 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 3 April 2025 19:01:00 UTC