- From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Dec 2021 01:57:00 +0000
- To: public-css-archive@w3.org
> 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. I think we don't need to be quite this strict. It's a sufficient condition for the browser to know that no "computationally expensive rendering work" of the contained area can cause a need to repaint elsewhere. DOM state affecting such can change, so long as it's not computationally expensive rendering work. The intent is to save the browser the work of doing style, layout, paint and compositing work *in that subtree*, not work maintaining the DOM tree or necessarily rendering work for other DOM content in general (various kinds of containment like `contain:size` reduce the likelihood of work elsewhere though). Therefore, the work to invalidate a static range within a `contain:paint` subtree, including induced paint changes elsewhere, is only a problem if some computationally expensive rendering work related to paint had to be recomputed in that subtree in order to figure out what to invalidate. It's ultimately a gray area what counts as "computationally expensive rendering work", but I'd say anything that forces style recalc or any of the later rendering phases of a typical browser pipeline are "computationally expensive". DOM state update is generally not. Reasoning from the [definition](https://dom.spec.whatwg.org/#staticrange), it depends only on presence of the start or end `Node`, its position in the DOM, the number of their children, the length of text content under a `Node`. Therefore, determining whether a `StaticRange` has been invalidated seems not especially computationally expensive to me. The worst case seems to be moving it around in the DOM and having to figure out what that means relative to the other endpoint, but that seems acceptable because it's about validating DOM state, optimizing which is out of the scope of `contain`, a feature that is targeted at rendering work only. This seems similar to the effect of using regular browser highlighting with a mouse gesture to cover a `contain:paint` subtree plus other content, then scrolling the subtree offscreen and subsequently performing a mutation to remove the endpoint of the highlight. -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4598#issuecomment-989429904 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 December 2021 01:57:02 UTC