- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 17:08:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Overscroll observability`. <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: Overscroll observability<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/4011<br> <heycam> smfr: the issue here is whether web content should be able to observe when the user is rubber banding<br> <heycam> ... when you reach the scroll extent of the scroll bar, and you pull down some more<br> <heycam> ... on Apple platforms we have rubber banding. on Android you et some overscroll affordance<br> <heycam> ... on Apple platforms we continue to send scroll events, and those have negative offsets if you're at the top/left<br> <heycam> ... or great than max offsets at bottom/right<br> <heycam> ... we found that this is not very web compatible, a bit of web content doesn't expect negative offsets<br> <heycam> ... listening to scroll events, taking those scroll positions as input to some math<br> <heycam> ... CodeMirror does this, the line numbers will jiggle around in weird ways<br> <heycam> ... so I'm considering making the rubber banding scroll offsets clamp to 0<br> <heycam> ... that then implies authors canont detect when that is happneing<br> <heycam> ... should there be a different event that gets fired during overscrolling?<br> <heycam> ... I saw jonjon linked to a proposal<br> <heycam> ... I'd like to get feedback from other browser vendors<br> <bokan> q+<br> <heycam> smfr: common desire for authors would be to have a pull to refresh<br> <heycam> ... it's possible I might break that when clamping to 0<br> <heycam> bokan: we at Chrome are very supportive of this<br> <heycam> ... an overscroll event?<br> <smfr> https://github.com/w3c/csswg-drafts/issues/3801<br> <heycam> smfr: we're supportive of that. we've seen this as well, implement pull to refresh is difficult<br> <heycam> ... pages want to know when you're reaching the end of the scroll, maybe adding a transform to start bringing in another view<br> <Rossen_> q?<br> <Rossen_> ack bokan<br> <heycam> AmeliaBR: so this would mean, having a separate event -- the scroll event would never give you overscroll results, never give you negative offsets or larger than max<br> <heycam> ... and then this custom overscroll event would start firing instead?<br> <heycam> ... also means author could listen to overscroll without listening to scroll<br> <heycam> ... so they could handle pull to refresh even if they don't care about regular scrolling<br> <heycam> ... so smfr your only concern is that web apps might be currently listening to negative scroll offsets, when whta they really want is overscroll events?<br> <heycam> smfr: yes<br> <heycam> ... there is one somewhat tricky thing here which is if the user built up enough momentum when scrolling, and the scroller hits the end, it will rubber band<br> <heycam> ... so the overscroll events probably need to contain enough info to know the user has the finger down<br> <heycam> myles_: an additional benefit, a website might not care where you are in the content, but do care about overscroll<br> <heycam> ... distinguishing the types lets you do that<br> <heycam> heycam: especially since scroll events are bad for perf?<br> <heycam> mstange: scroll events themselves are fine because they fire async<br> <heycam> ... wheel events are bad for perf, but that's only on desktop<br> <heycam> smfr: wheel events and touch events are input to scrolling, scroll events are reactive to scroll<br> <heycam> mstange: I support the addition of scroll events, having a distinction is good<br> <heycam> smfr: the CSSOM View spec is the one that talks about scroll events<br> <bkardell_> +1<br> <heycam> ... would it fit into that spec?<br> <heycam> emilio: probably, but do you want to edit that spec? there's no editor<br> <heycam> smfr: not particularly<br> <heycam> Rossen_: you might have to<br> <heycam> smfr: I'd be willing to write text for this specific thing<br> <bkardell_> heycam: do these just send negative positions or ...?<br> <bradk> If the negative offsets are going away, can they have a deprecation warning in the console for a while first? So, some overlap of having both that and the new overscroll events for a while?<br> <bkardell_> smfr: on some platforms there is not concept of a real negative positions values here<br> <AmeliaBR> The WICG repo for Overscroll & Scrollend events: https://github.com/NavidZ/overscroll-scrollend-events<br> <bkardell_> heycam: I am kind of wondering if we should not be asking authors to do the math to figure out these things based on positions - like when does it 'indicate'<br> <AmeliaBR> s/WICG//<br> <bkardell_> heycam: maybe we should just have events when that happens<br> <bkardell_> smfr: the simpler thing is that we just do that, the more complex is that we give them discrete values<br> <heycam> bokan: I think the pull to refresh is just one case<br> <heycam> ... you have a carousel article, horizotnlaly scrolling and when you reach the end you do an animated transition<br> <heycam> ... having a predefined animation owuld be more limiting<br> <heycam> smfr: I think I agree<br> <heycam> majidvp: I just want to point out that this matches nicely with overscroll-behavior property<br> <heycam> ... the author will use that property to prevent chaining, or the overscroll action triggering the native overscroll behavior<br> <heycam> ... and declaratively you prevent the default action<br> <heycam> ... then you use overscroll events to customize, create the animation that responds to user input without having to add any sort of blocking events, I think that allows you to do this without being main thread bound<br> <heycam> smfr: that sounds good<br> <heycam> mstange: do we already have a spec with overscroll events with delta fields?<br> <smfr> https://navidz.github.io/overscroll-scrollend-events/<br> <heycam> majidvp: this is in incubation. proposed in WICG<br> <heycam> ... they are looking for feedback<br> <heycam> ... whether you need the deltas, or maybe just the sum of the deltas, they'd like feedback on that<br> <heycam> ... there's also scrollend event<br> <NavidZ_> It is not yet in incubation. I would love more support to move the repo under WICG. So please comment on the discourse.<br> <heycam> mstange: is there also a way to tell -- let's say fingers down, get into overscroll, then release<br> <heycam> ... and you're still in the overscroll state for a while after lifting the finger<br> <heycam> bokan: not sure if it's patr of the same proposal, but there was an event called scrollend when the scroll gesture finishes<br> <heycam> ... that would be for this case<br> <NavidZ_> There has been some concerns for example regarding the reversal of scroll in UAs but I think we can iterate on those and add more css attributes to control those as well<br> <heycam> mstange: so scroll event wouldn't be separation of scroll and overscroll<br> <heycam> bokan: it could come between either, but all at the end<br> <heycam> ... it's when the finger is lifted<br> <heycam> ... if you're rubber banding, the proposal here would be "you're no longer scrolling"<br> <heycam> smfr: there's a period where the scroll view is animating back from negative position to 0<br> <heycam> ... when do you fire scrollend, and do you fire overscroll events for that automatic animation<br> <heycam> bokan: smfr you said you found negative scroll was not web compat?<br> <heycam> smfr: but if you turn those into overscroll events for that settling period, that's fine<br> <heycam> ... but I think we may need to add data to the overscroll event to say if the finger is down<br> <heycam> bokan: I don't think we're set on one shape of the API, but it is important to know when the user has lifted their finger<br> <heycam> mstange: there are a bunch of different questions here, don't know which we need to discuss now<br> <heycam> ... one more quesiton. the idea is scrollTop will reflect out of range values?<br> <heycam> smfr: having scrollTop reflect negative values is one of the big parts that's not web compat<br> <heycam> ... so it would need to be clamped to zero<br> <heycam> mstange: in the overscroll events we'd carry the correct information, maybe the relative update since the last event and the current absolute position?<br> <heycam> ... you need the aboslute position e.g. to update your parallax background<br> <heycam> ... I've seen cases maybe int he Apple Maps app, if you open a panel on the point of interest, you can scroll in the panel, and it does something parallaxy in the header imgae<br> <heycam> ... it wants to know the scrollTop<br> <heycam> smfr: I think that's probably necessary<br> <heycam> ... we should start opening issues on the overscroll spec<br> <heycam> ... and go from there<br> <heycam> mstange: sounds good<br> <heycam> bokan: there's a WICG thread about this, please chimein<br> <bokan> WICG thread: https://discourse.wicg.io/t/proposal-new-events-for-overscroll-and-scrollend/3481/16<br> <heycam> AmeliaBR: smfr did you want a resolutoin on your original issue about the scroll events and negative offsets? or are you going to wait on resolve that until overscroll events are more clearly defined<br> <heycam> smfr: the CSSOM View spec currently doesn't say anything about overscroll<br> <heycam> ... better to leave it that way until we have the rest of the stuff in a well defined state<br> <heycam> Rossen_: that's a good way<br> <heycam> ... plus when we have the WICG repo we can filing more issues there<br> <heycam> mstange: if we start clamping scrollTop, do we clamp other things like<br> <heycam> ... like getBoundingClientRect in the middle of overscroll state<br> <heycam> ... we can discuss those in that other location<br> <heycam> -- lunch time --<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4011#issuecomment-499584228 using your GitHub account
Received on Thursday, 6 June 2019 17:08:47 UTC