Re: [csswg-drafts] [css-overflow-5] Allowing markers to be active even when not scrollable to aligned position (#10738)

The CSS Working Group just discussed `[css-overflow-5] Allowing markers to be active even when not scrollable to aligned position`, and agreed to the following:

* `RESOLVED:  Adopt proposal in https://github.com/w3c/csswg-drafts/issues/10738#issuecomment-2448204794 to anchor to identified elements`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> q+<br>
&lt;dbaron> flackr: It's easy to create a design where you can't reach the natural scroll-aligned position of the first or last elements in your scroller.<br>
&lt;dbaron> flackr: this leads to an odd usability issue that clicking on them doesn't make the mrakers active<br>
&lt;dbaron> flackr: we have the same problem today where if you follow an anchor link to something whose scroll position can't be reached, we could scroll you away from that link as a resul tof scroll anchoring<br>
&lt;dbaron> flackr: My proposal here is that browsers track when the scroll in a scroll container trageted a particular element, and then use that element as the targeted item until the user does another scroll.<br>
&lt;astearns> ack TabAtkins<br>
&lt;dbaron> flackr: for the purposes of markers this would mean that the marker is the first marker at or before that targeted element<br>
&lt;TabAtkins> https://github.com/w3c/csswg-drafts/issues/11165<br>
&lt;dbaron> TabAtkins: I was wondering how this would interact with 11165 which is about indicating markers in the unscrollable region that you can't reach... but I don't think it does, so I'm good with what's suggested here.<br>
&lt;astearns> ack fantasai<br>
&lt;dbaron> fantasai: Overall I agree with the direction... one thing is if we've targeted a particular element that's not the one we'd select at this scroll position because we're urther down towards the end... the user would have to scroll back up to shift focus to something else?<br>
&lt;dbaron> flackr: right<br>
&lt;dbaron> fantasai: so if they continued to scroll down it would not cause it to recalculate<br>
&lt;dbaron> flackr: they're not changing their scroll position by scrolling down<br>
&lt;dbaron> fantasai: then this seems fine to me<br>
&lt;dbaron> +1 to element tracking from me to -- something I wanted to do a very long time ago well before scroll anchoring was a thing :-)<br>
&lt;fantasai> PROPOSED: Adopt proposal in https://github.com/w3c/csswg-drafts/issues/10738#issuecomment-2448204794 to anchor to identified elements<br>
&lt;dbaron> Proposed resolution from flackr: each scrolling container tracks the last element scrolled into view until that container's scroll position is otherwise changed<br>
&lt;dbaron> RESOLVED:  Adopt proposal in https://github.com/w3c/csswg-drafts/issues/10738#issuecomment-2448204794 to anchor to identified elements<br>
&lt;TabAtkins> ScribeNick: TabAtkins<br>
</details>


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


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

Received on Wednesday, 20 November 2024 16:28:25 UTC