[resize-observer] Add option to skip firing on observe

[gitspeaks]

observe() always triggers the callback once with the current size. This makes it impossible to pause and resume without extra logic to ignore that first call.

For example, if we want to explicitly change an element’s size and not have the callback fire, we cannot simply unobserve() and then observe() again - the re-observation will still trigger the callback.

Proposal: Add a boolean option to ResizeObserverOptions to suppress the initial callback when starting observation.

[Loirooriol]

Why is that first call problematic for you? And why not handle this with an early return in your callback?

[gitspeaks]

The "first" call itself isn’t the problem - it’s the subsequent calls to observe() that are.

For example, suppose I want to monitor the width of a stretched element when the browser window is resized, but I also allow the user to set the element’s height explicitly. When the user sets the height (which I already know about), I don’t need a ResizeObserver notification. So before applying the height, I call unobserve(), and afterward I call observe() again. The issue is that re-observing immediately triggers a callback, even though nothing has changed. I can work around this by adding extra logic to ignore that first call, but I don’t see why it should be mandatory for the callback to fire on observe() when no change has occurred. A boolean option to suppress the initial callback would remove the need for this extra handling.

[Loirooriol]

I still don't get your goal. Is you callback expensive, and then you don't want it called when there is no change for performance reasons? Does the logic in your callback break when there was no change?

I don’t see why it should be mandatory for the callback to fire on observe() when no change has occurred

It doesn't have to be mandatory, it's just a question of whether the added complexity of the new option is worth it, and I'm leaning towards no.

[gitspeaks]

What added complexity? My request is simply for a trivial conditional flag that observe() could check to decide whether to invoke the callback.

We can argue about performance endlessly, but the fact is that if the developer has to manually discard the unwanted callback, it objectively complicates the user’s code. At the very least, the current API performs unnecessary work and invites unproductive debates about performance.

The core of this request is, first and foremost, about developer ergonomics.

[Loirooriol]

The complexity:

• Spec editors need to edit the spec
• Browsers need to implement the changes
• Spec editors or implementers need to write tests
• Documentations writers need to write about it
• Authors will need to learn about it in order to use it or to understand code that is using it

The web is already a very complex system. We add new things if they are useful, not just for the sake of it.

[gitspeaks]

What you listed isn’t evidence that my request is complex. That’s just the normal process for any CSS enhancement. Complexity should be judged by the technical and conceptual burden of the feature itself, not by the routine steps every new feature has to go through.

And again, the core of this request is developer ergonomics. If authors have to add logic to discard unwanted callbacks, the API objectively complicates their code. My proposal removes that friction - it’s not ‘for the sake of it’ but to make the platform more usable.