- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 04 Jun 2025 16:24:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scroll-anchoring] anchoring within contenteditable elements`, and agreed to the following: * `RESOLVED: When selecting a viable priority candidate (e.g. contenteditable), run the regular selection algorithm scoped to that element instead.` <details><summary>The full IRC log of that discussion</summary> <fantasai> vlad: For scroll anchoring we have priority candidates<br> <fantasai> vlad: Here there are two, which are [missed]<br> <fantasai> vlad: Algorithm says if one of the candidates are viable, keep it stable within the viewport<br> <fantasai> vlad: viability includes intersecting viewport, among other conditions<br> <fantasai> vmpstr: There was a case with a large div with editable content<br> <fantasai> vmpstr: algorithm takes the whole element as the anchor<br> <fantasai> vmpstr: If content is inserted higher in the element, and cursor is lower, then the whole element starts shifting around because the whole element is the anchor<br> <fantasai> vmpstr: I'll discuss some of the solutions proposed<br> <fantasai> vmpstr: One is to change the algorithm to say, instead of just picking the priority candidate as the candidate, pick it as the starting point from which we run the rest of the algorithm<br> <fantasai> vmpstr: the rest of the algorithm picks the first fully visible thing on the screen<br> <fantasai> vmpstr: So you would ...<br> <fantasai> vmpstr: For small elements like text boxes, there's no effect<br> <astearns> q+<br> <fantasai> vmpstr: for contenteditable, it means the content actually on screen is anchored<br> <astearns> ack fantasai<br> <fantasai> vmpstr: as if the content editable element was not focused<br> <flackr> q+<br> <fantasai> vmpstr: That's what I'm proposing, and I think it's a fairly small change<br> <fantasai> vmpstr: Rob proposed instead to anchor to the cursor whenever we have that on the screen<br> <fantasai> vmpstr: There are cases where that's better, e.g. inserting an image and want cursor to stay in place<br> <fantasai> vmpstr: I tried prototyping, but lots of cases where it looks weird<br> <fantasai> vmpstr: e.g. the document starts scrolling to make the cursor stay in place<br> <fantasai> vmpstr: so not saying we shouldn't do that, but maybe we treat this as two separate issues<br> <fantasai> vmpstr: and fix the priority candidate issue first, and then see if we want cursor as another priority candidate<br> <fantasai> astearns: First solution, said that for small elements no effect<br> <fantasai> astearns: but if you are starting at and then looking down into its children to see which element is the first one that is fully in view, and the element itself is slightly off-screen<br> <fantasai> astearns: are we going to be changing the anchor selection there, where we aren't going to take something that doesn't have any of its elements fully on screen?<br> <fantasai> vmpstr: Algo is more sophisticated than what I descried. It does pick first element that intersects viewport, but searches further for fully on screen<br> <astearns> ack astearns<br> <astearns> ack flackr<br> <fantasai> vmpstr: if no such element, takes the partial one<br> <fantasai> flackr: I do think that what vlad is proposing here is an improvement<br> <fantasai> flackr: I'm surprised we don't choose focused elements that are not contenteditable as priority candidates<br> <fantasai> flackr: but for contenteditable, there is a strong expectation that you continue to see the cursor<br> <fantasai> flackr: the weirdness that vlad saw seems like a weirdness we could address<br> <astearns> ack fantasai<br> <fantasai> flackr: but happy to take vlad's solution for now and iterate later<br> <kbabbitt> fantasai: want to make sure I understood<br> <kbabbitt> ... if contenteditable is the primary candidate then we<br> <kbabbitt> ... I think if we have contenteditable and ?? then scope to contenteditable element<br> <dholbert> q+<br> <smfr> q+<br> <astearns> ack dholbert<br> <fantasai> [agreement that this is the desired algo]<br> <fantasai> dholbert: [missed question]<br> <fantasai> vmpstr: We only pick a candidate that's viable, which includes intersection with the viewport<br> <fantasai> s/[missed question]/does this account for if the contenteditable is off-screen, e.g. picked a field at top of article, and then scrolled down and reading the article/<br> <astearns> ack smfr<br> <fantasai> smfr: Your contenteditable might just contain a wall of text, no elements. Then how do you keep the insertion point in view?<br> <fantasai> vmpstr: It would be no worse than today, where whole contenteditable is anchored<br> <fantasai> vmpstr: that might be better addressed by anchoring to the cursor<br> <fantasai> smfr: I think we do need to solve that<br> <fantasai> flackr: happy to open up a separate issue to anchor to the cursor<br> <fantasai> flackr: would love to look into those degenerate cases, I think they can be fixed<br> <fantasai> smfr: Is the scroll anchoring algo triggered by typing, or by content changes elsewhere?<br> <fantasai> vmpstr: some affordances to user interaction, e.g. if user action causes a change then algorithm wouldn't trigger in the same way<br> <fantasai> vmpstr: this is my understanding, but not sure<br> <fantasai> vmpstr: so typing would be a part of user action, not included<br> <fantasai> smfr: maintaining visibility of insertion point is finely tuned, and don't want scroll anchoring messing with it<br> <fantasai> vmpstr: agreed<br> <fantasai> astearns: I think resolution is minor improvment, where if contenteditable has focus and is viable anchor, we will run anchor selection scoped to that contenteditable element<br> <fantasai> vmpstr: if there is a viable priority candidate, then run selection algorithm scoped to that priority candidate<br> <fantasai> astearns: so not limited to contenteditable<br> <fantasai> vmpstr: Right, other priority candidates include [selection?]<br> <fantasai> astearns: and flackr will post an issue wrt active cursors<br> <vmpstr> s/[selection?]/find-in-page selection/<br> <fantasai> PROPOSED: When selecting a viable priority candidate (e.g. contenteditable), run the regular selection algorithm scoped to that element instead.<br> <fantasai> RESOLVED: When selecting a viable priority candidate (e.g. contenteditable), run the regular selection algorithm scoped to that element instead.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11748#issuecomment-2940651585 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 June 2025 16:24:55 UTC