bind:clientWidth does not update when scrollBar appears/disappears

[CrumbsTrace]

Describe the bug

Svelte internally uses a border-box ResizeObserver for bindings to clientWidth. Since the border-box size does not change when a scrollbar appears due to overflow, the clientWidth binding is never updated even when it should be.
Same issue would occur for clientHeight and a horizontal scrollbar.

Reproduction

https://svelte.dev/playground/0939f434e88d4fc7bda693b2a9ab78f5?version=5.46.1

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (12) x64 13th Gen Intel(R) Core(TM) i5-1345U
    Memory: 14.52 GB / 31.66 GB
  Binaries:
    Node: 24.11.1 - C:\Program Files\nodejs\node.EXE
    npm: 11.7.0 - C:\ProgramData\npm\npm\npm.CMD
    bun: 1.2.18 - C:\Users\vkalkman\.bun\bin\bun.EXE
  Browsers:
    Chrome: 143.0.7499.193
    Edge: Chromium (140.0.3485.54)
    Firefox: 146.0.1 - C:\Program Files\Mozilla Firefox\firefox.exe
    Internet Explorer: 11.0.22621.3527

Severity

annoyance

[ptrxyz]

This is not necessarily a bug. clientWidth and getBoundingClientRect return different widths -- one includes the scroll bar where as the other one doesn't. Don't ask me why that is -- probably something about legacy support or so? -- but that's how MDN defines it.

[CrumbsTrace]

I might be missing something but what does difference between clientWidth and getBoundingClientRect have to do with with the bug I'm reporting? All I am reporting is a scenario where bind:clientWidth does not update its bound variable even though the DOM element's actual clientWidth has actually changed.

As per MDN's definition the clientWidth does not include the width of the the vertical scroll bar. The way svelte is currently detecting changes of the clientWidth does not trigger when a vertical scrollbar appears, causing the element's actual clientWidth and the clientWidth inside of the bound variable to go out of sync

In the reproduction (assuming you are using a browser/device where scrollbars take up space of course) open it, Press the Cause overflow button and then print the clientWidths and they'll give different results despite both being the clientWidth

[ptrxyz]

So internally Svelte uses a ResizeObserver like you said. But this observes the bounding box of the client which includes the scroll bar. Since that one doesn't change, the value for your binding won't change. One could argue that it's a bit misleading to call it clientWidth when it is actually the border-box/content-box/decice-pixel-content-box. So basically it observes the space that the box is given from the outside to live in, not the box that is available to draw in.

Long story short, clientWidth is the width of the outer box, not the content box. And div.clientWidth is related to the content box, div.getBoundingClientRect is the border box and the latter is what the ResizeObserver looks for.

[CrumbsTrace]

The resize_observer_border_box is used internally which is causing the issue which we seem to agree on.

I don't really know what the solution here would be. With the resize_observer_border_box observer it will not trigger for the aforementioned appearance/disappearance of the scrollbar.
However as far as I can tell you also can't use the resize_observer_content_box because that won't detect changes in padding which is also part of the clientWidth and also needs to be detected.

The only "solution" I can think of is for clientWidth/clientHeight to use both of these observers to cover all scenario's in which the the clientWidth/clientHeight of an element might change... But I'm not particularly very fond of that approach and would love for someone to have a cleaner idea that doesn't require two observers with significant overlap in when they trigger.

Considering how niche this scenario might be it might be fine to just document this shortcoming in the svelte docs like is already done for display: inline. It's relatively straightforward to work around on the application's side if they run into it like I have.