- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 19:40:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-1] Preserve the previously used fallback position when all fallbacks fail`, and agreed to the following: * `RESOLVED: Modulo timing details and things that should cause us to forget, the last successful fallback position is used when all options fail` * `RESOLVED: If there's no previously successful fallback, we'll use the base styles with no fallback rules applied` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: If all of the fallback options produce overflow, we need to decide what to do<br> <emilio> ... currently the spec says that if you have ever successfully laid out one of the options we stick with the last successful position<br> <emilio> ... this happens at resize observer timing, attached to the element rather than the box, etc<br> <emilio> ... if it has never being laid out successfully we just use the first one<br> <dbaron> [whiteboard from before (or during?) break was PXL_20240213_191901443.jpg]<br> <emilio> ... ignoring more control around this, is everyone fine with this?<br> <florian> q?<br> <florian> q+<br> <emilio> fantasai: there's two versions of the spec, what you're proposing and the one we resolved on, which one?<br> <emilio> TabAtkins: the one that is in ED, which is the one currently exists<br> <emilio> fantasai: that is super confusing<br> <emilio> TabAtkins: before what I described there's nothing describing this<br> <emilio> florian: that might be the one on TR<br> <emilio> TabAtkins: there's none or TR<br> <emilio> florian: there is?<br> <emilio> TabAtkins: I'm not proposing what used to be in the spec at all<br> <emilio> q+<br> <astearns> ack florian<br> <fantasai> If there's nothing to consider, then there's nothing to discuss.<br> <fantasai> but there is something to discuss, because we're asking the CSSWG to approve something<br> <emilio> florian: so state in css is a bit fiddly, how well defined is the timing?<br> <emilio> TabAtkins: same definition as "last-remembered size" for contain-intrinsic-size<br> <astearns> ack emilio<br> <fantasai> scribe+<br> <fantasai> emilio: What timing are we using for re-evaluating?<br> <fantasai> emilio: e.g. when you scroll, you need to re-evaluate the fallbacks<br> <fantasai> emilio: when is that? IntersectionObserver timing?<br> <fantasai> TabAtkins: Not currently drafted. Depends how implementers feel<br> <fantasai> TabAtkins: currently "do the best you can"<br> <fantasai> TabAtkins: but will refine as get more information<br> <fantasai> s/information/experience/<br> <fantasai> emilio: It's a bit weird if we need to do both ResizeObserver and IntersectionObserver timing for this<br> <fantasai> emilio: maybe we can just do IntersectionObserver for this?<br> <fantasai> TabAtkins: I think i tmakes sense to use the same timing for those<br> <fantasai> emilio: update timing includes both IntersectionObserer and ResizeObserver<br> <fantasai> emilio: ... is in a loop, which is what you want<br> <fantasai> emilio: IntersectionObserver is [missed]<br> <fantasai> ???: If at RO timing you say "this is the last workable thing" and IO says "well no", then you have a problem<br> <dholbert> s/.../ResizeObserver timing/<br> <fantasai> emilio: We need a timing for evaluating a fallback list<br> <fantasai> iank_: during layout<br> <fantasai> emilio: not any layout if you're just scrolling<br> <fantasai> iank_: invalidation to layout and timing of that<br> <fantasai> iank_: that's different. You evaluate the fallbacks during layout<br> <fantasai> emilio: sure, but storing the last successful fallback and deciding when to invalidate layout when you scroll<br> <fantasai> emilio: the obvious choice of the positioning rect is the viewport, so obvious choice is IntersectionObserver timing because that's the same thing you use to dispatch DOM events for things in view<br> <fantasai> iank_: It's not the timing of the evaluating fallbacks, it's the time of storing the last one and invalidating<br> <fantasai> emilio: yes, you could say that<br> <fantasai> iank_: It's a big difference between those two<br> <fantasai> emilio: you need to evaluate fallbacks during layout<br> <fantasai> iank_: the main thing is invalidation<br> <astearns> s/during/every time you/<br> <fantasai> emilio: it may make sense, since fallbacks change sizes potentially, probably makes sense to evaluate the fallbacks as ResizeObserver time<br> <fantasai> emilio: IO time is afterwards<br> <fantasai> emilio: so anything attached to the popup would be one frame late<br> <fantasai> iank_: you're re-running ?? in the layout loop<br> <khush> q?<br> <fantasai> emilio: When you scroll, you need to decide what does that mean<br> <khush> q+<br> <fantasai> emilio: if you invalidate after RO timing, then you re-run layout for ???, but resizeobserver attached to the popup will be one frame late<br> <fantasai> iank_: I need to think about that<br> <fantasai> emilio: so RO timing makes sense for storing the last fallback<br> <fantasai> emilio: should probably also make sure that updates any fallback when you scroll<br> <fantasai> TabAtkins: ok<br> <khush> q-<br> <fantasai> iank_: Can't you just store the last fallback, capture that during layout?<br> <fantasai> emilio: that may be not well defined. Engines can skip layout<br> <fantasai> emilio: there are DOM APIs that update layout in some engines but not others<br> <fantasai> iank_: Need to run through and evluate all the anchor positions when you flush layout to return used values etc.<br> <fantasai> emilio: in those cases engines are interoperable<br> <fantasai> iank_: I don't understand the distinction between capturing that information then vs later time<br> <fantasai> emilio: boundingClientRect and take element out of the DOM, position is stored or not depending on RO vs layout time<br> <fantasai> iank_: you'll still flush layout when [missed]<br> <fantasai> astearns: I wonder whether we're approaching something that we'll put in the spec?<br> <fantasai> astearns: or separate issue about specific time?<br> <fantasai> emilio: I think Tab's proposal, using contain-intrinsic-size stuff, makes sense to me<br> <fantasai> TabAtkins: Precise timing I think we can consider orthogonal to when capturing<br> <fantasai> TabAtkins: want to be consistent<br> <fantasai> TabAtkins: so propose that we talk about that in a different issue<br> <emilio> fantasai: this issue was opened with the q of what to use with all fallbacks fail<br> <emilio> ... I think this discussion needs to include that we want to include the previous fallback position if all fail<br> <astearns> ack fantasai<br> <fantasai> s/include that/conclude that/<br> <fantasai> s/include the/use the/<br> <emilio> dholbert: suppose you make some CSS change and it's unclear whether options have changed or not<br> <emilio> ... if the computed style of the fallback property changes? Or is it an index?<br> <emilio> TabAtkins: ah, so what are you remembering and what the right answer<br> <emilio> ... I think if you mutate the position options should probably forget the last option<br> <emilio> ... not in the spec yet<br> <emilio> Proposed resolution: Modulo timing details and things that should cause us to forget, the last successful fallback position is used<br> <fantasai> when all options fail<br> <emilio> RESOLVED: Modulo timing details and things that should cause us to forget, the last successful fallback position is used when all options fail<br> <emilio> Proposed: If there's no previously successful, we'll fallback to the base styles (the first attempt).<br> <emilio> Resolved: If there's no previously successful fallback, we'll use the base styles with no fallback rules applied<br> <emilio> s/Resolved/Proposed<br> <fantasai> +1<br> <emilio> RESOLVED: If there's no previously successful fallback, we'll use the base styles with no fallback rules applied<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8200#issuecomment-1942271377 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 19:40:04 UTC