WICG / user-gesture-nav

API to control user gesture navigations (swipe to navigate, pull-to-refresh)
http://wicg.github.io/user-gesture-nav
4 stars 4 forks source link

Multiple value syntax for CSS? #2

Open chuckhacker opened 7 years ago

chuckhacker commented 7 years ago

This spec is a little confusing to me: overscroll-action: [auto || [no-navigation-x | no-navigation-y]]

I'm trying to prevent navigation via swipe gestures in both the x (i.e. back/forward) and y (i.e. refresh) directions.

The single-pipe OR operator (|) suggests that I can set both no-navigation-x and no-navigation-y simultaneously, given I'm not setting auto. How can I specify both together in real CSS code? Can you please give me an example snippet of CSS code that sets both values at the same time? Pardon my ignorance, but I haven't ever seen multiple value syntax like this in CSS before...

Also, is there an ETA for when browsers will actually support this? Does Chrome already support it?

I've built a really customized touch-heavy page for my educational web project on Chromebooks with touch screens, and my users are young 6 to 8 year-old children who have continually inadvertently refreshed or navigated away from the page by accidentally triggering overscroll actions during our testing because they lack the fine motor skills to avoid them (in fact, even I've accidentally triggered them as a 27 year-old!).

It's a really poor user experience for the kids, and it just ends up frustrating everyone whenever it happens (it happens 2-3 times per hour!) so I just want to disable these built-in swipe actions all together.

Thank you so much for your help! :-)

majido commented 7 years ago

Ahh, the grammar should actually be overscroll-action: [auto | [no-navigation-x || no-navigation-y]] Double bar || means that one or more of the options could occur in any order. So for example these are all valid:

Also, is there an ETA for when browsers will actually support this? Does Chrome already support it?

No ETA but we are working on this "functionality" in Chrome. However we have decided to abandon this proposed syntax in favor of scroll-boundary-behavior API (proposal, draft spec) which can address the same usecase in a simpler and more generic fashion.

It's a really poor user experience for the kids, and it just ends up frustrating everyone whenever it happens (it happens 2-3 times per hour!) so I just want to disable these built-in swipe actions all together.

I completely understand the pain. Hopefully once we ship the API this is easily fixed but in the meantime, you may be able to use some of the workarounds listed here to disable pull-to-refresh. A variants of these may also work for swipe navigations too. Note that using "touch-actions" to do so is preferable over having blocking touch event handlers as it does not regress threaded scrolling.

majido commented 7 years ago

BTW this is the bug to track for scroll-boundary-behavior in Chromium.