HTML5 Rocks

HTML5 Rocks

A More Compatible, Smoother Touch

By Vivian Cromwell at

You and your users want mobile web apps that react and scroll smoothly to the touch. Developing them should be easy but, unfortunately, how mobile web browsers react to touch events during scrolling is left as an implementation detail in the TouchEvent specification. As a result, approaches can be broken down roughly into 4 categories. This situation exposes a fundamental tension between delivering scroll smoothness and maintaining developer control.

Four different models of touch event processing?

The behavior differences between the browsers break down into four models.

  1. Normal synchronous event processing

    Touchmove events are sent during scrolling and each scroll update blocks until touchmove handling has completed. This is good as the simplest to understand and the most powerful but bad for scroll performance because it means that each frame during the scroll must block on the main thread.

    Browsers: Android Browser (Android 4.0.4, 4.3), Mobile Safari (when scrolling div)

  2. Asynchronous touchmove processing

    Touchmove events are sent during scrolling, but scrolling can proceed asynchronously (the touchmove event is ignored after scrolling has begun). This can result in "double handling" of events, for example, continuing to scroll after the web site does something with the touchmove and calls preventDefault on the event, telling the browser not to handle it.

    Browsers: Mobile Safari (when scrolling Document), Firefox

  3. Touchmove suppressed while scrolling

    Touchmove events are not sent after scrolling starts and do not resume until after the touchend event. In this model, it's hard to tell the difference between a stationary touch and a scroll.

    Browsers: Samsung Browser (mousemove events sent)

  4. Touchcancel on scroll start

    You can't have it both ways -- scroll smoothness and developer control -- and this model makes clear the trade-off between smooth scrolling and event handling, similar to the semantics of the Pointer Events specification. Some experiences that may need to track the finger, like pull-to-refresh, are not possible.

    Browsers: Chrome Desktop M32+, Chrome Android

Why Change?

Chrome for Android currently uses Chrome's Old Model: touchcancel on scroll start, which enhances scrolling performance, but leads to developer confusion. In particular, some developers aren't aware of the touchcancel event or how to deal with it, and this has caused some web sites to break. More importantly, an entire class of UI scrolling effects and behaviors, such as pull-to-refresh, hidey bars, and snap points are difficult or impossible to implement well.

Rather than adding specifically hardcoded features to support these effects, Chrome aims to concentrate on adding platform primitives that allow developers to implement these effects directly. See A Rational Web Platform for a general exposition of this philosophy.

Chrome's New Model: The Throttled Async Touchmove Model

Chrome is introducing a new behavior designed to improve compatibility with code written for other browsers when scrolling, as well as enabling other scenarios that depend on getting touchmove events while scrolling. This feature is enabled by default and you can turn it off with the following flag, chrome://flags#touch-scrolling-mode.

The new behavior is:

  • The first touchmove is sent synchronously to allow scroll to be canceled
  • During active scrolling
    • touchmove events are sent asynchronously
    • throttled to 1 event per 200ms, or if a CSS 15px slop region is exceeded
    • Event.cancelable is false
  • Otherwise, touchmove events fire synchronously as normal when active scrolling terminates or isn't possible because the scroll limit has been hit
  • A touchend event always occurs when the user lifts their finger

You can try this demo in Chrome for Android and toggle the chrome://flags#touch-scrolling-mode flag to see the difference.

Let us know what you think

The Async Touchmove Model has the potential to improve cross-browser compatibility and enable a new class of touch gesture effects. We're interested in hearing what developers think, and in seeing the creative things you can do with it.

Chrome Dev Summit: Performance Summary

By Paul Lewis at

#perfmatters: Tooling techniques for the performance ninja

Knowing your way around your development tools is key to becoming a performance Grand Master. Colt stepped through the three pillars of performance: network, compute and render, providing a tour of the key problem in each area and the tools available for finding and eradicating them.


  • You can now profile Chrome on Android with the DevTools you know and love from desktop.
  • The iteration loop for performance work is: gather data, achieve insight, take action.
  • Prioritize assets that are on the critical rendering path for your pages.
  • Avoid painting; it’s super expensive.
  • Avoid memory churn and executing code during critical times in your app.

#perfmatters: Optimizing network performance

Network and latency typically accounts for 70% of a site’s total page load time. That’s a large percentage, but it also means that any improvements you make there will reap huge benefits for your users. In this talk Ilya stepped through recent changes in Chrome that will improve loading time, as well as a few changes you can make in your environment to help keep network load to an absolute minimum.


  • Chrome M27 has a new and improved resource scheduler.
  • Chrome M28 has made SPDY sites (even) faster.
  • Chrome’s simple cache has received an overhaul.
  • SPDY / HTTP/2.0 offer huge transfer speed improvements. There are mature SPDY modules available for nginx, Apache and Jetty (to name just three).
  • QUIC is a new and experimental protocol built on top of UDP; it’s early days but however it works out users will win.

