Re: [csswg-drafts] [css-contain][filter-effects] paint containment vs filter effects (#6325)

The CSS Working Group just discussed `CSS Contain`, and agreed to the following:

* `RESOLVED: Update spec to acknowledge effects of filters. No other change.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: CSS Contain<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6325<br>
&lt;fantasai> florian: Had not realized earlier, but there's a problem with paint containment<br>
&lt;fantasai> florian: The point of paint containment is to ensure that if anything changes inside an element with paint containment, nothing leaks in terms of changing painting outside it<br>
&lt;fantasai> florian: However, filter-effects, when specified on an ancestor of the contained element,<br>
&lt;fantasai> florian: e.g. consider a large blur radios<br>
&lt;fantasai> florian: In order to calculate the result of pixels outside the box, need to consider the painting of pixels inside the box<br>
&lt;chris> q+<br>
&lt;Rossen_> q<br>
&lt;fantasai> florian: I think there's no infinite-range filter? So maybe you just need to calculate a margin of error to repaint.<br>
&lt;fantasai> chris: FE-flood, which can fill an entire region?<br>
&lt;fantasai> florian: Fills the entire region, but does it take the entire region as input?<br>
&lt;fantasai> chris: no<br>
&lt;fantasai> florian: yeah, that's the trouble. Blur does that.<br>
&lt;fantasai> smfr: Also FE-displacement, which can take arbitrary displacement.<br>
&lt;fantasai> florian: can be arbitrary, but can't be infinite at least<br>
&lt;fantasai> Rossen: ... considering chrishtr's comment<br>
&lt;fantasai> florian: If talking about bg of element or things inside it, issue still applies. Filter on parent will still fetch those<br>
&lt;fantasai> florian: If you have a 15px blur filter on BODY element<br>
&lt;fantasai> florian: and somewhere inside tree have a paint-contained element<br>
&lt;fantasai> florian: then even if it's 3px off-screen, have to repaint it so you know what pixels to spread into the screen area<br>
&lt;fantasai> florian: Because you have a 15px blur on the BODY, know it's within a range<br>
&lt;chris> standard deviation of feGaussianBlur is not bounded, but can't be infinite<br>
&lt;chris> https://drafts.fxtf.org/filter-effects/#element-attrdef-fegaussianblur-stddeviation<br>
&lt;fantasai> florian: but you have to walk up the tree to figure out what filters might apply<br>
&lt;chrishtr> I don't think it's a problem.<br>
&lt;fantasai> smfr: Do any implementers think this is a problem?<br>
&lt;fantasai> Rossen: do you?<br>
&lt;fantasai> smfr: I haven't implemented yet, I think it's fine.<br>
&lt;fantasai> florian: Well, the spec says as soon as element is off-screen can stop painting, that point definitely is not true<br>
&lt;fantasai> chrishtr: Yes, spec will need to be updated to account for filters.<br>
&lt;fantasai> florian: Is that good enough? or do we need to find some other solution<br>
&lt;fantasai> chrishtr: I think it's good enough<br>
&lt;fantasai> Rossen: How about we start with this, and if we find additional evidence we'll come back<br>
&lt;fantasai> florian: Alternative might be to say that paint-contained elements are not taken as input into filters<br>
&lt;fantasai> fantasai: That sounds worse<br>
&lt;fantasai> chrishtr: Sounds weird<br>
&lt;fantasai> chrishtr: Browsers can compute this, don't see a big problem<br>
&lt;fantasai> florian: If you don't think it'll be expensive, then fine<br>
&lt;fantasai> chrishtr: e.g. browser could apply simple heuristic if page doesn't have an any pixel-moving filters  on it, then apply reasonable margin, or whatever<br>
&lt;fantasai> fantasai: proposal: update spec to acknowledge effects of filters?<br>
&lt;fantasai> RESOLVED: Update spec to acknowledge effects of filters. No other change.<br>
</details>


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


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

Received on Wednesday, 23 June 2021 16:39:45 UTC