- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 19:08:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow] add method to prevent elements from contributing to scrollable overflow`, and agreed to the following: * `RESOLVED: we will work on these two properties, names and perspective details TBD` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: we had some discussion about having elements that don't contribute to scrollable area<br> <TabAtkins> flackr: related problems around snapping to transformed or sticky elements<br> <TabAtkins> flackr: it seemed like these were orthogonal things we could control with separate props<br> <iank_> q+<br> <TabAtkins> flackr: I have a rough proposal for the overflow, and for how to determine scroll alignment of an element - whether it ignores or honors transforms and sticky<br> <astearns> ack iank_<br> <TabAtkins> iank_: I think these proposals look good, two separate things. similar but orthogonal<br> <TabAtkins> iank_: we might want ignore-transform in overflow-cotnribution as well, I have a use-case for it<br> <TabAtkins> flackr: reasoanble<br> <smfr> q+<br> <astearns> ack smfr<br> <TabAtkins> smfr: is overflow-cotnribution inherited?<br> <TabAtkins> flackr: I think it would have to be?<br> <TabAtkins> iank_: if you're not going to... gets into how it works<br> <emilio> q+<br> <TabAtkins> iank_: I imagine you don't add the direct overflow for the element or its descendants<br> <TabAtkins> iank_: so it doesn't need to be inherited<br> <TabAtkins> smfr: so can you undo it on a descendant?<br> <TabAtkins> iank_: no, if we're not inheriting<br> <TabAtkins> smfr: so it hides the whole subtree then<br> <TabAtkins> iank_: yeah<br> <ntim> q+<br> <TabAtkins> astearns: but if is inherited you could undo it but not have an effect<br> <TabAtkins> flackr: the challenge with undoing it is, what does it means to ignore the transform<br> <astearns> ack emilio<br> <TabAtkins> iank_: we dont' want visibility shenanigans<br> <TabAtkins> smfr: certainly<br> <TabAtkins> emilio: should this effect abspos boxes?<br> <astearns> s/effect/affect/<br> <TabAtkins> emilio: abspos in the affected element<br> <TabAtkins> emilio: I think it wouldn't, they're in the scroll container but not with the same box parent<br> <TabAtkins> iank_: I was imagining it would work on the fragment tree. abspos would escape<br> <TabAtkins> emilio: I think I agree, it was just unclear<br> <TabAtkins> emilio: was wondering if there was an interesting effect with transforms... but they establish abspos container<br> <TabAtkins> emilio: top layer... you do want that to be totally independent<br> <astearns> ack ntim<br> <TabAtkins> TabAtkins: yeah top layer is even more escape-y<br> <TabAtkins> ntim: If you have an element with overflow-cotnribution:none, and inside you have an abspos, and in that abspos you have other children, do those stop contributing to the abspos overflow?<br> <astearns> doesn’t stop, it continues to not contribute<br> <TabAtkins> astearns: anyone need more time to look at the proposal before we adopt it?<br> <TabAtkins> emilio: overflow-cotnribution seems fine<br> <TabAtkins> emilio: is the idea that ink overflow would still be...<br> <TabAtkins> iank_: yeah this only affects scrollable overflow, no effect on ink overflow<br> <TabAtkins> emilio: do we need to do something for perspective? not just pre and post transform overflow... perspective and scrolling have weird interactions<br> <TabAtkins> astearns: is perspective included int transforms?<br> <TabAtkins> emilio: should be. in gecko we have a special case to compute scrollable overflow later if you have perspective<br> <TabAtkins> dbaron: yeah, perspective is interesting<br> <TabAtkins> dbaron: i've seen blink bug reports for which the solution is the gecko behavior<br> <TabAtkins> dbaron: the gecko behavior is correct in an observable way<br> <TabAtkins> dbaron: I understand the correction, it would take me a bit to understand the implications of that on this feature<br> <TabAtkins> iank_: I think we'd consider perspective a transform, so it would get ignored with ignore-transform<br> <TabAtkins> iank_: might be able to revisit that depending on compat<br> <TabAtkins> astearns: so proposed resolution is we add these two properties, + ignore-transform on overflow-cotnribution?<br> <TabAtkins> emilio: can rob clarify scroll-align-origin?<br> <TabAtkins> flackr: scroll-align properties are used for snap scrolling alignment<br> <TabAtkins> flackr: devs will have a scroll-driven animations that chances the transform on the element. if you snap to the transformed position that has an effect on the snap position<br> <TabAtkins> emilio: I see. should it have snap in the name somehow?<br> <smfr> q+<br> <TabAtkins> flackr: my intention is that this would work for scrollIntView as well, which scroll-snap does work for<br> <TabAtkins> flackr: so maybe that's fine<br> <TabAtkins> emilio: scroll-align-origin just feels very generic... scroll-snap-align-origin suggests better<br> <TabAtkins> flackr: scrollIntoView should affect this too tho.<br> <TabAtkins> flackr: but that said, scroll-snap-align does apply to scrollIntoView, so...<br> <astearns> ack dbaron<br> <TabAtkins> flackr: i'm fine with adding snap to the name<br> <TabAtkins> dbaron: i'm trying to remember the perspective thing. not sure about what Ian said, treating perspective like a transform and ignoring it<br> <TabAtkins> dbaron: I think where this matters... only for the perspective property, not the transform<br> <TabAtkins> dbaron: the property interesting but is it fits in tot he transform and origin order differently<br> <TabAtkins> dbaron: so the scrolling of the element's own scroller matters, so you can do parallax with perspective property<br> <TabAtkins> dbaron: the gecko fix is when you do these parallax effects ,and give content a positive z transform to make it move faster, the scroll extents come up short<br> <TabAtkins> dbaron: I think that's the bug, maybe it's more subtle than that<br> <TabAtkins> dbaron: authors hit this frequently, I think their normal solution is using another element to pad their scroll extents. hard if the height is dynamic<br> <TabAtkins> astearns: nice background info but i'd like to punt on perspective for now<br> <TabAtkins> dbaron: right, just don't want to take a resolution on perspective right now<br> <astearns> ack smfr<br> <TabAtkins> smfr: mino rpoint about scrolling origins. trasnform-origin is a point, background-origin is keyword. minor preference for not using the word "origin" here, then<br> <TabAtkins> emilio: right, it's not just the origin. if you ignore transforms you also ignore size differences<br> <TabAtkins> flackr: that is correct<br> <TabAtkins> emilio: maybe scroll-snap-align-rect?<br> <TabAtkins> astearns: -basis?<br> <TabAtkins> how about scroll-snap-align-decide-in-two-weeks<br> <dbaron> https://issues.chromium.org/40203207 has some links to the perspective issue I was thinking of<br> <TabAtkins> flackr: we can Bikeshed the name in the issue<br> <TabAtkins> astearns: proposed: we will work on these two properties, names and perspective details TBD<br> <dbaron> (I think I filed that because someone mentioned it somewhere else, but I'm not sure)<br> <TabAtkins> RESOLVED: we will work on these two properties, names and perspective details TBD<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8361#issuecomment-4179919901 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 19:08:02 UTC