#perfmatters: 60fps layout and rendering

Hitting 60fps in your projects directly correlates to user engagement and is crucial to its success. In this talk Nat and Tom talked about Chrome’s rendering pipeline, some common causes of dropped frames and how to avoid them.


  • A frame is 16ms long. It contains JavaScript, style calculations, painting and compositing.
  • Painting is extremely expensive. A Paint Storm is where you unnecessarily repeat expensive paint work.
  • Layers are used to cache painted elements.
  • Input handlers (touch and mousewheel listeners) can kill responsiveness; avoid them if you can. Where you can’t keep them to a minimum.

#perfmatters: Instant mobile web apps

The Critical Rendering Path refers to anything (JavaScript, HTML, CSS, images) that the browser requires before it is able to begin painting the page. Prioritizing the delivery of assets on the critical rendering path is a must, particularly for users on network-constrained devices such as smartphones on cellular networks. Bryan talked through how the team at Google went through the process of identifying and prioritizing the assets for the PageSpeed Insights website, taking it from a 20 second load time to just over 1 second!


  • Eliminate render-blocking JavaScript and CSS.
  • Prioritize visible content.
  • Load scripts asynchronously.
  • Render the initial view server-side as HTML and augment with JavaScript.
  • Minimize render-blocking CSS; deliver only the styles needed to display the initial viewport, then deliver the rest.
  • Large data URIs inlined in render-blocking CSS are harmful for render performance; they are blocking resources where image URLs are non-blocking.

Chrome Dev Summit: Polymer declarative, encapsulated, reusable components

By Eric Bidelman at

Polymer is one gateway into the amazing future of Web Components. We want to make it easy to consume and build custom elements. For the past year, the team has been working hard on a set of polyfills for the evolving specifications. On top of that, we've created a convenient sugaring library to make building web components easier. Lastly, we're crafting a set of UI and utility elements to reuse in your apps. At the 2013 Chrome Dev Summit, I dove into the different parts of Polymer and the philosophy behind our "Everything is an element" mantra.


"Everything is an element" (from <select> to custom elements)


Building web pages in the 90s was limiting, but powerful. We only had a few elements at our disposal. The powerful part?...everything was declarative. It was remarkably simple to create a page, add form controls, and create an "app" without writing gobs of JavaScript.

Take the humble <select> element. There is a ton of functionality built into the element, simply by declaring it:

  • Customizable through HTML attributes
  • Renders children (e.g. <option>) with a default UI, but configurable via attributes.
  • Useful in other contexts like <form>
  • Has a DOM API: properties and methods
  • Fires events when interesting things happen

Web Components provide the tools to get back to this heyday of web development. One where we can create new elements, reminiscent of <select>, but designed for the use cases of 2014. For example, if AJAX was invented today it would probably be an HTML tag (example):

<polymer-ajax url="" 

Or responsive elements that data-bind to a queryMatches attribute:

<polymer-media-query query="max-width:640px" queryMatches="{{isPhone}}"></…

This is exactly the approach we're taking in Polymer. Instead of building monolithic JavaScript-based web apps, let's create reusable elements. Over time, an entire app grows out of composing smaller elements together. Heck, and entire app could be an element:


Building web components with Polymer's special sauce


Polymer contains a number of conveniences for building web component based applications:

  • Declarative element registration: <polymer-element>
  • Declarative inheritance: <polymer-element extends="...">
  • Declarative two-way data-binding: <input id="input" value="{{foo}}">
  • Declarative event handlers: <button on-click="{{handleClick}}">
  • Published properties: = 5 <-> <x-foo bar="5">
  • Property observeration: barChanged: function() {...}
  • PointerEvents / PointerGestures by default

Moral of the story is that writing Polymer elements is all about being declarative. The less code you have to write, the better ;)

Web Components: the future of web development


I would be remissed if I didn't give a shout out to the standards behind Web Components. After all, Polymer is based on these evolving foundational APIs.

We're on the cusp of a very exciting time in web development. Unlike other new features being added to the web platform, the APIs that make up Web Components are not shiny or user-facing. They're purely for developer productivity. Each of the four main APIs is useful by itself, but together magical things happen!

  1. Shadow DOM - style and DOM encapsulation
  2. Custom Elements - define new HTML elements. Give them an API with properties and methods.
  3. HTML Imports is the distribution model for a package of CSS, JS, and HTML.
  4. Templates - proper DOM templating for defining inert chunks of markup to be stamped out later

