Profile

Cover photo
Rick Byers
Works at Google
Attended University of Washington
Lives in Waterloo, ON, Canada
838 followers|577,641 views
AboutPostsPhotosYouTubeReviews

Stream

Rick Byers

Shared publicly  - 
 
Chrome 35 beta is out for Android, and it includes a feature I've been working on for awhile: touch-action.  touch-action is a CSS property that controls filtering of gesture events, providing developers with a declarative mechanism to selectively disable touch scrolling (in one or both axes), pinch-zooming or double-tap-zooming.

Benefits include:
1. Provides precise control over the dreaded 300ms click delay on mobile
2. Reliably enables side-swipe UIs (frees libraries from having to predict when exactly scrolling may start on different browsers)
3. Enables high-fidelity polyfills of pointer events (eg. as in Polymer)
4. Provides a declarative signal to blink (and potentially the compositor) about the developers intent wrt. touch input - eg. providing a potential solution the touchstart ACK timeout problem
5. Reducing confusion around the highly-overloaded response to preventDefault on touch events
6. A prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread

Check out the demo page below to see this in action.  It's part of the W3C Pointer Events specification and is already shipping in IE and behind a flag in Firefox.  Unfortunately there's no word on support in mobile Safari (I've asked their touch folks whether they like it but gotten no response).
6
Norman Robinson's profile photoTaylor Wickens's profile photoDoug Simmons's profile photoRick Byers's profile photo
5 comments
 
Seems I could spend all day fiddling in chrome://flags...
Add a comment...
 
I'm glad we blinked!
 
Amazing how much we've accomplished in one year.  Happy Birthday Blink.
3
Add a comment...

Rick Byers

Shared publicly  - 
 #UI
 
A nice summary of what makes a good touch UI effect.
2
1
fabrice piedanna's profile photo
Add a comment...

Rick Byers

Shared publicly  - 
 
I'd love to hear if people prefer my "disable click delay" flag enabled. Personally I find the speedier response worth the hassle of having to avoid links when I double tap. But it doesn't seem like we could really enable this by default.
 
By now we all know that in M32 Chrome for Android remove the 300ms delay when a sets the viewport to width=device-width.

300ms tap delay, gone away - HTML5Rocks Updates
http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

But I didn't know that the Chrome team had also landed a flag to disable the 300ms delay on all pages including desktop oriented websites, which in my case are most ones I see :(

[chrome] Revision 230183
https://src.chromium.org/viewvc/chrome?revision=230183&view=revision

Go to chrome://flags#disable-click-delay and enable the flag, the experience feels nicer. The downside is that it now is harder to double-tap to zoom on a page packed with links. But you are still able to use pinch to zoom. Sweet!

Btw, “Enable” to “Disable ~~” look really failed labels :p
2
Add a comment...
 
Yay, no more click delay on mobile optimized sites in Chrome! Additionally I've added a flag that can be used to disable the click delay on desktop sites too. The down side is that you will accidentally navigate if you try to double-tap zoom on top of a link. Try it out at chrome://flags/#disable-click-delay and tell me what you think.
 
300ms tap delay is history (on Chrome 32 for Android): http://bit.ly/1c1plSe - that's 300ms saved on every interaction! Needless to say, this is a huge win and a nice way to cap off 2013! 
11
Add a comment...
Have him in circles
838 people
Alan Paulin's profile photo
Ryan Fioravanti's profile photo

Rick Byers

Shared publicly  - 
 
How big of a catastrophe will it take to convince us to start writing security critical code in a typesafe language that is immune to mundane buffer bugs? I mean if we're STILL making dumb mistakes like this with incalculable damage after all that we've learned, we must be doing something horribly wrong.
8
Michal Mocny's profile photoJames Mason's profile photo
2 comments
 
Can't +1 hard enough.
Add a comment...

Rick Byers

Shared publicly  - 
 
Well said. Be sure to also read +Jon Rimmer's response in the comments. Both approaches are crucial to the success of the web in my opinion.
 
I'd like to soapbox about the need for rationality in the web platform, using position:sticky as a guinea-pig to explain my perspective.

The thing that bugs me about position:sticky is that is entangled with the magical nature of scrolling on the web. Per spec, the browser can scroll the page up and down without telling JS: you get a scroll event, but it happens after the scroll has actually happened.

Wat.

Here's the thing: this ability in browsers is super important, because scrolling is super duper important to get right for users. Without it, going to espn.com and scrolling is a really horrible user experience. On mobile, that poor site janks for a half second while it loads. I NEED MY SPORTS SCORES TO SCROLL AT 60FPS. The browser works around this by making scroll asynchronous. A simpler example is this: http://jankfree.org/examples/simple_jank.html : on mobile browsers, this scrolls smoothly, even though in devtools you'll see that the page is a cataclysm of jank.

Unfortunately, we've painted ourselves into a corner here, with regard to position:sticky and all other scroll coupled effects. If you try to polyfill sticky positioning, you get jitter. Typically, the user's scroll is immediately handled by the browser, drawn to the screen as fast as possible so it feels responsive. THEN the browser tells JS about it. The polyfill thus hears about the onscroll too late: it valiantly tries to update the sticky position, but the page has been sent to the screen with the movement already applied, so the user perceives a little jump in the next frame as the polyfill's reaction finally makes it onscreen. Designers get cranky, and you don't get to go to space.

Because of this, we have a promulgation of urgent-for-some spec needs: anytime a user wants a scroll-coupled effect, they need need new spec. That gets scary quickly, because lets face it, there's a ton of cool stuff you an do in response to scroll. We articulated this concern once for snap points, here: http://lists.w3.org/Archives/Public/www-style/2014Feb/0769.html 

Sticky positioning is in this space too. A common misconception is that position:sticky is an easily speccable, ready to go, kind of thing. In reality, there many many many variations on position:sticky-ish behavior out there for every simple use case, so speccing it is all about compromises and generalization. Even if we implement a common form of position:sticky, there will be corner cases we don't implement. Want your element to sing a sea shanty and then shrink to scale(0) as it falls offscreen? Sorry, please wait for Level 2 version, tentatively titled "position: even-more-sticky."

So, what to do?

As some might recall, +Dimitri Glazkov wrote a great essay on our need for a rational web platform a while back (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/4jBAnIVwrt0). In it, he points out that we must first and foremost "explain the magic" behind our browser.

I submit that much of the sticky positioning debacle is fallout from the browser being magical about scroll. First and foremost, in this space, we need to explain the magic to the page: that way when the magic isn't quite right, you can get around it to do things your way.

What form should this particular fix to the magic take? Not sure, yet! Maybe we need to explain browser-side scrolling using some new APIs. Or maybe we need to allow content to opt-out of this magic. +Rick Byers has some much more formed ideas on how this might be done.

Important for me is embracing the idea of layering and accidental magic, recognizing that the lack of layering can take a basic feature request and turn it into a much bigger problem.

Consider: if we had a web that had an opt-out for magical scrolling, then we'd have plenty of content out there today doing position:sticky effects. Sure, there'd be the odd incurably janky page out there that wanted sticky, too. And there'd be people asking for sticky effects to be easier to author.

Both are great feature requests. With the immediate "I CANT IMPLEMENT THIS" fires resolved, we can then work through those goals at a normal and healthy web platform pace.

So, here's to identifying layers in the web platform, and fixing the bugs that cause layering to go wonky. And, here's to picking a subset of the most commonly occurring cases on the web and making those easy (https://code.google.com/p/chromium/issues/detail?id=231752).
3
1
Valery Arkhangorodsky's profile photo
Add a comment...

Rick Byers

Shared publicly  - 
 
There's some good advice around handling touch here.
 
Learn how the Build with Chrome project took a rich, interactive desktop-based web experience for making LEGO® creations, and redesigned it for the mobile web and made it touch-friendly so you can build and explore awesome things anywhere:

http://www.html5rocks.com/en/tutorials/casestudies/buildwithchrome/
1
1
Valery Arkhangorodsky's profile photo
Add a comment...

Rick Byers

Shared publicly  - 
 
This article does a good job of summarizing why I'm excited to work on ChromeOS. At Microsoft I saw the paralyzing effect of complexity. I hope that we'll be able to minimize unnecessary complexity in Chrome for a long time. Its a tough job though - features aren't easily removed from the web platform (eg. see heroic attempts by Adam Barth to remove XSLT support from Blink).
13
2
Maciej Kalisiak's profile photoMatt Dragon's profile photo
Add a comment...

Rick Byers

Shared publicly  - 
 
The first Chrome feature with code from Microsoft OpenTech and Google engineers working together. See http://crbug.com/248918 and http://crbug.com/312926.
 
The maximum number of simultaneous touch contacts supported by a Chrome OS Device is now available in the last Dev Update by enabling the chrome://flags/#enable-experimental-web-platform-features flag.

The value "maxTouchPoints" defined by the W3C Pointer Events¹ Draft would be 10 for a given device with 3 touchscreens, which support 2, 5, and 10 simultaneous touch contacts, respectively. 

For info, it returns 16 on the Chromebook Pixel.

¹ http://www.w3.org/TR/pointerevents/#widl-Navigator-maxTouchPoints

Source: https://codereview.chromium.org/59903023
7
1
Chris Wilson's profile photo
Add a comment...
People
Have him in circles
838 people
Alan Paulin's profile photo
Ryan Fioravanti's profile photo
Work
Occupation
Software Engineer
Employment
  • Google
    Staff Software Engineer, 2010 - present
  • Microsoft
    Software Engineer, 2004 - 2010
  • NeoEdge Networks
    Software Engineer, 2002 - 2004
  • Quack.com
    Intern, 2000 - 2000
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Waterloo, ON, Canada
Previously
Seattle, WA, USA - Toronto, ON, Canada - Sunnyvale, CA, USA - Welland, ON, Canada
Story
Tagline
Software Engineer on Google Chrome and ChromeOS in Waterloo Canada
Introduction
I'm a software engineer at Google on the Chrome team.  I currently lead the team working on touchscreen support in desktop Chrome, for the Chromebook Pixel in particular.  I'm the Google representative in the W3C web events and pointer events working groups advancing web standards for touch input.


Bragging rights
Lead chrome work for the Chromebook Pixel (touch, high-dpi), helped drive new 'Aura' UI in ChromeOS, and drove the design of .NET support for WinRT in Windows 8
Education
  • University of Washington
    Masters of Science - Computer Science / Computational Biology, 2006 - 2009
  • University of Waterloo
    Bachelors of Math - Computer Science, 1997 - 2002
Basic Information
Gender
Male
Relationship
Married
Other names
Richard Byers
Best food in town.
Public - 7 months ago
reviewed 7 months ago
Decent. Ribs good but a little dry. Pretty decent overall.
Public - 7 months ago
reviewed 7 months ago
Fast but very tasty. Good combo dinners.
Public - 8 months ago
reviewed 8 months ago
Great food and very fast.
Public - 8 months ago
reviewed 8 months ago
26 reviews
Map
Map
Map
Public - 7 months ago
reviewed 7 months ago
Fresh, delicious and fast!
Public - 8 months ago
reviewed 8 months ago
Great Lamb and Guiness pie with potatoe croquettes.
Public - 9 months ago
reviewed 9 months ago