[resize-observer-1] Firing observations on insert/remove when rendered size is (0, 0)

[vmpstr]

The group resolved to initialize the initial observation to (-1, -1) here: #3664 (comment)

I don't believe this is sufficient to satisfy the following listed properties of resize observer:

• Observation will fire when watched Element is inserted/removed from DOM.
• Observation will fire when watched Element display gets set to none.
• Observation will fire when observation starts if Element is being rendered, and Element’s size is not 0,0.

(the 0,0 part of the last point would presumably change due to (-1, -1) resolution)

The way the observations are fired is through some indirection but essentially this text:

isActive()

• Set currentSize by calculate box size given target and observedBox.
• Return true if currentSize is not equal to the first entry in this.lastReportedSizes.
• Return false.

Initializing the last reported sizes to (-1, -1) means that

1. Naively we will fire the observations even if the element is not yet being rendered, the implementations need to consider that case separately when computing the currentSize value.
2. After the initial observation, (0, 0) or not, we add the lastReportedSizes entry for that size. This means that when the element is removed, the observation will only fire if the rendered size was not (0, 0). This seems to go against the first point on firing observation on insertion/removal. Likewise when the element is inserted again, it would only fire an observation if the rendered size is not (0, 0).

Although it's in the spec, I don't believe Blink implementation exposes the lastReportedSizes property. I'm not sure about other implementations. One solution would be to add a new (-1, -1) entry any time the element is removed or display: none or loses its "being rendered" status in any way. It's a little awkward. Another option if lastReportedSizes is indeed not exposed anywhere would be to rewrite the resize observer spec to only keep track of one nullable lastReportedSize, have it be null as the initial value, and reset it to null any time the element loses its box

@Loirooriol

[Loirooriol]

Yes, but these listed properties were already broken with an initial observation of [(0, 0)], e.g.

• Inserting a 0x0 element into the DOM didn't trigger any observation.
• Removing a 0x0 element from the DOM didn't trigger any observation.
• Setting display: none on a 0x0 element didn't trigger any observation.

A relevant issue is #7734. If we say that an element with no box has a size of [], then

• When an element which was not rendered (e.g. because it was disconnected from the DOM or because of display: none) starts being rendered, it will trigger a notification, even if its size is 0x0. Because it will change from [] to [(0, 0)].
• When an element which was rendered stops being rendered, it will trigger a notification, even if its size was 0x0. Because it will change from [(0, 0)] to [].

But if elements with no box are supposed to have a size of [(0, 0)], then we will need to discuss what to do with elements of 0x0 size.

[vmpstr]

Yes, but these listed properties were already broken with an initial observation of [(0, 0)], e.g.

Agreed. I didn't mean to say that the change to -1,-1 is wrong, I meant to say that it doesn't handle all cases, such as insertion/removal of a 0x0 element.

Based on Blink code and the current spec, it sounds like the idea was that when the element is out of the DOM, it would have a 0x0 size and when it's in the DOM and rendered, then it would have non-0x0 size. So I don't think the case of having a rendered size of 0x0 was considered in detail.

I like your idea of having a [] size, which is the same as what I wrote about a nullable last size. That should fix all the issues without the need for -1,-1 initialization, right?

[vmpstr]

Rereading #7734, the distinction is that I'm proposing the nullable state to be an internal detail and continue to expose 0x0 to the API. As you mention in the other issue, exposing an empty array is risky since there are examples where script doesn't check size

[Loirooriol]

I like your idea of having a [] size, which is the same as what I wrote about a nullable last size. That should fix all the issues without the need for -1,-1 initialization, right?

Initializing to [] wouldn't trigger an observation when first observing an element with no box (if that also uses []). This wouldn't be consistent with IntersectionObserver.

the distinction is that I'm proposing the nullable state to be an internal detail and continue to expose 0x0 to the API

Yes, that's a possibility.

[Loirooriol]

I think this is the list or cases where it's not obvious whether they should trigger a notification or not:

• When an element whose size is considered to be 0x0 is first observed: [resize-observer] The initial size of ResizeObservation #3664 said yes, and I guess this is regardless of whether it's an actual 0x0 box, or it's an inline box, or there is no box, or the element is disconnected from the DOM.
• When a disconnected element becomes connected but generates no box, or an element that generates no box is disconnected from the DOM. I think a notification may not be necessary here.
• When a disconnected element becomes connected and generates a 0x0 box, or viceversa.
• When a disconnected element becomes connected and generates an inline box, or viceversa.
• When a connected element that generated no box starts generating a 0x0 box, or viceversa.
• When a connected element that generated no box starts generating an inline box, or viceversa.
• When an element that generated a 0x0 box becomes an inline box, or viceversa.

[css-meeting-bot]

The CSS Working Group just discussed [resize-observer-1] Firing observations on insert/remove when rendered size is (0, 0).

The full IRC log of that discussion

<bramus> vmpstr: we recently resolved to set … to -1 so ro would fire when size is 0,0
<bramus> vmpstr: I think that may break some of the spec because once it fires and you then remove and readd the element, the last reported size will now be 0,0 and the reinsertion wont fire again which is not what we expect
<bramus> vmpstr: we expect the process to be consistent. have a proprosal to have a nullable last reported size as opposed to -1,-1
<bramus> vmpstr: when removed it would be null
<bramus> vmpstr: i think oriol listed all cases to consider
<bramus> oriol: best to go over issues in list
<bramus> oriol: 1st question listed in issue at https://github.com//issues/7808#issuecomment-1263694781 – should we add a notification here?
<bramus> astearns: maybe take the list back to the issue? unless vpmstr has a summary?
<bramus> vpmstr: no strong opinion. most things listed should have a notification. ok with taking back to issue
<bramus> astearns: lets do that
<bramus> astearns: once we have answer to all issues we can bring a proposed resolution to the agenda
<bramus> oriol: call for people to reply in issue, its been open for a while
<bramus> astearns: yes, please record opinions in our issues

[vmpstr]

Here's my thoughts on this:

• When an element whose size is considered to be 0x0 is first observed: [resize-observer] The initial size of ResizeObservation #3664 said yes, and I guess this is regardless of whether it's an actual 0x0 box, or it's an inline box, or there is no box, or the element is disconnected from the DOM.

Yes, this should observe a 0x0 box or empty, as resolved elsewhere

• When a disconnected element becomes connected but generates no box, or an element that generates no box is disconnected from the DOM. I think a notification may not be necessary here.

This seems mandated by this line in the spec, but I agree that it doesn't seem useful

Observation will fire when watched Element is inserted/removed from DOM.

• When a disconnected element becomes connected and generates a 0x0 box, or viceversa.

This should probably fire an observation, since we're distinguishing no box from 0x0 box

• When a disconnected element becomes connected and generates an inline box, or viceversa.

Not sure about this :\

• When a connected element that generated no box starts generating a 0x0 box, or viceversa.

Yes, this should fire an observation

• When a connected element that generated no box starts generating an inline box, or viceversa.
• When an element that generated a 0x0 box becomes an inline box, or viceversa.

Not sure about inline boxes. I think the question really is whether inline boxes should be treated as "no box" or "0x0 box" from the perspective of resize observer

[Loirooriol]

In #7734 we resolved to use empty array when there is no box, so automatically it should follow that these trigger notifications, since there will be a change between [] and [(0,0)]:

• When a disconnected element becomes connected and generates a 0x0 box, or viceversa.
• When a connected element that generated no box starts generating a 0x0 box, or viceversa.

Here we keep having [], and doing something special to get a notification doesn't seem worth it:

• When a disconnected element becomes connected but generates no box, or an element that generates no box is disconnected from the DOM.

Here a notification can still be achieved by initializing the array to something invalid like [(-1,-1)]:

• When an element whose size is considered to be 0x0 is first observed: [resize-observer] The initial size of ResizeObservation #3664 said yes, and I guess this is regardless of whether it's an actual 0x0 box, or it's an inline box, or there is no box, or the element is disconnected from the DOM.

And I guess these will depend on what we do for inline boxes (#6358):

• When a disconnected element becomes connected and generates an inline box, or viceversa.
• When a connected element that generated no box starts generating an inline box, or viceversa.
• When an element that generated a 0x0 box becomes an inline box, or viceversa.

I think inline boxes should just populate the array with the actual sizes, then the first 2 cases would change between empty and non-empty array, triggering a notification. The 3rd case would typically trigger a notification too, but wouldn't for a 0x0 inline (e.g. font-size: 0).