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

[dholbert]

The "relevant to the user" ( https://www.w3.org/TR/css-contain-2/#relevant-to-the-user ) condition is defined as-follows:

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

• The element is "on-screen": its containing box's border box intersects with the viewport, or a user-agent defined margin around the viewport.
• [...other conditions...]

This definition is ambiguous about whether or not a on-screen 0-sized box would be considered relevant or not. Such a box has 0 area, and hence it would have zero intersection, even if it's positioned on-screen. So it arguably never "intersects with the viewport" (i.e. it never has a nonzero intersection area), even when it is fully contained within the viewport.

It would be nice for the spec to make clear what happens for such boxes. Possibly just adding a sentence saying "For the purpose of this consideration, a 0-sized box is considered as intersecting this area if it is fully contained within this area."

[Loirooriol]

In this image the intersection of the planes is a line with 0 volume. But it wouldn't be reasonable to say that then they don't intersect.

Seems basically the same in your case, with the viewport being a square, and the 0-sized box being a point. The intersection can be the same point (if it is in the square) or the empty set (if the point is not in the square). That the point has 0 area doesn't mean that there is no intersection.

The "is considered as intersecting this area if it is fully contained within this area" doesn't cover the case of a 0px tall box but positive width. It can still intersect the viewport (with 0 area) even if it's only partially contained within the area.

[dholbert]

@Loirooriol Thanks for that scenario & graphic -- good food for thought. However, I think it's a flawed analogy, because:

• the intersection between two planes (if it exists) is always a line -- that's what it's defined as, basically.
• whereas, the intersection between two shapes in 2D space is defined as another 2D shape; and one (perhaps-naive) implementation of "do they intersect" is to find out whether that shape has nonzero area.

Also, there are edge cases that make this somewhat more interesting. E.g. consider these cases (where I'm using "0-sized box" to mean a box with both height:0 and width:0):

(1) Does a viewport-adjacent nonzero-sized box (e.g. with position:absolute;left-100px;width:100px;height:100px) count as intersecting the viewport? (I would assume "no"; none of it is onscreen).
(2) Does a 0-sized box positioned at 1,1 count as intersecting the viewport? (I would assume "yes"; it's clearly on-screen, even if it doesn't have anything to render.)
(3) Supposing the viewport itself were 0-sized (kind of extreme, but humor me): does a 0-sized box at 0,0 intersect the viewport in that case? (I would assume yes, since these are two coincident points, which "intersect" as much as points possibly can intersect each other.)

(4) Now the interesting part (I think): let's go back to having a reasonably-sized viewport, say 1024x768. Now does a 0-sized box positioned at 0,0 count as intersecting the viewport? (This is unclear IMO; the logic of (1) suggests "no", whereas the logic of (2) and (3) suggests "yes".)

I mostly want to make sure case (4) is well-defined, since that's the one that feels ambiguous to me. Depending on what the decision & justification is for case 4, that informs what the answers are for cases (1)-(3), too.

[dholbert]

Right now, every explanation/justification that I can think of for case (4) happens to also destroy one of my intuitive expectations for one or more of the other cases (1)-(3). That's what makes it interesting.

Of course, it's fine to destroy my intuitive expectations for any/all of (1)-(3); but my point is that "do they intersect" is not an obvious question for these edge cases; so, it needs to be defined (or we need to nod to some external definition, e.g. if there's some external well-defined geometric definition that we're deferring to here).

[tabatkins]

I think a reasonably intuitive knot-cutting here would be:

• if the element has non-zero area, it's on-screen if the intersection area is non-zero
• if the element has zero area, it's on-screen if its bounds are in the (inclusive) range of the viewport's bounds

This answers your questions with no, yes, yes, yes.

The intuition here is that for nonzero-area boxes, we just use the standard "intersection area is nonzero" logic, answering (1). For zero-area boxes, they're on-screen if we could shift one of the edges by epsilon and give it a nonzero intersection area, answering (2) and (4). (With the special case of both being 0x0 and coincident, which falls under the general consistency that a 0x0 box at (0,0) is always on-screen, answering (3).)

(Edited, s/exclusive/inclusive/)

[Loirooriol]

if the element has zero area, it's on-screen if its bounds are in the (exclusive) range of the viewport's bounds

With "exclusive bounds" do you mean the interior (largest open subset)? But then if the viewport is 0-sized, its interior is the empty set, so I don't see why (3) would be yes.

[tabatkins]

No, I just wrote the exact opposite of what I meant - I meant inclusive bounds. ^_^

[tabatkins]

I also just realized the way I stated my conditions would imply that a 0x0 viewport and a nonzero-area element, with the element fully covering the viewport, would be considered "off-screen".

The intuition I'm actually going for, and should state more explicitly, is:

• if both shapes have non-zero area, their intersection must have non-zero area.
• if one or both shapes have zero area, they must just be coincident at at least one point.

This implies that two crossing lines are intersecting, that a point on the edge of a nonzero area is intersecting, etc. But two rectangles that are next to each other, sharing an edge, do not intersect.

Stated slightly differently, the justification for this intuition is that it's what you get if you forced a zero-area shape to have nonzero area by spreading it equally in all directions by an epsilon, but left shapes that already had nonzero area alone. (aka the "0x0 is actually a really tiny square" rule that we discussed during last week's meetings ^_^)

[dholbert]

The intuition I'm actually going for, and should state more explicitly, is:

• if both shapes have non-zero area, their intersection must have non-zero area.
• if one or both shapes have zero area, they must just be coincident at at least one point.

This makes sense to me (as does the epsilon-expansion thought-experiment). Thanks for working through this!

[frivoal]

Agenda+ to see if we can adopt Tab's proposal.

[css-meeting-bot]

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

The full IRC log of that discussion

<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
<flackr> TabAtkins: have to be careful whatever we do doesn't influence positive area boxes
<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
<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
<emilio> q+
<flackr> TabAtkins: Specifically, if the element has 0 it's on screen if it's in the inclusive range of the viewport's bounds
<flackr> s/0/0 area
<flackr> TabAtkins: if this sounds reasonable, we can add this
<astearns> ack emilio
<smfr> q+
<flackr> emilio: intersection observer has this idea of adjacent intersection which handles this, any reason we can't use this?
<flackr> TabAtkins: not aware of details of this
<emilio> https://w3c.github.io/IntersectionObserver/#update-intersection-observations-algo
<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).
<astearns> ack smfr
<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
<flackr> astearns: my understanding is we don't want to count ink overflow
<flackr> astearns: we aren't including box shadows for example
<flackr> astearns: something visible on the screen may be interesting to use even if it has 0 size
<flackr> s/astearns/smfr
<flackr> astearns: proposal is we would only count adjacent boxes for 0 size
<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
<flackr> astearns: this would catch those things which smfr mentioned and also things which don't have ink overflow
<flackr> TabAtkins: not necessarily, ink overflow can be larger than 1px but that's not included by intersection observer either
<flackr> smfr: just wanted to make sure we don't discount things that are 0x0
<flackr> RESOLVED: Match intersection observer behavior for this definition

[tabatkins]

IO's behavior is, intuitively, "boxes are intersecting if, after expanding both boxes by an epsilon in all directions, they have a non-zero overlap area". So it's my suggestion, but applied to positive-area boxes as well as zero-area boxes.