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

The CSS Working Group just discussed `statis ranges and highlights`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: statis ranges and highlights<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4598<br>
&lt;TabAtkins> sanketj: there was discussion in a previous meeting to just add a paint step taht ignores static ranges that cross a containment boundary<br>
&lt;TabAtkins> sanketj: it didn't seem like it was something unique to the highlight api<br>
&lt;TabAtkins> sanketj: selection also adds ranges, and they're allowed to cross containment boundaries<br>
&lt;TabAtkins> sanketj: so if this should be disallowed for highlights, it should be done at a more general level<br>
&lt;TabAtkins> sanketj: so Dan's proposal is that we shouldn't need to handle this case in the Highlight API specifically<br>
&lt;Rossen_> q<br>
&lt;TabAtkins> sanketj: but there's also a question of what forum this q should be taken up in<br>
&lt;florian> q+<br>
&lt;TabAtkins> dandclark: even for live ranges today, if i'm using a live rang eto paint a selection, i can use the range API to make it encompass a paint-contained element and cause paint changes inside that contained element<br>
&lt;TabAtkins> dandclark: so we already don't really pay attention to paint contain, and that makes sense - they're not really bound to the tree hiearchy<br>
&lt;TabAtkins> dandclark: before we were looking at this the wrong way - if i have a range across a paint boundary, and i remove the element that one end is on, we ahve to invalidate it and that requires more invalidation than seemed reasonable<br>
&lt;dandclark> Proposed resolution: Allow static-range-backed custom highlights to be painted across paint-contain boundaries. Changes in static range validity can invalidate an intersected element with paint-contain. This is OK, and we will document this interaction in the highlight spec.<br>
&lt;TabAtkins> dandclark: But really this sort of invalidation is akin to live range invalidation<br>
&lt;TabAtkins> dandclark: So proposed resolution [above]<br>
&lt;Rossen_> ack florian<br>
&lt;TabAtkins> florian: I think i disagree<br>
&lt;TabAtkins> florian: Problem is not whether something crosses a paint boundary. Crossing is fine<br>
&lt;TabAtkins> florian: The initial problem with static range is that if it starts outside the paint contain and goes inside, and the dom changes within the paint-contain area, and the paint-contain area is offscreen, then in that case there is part of the range inside and outside<br>
&lt;TabAtkins> florian: the part that is outside isn't changing, it still goes up to the edge, but the part inside does change, becuas eyou changed the DOM. But that breaks an invariant of paint containment, that you don't need to worrya bout the painting of a contained element that's offscreen<br>
&lt;TabAtkins> florian: I think that's different from your examples<br>
&lt;TabAtkins> florian: If you ahve a live range that you change, so the part that's outside shoudl be different, well you changed it, of course you have to repaint<br>
&lt;TabAtkins> florian: with selection it's the same - if you change the selection, surely you ahve to repaint it<br>
&lt;TabAtkins> florian: also, paint containment allows browsers to skip painting, and paint-based invalidation. it doesn't allow browser to skip dom updates.<br>
&lt;TabAtkins> florian: So if dom updates you do still have to handle that<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> florian: So that's why the live vs static range is important<br>
&lt;BoCupp> q+ to say in Florian's example state of the range is changed, and if a range intersects a contained element and its state changes its allowed to invalidate its painting<br>
&lt;TabAtkins> florian: live ranges are effectively part of the dom, so modifying the dom modifies the live range<br>
&lt;TabAtkins> florian: but the point of the static range is that it doesn't get updated; the author is meant to take care of that<br>
&lt;TabAtkins> florian: and it might get inconsistent where the entire thing shouldn't be painted<br>
&lt;TabAtkins> florian: So statics can give us an inconsistent state that live ranges can't<br>
&lt;TabAtkins> florian: Just not painting ranges that cross paint boundaries might not be right, we can explore this sapce more<br>
&lt;TabAtkins> BoCupp: In both cases, it's the state of the range that's changing. The range that's intersecting an element with paint containment needs to be able to invalidate inside that boundary<br>
&lt;TabAtkins> BoCupp: Misleading us is that we're using nodes that are inside or outside the containment, to trigger changes in the range.<br>
&lt;TabAtkins> BoCupp: I don't think it matters that the state is computed for static ranges so you can tell they're valid or invalid, or you change the start node so it moves from inside to outside the containment<br>
&lt;TabAtkins> BoCupp: so we don't think there's a new case here. we might need to dig more into what florian is bringing up<br>
&lt;TabAtkins> BoCupp: ultimately this is about optimizations browser can pursue, and rather than put in complicated rules, put the onus on browsers to pay attention to ranges that might intersect containments<br>
&lt;TabAtkins> florian: That invalidates the point of contain, tho. Point is that it removes several things that it no longer needs to pay attention to.<br>
&lt;TabAtkins> BoCupp: It only requires them to pay attention to this one thing, ranges.<br>
&lt;TabAtkins> Rossen_: Sounds like this discussion should continue on GH, there's more detail to be ironed out before we're ready for resolution.<br>
</details>


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


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

Received on Thursday, 2 December 2021 00:17:59 UTC