- From: Rick Byers <rbyers@chromium.org>
- Date: Mon, 27 Apr 2015 16:56:03 -0400
- To: "www-dom@w3.org" <www-dom@w3.org>
- Cc: Jared Duke <jdduke@chromium.org>
- Message-ID: <CAFUtAY-oWnGhbax7U5gypn6y=F1nPadm+O0QX7gNvN2WzoUt9g@mail.gmail.com>
Hi, Chrome on Android now has built-in "pull to refresh" UI <https://docs.google.com/document/d/12Ay4s3NWake8Qd6xQeGiYimGJ_gCe0UMDZKwP9Ni4m8/edit> designed to make it easy to refresh the current page (when there isn't space for a dedicated top-level reload button). This UI decision is controversial, but I'm not involved in that part so I'd prefer to take that as a given for this thread. Given that such UI exists, I feel it really should be extensible <https://code.google.com/p/chromium/issues/detail?id=465423>. "Pull to refresh" has a softer update expectation than a hard "reload" button. For many sites the default 'refresh' action should be smarter than page reload. So far our guidance has been to disable/override our UI (eg. consuming the touch events, or disabling document scrolling) and replace it with your own. In fact sites with existing pull-to-refresh UI (eg. twitter.com) already do that and so weren't affected by the introduction of the feature in Chrome. However it's not unreasonable for a site to want to depend on a browser's built-in refresh UI (eg. for consistency). So I propose adding a new simple UI event: Type: refresh Interface: UIEvent Sync / Async: Sync Bubbles: No Cancelable: Yes Default Action: reload the page It would of course be up to the user agent to decide what UI (if any) triggers this "refresh" behavior versus a non-interceptable "reload". For Chrome, I suspect we wouldn't wire up the reload button to this (at least not right away), but perhaps we could for better consistency across platforms (we already have Ctrl-Reload to force a hard reload). Are there any other use cases that might take advantage of such a 'refresh' event? Thanks, Rick
Received on Monday, 27 April 2015 20:56:50 UTC