[resize-observer] What should the fragment-aware behavior be when there are no fragments?

[Loirooriol]

See #3673 (comment)

RES0LVED: Option 1; contentBox is an array of fragment sizes

So if a box has 1 fragment then the array has length 1, if it has 2 fragments it has length 2, and so on.

What if the element has no fragments like in display: none? Then getting an empty array would probably make the most sense.

Likewise for non-atomic inlines, which are considered to have a size of zero. Since this is not a real size it might make more sense to represent it as a lack of fragments.

I think it's also possible (e.g. with continue: discard) to have an element that generates a box, but no fragment is created.

The risk of an empty array is that right now with the non-fragment aware API we get an array of length 1 (a 0x0 size). I'm concerned that several web pages may be using contentBoxSize[0].inlineSize without checking contentBoxSize.length. See https://github.com/envato/react-breakpoints/blob/5b25ede569801efa0030e42e49b9fca08308dc47/src/useBreakpoints.ts#L99-L120 for an example.

That said, elements with a size of 0x0 (either real or due to no box or inline box) weren't initially getting their ResizeObserver callback invoked before #3664, so it may not be a big deal if the callback now throws in the non-real 0x0 case.

[css-meeting-bot]

The CSS Working Group just discussed [resize-observer] What should the fragment-aware behavior be when there are no fragments?, and agreed to the following:

• RESOLVED: we will use an empty array when there are no fragments

The full IRC log of that discussion

<bramus> oriol: we had resolution in the past that ro should expose size of all fragments, which is exposes as an array by the API. spec is only populating single item in array (1st fagment)
<bramus> oriol: what should happen when el has no fragments? Do we keep 0,0 as the single entry or do we want an empty array?
<bramus> oriol: empty array makes more sense but there is a compat argument there bc there are scripts out there at assume the entry is there
<bramus> oriol: otoh if there is no fragment the size is 0x0 then the prev behavior was that the callback was not called anyway.
<bramus> oriol: so a change might not affect existing behavior that much
<bramus> oriol: can we risk with empty array orshould we go with safe bet of 1 entry in array?
<fantasai> I think the correct thing would be a zero-sized array
<TabAtkins> Empty array sounds good to me.
<fantasai> If we can get away with it, let's do that
<bramus> emilio: i think we are probably gonna have to have no item but maybe keep existing behavior and call it a day.
<bramus> emilio: fine with empty. if compat issue then try the other
<astearns> ack dbaron
<bramus> dbaron: i have mixed feelings about this
<bramus> dbaron: in one sense it seems like it is the right thing and ecourages ppl to know there are fragments
<bramus> dbaron: are ppl going to iterate over fragments?
<bramus> dbaron: having an array increases the risk devs can do wrong
<bramus> oriol: array we have right now, changing it is not web compatible I’m sure
<bramus> oriol: changing from arrays to something else that is
<bramus> oriol: ppl assume it is an array
<bramus> dbaron: i agree with you there
<bramus> dbaron: i am worried that an empty array - even though it increases awareness - will also lead to a lot more JS errors
<fantasai> I think it's reasonable. This is querying things that *don't have a box*
<bramus> dbaron: including future ones
<fantasai> Why would you query the size/position of things that don't have a box in the first place? Most people won't
<bramus> astearns: rough concsensus that empty array is correct thing to do
<bramus> astearns: fear that it leads to errors, but we can try it
<bramus> astearns: and if there is a webcompat issues can try the other thing
<bramus> dbaron: i[m fine with that, taking webcompat into account and listening to devs
<bramus> astearns: devs who want to process all can do the right thing
<bramus> emilio: i think it is a usefull thing. if we can, we should go with empty
<bramus> astearns: proposed resolution to we will use an empty array when there are no fragments
<bramus> oriol: also the case of inline elems
<bramus> oriol: should we treat this case of having no fragments or fragments-size-0?
<bramus> astearns: lets resolve on simpler case first
<bramus> astearns: objections?
<bramus> RESOLVED: we will use an empty array when there are no fragments
<bramus> astearns: what about other case?
<bramus> astearns: (non-atomic inlines)
<fantasai> We do have fragments in that case, should we return an array of those?
<bramus> astearns: they have a size of 0, so we would be returning an array of 0-size fragments
<bramus> astearns: oriol?
<bramus> oriol: no strong opinion
<bramus> oriol: we are special casing inline elems and ignoring their size
<bramus> oriol: seems arbitrary
<bramus> oriol: saying no fragments seems better?
<bramus> oriol: other option we could try to stop ignorigntthe size of the inline fragments
<fantasai> Returning an array of 0,0 fragments is not great. An array of the actual size of the fragments would make sense, though
<bramus> oriol: not sure if compat issues
<bramus> oriol: ppl have asked before to know the size of inline elems
<bramus> astearns: for purpose of this issue, we can return an empty array only if there are non-atomic inlines. should raise issue for other case. currently we dont have usefull info for inline boxes
<bramus> astearns: seems like it could be usesfull to do something else for inlines
<fantasai> since we're discussing this now, do we want to consider a resolution to just return an array of actual sizes?
<fantasai> if anyone has a concern with that, then we can open issue and return to it
<bramus> astearns: proposed resolution: given the state of inline box handling in current spec, since we have nothing useful to give the developers, we will give them empty array
<bramus> astearns: have separate issue for things fantasai just raised
<oriol> The issue is https://github.com//issues/6358
<astearns> ack fantasai
<bramus> astearns: proposed resolution: return empty array for inlines but also raise issue for returning better issue
<bramus> fantasai: if we are ready to decide we should do instead of postponing
<bramus> fantasai: i would say to leave open and not resolve
<bramus> astearns: can you open issue for this oriol?
<bramus> oriol: link already pasted in IRC
<bramus> astearns: leave thing for inlines open