- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Apr 2025 16:51:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view] Consider adding Element.scrollParent`, and agreed to the following: * `RESOLVED: add scrollParent to the spec` <details><summary>The full IRC log of that discussion</summary> <JoshT> flackr: We've had a bunch of other APIs to expose the parent and offset parent, but devs have to do a lot of querying to find nearest scroll container<br> <emilio> q+<br> <JoshT> ... resolution proposed is to expose it. scrollParent. the nearest container that's a scroll container<br> <TabAtkins> q+<br> <iank_> q+<br> <astearns> ack schenney<br> <astearns> ack emilio<br> <JoshT> emilio: Just to confirm, we're talking about the scroll container you scroll relative to<br> <JoshT> ... for stuff like fixpos, it should return null<br> <TabAtkins> yes, .scrollingElement I think is right<br> <JoshT> ... I'm assuming for the root scroller, we return ... there are some complexities there. we could return document.scrollingElement?<br> <JoshT> ... I guess ?? it sounds good<br> <astearns> ack TabAtkins<br> <emilio> s/??/modulo details<br> <JoshT> TabAtkins: bramus suggested in the thread calling it scrollingParent<br> <emilio> s/we return .../we return the scrollingElement (in quirks mode that's the body)<br> <astearns> ack iank_<br> <JoshT> ... I'm not sure if we have other scroll APIs that suggest we should stick with 'scroll'<br> <TabAtkins> to be consistent with .scrollingElement<br> <JoshT> iank_: just to check, flackr, this will walk up the containing block chain?<br> <kizu> q+<br> <smfr> q+<br> <JoshT> ... so if abspos skips, it can skip a scroller and make sure it returns the next one<br> <astearns> ack kizu<br> <emilio> q+<br> <JoshT> kizu: I wanted to mention how we handle elements with ??? auto, scroll, where there an element not overflowing<br> <JoshT> ... and cases where it clips something, so it is inside content but not scrollable by usual means<br> <JoshT> ... this is what we currently on our app do. we go up the chain, looking for scrollable containers (compared to offsetHeight with actual height) and go further if it's not currently scrollable<br> <JoshT> ... so if it will not work as expected, we will need to mention this and propose what it should do in this case<br> <JoshT> flackr: I disagree we should make it work this way. e.g. stickypos is offset to the nearest scroll container.<br> <TabAtkins> +1 to flackr's point<br> <iank_> +1<br> <JoshT> ... I think it should follow the spec definition of a scroll container<br> <smfr> q-<br> <oriol> +1. overflow:hidden can scroll by script, no scrollbar needed<br> <emilio> +1<br> <JoshT> ... if a dev wants to find the thing that actually scrolls, they will still need additional logic<br> <JoshT> astearns: you were saying the spec needs an example of how to do it this way?<br> <JoshT> kizu: authors will want to be able to do this. there is also a precident for us to have state queries to ask if an element is scrollable right now<br> <JoshT> ... this is what authors want now. not theoretical scrollability<br> <JoshT> ... it will be already accessible, but maybe we could make it better<br> <iank_> It depends a lot on the usecase for what you want to do.<br> <JoshT> flackr: this at least makes it easier to get what you're asking for<br> <JoshT> ... but changing the size of your window could cause a different scroll parent<br> <astearns> ack emilio<br> <JoshT> emilio: if we wanted to do something like that, it might be worth turning this into a function with options<br> <JoshT> ... but checking if it's scrollable is a matter of checking if scroll height is less than client height<br> <JoshT> ... modulo sub pixels get tricky but that's a separate issue.<br> <JoshT> ... if we need filters and whatnot, we need a different property for 'does it have scroll overflow'<br> <TabAtkins> *using* this API, it's pretty easy to walk the scrollParent chain to find one *with* a scrollbar. still a strict improvement over today, where if you just walk the *parent* chain you might catch something not in the element's CB chain<br> <JoshT> ... I do agree that pages tend to ask for it and get it wrong.<br> <ydaniv> +1 to not skip hidden etc. Otherwise will behave different from ViewTimelines as well<br> <JoshT> ... it is trickier to tell if something is truly scrollable.<br> <TabAtkins> and enough things *will* want the spec's notion of "scroll container" that we should expose that; can't really get scroll container from an API that returns "nearest thing with a scrollbar" as it might overshoot<br> <JoshT> ... but this API should just tell you if it's a scroll container<br> <emilio> q+<br> <JoshT> kizu: sounds good. we will need to think about how to fix it but not in this issue<br> <astearns> ack fantasai<br> <JoshT> fantasai: I agree with flackr and emilio<br> <JoshT> ... if we want to make it easier for authors to filter, we could do it based on container queries and filter by x or y<br> <flackr> +1 to emilio's suggestion of an IDL attribute to easily check if something is currently scrollable<br> <JoshT> ... that is a separate issue. this proposal makes sense<br> <astearns> ack emilio<br> <JoshT> emilio: for the root scroller case, should we return an element at all?<br> <JoshT> astearns: I'm not hearing objections<br> <TabAtkins> happy to leave name decision to flackr<br> <iank_> "scroll" matches "scrollWidth" etc.<br> <JoshT> ... does anyone have a pref for scrollParent or scrollingParent?<br> <kizu> +1 to `scrollParent`<br> <JoshT> astearns: proposed to add scrollParent to the spec<br> <JoshT> RESOLVED: add scrollParent to the spec<br> <JoshT> fantasai: who will make edits in which spec?<br> <JoshT> flackr: I can make edits<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1522#issuecomment-2842631086 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 April 2025 16:51:46 UTC