- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 29 Apr 2026 15:27:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view-1] Clip aligned element box by intermediate scrollers`, and agreed to the following: * `RESOLVED: scrollIntoView() targets the element's area as clamped by intervening scroll containers` * `RESOLVED: scroll-padding is only taken into consideration on the scroller being scrolled (not on intervening scrollers)` * `RESOLVED: scroll-margin is applied to the clamped area (is not itself clamped)` <details><summary>The full IRC log of that discussion</summary> <fantasai> scribe+<br> <fantasai> flackr: Differences in behavior when scrolling into view.<br> <fantasai> flackr: Historically, would scroll "into view" regardless of clipping<br> <fantasai> flackr: Chrome changed to scroll to the portion that was visible if it's clipped<br> <fantasai> flackr: But if it was wholly invisible, it'll scroll to its actual position which is nonsense<br> <emilio> q+<br> <fantasai> flackr: I think when we perform scrollIntoView(), clip the region to the portion of the element that is not clipped by the outer scroller<br> <fantasai> flackr: So you won't scroll to invisible spaces where the box occupies but is not visible to the user.<br> <fantasai> astearns: Would this change Chrome's behavior, or new thing?<br> <fantasai> flackr: Chrome does it some of the time, but not always.<br> <fantasai> flackr: I'm proposing to do it always.<br> <astearns> ack emilio<br> <fantasai> emilio: I think that's fine.<br> <fantasai> emilio: In the issue you mentioned clip-path, I suspect we don't want to do that.<br> <fantasai> flackr: Agree we don't want to do that.<br> <fantasai> emilio: My concern is things like, if an anchor is off-screen but in-position vertically ...<br> <fantasai> emilio: Maybe people use that to anchor scroll positions, and presumably we don't want to scroll that into view...? But maybe scrolling vertically makes sense?<br> <fantasai> flackr: Even if the visible box becomes zero area, it still has dimensions of top and bottom which would give you the correct vertical position.<br> <fantasai> emilio: Ah, so you want to do this per-axis.<br> <fantasai> flackr: I was imagining we want to scroll as close as we can to the visible part of the element, but not so far that we leave the scroller that's clipping it.<br> <fantasai> emilio: So wouldn't change behavior for anchors.<br> <fantasai> emilio: Slight concern about that, but overall makes sense.<br> <fantasai> fantasai: Wrt 'overflow: clip' I would suggest to keep it in sync with 'overflow: hidden' rather than 'clip-path' as you suggested, flackrr.<br> <fantasai> flackr: We could do this. My rationale for ignoring 'overflow: clip' is that it's not a scroll container. And we usually don't pay attention to non scroll-containers when walking the ancestors.<br> <emilio> I agree with flackr here<br> <fantasai> flackr: I always thought about 'overflow: clip' as purely decorative.<br> <fantasai> emilio: My mental model was the same<br> <fantasai> emilio: 'overflow: clip' is fundamentally not a scroll container, and this is about scroll containers.<br> <fantasai> emilio: Becomes a bit weird because there are other things that affect scroll-into-view like scroll-margin etc. and don't affect 'overflow: clip'<br> <emilio> q+<br> <fantasai> fantasai: I think from author perspective 'overflow' is for containment clipping, and 'clip-path' etc is decorative.<br> <astearns> ack fantasai<br> <fantasai> fantasai: So although from impl perspective 'overflow: clip' is like 'clip-path', I don't think that's true from authoring perspective.<br> <fantasai> flackr: Spec-wise it's pretty different thing.<br> <fantasai> flackr: but not opposed.<br> <fantasai> emilio: Treating 'overflow: clip' same as scroll ...<br> <fantasai> emilio: it gets you into a slipperly slope<br> <fantasai> emilio: Should you also inflate/deflate by 'scroll-margin' and 'scroll-padding'?<br> <fantasai> emilio: You deflate by that, but it feels weird<br> <fantasai> emilio: Treating it as a scroller but without these scrolly things, and then applying overflow-clip-margin on top ...<br> <fantasai> flackr: Prefer to start narrow and consider that separately.<br> <fantasai> astearns: Distinctions between 'overflow: clip' and 'clip-path'<br> <fantasai> astearns: concern is that it would have wider implications?<br> <fantasai> fantasai: No<br> <fantasai> flackr: Yes. That's the concern.<br> <fantasai> fantasai: Happy to split out to separate consideration.<br> <fantasai> PROPOSED: scrollIntoView() targets the element's area as clipped by intervening scroll containers<br> <fantasai> [tangent wrt scroll-padding etc.]<br> <fantasai> emilio: often used for abspos type stuff<br> <fantasai> flackr: I think it'll be fine [missed rationale]<br> <fantasai> emilio: But doesn't it give you some weird degenerate behavior... it's probably fine<br> <fantasai> PROPOSED: scroll-padding is only taken into consideration on the final scroller, and scroll-margin is applied to the clipped region (??)<br> <fantasai> astearns: Do we need to clarify that it's clamped if out of region?<br> <fantasai> flackr: Yeah we could clarify<br> <fantasai> PROPOSED: scrollIntoView() targets the element's area as clamped by intervening scroll containers<br> <fantasai> flackr: Inner scroller will use scroll-padding when scrolling<br> <emilio> Lgtm<br> <fantasai> RESOLVED: scrollIntoView() targets the element's area as clamped by intervening scroll containers<br> <fantasai> PROPOSED: scroll-padding is only taken into consideration on the scroller being scrolled<br> <fantasai> flackr: scroll-margin should be re-applied to the clipped bounds<br> <emilio> Sounds good<br> <fantasai> PROPOSED: scroll-padding is only taken into consideration on the scroller being scrolled (not on intervening scrollers)<br> <fantasai> RESOLVED: scroll-padding is only taken into consideration on the scroller being scrolled (not on intervening scrollers)<br> <fantasai> PROPOSED: scroll-margin is applied to the clamped area (is not itself clamped)<br> <fantasai> emilio: Feels a bit weird<br> <fantasai> emilio: but maybe it's fine<br> <fantasai> flackr: I got some bug reports about this, and in those cases tended to agree.<br> <fantasai> flackr: But we can revisit if it seems broken<br> <fantasai> RESOLVED: scroll-margin is applied to the clamped area (is not itself clamped)<br> <fantasai> astearns: We can revisit if needed<br> <fantasai> s/Topic:/Subtopic:/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13411#issuecomment-4345155434 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:27:35 UTC