- From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Dec 2021 17:36:57 +0000
- To: public-css-archive@w3.org
> > The intent is to save the browser the work of doing style, layout, paint and compositing work in that subtree > > Actually, the intent is pretty much the exact opposite: the intent is to make sure that any work the Browser has to do is limited to that subtree, and saving from having to do work elsewhere. I'd say it's most correct to say both. Yes, containment prevents various kinds of rendering invalidation from causing work outside of the subtree. But that's exactly what allows potentially doing no work when the content is offscreen, or script is calling a DOM API on an element outside of the subtree. To summarize in a different way, there there are two optimization opportunities: 1. Faster rendering updates when mutations only occur in the subtree (because the rendering update is limited to that subtree, depending on the `contain` value. 2. Avoiding rendering work in that subtree when the API or screen doesn't need it (offscreen or DOM API call). > * find all the ranges that previously has at least one end in the updated card and check if it's still valid, even if the card is offscreen (because part of the range might be on-screen) > * For any that did become invalid, you need to repaint parts of the document that were outside of the contained area if they were covered and affected by that no-longer-valid range, even if the updated card is offscreen Yes, but I think this is fine, because the static range went outside of the contained subtree, and the computation doesn't require doing any rendering work for the contained subtree. The work required is some DOM traversal/validation, and paint of the content outside the subtree. It also has better UX, because the feature of highlighting will work in cases where, as far as the user can see, it should. Further, if the developer is truly concerned about optimizing this then they can avoid creating static ranges that cross their own containment boundaries and/or avoid invalidating the static ranges with DOM mutations. In the case of a stock ticker and them implementing their own find-in-page, I don't think that is all that hard. > * Right after you do that, the author's script will likely trash that range that you just did some work for, and possibly recreate a new one (if it found a new match for the user's search), which possibly will cause you to need to repaint again, and as that too could be over the whole document. The whole document *except* the subtree. > > Now, admittedly, if you did intent to let the user find things that span across containment boundaries, then that's unfortunate, because that speed-up is achieved by making that impossible. Maybe authors just need to be aware of that, and only use static ranges either when they're not using containment know that they don't need to cross containment boundaries, and use live ranges when that's not an option. That doesn't sound author friendly though. The user is more important than the developer. Further, I don't think the performance is really a big problem in terms of the performance browsers should provide, since as I said the repaint is limited to the parts of the screen the user cares about, and not the subtree that was contained and offscreen. > > 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 off-screen and subsequently performing a mutation to remove the endpoint of the highlight. > > This is not similar, because that range is a live one. Yes, but live in this example just means the UA is doing the heavy lifting rather than script. Isn't it the same otherwise? > * A mutation within a contained subtree may move the end-point of a live-range that was within that subtree. If that subtree is on screen, it will need to be repainted (it had to anyway, since the DOM has changed), but as that moving end-point cannot be moved to outside of the contained subtree by a DOM change within the subtree, the part of the range that is outside of the contained area cannot be changed by this operation, and doesn't thus cannot trigger a repaint of a broader part of the document. I think a static or live range that spans containment is not contained within the subtree, and so containment can't really help it unless we disallow the feature for this situation. I think we agree on this point though. My view is that (a) the rendering cost is acceptable given the benefits to the user, and (b) the rendering doesn't need to do anything in the offscreen subtree, so the goal of use case (2) I mentioned above of CSS contain is obtained. -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4598#issuecomment-995014058 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 December 2021 17:37:00 UTC