.ML__sr-only escapes scroll containers and extends the page height #3073

Description
Summary
A placed inside an overflow: auto container adds blank scrollable space to the nearest positioned ancestor outside that container, typically the page. Once the field is scrolled out of view inside the container, the page grows a second scrollbar into empty space.

The cause is the aria-live wrapper .ML__sr-only. It is position: absolute with top and left left at auto, and nothing between it and the host is positioned: :host is display: block with no position, and the span is a direct child of the shadow root next to .ML__container (see src/editor-mathfield/mathfield-private.ts, the markup.push('') line, and css/core.less for the class). The span therefore takes its static position, which is wherever the field happens to be, but its containing block is the first positioned ancestor of the host in the light DOM. Scroll containers only clip absolutely positioned descendants whose containing block lies inside them, so the span sits outside the scroller's clip and contributes to the outer ancestor's scrollable overflow.

#971 reported this same symptom in 2021 and was resolved by making the host position: relative by default. That rule is no longer present in css/mathfield.less, so the behaviour is back.

Steps to reproduce
Open this page and scroll the inner box to the bottom. The page grows a vertical scrollbar into empty space below the box.

<!doctype html>

<script type="module" src="https://unpkg.com/mathlive"></script> <script> box.innerHTML = Array.from({ length: 40 }, (_, i) => `

Line ${i}

x^{${i}}+\\frac12` ).join(""); </script> Measured in Chrome 152 with mathlive 0.110.0, the outer div reports scrollHeight 2303 against a clientHeight of 300, and the last field's .ML__sr-only has a computed top of 2303px. Adding position: relative to #box brings the outer scrollHeight back to 300, which confirms the containing block is the problem rather than the field's own size.

Editable fields emit the same markup, so read-only is not required to reproduce. The .ML__keyboard-sink span is position: fixed and does not contribute, so the sr-only span is the only offender.

Expected behaviour
A field inside a scroll container should not affect layout outside that container.

Actual behaviour
The host page gains scrollable blank space equal to the field's offset inside the scroller, and the browser shows a second scrollbar.

Environment
mathlive 0.110.0 (also reproduced against current master source by inspection)
Chrome 152 on macOS 26; the same containing-block rules apply in every engine
Suggested fix
Any one of these keeps the span inside the host:

:host { position: relative; } in css/mathfield.less, restoring the resolution from #971.
top: 0; left: 0; on .ML__sr-only, so it no longer depends on its static position.
Emit the sr-only span inside .ML__content, which is already position: relative.
The first option is the smallest change and matches what #971 settled on.

Workaround
Give the scroll container position: relative. The span then uses the scroller as its containing block and is clipped with the rest of the content.