Re: [csswg-drafts] [css-contain-2] filter effects and "relevant to the user" (#7711)

The CSS Working Group just discussed `[css-contain-2] filter effects and "relevant to the user"`, and agreed to the following:

* `RESOLVED: Add a SHOULD requirement for considering the filter effect extent and interaction with UA margin`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-contain-2] filter effects and "relevant to the user"<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/7711<br>
&lt;dael> florian: Discussed similar for contain 1. Filter effects can be non-local. Like blur can draw from broader area to render what you want. Kind of defeats containment a bit. Was limited enough it was fine.<br>
&lt;dael> florian: Similar issue on content-visibility:auto<br>
&lt;dael> florian: effects of c-v:auto change depending on if it's relevent to user. And one of the ways is if it's on screen.<br>
&lt;dael> florian: Spec has provision to not be considered if it's close to onscreen by a margin. Not clear how it's defined, but text anticipates it's a fixed size<br>
&lt;dael> florian: For filter-effects tehre is no bound for how far reaching it might be. Very large is unusual but not impossible. Depending on how big the UA margin and filter effect are it might have a slightly offscreen element have an effect on the filter.<br>
&lt;dael> florian: Probably negligible effect, but tiny is not none.<br>
&lt;dael> florian: Suggest a small alert to spec that not only is the element relevent when it's close to onscreen but also that rendering it is necessary to do filter effects<br>
&lt;dael> florian: It's probably a small error but need to decide if have small error or complete correct<br>
&lt;dael> astearns: Long range filter effect will blink into existince once small threashold is hit?<br>
&lt;dael> florian: Let's say you have bright red thing offscreen in c-v:auto and a blur. Without the change the element could come close enough that it should bled red but doesn't impact filter. But instead it doesn't render until it gets close enough and then it blinks into site<br>
&lt;astearns> ack dbaron<br>
&lt;dael> dbaron: I wanted to say I think even if it may or may not be impl this way I think the spec should describe them additively. c-v being in range of the screen is you want ti ready in case it scrolls on. I think better to desc additively but allow flexibility<br>
&lt;dael> florian: Makes sense.<br>
&lt;vmpstr> q+<br>
&lt;dael> dbaron: By additive if what you're trying to say is if scroll within 50% of screen, but you want it to be if you're in 50% or relevent to some filter pixels onscreen...<br>
&lt;astearns> ack vmpstr<br>
&lt;dael> vmpstr: A little concerned about impl efficiency for this. In order to know about content under a stack of pixels will effect on screen doesn't seem trivial<br>
&lt;dael> vmpstr: To run that on every scroll would be portentially slow. A little concerned about spec being strict on this<br>
&lt;astearns> ack dbaron<br>
&lt;dael> dbaron: I don't think it should be strict. But I think most impl have this sort of code b/c needed for invalidation. But code can be conservitive and make approximations<br>
&lt;dael> vmpstr: Typically done in graphics stack. This would then cause us to go back to style when we detect it and decide you need to be rendered. I don't think at the time when inersectionObserver determines intersection I don't think we have good information about filter effects<br>
&lt;dael> dbaron: That's certainly belivable. I know Gecko code better then chromium though have forgotten some<br>
&lt;dael> florian: When we resolved for containment we said it was easy enough to track. If we could allow something to spec to allow the correct and encourage. Maybe require is nice.<br>
&lt;dael> florian: That said, number of cases where it's user important will be rare. Maybe okay to sacrifice accuracy<br>
&lt;dael> dbaron: I think reasonable for should<br>
&lt;dael> vmpstr: Agree with that<br>
&lt;dael> astearns: only concern I have is testing if it's a should<br>
&lt;dael> florian: Hard to test because not only is it a should there's ua defined fixed-size margin. How far offscreen you should be is hard<br>
&lt;astearns> ack dbaron<br>
&lt;dael> astearns: Prop: Add a SHOULD requirement for considering the filter effect extent and interaction with UA margin<br>
&lt;dael> dbaron: One comment on testing. SVG filters has things easier to see than blur, but I don't think there are css versions<br>
&lt;dael> iank_: BUt can reference svg filters. But I think they'll make it more complex<br>
&lt;dbaron> (displacement map)<br>
&lt;dael> florian: Interestingly that makes it more relevent. If it's just blur you don't get much color but displacement moving pixels you would see it<br>
&lt;dael> astearns: Any concerns?<br>
&lt;dael> RESOLVED: Add a SHOULD requirement for considering the filter effect extent and interaction with UA margin<br>
</details>


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


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

Received on Wednesday, 2 November 2022 23:56:02 UTC