If you want to learn more about the fundamentals of the APIs, check out

Chrome Dev Summit: Mobile Summary

By Paul Kinlan at

The Chrome Dev Summit finished a couple of weeks ago, and here's the first in a series of reports from the event. There was a strong emphasis on Mobile and Cross-device development, so we'll kick off with that!

Best UX patterns for mobile web apps by Paul Kinlan

After an analysis of the mobile-friendliness of the top 1000 sites we found some problem areas: 53% still only provide a desktop-only experience, 82% of sites have issues with interactivity on a mobile device and 64% of sites have text that users will have issues reading.

Quick hits to dramatically improve your mobile web experience:

  • Always define a viewport
  • Fit content inside the viewport
  • Keep font sized at a readable level
  • Limit use of Web Fonts
  • Size and space out tap targets appropriately
  • Use the semantic types for input elements

PageSpeed Insights just launched a UX analysis for determining how mobile-friendly your site is. It will help you find common problems with your sites mobile UX. Try it out!

Slides: Best UX patterns for mobile web apps

Multi-device Accessibility by Alice Boxhall

Users will be accessing your sites and services from a multitude of devices with a wide range of different accessibility requirements. By using the correct semantic elements and correct ARIA roles you help give the browser and assistive technology a much improved understanding of your page.

Slides: Multi-device Accessibility

Key ways to understand and address a11y issues

  • Ensure you have a good keyboard-only user experience
  • Express the semantics of your interface with correct element choice and ARIA
  • Use ChromeVox on desktop and TalkBack on Android to test.
  • Try the Accessibility Developer Tools Chrome extension
  • A more diverse audience is getting online, which further amplifies the need of making your sites accessible

Build Mobile Apps using the Chrome WebView by Matt Guant

We all know the problems that developers have had in the past building for WebView: Limited HTML5 features, no debugging tools, no build tools. With the introduction of a Chromium powered WebView in Android 4.4 (KitKat) developers now have a huge range of new tools at their disposal to build great native apps using the WebView.

The WebView supports full remote debugging with the same tools you use for Chrome. You can also take your trusted web development workflow with Grunt and integrate that into your native stack tooling via Gradle. Further merging worlds, there's a clever trick to use the Chrome DevTools to test your native code from Javascript.

Slides: Build Mobile Apps using the Chrome WebView

Effective WebView development takeaways

  • It’s not the new features that are important, its the tooling that you can now use to speed up your workflow
  • Don’t try to emulate the native UI. But make sure to remove some of the tells that it is Web Content.
  • Use native implementations of features when appropriate. i.e, use the DownloadManager rather than XHR for large files.

Optimizing your Workflow for a Cross-device world by Matt Gaunt

If we have to develop for Desktop, Mobile, Tablet, wearables and other form factors, how can you optimise your workflow to make your life less stressful? There's a solid multi-device approach for quick iteration with LiveReload, Grunt, Yeoman, and the newly-unveiled Mini Mobile Device Lab. Lastly, if you don't have the physical hardware you want to test, some providers make it available through the cloud.

Slides: Optimizing your Workflow for a Cross-device world

Key points

  • The number of devices that we are going to have to cater for is only going to increase
  • Getting your workflow with the right with Grunt and Yeoman
  • Simplify cross browser and cross device testing with Mini Mobile Device Lab
  • Be smart with your emulation choice using Chrome DevTools Emulation, Stock Emulators, Cloud Based Emulators like Saucelabs, Browserstack and Device Anywhere and third party emulator Genymotion
  • Mobile testing means more than just testing on your wifi connection, use a proxy to simulate slower network speeds

Network connectivity: optional by Jake Archibald

We learnt many things from this talk: Jake doesn’t wear shoes when presenting; Business Kinlan has a new book coming out soon; Offline is being taken seriously by browser vendors and you will soon have the tools in your hands that help you build great experiences that work well when you are offline.

ServiceWorker will give us the flexibility that we need to build compelling offline first experiences with ease and not suffer the pains inflicted by AppCache. You can even experiment with the API using a Polyfill.

Slides: Network connectivity: optional

ServiceWorker to the rescue

  • In the next generation of progressive enhancement, we treat the network as a potential enhancement
  • ServiceWorker gives you full, scriptable, debuggable control over network requests
  • If you have an offline experience, don’t wait for the network to fail before you show it, as this can take ages

300ms tap delay, gone away

