- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 May 2025 17:22:58 +0000
- To: public-css-archive@w3.org
> This one sounds like the bare minimum (and maybe enough?), pretty straight-forward to solve, and will be similar to how we already deal with scrolling, yes. No opt-in mechanism needed for this, as far as I can tell (we didn't add one when implementing this for scrolling although it was a behavior change). Yeah, my only concern is compat, tho that's probably safe to do at this point, as long as we don't dawdle too much. > We don't have to solve or spec both these at the same time. Responding at anchor recalculation points will most likely cover most use cases. At the same time, it would be interesting to know how far we would like to go. Right, we can indeed separate them, especially if we tie the "live" transform tracking to an opt-in property. > Although the last example is the only one that has boxes that get resized based on transform changes, it's not that different from the first example. Resizing makes it pretty significantly different. ^_^ > The first example only changes the offsets of the anchored elements, but in our implementation at least, this means performing layout (nothing is resized, but their offsets in the layout fragment tree change - that's main thread stuff). Does this throw a spanner in your thought works? No, I think that's just an artifact of how you're currently doing things under the covers. My proposed behavior is that the "live" offset be applied as a translation, not a layout offset. That should hopefully allow us to avoid main-thread work. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8584#issuecomment-2884554150 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 May 2025 17:22:59 UTC