- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Feb 2025 01:28:44 +0000
- To: public-css-archive@w3.org
> Thinking a bit more about this... We can also adjust the algorithm to say that the focused element is a priority, but we don't directly select priority elements but rather use the priority element as the root for the rest of the scroll anchoring: we start at the focused element, if one exists, and then run the typical scroll anchoring that selects the first element that is fully visible in that subtree This makes sense for the non-text focus cases, but for text cases like contenteditable I think you really do want to find the nearest element at or before the cursor. This is the same logic behind why we use the focused element even if it wouldn't normally be the element selected for anchoring because it's not near the top of the page. I can make an example page to demonstrate this. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11748#issuecomment-2670174617 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 20 February 2025 01:28:45 UTC