- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 23 Jul 2025 17:04:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] Behavior with transforms and offset-path`, and agreed to the following: * `RESOLVED: Anchor positioning will take transforms into account.` <details><summary>The full IRC log of that discussion</summary> <fantasai> kizu: problem we have with anchor positioning is that it currently doesn't behave well when the anchor is transformed or offset-path<br> <fantasai> kizu: have an element, it's positioned over offset path, the anchor element will not be in the correct position<br> <fantasai> kizu: there are many cases where you might want something like this<br> <TabAtkins> Q+<br> <fantasai> kizu: e.g. popover and you have ??? and you rotate something someway, you will expect your popover to be closer to the target<br> <fantasai> kizu: right now it might get completely off the target<br> <fantasai> kizu: long discussion, some last comments say, maybe it's possible to do this<br> <fantasai> kizu: but not in a way that the anchored element will be a bit behind by a frame or two<br> <fantasai> kizu: my personal opinion, this is okay<br> <fantasai> kizu: it is better than not being at the right position at all<br> <chrishtr> +1 to it being ok<br> <fantasai> kizu: when we first implemented position: sticky and fixed, and over time we improved the behavior<br> <fantasai> kizu: this might be a similar case<br> <fantasai> kizu: we might not be able to make it look and behave perfectly as you expect, but maybe in the future it will work<br> <fantasai> kizu: but authors expect anchored elements to be close to their anchor<br> <fantasai> kizu: otherwise it looks like a bug, and authors will not be able to replace their current solutions with anchor positioning<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: Transforms, implementation-wise, fall into a similar bucket as scrolling, where they are hardware-accelerated<br> <fantasai> TabAtkins: limitations we have with anchor positioning are to avoid having lag<br> <fantasai> TabAtkins: but since initial version of anchorpos, we've done significant work to make those limitations as invisible as we can<br> <fantasai> TabAtkins: most of the time you don't need to worry about scrolling, it does the reasonable thing<br> <fantasai> TabAtkins: intention was always to address transforms<br> <chrishtr> Animating scrolling is much more common than transform. Transform is also sometimes used by developers as a "layout feature", e.g. offset by 50% relative to viewport<br> <fantasai> TabAtkins: we should address that now, so we don't get compat dependence on current behavior<br> <fantasai> TabAtkins: I agree that transfroms are sufficiently layout-like that it's worth making sure it's always correct<br> <fantasai> TabAtkins: so I think we should live update in response to transforms same as we do with layout today<br> <emilio> q+<br> <fantasai> TabAtkins: accept that it won't be perfect<br> <fantasai> TabAtkins: so we should do this work<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: one thought that might be worth exploring is making it work for transforms other than the transform property itself<br> <TabAtkins> fantasai: so translate, offset-path, etc, but not transform itself<br> <TabAtkins> fantasai: maybe separating out the transform property itself would help<br> <astearns> ack emilio<br> <TabAtkins> fantasai: might avoid us having to worrya bout 3d, let the author decide what to respond to<br> <TabAtkins> fantasai: may not be a good idea, just throwing it out<br> <TabAtkins> emilio: so proposal is to make transformed anchors not block a sync animation<br> <TabAtkins> emilio: which would be the alternative<br> <TabAtkins> emilio: forcing those animations onto the main thread<br> <fantasai> TabAtkins: Yeah, no demotion of animations<br> <fantasai> TabAtkins: that would require arbitrary walking up to other elements in the tree that might be transformed and affecting this<br> <fantasai> emilio: Yeah that was my concern<br> <chrishtr> Or you could say that it's up to UAs to decide whether they prefer main thread transform animations or sometimes lagging anchors<br> <fantasai> emilio: Real question is, if this is good enough ... but probably it's better to do this?<br> <flackr> my general thinking is that authors can roughly think of it as anchoring to the bounding box in the space of the anchor's offset parent<br> <fantasai> emilio: Makes changes to 'transform' affect layout in deeper ways, though right now it only affect scrollable overflow which does affect content (which is annoying)<br> <fantasai> emilio: optimizing that is scary<br> <fantasai> TabAtkins: Proposal is that anchor positioning takes transforms of its anchors into account, same as it takes changes to layout into account<br> <fantasai> astearns: Decide if we want to reduce scope of this to e.g. avoid 3D transforms<br> <fantasai> astearns: Objections?<br> <fantasai> emilio: Not objecting, but it's not great to do style invalidation for changes in transforms<br> <fantasai> flackr: It could be visually incorrect for a few frames, but once you do style update on main thread, it'll update<br> <fantasai> emilio: Animations I'm ok with it<br> <fantasai> emilio: but let's say you update transforms via script. Right now it's very cheap<br> <fantasai> emilio: only affects a few things, doesn't require style recalc<br> <chrishtr> I think it's ok to have this dependency when anchors are present<br> <fantasai> emilio: But with this change, you would need to make that change<br> <fantasai> emilio: feels unfortunate<br> <TabAtkins> yes, dirtying based on transforms is implied here<br> <chrishtr> +1 to tests, Morten will add them<br> <fantasai> emilio: You would need lots of tests for this... transforms are well-optimized in engines right now, and this will break some of those<br> <TabAtkins> fantasai: one possibility is only do this for position-area changes, not for anchor computations. that would avoid style recalc<br> <fantasai> TabAtkins: It's not the problem, it's dirtying layout which is the problem<br> <chrishtr> +1 to resolve now and continue discussing other details<br> <fantasai> astearns: So are we going to resolve on this, or dig into implications?<br> <fantasai> emilio: Fine resolving now, if considered all these<br> <fantasai> RESOLVED: Anchor positioning will take transforms into account.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8584#issuecomment-3109444615 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 July 2025 17:04:55 UTC