[css-contain-2] Is proximity to the viewport a property of the element or the box

[vmpstr]

This question came up on the following PR: #8904

The change in the PR defines a proximity to the viewport and asserts that once determined, the value can change (from being close to being far away and back) but can never go back to being undetermined for the lifetime of the element.

The question is whether the proximity being determined should instead be a property of the box, which will go back to being undetermined if the element loses the box (e.g. display: none). The reasoning is that proximity to the viewport is inherently a property of a box rather than an element.

My opinion is that being a property of the element is sufficient since it accomplishes the intent of the property (first determination has to be "synchronous"). It also avoids all of the cases that the group dealt with for contain-intrinsic-size's last remembered size -- specific timings of when it is forgotten, block <-> inline <-> contents <-> none transitions, etc

[khushalsagar]

Between placing the proximity on the element vs the box, the pro of placing it on the element is simplicity. We don't have to define when the state is reset since the layout could be recomputed at multiple points. Or changing from inline to block layout. That said, all such cases have been clearly defined for "last remembered size" so we should try to build on top of the same timing.

The only motivating case to place this on the box would be the author detaching the element from offscreen to in viewport. If the proximity is not re-computed in the same frame, there will be one frame where the element is not displayed.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-2] Is proximity to the viewport a property of the element or the box, and agreed to the following:

• RESOLVED: Proximity state is a proeprty of the element (shares its lifetime)
• RESOLVED: Proximity to the vieport is reset (returned to undefined) when the element is disconnected

The full IRC log of that discussion

<TabAtkins> khush: filling in for vlad...
<TabAtkins> khush: adding in spec text for c-i-s, there's a state about its proximity to the vieport
<TabAtkins> khush: starts undetermined, then later becomes far or close to the viewport, affecting whether it's relevant
<TabAtkins> khush: we know it can toggle between close and far, but can it ever toggle back to undefined?
<TabAtkins> khush: options are to say it has the same lifetime as the element, so once determined it stays that way
<TabAtkins> khush: other is to say it's a property of the box, which means if th ebox disappears it goes back to undetermined
<TabAtkins> khush: Reason is that in the frame that it becomes visible to the user, if it's initially undetermined it has a frame where it's still not drawn
<TabAtkins> khush: This also runs into the same issues as last remembered size, where you ahve to specify the timing of when it goes back to undetermined
<TabAtkins> khush: hopefully we can reuse that text
<TabAtkins> khush: I think the spec text for last remembered size hasn't fully landed? i was looking at impl to figure this out
<TabAtkins> khush: In blink it's when the RO runs, if element is detached, it forgets its last remembered size
<TabAtkins> khush: but here if you detach and reattach in the same frame you might want to forget its proximity
<TabAtkins> khush: with implementor hat on, might prefer it being a proeprty of the element, less work when it gets reattached
<emilio> q+
<TabAtkins> khush: and we can change that easier in the future if we want to make it care about box destruction, i think
<TabAtkins> emilio: use-case of detach/attach can also be fixed if it's a proeprty of the element
<TabAtkins> emilio: You can define that when it's removed from the doc its size is removed - i think taht's what we defined for last remembered size?
<TabAtkins> emilio: And that would fit the use-case I think?
<TabAtkins> khush: yeah, if element is detached from the dom you reset it, that could be the only case
<TabAtkins> astearns: i'm a little confused, you wanted it a property of the element os it's not reset...
<TabAtkins> khush: it's simpler than if it's a property of the box - there are more cases where the box is destroyed
<TabAtkins> khush: if it's a property of the element, and just *detaching* is the only way to reset, that's simpler to ipmlements
<TabAtkins> emilio: and "when the box is recreated" isn't really specified
<TabAtkins> yup, was gonna say that
<khush> +1 to emilio's thinking.
<emilio> ack emilio
<astearns> ack emilio
<astearns> ack dbaron
<TabAtkins> dbaron: I'm happy with this proposal to say it's on the element and reset upon removal
<TabAtkins> dbaron: it feels logically that it's associated with teh box, but we don't define box lifetime clearly so it's hard to make something interoperable that depends on taht
<TabAtkins> dbaron: so better off depending it as a proeprty of the element even if it makes a little less sense
<TabAtkins> +1
<TabAtkins> proposed resolution: the proximity state is a property of the element
<TabAtkins> RESOLVED: Proximity state is a proeprty of the element (shares its lifetime)
<TabAtkins> second proposed, state is reset upon detach
<TabAtkins> emilio: I think "disconnected" is the right technical term there
<TabAtkins> RESOLVED: Proximity to the vieport is reset (returned to undefined) when the element is disconnected