Re: [csswg-drafts] [resize-observer] ResizeObserver should support fragments (#3673)

Thanks - that clarifies it for me. So effectively that would require a change to the specification in two ways:

**1. The entry object**

This would need to have a notion of fragments although I don't desire to denote that in any way. Taking a scenario such as multi-column - we could adjust the `ResizeObserverEntry` to a <boxName>: sequence<ResizeObserverSize> which would end up with a result of something like this, again assuming multi-col with two resulting columns and the author observing the contentBox:

```
contentBox: [
        {
           inlineSize: <double>,
           blockSize: <double>
        },
        {
           inlineSize: <double>,
           blockSize: <double>
        }
]
```

This has the added benefit, to @atotic point in the TAG review of the most common use cases currently not being about fragmentation so even if an implementation can't initially support building out the fragments easily or performantly they can add it as demand for the capabilty increases and we don't have to revisit the API or come up with a brand new one to support it.

**2. Observing numerous boxes**
I'll need to thing about this a bit more thoroughly to understand if there is anything that currently needs to change with the how boxes are observed. Regions currently aren't auto generated and thus there would need to be seperate observers attached to the seperate elements.

Now if we assume a regions that does auto generate a new box, similiar to how multi-col works where it clones it's sibling to generate a new box to contain the new content, it is a completely new element although matching the definition of a fragment. In this scenario I would expect that the Observer would be then attached to each additional fragment and its associated box to observe to ensure that any time that any box's dimensions change the callback is called and the above ResizeObserverEntry is passed.

There may be issues here with queueing up numerous additional Observers, some open questions I have is:
* Are dynamically clonable observers supported by Observer's currently
* What are the performance implications within the adjusted ResizeObserver lifecycle of queueing up potentially infinite Observers? I have a feeling we'll run into a situation where it will result in an increase of skipped observations and thus lead to increase of LoopErrors.
* @atotic it would valuable, with your work on LayoutNG to put together a rough dev assessment of supporting fragments in resizeObserver in conjuction with LayoutNG since it seems Firefox will be able to support this.

@plinss Primarily, does the ResizeObserverEntry object above address your concerns with support of fragments and this API not blocking the capality of using RO in conjuction for fragment based scenarios in the future?

Sorry for the book, just trying to think out loud here about the potential issues and the usecases where this may be utilized as I agree I don't want RO to become useless if we light up future scenarios where more fragmentation occurs.

I look forward to hearing your thoughts @atotic & @plinss 


-- 
GitHub Notification of comment by gregwhitworth
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3673#issuecomment-466736027 using your GitHub account

Received on Sunday, 24 February 2019 05:34:52 UTC