[css-contain-2] filter effects and "relevant to the user"

[frivoal]

from the spec:

An element is relevant to the user if any of the following conditions are true:

• The element is "on-screen": its paint containment box's overflow clip edge intersects with the viewport, or a user-agent defined margin around the viewport.

  Note: This margin is meant to allow the user agent to begin preparing for an element to be in the viewport soon. A margin of 50% is suggested as a reasonable default.

Technically, the "or a ua defined margin" part of this gives enough flexibility for the ua to extend the relevant area in whatever way it wants, including smart ones, but this phrasing, especially when accompanied with the note, suggests that we're talking about a fixed-size margin rather than something that may depend on content.

However, as discussed in #6325, non-local filter effects on the ancestors of the element with paint containment can cause the ua to need to render off screen paint contained elements, in order to get the filter right.

It seems that the notion of "relevant to the user" should account for that as well.

• The element is "on-screen": its paint containment box's overflow clip edge intersects with the viewport, or a user-agent defined margin around the viewport, or is close enough to the viewport that rendering it is necessary to calculate filter effects correctly.

A sufficient UA margin around the viewport is likely to make the effect of any filter barely noticeable, so maybe we don't actually need to bother, but if we're aiming for strict correctness, I think we need to take this into account.

[frivoal]

Agenda+ to see if the proposal above is acceptable.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: [css-contain-2] filter effects and "relevant to the user"
<dael> github: https://github.com//issues/7711
<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.
<dael> florian: Similar issue on content-visibility:auto
<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.
<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
<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.
<dael> florian: Probably negligible effect, but tiny is not none.
<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
<dael> florian: It's probably a small error but need to decide if have small error or complete correct
<dael> astearns: Long range filter effect will blink into existince once small threashold is hit?
<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
<astearns> ack dbaron
<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
<dael> florian: Makes sense.
<vmpstr> q+
<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...
<astearns> ack vmpstr
<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
<dael> vmpstr: To run that on every scroll would be portentially slow. A little concerned about spec being strict on this
<astearns> ack dbaron
<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
<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
<dael> dbaron: That's certainly belivable. I know Gecko code better then chromium though have forgotten some
<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.
<dael> florian: That said, number of cases where it's user important will be rare. Maybe okay to sacrifice accuracy
<dael> dbaron: I think reasonable for should
<dael> vmpstr: Agree with that
<dael> astearns: only concern I have is testing if it's a should
<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
<astearns> ack dbaron
<dael> astearns: Prop: Add a SHOULD requirement for considering the filter effect extent and interaction with UA margin
<dael> dbaron: One comment on testing. SVG filters has things easier to see than blur, but I don't think there are css versions
<dael> iank_: BUt can reference svg filters. But I think they'll make it more complex
<dbaron> (displacement map)
<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
<dael> astearns: Any concerns?
<dael> RESOLVED: Add a SHOULD requirement for considering the filter effect extent and interaction with UA margin