Re: [csswg-drafts] [css-highlight-api][css-contain] static ranges and css-contain (#4598)

turning on contain:paint is supposed to be a **sufficient** condition to allow the browser to know that no change inside of the contained area can cause a need to repaint something outside of the contained area.

If we continue to say that invalid static ranges aren't painted, and add no other logic, then that is violated: a DOM change inside the contained area can make a static range invalid. If that range extended outside of the contained area, we now have a problem. It's fine that the part of the range inside the contain area is invalid. If the browser has no particular need to repaint the contained area (for example, it is off-screen), then it doesn't, and it doesn't matter than this part of the range was invalid. However, the part of the range outside of the contain area is also invalid. Which means that it needs to be repainted, even if the contain area was offscreen and thus ignorable. Thus, the promise of paint-containment is broken.

The same situation does not cause problems with live ranges. If you change the DOM inside of the contained area, that change causes you to update the boundary of the range (that's what it means for a range to be live). This ensures the range is not invalid. Because the content of the contained area has changed, the part of the range that's inside of it has changed, so it may need repainting if that area itself is onscreen, but the part of the range that is outside the contained area is still valid and unchanged, and thus does not need repainting.

Here's an example: that you have a big div, filled with multiple screen worth of screen. It's text-color is black. At the bottom of that, there's a footer, currently off-screen. To keep the example simple, let's say the footer not only has paint containment, but actually strict containment, so that we don't have to worry about relayouts and whatnot. There's a highlight backed by a static range, which goes from the start of the div to somewhere in the middle of the footer, and makes the highlighted text red. Now some DOM operation deletes the text content of the footer. The end offset of the range is no longer valid, so the range is no longer valid, so it shouldn't be painted. So we need to repaint the whole div to switch the text from red to back, even though the only change we had was in an off-screen strictly contained element. Containment is supposed to allow the UA to not have to worry about that.

Had we used a live range, at the point where the DOM operation deleted the text content of the footer, making it shorter, the end offset of the range would have been adjusted as well (that's what live ranges do), so the range wouldn't be invalid, and the on-screen text of the div would have stayed red, and no repainting would be needed.


----

So, if we do add that static ranges crossing a containment boundary are never painted, we preserve the promise of paint containment (and we could, but don't need to, add the same thing for live ranges). But it does make for a bad author experience and user experience, because all of a sudden, you've got some ranges that are mysteriously not showing up if they happen to hit a contain boundary.

Can we get out of that problem by (dynamically) doing some automatic adjustement to static ranges when they cross a boundary? Seems to partially defeat the point of static ranges, which aren't supposed to be watched by the browser and updated, and to make life hard for authors when they try to implement they're own logic to update invalidated static range.

Can we get out of that problem by creating some kind of static range invalidation observer, letting authors know one just went bad due to crossing a containment boundary? Doesn't seem to work to me, because:
* the whole point of static ranges is that the browser doesn't need to do bookkeeping on them, which makes them cheap, and that the author is supposed to know when they do something that invalidates them, and recreate them then. This would defeat that
* that doesn't help users, when the author has not used this observer, and a range that seems like it ought to work just doesn't show up because it crosses and invisible (to the user) boundary.

So I'm not quite sure what we should do.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4598#issuecomment-989082031 using your GitHub account


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

Received on Wednesday, 8 December 2021 18:39:24 UTC