- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 Nov 2017 17:50:48 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Interaction of scroll-snap and JS scrolling APIs`, and agreed to the following resolutions: * `RESOLVED: When using SIV you should take scroll snap margin into account` * `RESOLVED: SIV must use the element position if it has one and snapping is on` * `RESOLVED: Implementation may use the snap position if snapping is off` <details><summary>The full IRC log of that discussion</summary> <gregwhitworth> Topic: Interaction of scroll-snap and JS scrolling APIs<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1707<br> <leaverou> TabAtkins: A bit late but bullet is not clipped in Chrome in your example, it just inserts a line, see here: http://dabblet.com/gist/07b894c9f6c1bbc3237c422172d0e5b9<br> <gregwhitworth> TabAtkins: the scroll snap spec defines that if you do a fragment nav and it defines margin or something, you should pay attention to those<br> <gregwhitworth> TabAtkins: it doesn't have any guidance on similar scrollIntoView APIs rather than just target scrolling<br> <gregwhitworth> TabAtkins: we have the API opt into that<br> <gregwhitworth> TabAtkins: the API has other properties of its own<br> <Rossen> leaverou, add the <ul><br> <gregwhitworth> florian: when you say some properties what are those<br> <gregwhitworth> fantasai: the things we were consider the scroll snap margin that's the indication that there should be additional space<br> <leaverou> Rossen: oops, added. Same result.<br> <gregwhitworth> fantasai: if it has a snap position that's an indication that you should snap that position<br> <Rossen> leaverou, there is a bullet, right?<br> <leaverou> Rossen: yes. Tab said there wouldn't be.<br> <gregwhitworth> fantasai: the third thing, the UA could opt into using the snap position even if snapping is not turned on because the UA is trying to determine this and they may utilize this info from the author for the best end user behavior<br> <Rossen> leaverou: good, we have interop then :)<br> <gregwhitworth> astearns: it's a bit vague, but you're going for a must to consider the padding and positioning<br> <gregwhitworth> smfr: if it an element is in scrolled to it but look at it's container's scroll margin?<br> <gregwhitworth> fantasai: usually you're looking at the border box for SIV and it will then take scroll margin into account<br> <gregwhitworth> florian: the other aspect about snap position, if snapping is not turned on but it has position you may use that to position<br> <gregwhitworth> smfr: would you only look at the targeted item or the ancestor chain?<br> <gregwhitworth> fantasai: just the one that's being targeted<br> <gregwhitworth> smfr: it seems weird that your taking a property that's meant solely for scroll snapping and you're adding it to the SIV<br> <gregwhitworth> fantasai: this is adding author intent to the SIV<br> <gregwhitworth> smfr: you could add props to SIV<br> <gregwhitworth> fantasai: this makes it so that you don't have to track it all though<br> <astearns> q?<br> <gregwhitworth> smfr: is the UA allowed to override scroll snap margins?<br> <gregwhitworth> florian: is it implied that we should take scroll padding?<br> <gregwhitworth> fantasai: yes<br> <gregwhitworth> florian: I recall doing it in general, but wasn't aware we did it for this API<br> <gregwhitworth> fantasai: that was intentional, you shouldn't be able to get in a state in JS that you can't get to as a user<br> <gregwhitworth> astearns: the two of you smfr and Rossen showed some concern<br> <gregwhitworth> myles: we have to make sure that websites that turn off scroll snapping, with this change the margin will now have effect<br> <gregwhitworth> fantasai: usually this will get you a better experience<br> <gregwhitworth> myles: I'll be for implementing this and seeing if this has a web compat issue<br> <gregwhitworth> fantasai: I don't think we should have a web compat issue<br> <gregwhitworth> myles: I think we can resolve on this<br> <gregwhitworth> astearns: I'm hearing some movement to resolving<br> <gregwhitworth> astearns: anyone object?<br> <gregwhitworth> RESOLVED: When using SIV you should take scroll snap margin into account<br> <fantasai> scroll-into-view must use element's snap position if it has one and snapping is on<br> <gregwhitworth> RESOLVED: SIV must use the element position if it has one and snapping is on<br> <gregwhitworth> RESOLVED: Implementation may use the snap position if snapping is off<br> <gregwhitworth> florian: should this change intersection observer?<br> <gregwhitworth> TabAtkins: I don't think we should bring this in?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1707#issuecomment-342565591 using your GitHub account
Received on Tuesday, 7 November 2017 17:50:56 UTC