- From: vmpstr via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Feb 2025 15:35:40 +0000
- To: public-css-archive@w3.org
> 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. The reason I think the approach of starting with the focused root would work, is that this is the same behavior you get when contenteditable isn't focused (which has the correct behavior). Specifically in that case, we simply treat that element as any other and select a scroll anchor as the deepest fully visible child of the element. The downside would be that if content changes within the visible portion of contenteditable then it would indeed push the cursor down. So yeah, maybe finding the cursor element is better, it's just a bit more of a special case -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11748#issuecomment-2671864693 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 15:35:41 UTC