Profile

Cover photo
Rick Byers
Works at Google
Attended University of Washington
Lives in Waterloo, ON, Canada
1,096 followers|795,971 views
AboutPostsPhotosYouTubeReviews

Stream

Rick Byers

commented on a video on YouTube.
Shared publicly  - 
 
Interesting. I can't reproduce this. Can you narrow it down to specific devices, versions of Android or versions of Chrome? Can you reproduce in an Android native app? Sounds more like a touchscreen firmware thing to me (noise avoidance algorithms can delay recognition of fast taps).
1
Patrick Lauke's profile photo
 
+Rick Byers ah, so focused on testing web content, that i didn't even consider testing native apps etc. You're absolutely right, this seems to be a system-wide behavior (it's a Nexus 5/Lollipop device). Doing those super-fast taps on browser controls themselves, and really anywhere/in any other apps, has the same subtle delay. So...as you were :)
Add a comment...

Rick Byers

Shared publicly  - 
 
We've heard your feedback loud and clear.  We're restarting efforts to implement Pointer Events in blink.
Contact emails. rbyers@chromium.org, mustaq@chromium.org. Summary. The Pointer Events API is a low-level input API for mouse, touch and stylus introduced by IE. Pointer Events extends the MouseEvent model while offering a replacement for all uses of Mouse and Touch events.
15
7
Peter Kasting's profile photoValery Arkhangorodsky's profile photoAndrii Trybynenko's profile photoFlorian Sauvestre's profile photo
 
Thank you!
Add a comment...

Rick Byers

Shared publicly  - 
 
Chrome now reliably honors overflow: hidden on html/body

As part of shipping our "virtual viewport" feature (https://plus.google.com/+RickByers/posts/bpxrWN4G3X5), we're finally able to fix a long-standing bug where setting "html { overflow: hidden; }" had inconsistent behavior (http://crbug.com/175502).  It now reliably prevents scrolling of the document.  *WARNING* This has broken a couple pages which were relying on the bug (see http://crbug.com/444581).

To demonstrate, try loading this simple JSBin in your browser: http://jsbin.com/puzimo/1/edit?html,css,output.  In Chrome (prior to virtual viewport) and Safari the behavior is inconsistent.  When displayed in an iframe, the document won't scroll as expected.  But when you click the "pop out" button to load http://jsbin.com/puzimo/1 into it's own document, now the document scrolls!  This is because the compositor-accelerated scrolling done by default for documents wasn't smart enough to understand scrolling should be disabled.  In chromium we couldn't easily disable scrolling here without also disabling panning the pinch viewport.

The CSS spec is clear on the expected behavior here (http://www.w3.org/TR/CSS21/visufx.html#overflow): "UAs must apply the 'overflow' property set on the root element to the viewport".  IE and Firefox appear to implement this correctly already. 

With the virtual viewport feature enabled (default in Chrome 40 for Android and ChromeOS, and Chrome 41 for Windows/Mac/Linux), we now properly disable scrolling without breaking pinch-zoom.
Pinch-zooming pages with fixed position elements now behaves rationally in Chrome 40 for Android We're shipping a feature called "virtual viewport".  The… - Rick Byers - Google+
1
Add a comment...

Rick Byers

Shared publicly  - 
 
WTFrames: Another really interesting proposal for decomposing web pages into chunks whose performance you can reason about independently: https://docs.google.com/a/chromium.org/document/d/1naxaMvhHbD_Rdr6o8hBdaAJczhpL8INkoglQw5TGcNk/edit

+Fady Samuel is working on a prototype now: http://crbug.com/434226
3
2
Kenneth Rohde Christiansen's profile photoMatt Dragon's profile photo
Add a comment...

Rick Byers

Shared publicly  - 
 
+Ian Vollick and I talked about UIWorker with the W3C CSSWG at TPAC a few weeks back (where we heard a lot of interest from other browser vendors), and then Ian gave this great presentation at BlinkOn. The goal is to "explain" (in the extensible web manifesto sense) threaded compositing and enable custom threaded UI effects as a mechanism for achieving rich effects that are consistently 60fps smooth.

It's still very speculative, but the idea is really interesting and the prototype is compelling.  We're now making it a priority on my chromium input team to land support for this behind a flag so web developers can experiment with it.
 
Interesting new idea for better scrolling effects on the web
9 comments on original post
3
Add a comment...

Rick Byers

Shared publicly  - 
 
This precisely describes why I choose to work on the web platform, and believe in it's unique value to society.
 
The elastic band of compatibility
This post, like all posts here, is my personal opinion.

When it comes to the open, compatible web platform, I've been a True Believer since I read Yochai Benkler's The Wealth of Networks in college. It is my sincere belief that the web platform is fundamentally different from other platforms and is a tremendous force for good in society. But first it's useful to look at more traditional platforms that aren't based on standards (read: most every other platform). 

How traditional platforms work
These traditional platforms generally have one gatekeeper who is ultimately in charge and has the power to stop uses he doesn't like. On the plus side, these gatekeepers don't answer to anyone so they can innovate very quickly, and they're also incentivized to create new categories of platforms (where categories are things like desktops, smartphones, and smartwatches) so that they can monetize them. 

They can be a tremendous force for good--but they aren't perfect. From society's perspective one downside is that gatekeeper incentives aren't always aligned with society's best interest (more on those in a later post, perhaps). For gatekeepers a downside is that any success will be hard won but ultimately fleeting.

I want to take a moment to dive into that latter downside. Where there are platforms competing within a category, there is strong competition (which is good) but for the most part it's a zero-sum game (which is not so good). In particular, innovation from one player does not often spill over to another player. 

It's also an unstable equilibrium. That's because a platform, in many ways, is only as good as its apps. Further, developers (who make the apps) will seek out opportunities to minimize the number of apps they have to write. This means that when the balance between platforms tips past a critical point, developers stop writing apps for the losing platform so the balance keeps tipping at an accelerating rate. 

Ultimately one platform wins and the winner's incentive to innovate evaporates, often leading to a period of stagnation. This lasts until a new platform category inevitably comes onto the scene and eclipses the earlier category. Some winners are able to parlay success from an earlier round to a later one, but many aren't. If your platform won that last round, big whoop: in the grand scheme of things it was a temporary victory. From society's point of view, there are periods of innovation followed by periods of stagnation--but there's always a gatekeeper.

How the open web platform works
The web is different for a simple reason: compatibility. A number of players are competing within the same platform. Innovation from one player often spills directly over to other players; it's a positive-sum game. There is no gatekeeper because if any player stagnates it's possible for someone else to swoop in with a compatible implementation and innovate. 

For a lot of companies interested in building platforms, the fact that the web platform does not permit a single player to "win" is a deal breaker. Google, however, has grown up hand in hand with the web and has a deeply symbiotic relationship with it. In a very real way, Google's long-term success is tied to the success of the open web platform.

The elastic band of compatibility
Compatibility is like an elastic band that ties the whole ecosystem (browser vendors, web developers, standards bodies, and end users) together and makes the sum greater than the individual parts. However, if everyone were just tied together tightly with no room to move--to innovate--then the web would never get any better. With innovation comes some healthy stretching of the elastic that ultimately helps pull the rest of the ecosystem upward. But if any one player pulls too hard then the elastic will break and everything that makes the web special would be gone. You'd have just another temporarily victorious platform with just another gatekeeper. It is in the web's--and Google's--long-term interest to keep that elastic band of compatibility taut but never in risk of breaking.

This logic is obvious--but only if you take the long-term perspective. In the short term it can be tempting for a player to think that the elastic is just holding him back (the gatekeepers of other platforms can innovate as fast as they want, after all) and miss how vitally important it is for the long-term success of the ecosystem.

I'm proud to be a member of the Blink team because I know that I'm surrounded by people who truly understand why that elastic band is so important (for proof, check out the guidelines for shipping new features at http://www.chromium.org/blink#new-features , which emphasize standards, interoperability, conformance tests, and transparency). I've never been as excited for the open web as I am today.
2 comments on original post
2
Add a comment...
Have him in circles
1,096 people
nermeen mark's profile photo
Rtn. Arul Prakasam T's profile photo
Valerie MacDonald's profile photo
Bing G's profile photo
Harold Putman's profile photo
Vicky Gupta's profile photo
Alan Paulin's profile photo
Merasol oga's profile photo
Long Nguyen's profile photo

Rick Byers

Shared publicly  - 
 
Chrome supports using hover-capable touchscreens (such as on the Galaxy S4/S5) by triggering :hover styles and mouseover/move/out handlers (just like it does for a stylus or mouse device).

If you have such a device, try enabling this feature at chrome://flags/#enable-touch-hover.  Do you find this useful in practice for navigating websites designed for a mouse, or is it only a gimmick?  Even for sites designed to work well with both touch and mouse, do you like seeing the hover effects with touch?

See http://crbug.com/418188 for details.
4
1
Jared Duke's profile photoDan Snel's profile photoElijah Lynn's profile photo
2 comments
 
It's perfect, this means that mouseover event has chances to be use for mobile devices without any problems.Pure css menus too.I'm a server's script programmer but I'll make a research on this aspect.I know that was some advices to avoid hover events and have to know if they are still holded.
Add a comment...

Rick Byers

Shared publicly  - 
 
Chrome 42 now reports fractional scroll offsets on high-dpi devices (virtually all Android devices). [edit: we just decided to postpone this, probably to Chrome 44.  http://crbug.com/468513]

Chrome (and all other major browsers) have reported scroll offsets (eg. window.scrollY and Element.scrollTop) as integers, even though scrolling can occur at the granularity of device pixels. The CSS spec was updated awhile ago to use "double" instead of "long" for these APIs (http://dev.w3.org/csswg/cssom-view/#extension-to-the-element-interface). As of Chrome 42, we're no longer doing any truncation / rounding of scroll offsets, reporting the full precision values to JavaScript. So on a device with device scale factor = 2, you should expect to see scrollTop values like 10.5 (instead of just 10 or 11).  Demo: http://jsbin.com/dejoxo/

This will immediately improve the behavior of code which tries to transform an element in-sync with scrolling. Eg. In this simple example, JS is transforming the green box to try to keep it aligned with the red box scrolling with the page: http://tdresser.github.io/sync-scroll-offset-test/index.html. On a high-dpi device prior to Chrome 42 you can see the green box wiggle up and down noticeably when scrolling slowly due to scrollTop truncation to integers. In 42 (currently Beta) it's positioned precisely at the right location. A more realistic example is a scroll header like https://www.polymer-project.org/0.5/components/core-elements/demo.html#core-scroll-header-panel.

Note that this could cause some compat problems if your code isn't expecting to see non-integer scroll offsets. But we have yet to encounter issues in practice.

9
1
Alexander Lent's profile photo
Add a comment...

Rick Byers

Shared publicly  - 
 
Pinch-zooming pages with fixed position elements now behaves rationally in Chrome 40 for Android

We're shipping a feature called "virtual viewport".  The mental model which I argued for is that a zoomed page will look as if you had held a magnifying glass up to the screen.  Eg. when you pan the viewport sideways, you'll also be panning any top header (no more seeing only the top left of nav bars when zooming!).  Try this comparing Chrome Stable (39) on http://videojs.com (or the desktop version of http://nytimes.com) to Chrome Beta (40).  Essentially we're splitting the notion of "the viewport" into "the layout viewport" (where fixed position items are attached) and "the visual viewport" (what you actually see).

In this regard, Chrome now (mostly) matches IE's behavior instead of doing something kinda like Safari's weird behavior.  Interestingly, we came to the conclusion that this was the right behavior completely independently from the IE team (it was fun to be able to show them a demo when they described their new model to us).  Now we're working together to try to get the CSS specs updated to accommodate it.

For details see: 
https://docs.google.com/presentation/d/1nJvJqL2dw5STi5FFpR6tP371vSpDWWs5Beksbfitpzc/edit
http://www.quirksmode.org/mobile/viewports2.html
http://crbug.com/148816
30
13
Marzio Massari's profile photoSam Dutton's profile photoDavid Barber's profile photoElijah Lynn's profile photo
12 comments
 
Damn, looks like the embedded link view doesn't update when the text does.  I just removed it.
Add a comment...

Rick Byers

Shared publicly  - 
 
Awesome new devtools feature.
 
#DevTools Tip: Paint Profiler

Use the paint profiler to see exactly what draw calls were executed to draw a page. You can scrub through the profile to find only those portions you are interested in.
1 comment on original post
4
Add a comment...

Rick Byers

Shared publicly  - 
 
Scott Goodson from Facebook: "It was possible for the Paper team to focus so deeply on these challenges of interactivity and performance only because of the infrastructure we were able to build upon. iOS has a rich set of APIs that give us key functionality to use and extend with our own." (https://code.facebook.com/posts/656530327776932/building-paper/)

The subtext I see is "and the web does not".  To thrive, the web must return to enabling innovation by being more extensible: http://www.extensiblewebmanifesto.org/.

There are interesting parallels between AsyncUIKit (https://code.facebook.com/posts/721586784561674/introducing-asyncdisplaykit-for-smooth-and-responsive-apps-on-ios/) and WTFrames (https://plus.google.com/+RickByers/posts/CJT6ATKQNFC).

#extensibleweb   #Chrome  
A few weeks ago we launched Paper, a new app to explore content from your friends and the world around you—with built-in access to all the core features of Facebook. Through the process of implementing the fresh design and creating about 20 new categories of content, the team has developed new frameworks and architectural approaches to address the toughest challenges we encountered. In a series of blog posts, tech talks, and open source releases,...
2
Ian Vollick's profile photoRick Byers's profile photo
2 comments
 
Agreed.  UIWorker and WTFrame are both mechanisms for doing some UI work asynchronously from other UI work.  But WTFrame is the closer one here.  Edited to point to WTFrame instead of UIWorker.
Add a comment...

Rick Byers

Shared publicly  - 
 
Video is now available from my BlinkOn talk with Tim Dresser about how we hope to make scrolling extensible (https://extensiblewebmanifesto.org/). Slides: https://docs.google.com/a/chromium.org/presentation/d/1P5LYe-jqC0mSFJoBDz8gfJZMDwj6aGeFYLx_AD6LHVU/edit
3
1
Kenneth Rohde Christiansen's profile photo
Add a comment...
People
Have him in circles
1,096 people
nermeen mark's profile photo
Rtn. Arul Prakasam T's profile photo
Valerie MacDonald's profile photo
Bing G's profile photo
Harold Putman's profile photo
Vicky Gupta's profile photo
Alan Paulin's profile photo
Merasol oga's profile photo
Long Nguyen'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 lead a team working on input in Chrome and Blink.  I'm the Google representative in the W3C touch events community group 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
Apps with Google+ Sign-in
Public - 2 months ago
reviewed 2 months ago
Public - 4 months ago
reviewed 4 months ago
Amazing curries with meat that is very tender.
Public - 6 months ago
reviewed 6 months ago
38 reviews
Map
Map
Map
Food tastes fresh and good service. My family agrees that it's our favorite pizza place in KW.
Public - 4 months ago
reviewed 4 months ago
Public - 8 months ago
reviewed 8 months ago