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

The CSS Working Group just discussed ``[cssom-view] scroll and client properties of `<input>` elements / `overflow-clip-margin: content-box`.``, and agreed to the following:

* `RESOLVED: clientRect matches the overflow-clip-margin rect, and scrollRect is relative to that (i.e. scrollLeft = 0 is the initial scroll position)`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> i/Subtopic: [cssom-view-1]/Topic: CSSOM and CSSOM View<br>
&lt;fantasai> emilio: input elements clip to the content-box edge, is a bit weird<br>
&lt;fantasai> emilio: In Firefox clientLeft includes the padding<br>
&lt;fantasai> emilio: But overflow-clip-margin should maybe be consistent ...<br>
&lt;fantasai> emilio: Do people feel strongly about this? I think FF is sensible.<br>
&lt;fantasai> emilio: The coordinates don't quite make sense<br>
&lt;fantasai> astearns: Before considering overflow-clip-margin: content-box<br>
&lt;fantasai> astearns: is what you get from clientLeft interoperable or not?<br>
&lt;fantasai> emilio: I need to retest the current state<br>
&lt;fantasai> emilio: Haven't really seen compat issues<br>
&lt;fantasai> emilio: Makes sense that client area would not include thing you cannot scroll<br>
&lt;fantasai> emilio: thoughts?<br>
&lt;fantasai> emilio: For inputs, if we're interoperable, we can leave it as is<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: but for overflow-clip-margin we have opportunity to choose the right behavior<br>
&lt;emilio> ack emilio<br>
&lt;flackr> fantasai: overflow-clip-margin doesn't change how far you can scroll. if we want to use it for inputs need to be able to scroll to end so the content fits in content box<br>
&lt;flackr> fantasai: I know we made some changes for certain cases in block layout in inline axis<br>
&lt;flackr> fantasai: as long as you can scroll to the end making it visible in the content box, using overflow-clip-margin seems like a good idea rather than a scroller inside a box.<br>
&lt;flackr> fantasai: it makes the content model much more straight-forward<br>
&lt;flackr> scribe+<br>
&lt;fantasai> emilio: That would be a behavior change ... it's common to put background-image and (missed)<br>
&lt;fantasai> emilio: On block layout, if you have padding and overflow on the inline axis, the padding is part of what you scroll, whereas for inputs it's not<br>
&lt;fantasai> emilio: Consider you have 'white-space: nowrap' and 'padding-inline: 10px'<br>
&lt;fantasai> emilio: In a block that's a scroller, you see the padding-start, which is blank, and then you can scroll the "padding area" of the scroller is inside of what you scroll<br>
&lt;fantasai> emilio: The clip doesn't ...<br>
&lt;fantasai> emilio: The scrollport is not used by the padding.<br>
&lt;fantasai> emilio: That's the main difference<br>
&lt;fantasai> emilio: What you're proposing is the input would start showing the end of the content, instead of the padding area<br>
&lt;flackr> fantasai: that's why we have overflow-clip-margin: content-box. OCM should always be w.r.t. the scrollport<br>
&lt;flackr> fantasai: The idea of the input would be display: inline-block; overflow-clip-margin: content-box; would cause it to clip any content outside of the content box from the perspective of the scrollport<br>
&lt;flackr> fantasai: we just need to make sure the scrollable area has padding attached to the scrollable content so that you can scroll to the end<br>
&lt;fantasai> flackr: Is this the thing that doesn't work right now?<br>
&lt;flackr> fantasai: we're working on adding padding to the end of scrollable areas to see where we can add it. Think it can be added for a number of different boxes, e.g. flex and grid, blocks in the block axis. The inline axis may be tricky<br>
&lt;flackr> fantasai: For this to work, we need that to work, we'll have to check in with ian<br>
&lt;fantasai> emilio: If you think of the scroll container as like two different boxes, one inside the other<br>
&lt;fantasai> emilio: I guess, to the main question of this issue, should clientLeft depend on overflow-clip-margin<br>
&lt;fantasai> emilio: I think it probably should<br>
&lt;flackr> q+<br>
&lt;fantasai> emilio: Other mental model is the clip is reduced, but you do this weird padding thing then it kinda works out?<br>
&lt;astearns> ack fantasai<br>
&lt;fantasai> emilio: If you ask for clientRect of something you want the rect that's visible, and that's the content area<br>
&lt;astearns> ack flackr<br>
&lt;fantasai> flackr: The other way it could work is that the scrollable area is sufficiently large that even though the clientRect includes the clipped region, you can scroll all the content into view<br>
&lt;fantasai> emilio: That feels really weird<br>
&lt;fantasai> emilio: Could make the same argument for (?) and then clientRect is just the border-box instead of the padding-box<br>
&lt;fantasai> emilio: I think you want the area that's visible<br>
&lt;fantasai> emilio: People use this to check whether something is overflowing or not<br>
&lt;fantasai> emilio: I guess for that case if both are consistent.<br>
&lt;fantasai> flackr: I get it, does make sense for clientRect to represent the visible portion<br>
&lt;fantasai> astearns: Is there a proposed resolution on the interaction of overflow-clip-margin and clientRect?<br>
&lt;fantasai> emilio: I think ideally both scrollRect and clientRect ... clientRect gets reduced by [missed]<br>
&lt;fantasai> emilio: That implies that clientLeft, clientTop, etc.<br>
&lt;fantasai> emilio: get reduced by the padding area<br>
&lt;fantasai> emilio: if you have 'overflow-clip-margin: content-box'.<br>
&lt;fantasai> flackr: Can you specify 'overflow-clip-margin' to arbitrary values?<br>
&lt;fantasai> [discussion about positive vs negative values]<br>
&lt;fantasai> flackr: Would you choose the 'overflow-clip-margin' or the content box?<br>
&lt;fantasai> emilio: If you're expanding the scroller outside somehow then clientLeft should be negative somehow?<br>
&lt;fantasai> emilio: Whatever 'overflow-clip-margin' clips.<br>
&lt;fantasai> emilio: Make clientRect match that<br>
&lt;fantasai> flackr: It's a bit weird that (?)<br>
&lt;fantasai> emilio: overflow-clip-margin is weird, if it had applied to scrollers from the beginning it would have made more sense<br>
&lt;fantasai> PROPOSED: clientRect matches the overflow-clip-margin rect<br>
&lt;fantasai> emilio: scrollLeft of zero should be the start of the client, like if you set scrollLeft = 0 then that should scroll to the start<br>
&lt;fantasai> astearns: So because scrollRect is defined in terms of clientRect it should be fine?<br>
&lt;fantasai> emilio: Maybe we should be explicit about that<br>
&lt;fantasai> PROPOSED: clientRect matches the overflow-clip-margin rect, and scrollRect is relative to that (i.e. scrollLeft = 0 is the initial scroll position)<br>
&lt;fantasai> RESOLVED: clientRect matches the overflow-clip-margin rect, and scrollRect is relative to that (i.e. scrollLeft = 0 is the initial scroll position)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13502#issuecomment-4345295618 using your GitHub account


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

Received on Wednesday, 29 April 2026 15:46:33 UTC