Re: [csswg-drafts] [cssom-view] Should `scrollParent` allow axis filtering? (#12731)

The CSS Working Group just discussed ``[cssom-view] Should `scrollParent` allow axis filtering?``, and agreed to the following:

* `RESOLVED: make scrollParent a function`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> oriol: we have these APIs that return the scroll container, in another issue we resolved that we can have a scroll container in one axis<br>
&lt;ydaniv> ... authors may be able to find that by checking scroll containers in a loop, but would it be useful to expose this as param, whether scroll parent is scrollable?<br>
&lt;ydaniv> ... problem is that scrollParent is only specifed as  getter<br>
&lt;ydaniv> ... also it was wanted in shadow DOM to check in a loop if scroll parent is scrollable<br>
&lt;flackr> q+<br>
&lt;ydaniv> ... so need to first resolve to turn it into a function, and then check whether it's worth adding these filtering capabilities<br>
&lt;astearns> ack flackr<br>
&lt;ydaniv> flackr: I think we resovled to make it a function before<br>
&lt;ydaniv> ... and I added a proposed syntax to add a param to check specific axis<br>
&lt;emilio> +1<br>
&lt;ydaniv> astearns: an issue would be nice<br>
&lt;ydaniv> flackr: sure, good to resolve<br>
&lt;ydaniv> astearns: other comments?<br>
&lt;ydaniv> PROPOSED RESOLUTION: make scrollParent a function<br>
&lt;ydaniv> astearns: obejctions?<br>
&lt;ydaniv> RESOLVED: make scrollParent a function<br>
&lt;flackr> q+<br>
&lt;ydaniv> flackr: prefer we leave shadow roots for another time<br>
&lt;ydaniv> ...  I assume if we don't have any mention of shadow root it behaves as offsetParent where it's skipped<br>
&lt;ydaniv> ... for the axes would be good to be able to specify x/y/block/inline/...<br>
&lt;ydaniv> ... there should be either or auto or something<br>
&lt;ydaniv> oriol: just checking without specifying an axis would just check if it's a scroll container or not<br>
&lt;ydaniv> emilio: at least if it's scrollable in that axis or scroll container in that axis,<br>
&lt;ydaniv> ... may be worth to see if we want to somehow shape the API that it's not weird<br>
&lt;ydaniv> flackr: would that be same property?<br>
&lt;ydaniv> emilio: it's kind of a property of the axis. Is there a use-case of whether it's a scrollable in both vs. in one? not sure it makes sense<br>
&lt;ydaniv> flackr: right<br>
&lt;ydaniv> emilio: also is it user-scrollable? if there's hidden in one axis?<br>
&lt;ydaniv> flackr: if it's going to change the way we define the axis property then we need to specify first<br>
&lt;ydaniv> ... it's easier to add a filter and check<br>
&lt;ydaniv> emilio: I guess that's fine<br>
&lt;ydaniv> flackr: the point of adding the function is that we can later have it<br>
&lt;ydaniv> emilio: it might be worth thinkning on what axis filtering we need<br>
&lt;ydaniv> astearns: we have a resolution to make it a function, if we're not ready to resolve on how we resolve axis as param do we take it back? or resolve on minimum?<br>
&lt;ydaniv> ... probably take it back and design with more care<br>
&lt;ydaniv> flackr: I think it's fine<br>
&lt;ydaniv> astearns: taking back to the issue<br>
</details>


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


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

Received on Wednesday, 11 February 2026 17:00:58 UTC