By Jake Archibald at

You'll find large articles throughout this site dedicated to shaving 10ms here and 90ms there in order to deliver a fast and fluid user experience. Unfortunately every touch-based mobile browser, across platforms, has an artificial ~300ms delay between you tapping a thing on the screen and the browser considering it a "click". When people think of the web as being sluggish compared to native apps on mobile, this is this one of the main contributors.

However, as of Chrome 32 for Android, which is currently in beta, this delay is gone for mobile-optimised sites, without removing pinch-zooming!

This optimisation applies to any site that uses:

<meta name="viewport" content="width=device-width">

(or any equivalent that makes the viewport <= device-width)

Why do clicks have a 300ms delay?

If you go to a site that isn't mobile optimised, it starts zoomed out so you can see the full width of the page. To read the content, you either pinch zoom, or double-tap some content to zoom it to full-width. This double-tap is the performance killer, because with every tap we have to wait to see if it might become a double-tap, and that wait is 300ms. Here's how it plays out:

  1. touchstart
  2. touchend
  3. Wait 300ms in case of another tap
  4. click

This pause applies to click events in JavaScript, but also other click-based interactions such as links and form controls.

You can't simply shortcut this with touchend listeners either. Compare these demos on a mobile browser other than Chrome 32:

Tapping on the rows changes their colour. The touchend example is much faster but also triggers after scrolling depending on the browser. This is because the spec doesn't define what can cancel the flow of touch events. Current versions of iOS Safari, Firefox, IE, and the old Android Browser trigger touchend after scrolling, Chrome doesn't.

Microsoft's PointerEvents spec does the right thing and specifies that pointerup doesn't trigger if a lower-level action such as scrolling occurs. However, currently only IE supports pointer events, although Chrome has a ticket for it. But even then, the 300ms delay would only be dropped on sites that used this listener in a way that applied to all links, form elements, and JavaScript interactions on the page.

How Chrome removed the 300ms delay

Chrome and Firefox for Android have, for some time now, removed the 300ms tap delay for pages with this:

<meta name="viewport" content="width=device-width, user-scalable=no">

Pages with this cannot be zoomed, therefore "double-tap to zoom" isn't an interaction, therefore there's no need to wait for double-taps. However, we also lose pinch-zooming.

Pinch-zooming is great for taking a closer look at a photo, some small print, or dealing with a set buttons/links that are placed too closely together. It's an out-of-the-box accessibility feature.

If a site has…

<meta name="viewport" content="width=device-width">

…double-tap zooms in a little bit. Not a particularly useful amount. A further double-tap zooms back out. We feel this feature, on mobile-optimised pages, isn't useful. So we removed it! This means we can treat taps as clicks instantly, but we retain pinch-zooming.

Is this change an accessibility concern?

We don't believe so, but the reason we release beta versions of Chrome is so users can try new features and give us feedback.

We tried to imagine a user this may affect, someone who:

  • has a motor impairment that prevents multi-touch interaction such as pinch-zoom, but not two taps in the same area within 300ms
  • has a minor visual impairment that is overcome by the small amount of zooming provided by double-tap on mobile optimised sites

But they're catered for by the text sizing tools in Chrome's settings, or the screen magnifier in Android, which covers all sites and native apps, and can be activated by triple-tap.

Chrome accessibility settingsAndroid screen magnification

However, we may have missed something, so if you are affected by this change, or know someone who is, let us know in the comments or file a ticket.

Will other browsers do the same?

I don't know, but I hope so.

Firefox has a ticket for it and currently avoids the 300ms delay for unzoomable pages.

On iOS Safari, double-tap is a scroll gesture on unzoomable pages. For that reason they can't remove the 300ms delay. If they can't remove the delay on unzoomable pages, they're unlikely to remove it on zoomable pages.

Windows phones also retain the 300ms delay on unzoomable pages, but they don't have an alternative gesture like iOS so it's possible for them to remove this delay as Chrome has. You can remove the delay using:

