- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 May 2025 12:02:04 +0000
- To: public-css-archive@w3.org
> One idea that Rob had is to only use a deep node anchor for its immediate scroll parent. Then using that scroll parent as the anchor for the next scroll parent and so on This is similar to what chromium does for the scrollIntoView algorithm, in that you don't try to scroll the clipped area of the content into view - just the visible part. > In my testing I found the cursor anchoring case to be unexpected and it looked strange to me (within contenteditable). Do you have an example case? I assume this is without the proposed change to how anchoring works? I could prototype the algorithm. > The node selection from candidate change that I propose appears to me to be a smaller incremental change that is less likely to cause "good cases" to break, which is why I'm still leaning towards that However, it leads to dramatically different behavior to cases that to the user look almost identical, i.e. having focus be on a single line input text and focus being on that text within a contenteditable. I think it is an improvement to what we have today but I think we should aim to fix the issue with anchoring to content outside of the scrollport generally, with which I think anchoring to the cursor would produce the nice expected result. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11748#issuecomment-2894151241 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 May 2025 12:02:05 UTC