Indeed, developer sentiment is full of excitement! Who wouldn't want to throw out their hyper intersection observers with a perfectly timed callback? or even better, getting insights into the concept of "changing" which is currently opaque to authors.
> Philip: For the scrollsnapchange event it's easy to imagine updating some state below a carousel to match the snapped element, such as item description or store inventory. For scrollsnapchanging I don't dare hazard a guess, can someone say what the canonical use case for this is? I think you'll find that snapchanging is very prominent in mobile gesture based UI and may be used even more than snapchange. Like one of those features you can't unsee once you see it working. Consider this video I took of a game on mobile <https://photos.google.com/photo/AF1QipO6HUraOd43T9e7lPU4yXHOFX92r15vCX39DRAQ>, snapchanging and snapchanged are distinctly used for 2 separate moments of UI feedback. I have many examples like this! The examples are what led to the APIs. Another really common example will be revealing the caption or action buttons in a carousel. Which it's probably worth noting we're working on a CSS way to know some of this information too, we're prototyping snapped as a "state query." Here's a few demo's showing some "picker" use cases, which I feel will be the majority cases, where folks are observing the snapped or soon to be snapped item and updating ancillary UI for the user. I have a backlog of many more to make 😅 Think of these things like snap triggered animation, which can be a very healthily compliment to scroll driven animation (which currently doesn't have a "trigger" feature, only linked). I bucket the 2 events like: - the *scrollsnapchanging* event is eager to provide user feedback, can fire many more times than change - while *scrollsnapchange* is great for user feedback after they've lifted their finger or scroll has ended, timed better for confirmation or whatever. I show an example below that I use change instead of changing so the animation trigger isn't too busy. *Color picker*: https://codepen.io/argyleink/pen/zYXdgew *Date time picker (both eager and timed):* https://codepen.io/argyleink/pen/WNageoZ *Date time picker (eager):* https://codepen.io/argyleink/pen/oNOWwKq *Date time picker (timed for view transitions):* https://codepen.io/argyleink/pen/LYvzGRW > Regarding origin trials: I havent met a front-end dev who's been interested in an origin trial, but fullstack or backend devs needing a high impact business feature (like a fugu feature) do. We didn't do an origin trial for scrollend <https://developer.chrome.com/blog/scrollend-a-new-javascript-event>, and that felt like the right path forward. Feels like these 2 events are in a similar bucket as scrollend. Let me know how else I can help! On Wed, Jun 5, 2024 at 7:40 PM Alex Russell <slightly...@chromium.org> wrote: > Thanks for the link, Phillip. Absolutely agree that this is an unmet need > and something we should have added long ago; I'd just like to see evidence > that we're matching that need with a sufficient solution and that we've > done our homework. There's almost nothing worse than getting to the end of > a launch and realizing that some important use-cases isn't covered, and I > don't have confidence based on what we've produced that we would not end up > in this situation. > > An exhaustive explainer with considered alternatives and sample code would > unblock this from my end. > > Best, > > Alex > > On Wednesday, June 5, 2024 at 9:48:48 AM UTC-7 David Awogbemila wrote: > >> >>>>>> Hi Alex, thanks for yout input! >>>>>> >>>>>> (Like Tab said, we’re planning to have a review of the feature as a >>>>>> whole so I plan to share any feedback from that here, but since that >>>>>> won’t >>>>>> happen for at least another week, I wanted to update this thread in the >>>>>> meantime.) >>>>>> >>>>>> I'm now hosting the explainer >>>>>> <https://github.com/DavMila/ScrollSnapExplainers/tree/update/js-snapChanged> >>>>>> and I've updated it to reflect the research and investigation which went >>>>>> into the API design (which I certainly should have done earlier). We've >>>>>> discussed all of the non-trivial decisions made for the API over many >>>>>> CSSWG >>>>>> issues >>>>>> <https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-scroll-snap-2+>. >>>>>> The API choices reflect the minimum amount of information that meets the >>>>>> needs of use cases we have evidence >>>>>> <https://github.com/DavMila/ScrollSnapExplainers/tree/update/js-snapChanged#interest-in-snap-events> >>>>>> of interest in: the element that was selected as the snap target, and >>>>>> deferred adding other bits of information for which we don't have quite >>>>>> as >>>>>> much evidence. We think that an origin trial might bring to light other >>>>>> things that could be added to the interface but is not likely to provide >>>>>> more information about the single data point we've currently put in the >>>>>> interface (the selected element, which satisfies most of the use cases we >>>>>> are aware of) so we thought not blocking that piece on an origin trial >>>>>> might be a good idea. Happy to hear further thoughts. >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEZW8QGW%2BY1oRLHOEAOKpbQhZBjNCLdRJWeT6jF8uwtBQw1niw%40mail.gmail.com.
