Re: [csswg-drafts] [css-contain-2] Spec is unclear about whether 0-sized boxes can be "relevant to the user" (since they have zero intersection area) (#5641)

The CSS Working Group just discussed `[css-contain-2] Spec is unclear about whether 0-sized boxes can be "relevant to the user" (since they have zero intersection area)`, and agreed to the following:

* `RESOLVED: Match intersection observer behavior for this definition`

<details><summary>The full IRC log of that discussion</summary>
&lt;flackr> TabAtkins: problem is if you have a 0-sized box, it's not clear in several conditions whether it's relevant to the user on screen, next to screen, etc<br>
&lt;flackr> TabAtkins: have to be careful whatever we do doesn't influence positive area boxes<br>
&lt;flackr> TabAtkins: the definition in the thread is if a box is 0 area we treat it as if it's epsilon size in the 0-axis and calculate intersection as normal<br>
&lt;flackr> TabAtkins: this means if it's inside the viewport it's intersecting. If it's next to, it also does so. But if it has positive area but is adjacent it will remain not intersecting<br>
&lt;emilio> q+<br>
&lt;flackr> TabAtkins: Specifically, if the element has 0 it's on screen if it's in the inclusive range of the viewport's bounds<br>
&lt;flackr> s/0/0 area<br>
&lt;flackr> TabAtkins: if this sounds reasonable, we can add this<br>
&lt;astearns> ack emilio<br>
&lt;smfr> q+<br>
&lt;flackr> emilio: intersection observer has this idea of adjacent intersection which handles this, any reason we can't use this?<br>
&lt;flackr> TabAtkins: not aware of details of this<br>
&lt;emilio> https://w3c.github.io/IntersectionObserver/#update-intersection-observations-algo<br>
&lt;emilio> > Let isIntersecting be true if targetRect and rootBounds intersect or are edge-adjacent, even if the intersection has zero area (because rootBounds or targetRect have zero area).<br>
&lt;astearns> ack smfr<br>
&lt;flackr> smfr: a 0-sized box can be made and have a visual impact by having an outline or box outset. These may have painted ink overflow<br>
&lt;flackr> astearns: my understanding is we don't want to count ink overflow<br>
&lt;flackr> astearns: we aren't including box shadows for example<br>
&lt;flackr> astearns: something visible on the screen may be interesting to use even if it has 0 size<br>
&lt;flackr> s/astearns/smfr<br>
&lt;flackr> astearns: proposal is we would only count adjacent boxes for 0 size<br>
&lt;flackr> TabAtkins: my definition was carefully crafted to do a minimal change but aligning with intersection observer is a good idea and have no strong opinions on specific so prefer to align with what IO does<br>
&lt;flackr> astearns: this would catch those things which smfr mentioned and also things which don't have ink overflow<br>
&lt;flackr> TabAtkins: not necessarily, ink overflow can be larger than 1px but that's not included by intersection observer either<br>
&lt;flackr> smfr: just wanted to make sure we don't discount things that are 0x0<br>
&lt;flackr> RESOLVED: Match intersection observer behavior for this definition<br>
</details>


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


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

Received on Wednesday, 7 December 2022 17:59:20 UTC