- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 21:53:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scroll-snap-1] Avoid page scrolling skipping past snappable items`, and agreed to the following: * `RESOLVED: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area` * `ACTION: flackr to sketch out a scroll-by-page API` <details><summary>The full IRC log of that discussion</summary> <fantasai> flackr: context of scroll buttons , but pre-existing issue with snapping<br> <fantasai> flackr: currently if you pgae down, the browser can select a snap area that is more than one page away<br> <fantasai> flackr: even though there's a possible snap area that's not that far away<br> <fantasai> flackr: I propose putting wording in the spec that, at least for explicit actions like page down, find a snap area that is less than one page away<br> <fantasai> flackr: so that you don't skip over content<br> <fantasai> flackr: then I had a further open question of whether we need to solve this for scrolling APIs<br> <fantasai> flackr: original issue was calling .scrollTo<br> <fantasai> flackr: to mimic same behavior<br> <dholbert> fantasai: I think yes, page-up page-down should scroll <= viewport<br> <dholbert> fantasai: might be exactly equal, but could be <=<br> <dholbert> fantasai: for programmatic API, those are supposed to [...]<br> <Rossen6> ack fantasai<br> <dholbert> fantasai: ...have the same behavior as a person scrolling<br> <dholbert> fantasai: if scroll-snap is going to interfere with a person scrolling, then programmatic aPI should get that same interference<br> <dholbert> flackr: if I make a page-down button, as a web developer, and add an event listener that calls scrollTo(currentPos + 85% of scrollport)<br> <dholbert> flackr: the same problem as pressing pagedown on keyboard exists, that browser could select something further away<br> <dholbert> flackr: should we try to scroll less?<br> <dholbert> fantasai: round-down version?<br> <dholbert> flackr: most expressive version is to say "don't want to scroll more than 1 page"<br> <dholbert> fantasai: ...<br> <dholbert> flackr: that's scrollIntoView<br> <dholbert> flackr: this is for APIs where you specify how far you want to scroll, or a position<br> <dholbert> fantasai: do we want to add a scrollByPages API?<br> <dholbert> flackr: that would be reasonable<br> <dholbert> fantasai: or do we give a "bias-towards" parameter?<br> <dholbert> fantasai: which of those would make more sense<br> <dholbert> flackr: I feel like we'd be more likely to do what the dev expects, if the API was specifically "scroll by a page"<br> <dholbert> fantasai: I guess then we have 2 resolutions?<br> <dholbert> fantasai: (1) pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area<br> <dholbert> PROPOSED RESOLUTION: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area<br> <dholbert> RESOLVED: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area<br> <dholbert> fantasai: (2) we want to add some kind of scroll-by-page type API, to be sketched out by flackr<br> <dholbert> flackr: I can sketch that out<br> <dholbert> Rossen6: no need to resolve on that now<br> <fantasai> ACTION: flackr to sketch out a scroll-by-page API<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10914#issuecomment-2380139977 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 21:53:39 UTC