- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Feb 2022 17:29:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `proposing :snapped`, and agreed to the following: * `RESOLVED: Start Scroll Snap 2 ED, with :snapped and snapping event model, with Adam Argyle as additional editor` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: proposing :snapped<br> <TabAtkins> GitHub: https://github.com/w3c/csswg-drafts/issues/6985<br> <TabAtkins> argyle: Explainer in the issue<br> <TabAtkins> argyle: Hacks and intense work with IntersectionObserver to figur eout what element is snapped to.<br> <TabAtkins> argyle: Especially with snapping being a 2-d thing, where it can be snapped to two elements<br> <TabAtkins> argyle: And multiple elements could overlap, any of which could be the snappee<br> <bkardell_> present +<br> <TabAtkins> argyle: This proposal attempts to deal with layout-dependency issues<br> <TabAtkins> argyle: And lets the user know if there is a snapped element<br> <TabAtkins> argyle: Biggest gotcha is that if you have a scroller that's shrinkwrapped so items don't have padding, not every item might be snappable<br> <TabAtkins> argyle: So this isn't necessarily useful for selection<br> <TabAtkins> argyle: Example, header tabs in a scroller, and whichever is snapped to determines the contents of the tab<br> <TabAtkins> argyle: Right now people go to JS that does synthetic scrolling and snapping to do things like this<br> <TabAtkins> argyle: So this brings the functionality into CSS.<br> <TabAtkins> argyle: The explainer addresses the previous issue; using scroll-padding can enable all elements to be snapped<br> <TabAtkins> argyle: Second biggest issue is avoiding the :hover issue, where something can "jiggle" matching<br> <TabAtkins> argyle: CSS has "loose" and "tight" loops, whether it goes out to user interaction or cycles within the style engine<br> <TabAtkins> argyle: The epxlainer defines how to have :snapped be a loose loop like :hover, once per frame<br> <TabAtkins> argyle: And it would only be able to infinite-loop during user interaction; it wouldn't be able to jiggle on its own while the page is at rest<br> <florian> q+<br> <TabAtkins> argyle: So devs *could* apply styles to make something snap/unsnap rapidly while the user is interacting, but that's it, and it shoudl hopefully be very obvious<br> <flackr> q+<br> <smfr> q+<br> <TabAtkins> argyle: So our hope is that we can take the good success of :hover and apply it over to :snapped, letting users do snapping control without JS.<br> <TabAtkins> argyle: Maybe flackr or TabAtkins can talk about the loop prevention.<br> <astearns> ack florian<br> <astearns> q+<br> <TabAtkins> florian: I'm convinced there's a giant use-case. Not too worried about the first problem, about things not being reachable by snapping.<br> <TabAtkins> florian: Am bothered by the second situation. In proximity it's fine, but in mandatory i'm a little concerned...<br> <TabAtkins> florian: I've not yet convinced myself you can apply the :hover workaround while maintaining the invariant of mandatory snapping.<br> <TabAtkins> florian: That is, that while restyling you must resnap.<br> <TabAtkins> florian: You can probably limit it to once per frame, but you'd have jiggling at rest, or you'd violate the mandatory requirement and not be snapped at some times.<br> <TabAtkins> florian: So my quesiton is if we *need* to solve the problem this way? Would it be simpler to have snapping events that fire when snapping to something?<br> <TabAtkins> florian: You'd still have loops if your JS did silly things, but that's much wider.<br> <fantasai> +1 to JS events<br> <argyle> https://github.com/argyleink/ScrollSnapExplainers<br> <astearns> q- (was going to ask about events)<br> <TabAtkins> argyle: Some JS events talked about in the explainer; those are part of the proposal. snapped, spanchange, and snapTo() function<br> <astearns> q-<br> <TabAtkins> argyle: So yeah, JS definitely important.<br> <fantasai> That issue's been open for awhile and needs help https://github.com/w3c/csswg-drafts/issues/156<br> <TabAtkins> s/snapped, spanchange/snapChanged, snapChanging events/<br> <TabAtkins> argyle: "changing" triggered when you've passed a threshold to start switching to a new snap target<br> <TabAtkins> florian: My question is if it's *sufficient* to have events, rather than just the pseudo?<br> <TabAtkins> argyle: There's a lot of cases where the CSS visual feedback is justa s important to JS knowing the snapped items.<br> <TabAtkins> argyle: I've got an example that adds a huge gap for one frame to detect the snappee... the timing isn't right. We're trying to give CSS visibility into the inner state.<br> <TabAtkins> argyle: I don't think we could use just a JS solution. But I do think there's a competetive proposal in Style Queries.<br> <TabAtkins> argyle: So style queries might bea ble to pacify this use-case.<br> <TabAtkins> (I don't think they could; snapping isn't exposed in CSS state except via side-channels of properties being applied.)<br> <astearns> ack flackr<br> <florian> q+ to comment on the limits of similarity with hover<br> <TabAtkins> flackr: I think we have similar problems with :hover, and :hover state doesn't update until you move your cursor, we could do a similar thing for :snapped, so even if snap changes we wouldn't update the :snapped until user input occurs<br> <TabAtkins> flackr: We think in most cases devs wouldn't create these cycles, because they usually don't with :hover<br> <TabAtkins> flackr: We'll have to make sure we have the same snapped element, that does get tricky.<br> <TabAtkins> flackr: I think there are some cases that - say you have snapping in both directions, you probably want the element snapped in both directions to get the pseudo rather than first in dom order, there's some tricky cases we'll need ot make sure of<br> <astearns> ack smfr<br> <TabAtkins> smfr: Your primary reasons to want sounded like something appropriate for script - knowing what element was selected.<br> <TabAtkins> smfr: Wonder if you considered exposing on the scroller itself a list of snapped elements.<br> <TabAtkins> smfr: Like .scrollLeft, etc, could have .snappedElements<br> <TabAtkins> smfr: Woudl change on scroll events<br> <TabAtkins> argyle: Like that idea, kinda goes with the scrollTo() options for snapping<br> <TabAtkins> argyle: JS should be able to get the list of snappable children. Sounds like a good idea<br> <astearns> ack florian<br> <Zakim> florian, you wanted to comment on the limits of similarity with hover<br> <TabAtkins> florian: There is indeed a similar to :hover when we talka bout proximity.<br> <TabAtkins> florian: But there is not in proximity a strong expectation you're always snapped to something. If we break a loop, that's fine.<br> <TabAtkins> florian: With mandatory you're required to always be snapped to something. Always - authors can depend on this.<br> <TabAtkins> florian: There's never an unsnapped state.<br> <TabAtkins> q+ to respond to florian<br> <flackr> q+ to respond to florian<br> <TabAtkins> florian: Not just scrolling can trigger this, restyling or animation can change the position of the snapped element.<br> <TabAtkins> florian: If we have a clean way to make this continue being true, great<br> <TabAtkins> florian: But I don't see a sufficient explanation in the explainer to be clear on this.<br> <TabAtkins> florian: If it's impossible, oh well, we'll figure it out. Worry is that it's possible, just very hard to do and maybe non-interoperable so the invariant is broken in different ways<br> <argyle> looks like as part of the event data on the js events snapChanged and snapChanging, i've added snappedList and snappedTargetsList which provide arrays of snap children on axes https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanged#:~:text=SnapEvent.snappedList. i do still think there's room for a generic api into this tho!<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to react to florian<br> <TabAtkins> flackr: I think the first proposal I presented does let you maintain mandatory snapping<br> <TabAtkins> flackr: Your snapped state changes the style, which might cause you to snap to another target, but your :snapped won't reflect that until the next frame<br> <fantasai> TabAtkins: Underneath the cover, smandatory snapping invariant is maintained, but not seen on every frame<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to point at issue #156<br> <astearns> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to respond to florian<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to respond to florian<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/156<br> <TabAtkins> fantasai: Wanted to point people to discussion about even tmodel, been open for a long time<br> <TabAtkins> fantasai: I think this pseudo-class would be great, and event model should be avaible at the same time or before the pseudo.<br> <TabAtkins> astearns: Agree, not against the pseudo, but think the events are the more important thing<br> <argyle> event `snapChanging` https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanging<br> <TabAtkins> astearns: Could even wait on the pseudo until we notice the events are often being used to add a class<br> <argyle> event `snapChanged` https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanged<br> <TabAtkins> fantasai: I'd also like to see the situation with mandatory snapping and overlarge elements fixed first; it makes content inaccessible if done wrong.<br> <TabAtkins> astearns: Any other comments? Concerns?<br> <TabAtkins> astearns: So it sounds like you have a lot of feedback.<br> <TabAtkins> argyle: The events should be well-defined, but I haven't taken up WG time yet. ARe they appropriate here?<br> <TabAtkins> fantasai: Yes, they'll be specced in this group.<br> <TabAtkins> fantasai: Probably in Scroll Snap 2.<br> <fantasai> TabAtkins: Sounded like ppl interested in adding to Scroll Snap 2, should we resolve to start that spec with this in it?<br> <TabAtkins> astearns: Any objections?<br> <TabAtkins> fantasai: We shoudl resolve to start an ED and include both :snapped and the events<br> <TabAtkins> florian: If there's a different event model drafted in an issue, shoudl probably decide<br> <TabAtkins> fantasai: Can put both in for now and figure it out<br> <TabAtkins> astearns: So proposal is to have Scroll Snap 2 ED with pseudo-class and event models, with Adam as editor?<br> <TabAtkins> florian: think we should have both so it doesn't get frozen in without discussion<br> <TabAtkins> argyle: I'll be checking soon how the two proposals compare<br> <TabAtkins> astearns: Objections? Anyone need more time?<br> <TabAtkins> RESOLVED: Start Scroll Snap 2 ED, with :snapped and snapping event model, with Adam Argyle as additional editor<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6985#issuecomment-1049029573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 February 2022 17:29:38 UTC