html {
    -ms-touch-action: manipulation;
    touch-action: manipulation;

Unfortunately this is a non-standard Microsoft extension to the pointer events spec. Also, programmatic fixes like this are opt-in by the developer, whereas the Chrome fix speeds up any existing mobile-optimised site.

In the mean time…

FastClick by FT Labs uses touch events to trigger clicks faster & removes the double-tap gesture. It looks at the amount your finger moved between touchstart and touchend to differentiate scrolls and taps.

Adding a touchstart listener to everything has a performance impact, because lower-level interactions such as scrolling are delayed by calling the listener to see if it event.preventDefault()s. Thankfully, FastClick will avoid setting listeners in cases where the browser already removes the 300ms delay, so you get the best of both!

CSS Background shorthand coming to mobile WebKit browsers

By Pete LePage at

Earlier this year, WebKit updated the behavior of the CSS background shorthand property. With this change, the background shorthand property will reset the background-size to its default value of auto auto if it’s not set in the shorthand declaration. This change brings Chrome and other WebKit browsers in compliance with the specification and matches the behavior of Firefox, Opera and Internet Explorer.

With Chrome for Android moving forward to current revisions on WebKit, this change is now rolling out in Android. Because this was a fix to webkit, sites that tested in multiple browsers are likely not affected.

Old way of doing things

// background-size is reset to auto auto by the background shorthand 
.foo {  
  background-size: 50px 40px;
  background: url(foo.png) no-repeat;

The background shorthand property does not contain any size property and will therefore reset the background-size to its default value of auto auto.

Correct way to specifying image size

// background-size is specified after background
.fooA { background: url(foo.png) no-repeat; background-size: 50px 40px;

// background-size is specified inline after position
.fooB { background: url(foo.png) 0% / 50px 40px no-repeat;

In fooB, specifying a background-size in the background shorthand requires the position (0%) be specified first, followed by a forward slash then the background-size (50px 40px). |

Fixes for existing code

There are several options that will provide an easy fix for this:

  • Use background-image instead of the background shorthand property.
  • Set the background-size last, with a higher specificity than any other CSS rules that set background on that element, and don’t forget to check and :hover rules.
  • Apply the !important property to background-size.
  • Move the sizing information to the background shorthand property.

Bonus: background image offsets

In addition to this change, there’s now greater flexibility in positioning the image within the background. In the past, you could only specify the image position relative from the top left corner, now you can specify an offset from the edges of the container. For example setting background-position: right 5px bottom 5px; the image will be positioned 5px from the right edge and 5px from the bottom. Check out this sample on JSBin

Chrome for Android: Accelerating the Mobile Web

By Boris Smus at

You've probably already heard that Chrome for Android Beta launched today. This new browser is based on the Chromium open source project, and brings with it many of the latest HTML5 features that Chrome developers have come to know and love. For an overview of the new hotness, see the launch announcement on and a more detailed overview on I'll quickly go through the stuff I personally find most interesting:

UI Improvements

Chrome for Android makes it easy for developers to create modern mobile web user interfaces using fixed positioning, and overflow: scroll for individually scrollable elements. In addition, native-like scroll behavior is enabled by default. Chrome for Android supports the old flexbox model, though be aware that the original flexbox model is deprecated in favor of a new one. Also supported are DateTime pickers, and early support for <input type="range">.

Fast graphics

Chrome for Android also supports hardware accelerated canvas, and performs quite well. There's also support for requestAnimationFrame, which is important for mobile, letting the browser decide when to render, giving it a chance to manage battery life more efficiently in GPU intensive applications. Chrome for Android introduces a slew of other notable HTML5 features including File System API, IndexedDB, Web Workers and Web Sockets.

Remote debugging

Hands down, my personal favorite feature of Chrome for Android is remote debugging through the Chrome Developer Tools. Remote debugging makes it very easy for web developers to debug their application as it's running live on their mobile device, without having to resort to clever hacks such as Weinre. Here's a quick screencast showing this feature in action:

For more information about remote debugging, see this remote debugging article.

Try Chrome for Android Beta for yourself by downloading it from the Android Market. If you've written a mobile web app to use a feature, but Chrome for Android doesn't support it, keep in mind that this is a beta release, and see if this is already a known issue, and star it if it is. Otherwise, please log a bug via

I'm stoked about the positive impact Chrome for Android will make on the mobile web developer community, and looking forward to see the great things we can build together! If you have additional questions, see if they are already answered in this FAQ. Otherwise, if you have a Chrome-specific mobile web development question, please post it on Stack Overflow, tagged with the google-chrome and android tags.

Use mediump precision in WebGL when possible

By Ilmari Heikkinen at

Heads-up from our friends at Opera, who have been testing WebGL on actual OpenGL ES 2.0 hardware: many demos and applications use highp precision in fragment shaders when it’s not really warranted.

Highp in fragment shaders is an optional part of the OpenGL ES 2.0 spec, so not all hardware supports it (and even when they do, there may be a performance hit). Using mediump will usually be good enough and it will ensure that your applications will work on mobile devices as well.

In practice, if your fragment shader previously started with

precision highp float;

Changing it to the following should do the trick:
precision mediump float; // or lowp