- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2025 17:44:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view-1] Option for scrollIntoView that doesn't propagate to ancestors`, and agreed to the following:
* ``RESOLVED: enum ScrollIntoViewContainer { "all", "nearest" }, defaulting to `all`, expanding to element in the future if needed``
<details><summary>The full IRC log of that discussion</summary>
<joshtumath> flackr: scrollIntoView is a useful API<br>
<joshtumath> ... does the right thing for common use cases. but propogates all the way up chain to scroll root<br>
<joshtumath> ... so the proposal is to add a container property to the dict added to scrollIntoView<br>
<joshtumath> ... it would use Tab's proposal here for the common ancestor about what to scroll into view<br>
<joshtumath> ... the main reason was to make it easy to refer to your own scrolling ancestor.<br>
<joshtumath> ... so you'd say container.target and it would refer to nearest ancestor<br>
<emilio> q+<br>
<joshtumath> ... I'm also fine with it just using the container. but then we have to answer what happens if the container is not actually an ancestor<br>
<joshtumath> ... you could just do nothing because that's what you've asked for<br>
<joshtumath> ... TabAtkin's suggestion is simple to use, but container is not quite the right name<br>
<joshtumath> Rossen: the top scrolling ancestor of the container?<br>
<smfr> q+<br>
<TabAtkins> X.scrollIntoView(container:Y), finds the nearest common scollable ancestor of X and Y<br>
<Rossen5> ack emilio<br>
<joshtumath> emilio: I think I was going to drop a similar question. Ancestor in the DOM sense or layout tree sense?<br>
<joshtumath> ... or maybe we need to... we have a switch to not scroll<br>
<joshtumath> ... I think what you want is to scroll to the first scrollable thing<br>
<joshtumath> ... let's say you have a fixedpos element<br>
<joshtumath> ... it does not scroll with the rest of the content<br>
<joshtumath> flackr: it would follow the scroll parent chain?<br>
<joshtumath> emilio: a layout ancestor.<br>
<joshtumath> ... so let's say if you scroll it on a popover.<br>
<joshtumath> ... that seems reasonable, but container is a misnomer. maybe scroll-parent?<br>
<joshtumath> ...but we have the scroll parent API<br>
<bramus> https://github.com/w3c/csswg-drafts/issues/1522 is that issue<br>
<joshtumath> flackr: we have a separate issue to add scroll parent to the element API<br>
<joshtumath> ... we have offset parent, which is close<br>
<joshtumath> emilio: Should we add something to skip over overflow: hidden stuff, but I can see you want both<br>
<joshtumath> bramus: they should use overflow: clip in that case<br>
<Rossen5> ack smfr<br>
<joshtumath> smfr: I agree with emilio. Should shadow roots be a boundary as well?<br>
<joshtumath> ... and at least in WebKit, scrolling goes across iframe boundaries<br>
<emilio> q+<br>
<joshtumath> ... it surprises me because ???<br>
<joshtumath> flackr: I thought chrome changed that to not propergate across iframe boundaries.<br>
<joshtumath> argyle: on codepen, the reproduce ability is available<br>
<joshtumath> ... you'll see the iframe scroll into view and you'll know it's the child iframe. it's kind of the issue<br>
<joshtumath> smfr: I have a feeling that's cross origin. maybe I'm thinking of jsbin<br>
<joshtumath> bramus: yes I think so<br>
<smfr> if Chrome did change the cross-origin iframe behavior, I'd like that to be raised in a CSS issue and specified<br>
<joshtumath> Rossen: but the point is righteous. allowing to escape iframes or cross-origin iframes, sounds like reasonably in scope<br>
<joshtumath> flackr: I think it's a different issue<br>
<bramus> +1 on it being a different issue<br>
<argyle> +1, two great different issues we should fix<br>
<joshtumath> ... the issue of smfr is iframes, it's scrolling and hijacking frames that are unrelated.<br>
<joshtumath> Rossen: but should be tackled in a separate issue. very related<br>
<Rossen5> ack emilio<br>
<joshtumath> emilio: so we could still at least agree that this doesn't work when the container you pass in comes from a separate document<br>
<joshtumath> ... smfr had a question about shadow root<br>
<joshtumath> ... they don't have boxes so they don't apply here?<br>
<joshtumath> ... depending on how we do this, scroll parent API has to retarget stuff from inside to outside shadow trees<br>
<joshtumath> ... the scroll only on the first ancestor would get you ???<br>
<joshtumath> ... so i wonder if we should do more research for that situation<br>
<joshtumath> ... the closest scroller, if it's in the shadow tree, do you want the container inside your tree<br>
<joshtumath> ... I don't think you want to get it without conversions, to get an element from a shadow tree<br>
<joshtumath> flackr: I guess in a way, you can scroll up to the ????<br>
<argyle> q+<br>
<joshtumath> emilio: you need a way of avoiding scroll parent in the shadow root<br>
<joshtumath> ... that may be an issue with shadow parent rather than this issue<br>
<joshtumath> flackr: we should have an API for that that expands to specifying a container in the future<br>
<bramus> q+<br>
<Rossen5> ack argyle<br>
<joshtumath> argyle: 100+ on this. it makes scrollIntoView unusable because of the side effects<br>
<emilio> maybe we have an enum Container { "all", "first" }, then optionally make it `(Container or Element) container;` in the future<br>
<joshtumath> ... maybe tag the containers with CSS. we indicate a scroll into view mechanism<br>
<emilio> q+<br>
<flackr> I would say nearest instead of first<br>
<joshtumath> ... then you declare on any container that you know of.<br>
<joshtumath> flackr: I disagree because that would change things like scrolling to an anchor link<br>
<emilio> q-<br>
<joshtumath> ... could spec it not to but maybe it would be weird, affect some APIs not others<br>
<joshtumath> ... agree with emilio's suggestion changing first to nearest<br>
<joshtumath> emilio: sounds good<br>
<joshtumath> bramus: could have default value being document root element<br>
<joshtumath> ... as smfr said in IRC, could continue this at F2F<br>
<joshtumath> flackr: that could be breaking. we could change what all does<br>
<joshtumath> Rossen: I want to see if we can resolve<br>
<joshtumath> ... instead of deferring to F2F<br>
<flackr> Proposed resolution: Add container: 'all' | 'nearest' with default value 'all'<br>
<joshtumath> ... we can agree to adopt it as currently specified<br>
<emilio> PROPOSED: enum ScrollIntoViewContainer { "all", "nearest" }, defaulting to `all`, expanding to element in the future if needed<br>
<joshtumath> flackr: scroll parent ancestry<br>
<joshtumath> emilio: not if the block is not scrollable<br>
<joshtumath> smfr: does it work in the popover case?<br>
<joshtumath> emilio: it would scroll the viewport, but that would be outside of the scroller<br>
<joshtumath> ... we should define this so that it works properly in that case.<br>
<joshtumath> smfr: OK<br>
<joshtumath> Rossen: sounds like it's resolved<br>
<joshtumath> RESOLVED: enum ScrollIntoViewContainer { "all", "nearest" }, defaulting to `all`, expanding to element in the future if needed<br>
<emilio> We should probably follow-up with issues for iframe and overflow-hidden tweaks<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9452#issuecomment-2607879021 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 January 2025 17:44:41 UTC