[csswg-drafts] [cssom-view] scroll and client properties of `<input>` elements / `overflow-clip-margin: content-box`. (#13502)

emilio has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cssom-view] scroll and client properties of `<input>` elements / `overflow-clip-margin: content-box`. ==
`<input>` elements are a bit special, because on the inline axis they don't clip to the padding-box edge but the content-box edge:

```
data:text/html,<input style="width: 40px; padding: 10px; appearance: none" value="some long long text">
```

That means that what `scroll{Width,Height}` / `client{Width,Height}` should do is a bit up-in-the-air, and it doesn't seem terribly well defined.

Browsers diverge here (behavior has changed not that long ago, in [bug 1991643](https://bugzilla.mozilla.org/show_bug.cgi?id=1991643) for example, and Safari also had that behavior early apparently?).

Here's a test-case:

```html
<!doctype html>
<style>
.measure {
  overflow: scroll;
  scrollbar-width: none;
  border: 1px solid;
  padding: 10px;
  box-sizing: border-box;
  width: 40px;
  height: 40px;
  white-space: nowrap;
  font: 10px/1 monospace;
}
</style>
<input class="measure" value="some long long text">
<div class="measure">some long long text</div>
<div class="measure" style="overflow-clip-margin: content-box">some long long text</div>
<div class="measure" style="overflow: clip;">some long long text</div>
<div class="measure" style="overflow: clip; overflow-clip-margin: content-box">some long long text</div>
<pre id="target"></pre>
<script>
  for (let e of document.querySelectorAll(".measure")) {
    target.appendChild(document.createTextNode(
    `sl: ${e.scrollLeft}, st: ${e.scrollTop}, sw: ${e.scrollWidth}, sh: ${e.scrollHeight}, cl: ${e.clientLeft}, ct: ${e.clientTop}, cw: ${e.clientWidth}, ch: ${e.clientHeight} ${e.outerHTML}\n`));
  }
</script>
```

Firefox implements it with an inner scroller inside the content box of the `<input>`, and thus has a `clientLeft` of 11 (border + padding), etc.

I think for the `<input>` case both things could make sense, and before `overflow-clip-margin` we didn't have a way of explaining the `<input>` behavior in CSS, so it's probably worth aligning with other browsers here.

However, we recently resolved to make `overflow-clip-margin: content-box` work on actual scrollers. Should that behave the same or should it actually change the scrollport / client area?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13502 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 16 February 2026 10:10:23 UTC