LGTM1 This seems like a useful addition, with lots of developer demand. While more detailed explainers would have been helpful, I don't feel it's a blocker atm, as the demos provided helped me understand what we're shipping and how developers will use it.
On Tue, Jun 11, 2024 at 4:46 PM Adam Argyle <arg...@google.com> wrote: > Slightly different strategy to share a public photo > https://photos.app.goo.gl/5vHQ4cecJqHWN7DGA, try this one? 😅 > > On Tue, Jun 11, 2024 at 12:36 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> On Fri, Jun 7, 2024 at 5:47 PM 'Adam Argyle' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> 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> >>> , >>> >> >> It's 404ing for me.. >> >> >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEZW8QGW%2BY1oRLHOEAOKpbQhZBjNCLdRJWeT6jF8uwtBQw1niw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/CAOmohSKwCDrS8c%3DS33mFkqzWP-ntCfn1TUBuuqUDX0MSJei5FQ%40mail.gmail.com.
