- From: Nick Coury via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 May 2023 02:42:50 +0000
- To: public-css-archive@w3.org
This is extremely useful, and hope it is able to land in some form! Some feedback based on the explainer: ## Swipe Types Not all swipe navigations are edge swipes. Specifically, UC Browser uses whole-page swipes for navigation as long as the element being touched doesn't have room to scroll, and doesn't prevent default. ## Opt-in vs out Opt-out seems like the preferred behavior. Most users already expect UA transitions to be available, and disabling them by default will unnecessarily remove a useful gesture from much of the web. ## CSS vs JavaScript API I am curious if a JavaScript API has been considered yet. It might be a more natural fit for the swipe case, with simpler semantics. For example: - For atomic navigations, the disable flag could be provided as part of the Navigation API, particularly in `intercept()` where similar transition handling customizations occur. - Since swipe navigations require touch events, it might be as simple as providing a reliable way to preventDefault on touch events. An advantage of this is it can still (mostly) work with older browsers with the same code, even if more unreliable. It also would eliminate needing a specific way to disable swipe transitions - they would be avoided via preventDefault which is already a common paradigm for disabling UA handling of events. - An API could provide extra guidance on the touch regions or a pseudo-element that can be used to trap touch events. Separate areas/elements could be provided for back/forward element swipes making it especially easy to handle those cases. This provides more flexibility around how to disable UA animations, even when their implementations vary wildly. - The other organizational advantage of this over CSS is that it groups the logic deciding to disable UA transitions with the code providing the user benefit (transition animations + gesture logic). A few other thoughts: - Is there a greater story where the CSS API is superior to JS, e.g. as part of interop with View Transitions? I believe it would still require JavaScript, so it could still be more natural to determine UA transition cancelling in the same place as `startViewTransition()`. Showing how it fits with VT API could be useful, as I imagine there's thoughts behind it complementing cross-document navigations where JavaScript doesn't apply as easily. - I'm not aware of any atomic default browser transitions, though it's easy enough to imagine them. Addressing that separately future proofs this, but if there are examples available I would be curious. ## hasUAVisualTransition On the JavaScript proposal for detecting hasUAVisualTransition, the mechanic seems in line with what I would expect. One possible enhancement is some sort of [paint holding](https://developer.chrome.com/blog/paint-holding/). In the ideal case this wouldn't be necessary and developers would immediately update to the end state of the transition without a user-visible flash. But depending on the website architecture, it's still possible for the predictive snapshot behind the swipe to show, then the live state of the site to show, then the desired end state to render (possibly progressively over multiple frames). There might be a reasonable mechanic to expose in the View Transition API, but it would be nice to have a similar mechanism even if developers do not use it. There still would likely be a hard timeout after which painting resumes regardless, but providing a short time window for a site to update rendering will reduce disorienting flashes in line with the overall goal of this proposal. E.g. ``` navigation.addEventListener("navigate", (event) => { if (event.hasUAVisualTransition) event.holdPaintUntil(new Promise(resolve => { updateDOM(event).then(resolve); }); else updateDOMWithVisualTransition(event); }); ``` -- GitHub Notification of comment by nickcoury Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8747#issuecomment-1532392951 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 May 2023 02:42:52 UTC