Re: [csswg-drafts] [css-scroll-anchoring] Consider adding an opt-in way of avoiding scroll anchoring suppressions (#7745)

The CSS Working Group just discussed `[css-scroll-anchoring] Consider adding an opt-in way of avoiding scroll anchoring suppressions`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> emilio: Scroll anchoring spec has a bunch of heuristics about when to apply or stop applying scroll anchoring<br>
&lt;emeyer> …We found some cases where pages rely on scroll anchoring to happen, and depending on timing of style changes, page may misbehave<br>
&lt;emeyer> …When you fire scroll events<br>
&lt;emeyer> …Seems to be no way for devs to say “I really really want scroll anchoring to happen”<br>
&lt;emeyer> …I think adding a way to opt into ignoring suppressions and in this scrolling, we’re going to do anchoring regardless of other things<br>
&lt;emeyer> …I think it’s moderately trivial to implement, but is it a good idea?  Or reason it’s a bad idea?<br>
&lt;emeyer> astearns: Any thoughts on adding a way to require scroll anchoring?<br>
&lt;emeyer> (silence)<br>
&lt;emeyer> astearns: Shoudl we add an `always` value and see how it goes?<br>
&lt;flackr> q+<br>
&lt;emeyer> emilio: If there’s no anchor you don’t do anchoring, so maybe that name doesn’t quite make sense<br>
&lt;astearns> ack flackr<br>
&lt;emeyer> flackr: What is `always` specified on?<br>
&lt;emeyer> emilio: overflow-anchor works on the scroll container, I believe<br>
&lt;emeyer> flackr: overflow-anchor I thought is applied to any element to prevent any element within to be selected as an achor<br>
&lt;SebastianZ> q+<br>
&lt;emeyer> emilio: Right, I guess should always have an effect on non-scroll containers<br>
&lt;emeyer> flackr: I was wondering if `always` would be a way of saying “this is the element to which I want to anchor”<br>
&lt;emeyer> emilio: Then we’d need another way to specify that an anchor should never lose the anchor even if there are suppressions<br>
&lt;emeyer> flackr: What do you anchor to?<br>
&lt;emeyer> emilio: Whatever you were anchoring to before<br>
&lt;emeyer> …What the suppression triggers do is prevent going back<br>
&lt;emeyer> flackr: The suppression trigger rpevent selecting an anchor within a given subtree<br>
&lt;emeyer> …You need to know which element should stay in the same position after anchoring<br>
&lt;emeyer> emilio: I’m not proposing to change anchor selection<br>
&lt;emeyer> …In my head, suppression triggers don’t affect anchor selection<br>
&lt;emeyer> flackr: Are we talking about overflow-anchor?<br>
&lt;emeyer> emilio: What I’m talking about it, the spec has heuristics that don’t affect anchor selection but do affect adjustments<br>
&lt;emeyer> …overflow-anchor seemed an obvious property to add this exception<br>
&lt;emeyer> flackr: I know anchor selection is a big problem and maybe overflow-anchor: always means you must selecto something in here as the anchor<br>
&lt;emeyer> emilio: This seems like an orthogonal problem<br>
&lt;emeyer> …I’m just trying to bypass the heuristics<br>
&lt;astearns> ack SebastianZ<br>
&lt;emeyer> SebastianZ: Quick note: overflow-anchor is targeting elements while something is targeting the scroll container, os maybe it should be another property in the end<br>
&lt;emeyer> astearns: Let’s take this back to the issue and come up with a proposed solution that can be agreed upon there<br>
&lt;emeyer> …Maybe we can get this and the linked issue on a near-future call<br>
&lt;emeyer> astearns: That’s time; anyone who wants to stay to talk about a summer FTF, please stay on<br>
</details>


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


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

Received on Wednesday, 19 April 2023 17:02:42 UTC