People hate filling out web forms, especially on mobile devices. They can be slow and frustrating to complete and often contain multi-page steps and validation issues. This leads to high user drop-off and frustration. To help make things easier for users, browsers have long been able to autocomplete fields on behalf of the user. Chrome took this a step further in 2011 by introducing Autofill, which fills in entire forms based on a user?s Autofill profile.
Starting in the next major version of Chrome (M43), we?re taking yet another step to help users fill out forms faster by expanding our support for credit cards and addresses in Google. This means that the same information users use to purchase things inside of the Google Play store are now available to them on websites. By using the standard autocomplete attributes, you can ensure your users? happiness by helping Chrome autofill your checkout forms with 100% accuracy.
Autocomplete attributes are a way for you, the developer, to control how the
browser should populate a given form field. For example, if you are expecting a
street address you can hint to the browser that you are expecting it by using
We?ve found that by correctly using autocomplete attributes on your forms, users complete them up to 30% faster. And since autocomplete is part of the WHATWG HTML standard, we hope that other browsers will support it in the near future.
In the past, many developers would add autocomplete=?off? to their form fields to prevent the browser from performing any kind of autocomplete functionality. While Chrome will still respect this tag for autocomplete data, it will not respect it for autofill data. So when should you use autocomplete=?off?? One example is when you?ve implemented your own version of autocomplete for search. Another example is any form field where users will input and submit different kinds of information where it would not be useful to have the browser remember what was submitted previously.
The most common autocomplete attributes are shown in the table below and are documented in Web Fundamentals.
The autocomplete attributes can be accompanied with a section name, such as:
It is recommended because it will make your markup easier to parse and understand. The browser will autofill different sections separately and not as a continuous form.
An example of a payment form
Forms best practices
You can see it in action over at:
Firstly, I apologise for that awful title, but I couldn?t not.
What this basically boils down to, is when you receive a push message, you can create a notification with some data, then in the notificationclick event you can get the notification that was clicked and get its data.
For example, creating a data object and adding it to your notification options like so:
Means we can get the information in the notificationclick event:
Before this, you had to stash data in IndexDB or put something on the end of the icon URL - eek.
One common request from developers working on push notifications is to have better control over the notifications that they display.
An example use case would be a chat application where a user sends multiple messages and the recipient displays multiple notifications. Ideally the web app would be able to notice you have several notifications which haven?t been viewed and collapse them down into a single notification.
Without getNotifications() the best you can do is replace the previous notification with the latest message. With getNotifications(), you can ?collapse? the notifications if a notification is already displayed - leading to a much better user experience.
The code to do this is relatively simple. Inside your push event, call ServiceWorkerRegistration.getNotifications() to get an array of current Notifications and from there decide the right behaviour, whether that?s collapsing all notifications or by using the Notification.tag.
The first thing to highlight with this code snippet is that we filter our notifications by passing a filter object to getNotifications(). This means we can get a list of notifications for a specific tag (in this example for a particular conversation).
Then we look over the notifications which are visible and check to see if there is a notification count associated with that notification and increment based on that. This way if there is one notification telling the user there are two unread messages, we would want to point out that there are three unread messages when a new push arrives.
A subtlety to highlight is that you need to call close() on the notification to ensure the notification is removed from the notification list. This is a bug in Chrome since each notification is replaced by the next one because the same tag is used. At the moment this replacement isn?t being reflected in returned array from getNotifications().
This is only one example of getNotifications() and as you can imagine, this API opens up a range of other use cases.
Remaining Common Feature Requests
The one remaining common feature request from developers is the ability to close a notification after a certain time period or the ability to send a push notification with the purpose of just closing a notification if it?s visible.
At the moment there isn?t a way you can do this and nothing in the spec that will allow it :( but the Chrome engineering team are aware of this use case.
On desktop you can create a notification with the following code:
This was never supported on Android due to restrictions of the platform: specifically, Chrome can?t support the callbacks on the Notification object, such as onclick. But it?s used on desktop for displaying notifications for web apps you may currently have open.
The only reason I mention it is that originally, a simple feature detection like the one below would help you support desktop and not cause any errors on Android:
However, with push notification support now on Chrome for Android, notifications can be created from a ServiceWorker, but not from a web page, meaning this feature detect is no longer appropriate. If you try and create a notification on Chrome for Android you?ll receive this error message:
Uncaught TypeError: Failed to construct ?Notification?: Illegal constructor. Use ServiceWorkerRegistration.showNotification() instead
The best way to feature detect for Android and desktop at the moment is to do the following:
This can be used like so:
With the Chromium 42 release, H.264 hardware video decoding support has been expanded to OS X. Now Chromium on Macs, Windows 7+ and essentially all Chromebooks support power efficient decoding of video by default. Chromium?s HTML5 video implementation will automatically make the best decision on when to use this feature based on driver and hardware support.
The same hardware support is available to browser plugins as well. Pepper Flash for instance provides full access to video acceleration via the ActionScript StageVideo object. Switching from the old style Video to the StageVideo object should in most cases be simple to do. We would like to refer to Adobe?s excellent Best Practices for High Performing and Efficient Flash Video.
For best platform support and video performance, we strongly recommend moving from plugins to HTML5 video. Using plugins such as Flash may also adversely affect search ranking on mobile: see Google?s Webmaster FAQ. The video element is implemented by over 90% of browsers on mobile and desktop; Adobe ended support for Flash in Android Jelly Bean. The Web Fundamentals video section shows how to make the most of plugin-free, cross-platform media. For adaptive streaming on the web we recommend Shaka Player, an easy-to-use media player that implements DASH using MSE, with optional native support for content protection via EME. Likewise ExoPlayer for Android native apps.
More information about plugin deprecation timelines, and how to move to native APIs, is available from the NPAPI deprecation developer guide.
The DevTools Timeline panel has always been the best first stop on the path to performance optimization. This centralized overview of your app?s activity helps you analyze where time is spent on loading, scripting, rendering, and painting. Recently, we?ve upgraded the Timeline with more instrumentation so that you can see a more in-depth view of your app?s performance.
We?ve added the following features:
Note that using the Paint capture options described in this article do incur some performance overhead, so flip them on only when you want ?em.
Using the JS Profiler capture option and Flame Chart view to investigate call stacks in the Timeline.
Tip: Use WASD to zoom and pan through the Flame Chart. Shift-drag to draw a selection box.
The art of layer compositing is another aspect of the browser that has been mostly hidden from developers. When used sparingly and with care, layers can help avoid costly re-paints and yield huge performance boosts. But it?s often not obvious to predict how the browser will composite your content. Using the Timeline?s new Paint capture option, you can visualize composited layers at each frame of a recording.
When you select a gray frame bar above the Main Thread, its Layers panel provides a visual model of the layers that compose your app.
Tip: Play back animations by clicking through frame bars on a Timeline recording.
You can zoom, rotate, and drag the layers model to explore its contents. Hovering over a layer reveals its current position on the page. Right-clicking on a layer lets you jump to the corresponding node in the Elements panel. These features show you what was promoted to a layer. If you select a layer, you can also see why it was promoted in the row labeled Compositing Reasons.
Inspecting a layer from Codrops' Scattered Polaroids Gallery to reveal the browser?s reasons for compositing.
Last but not least, we?ve added the paint profiler to help you identify jank caused by expensive paints. This feature enriches the Timeline with more details about the work Chrome does during paint events.
For starters, it?s now easier to identify the visual content corresponding to each paint event. When you select a green paint event in the Timeline, the Details pane shows you a preview of the actual pixels that were painted.
Previewing pixels that the browser painted using the Paint capture option.
If you really want to dive in, switch over to the Paint Profiler pane. This profiler shows you the exact draw commands that the browser executed for the selected paint. To help you connect these native commands with actual content in your app, you can right-click on a draw* call and jump straight to the corresponding node in the Elements panel.
Relating native browser draw* calls to DOM elements using the Paint Profiler.
The mini-timeline across the top of the pane lets you play back the painting process and get a sense of which operations are expensive for the browser to perform. Drawing operations are color-coded as follows: pink (shapes), blue (bitmap), green (text), purple (misc.). Bar height indicates call duration, so investigating tall bars can help you understand what about a particular paint was costly.
Profile and profit!
When it comes to performance optimization, knowledge of the browser can be incredibly powerful. By giving you a peek under the hood, these Timeline updates help clarify the relationship between your code and Chrome?s rendering processes. Try out these new options in the Timeline and see what Chrome DevTools can do to enhance your jank-hunting workflow!
If you?ve worked with the Geolocation API before, chances are you?ve wanted to check if you had permission to use Geolocation without causing a prompt. This simply wasn?t possible. You had to request the current position and this would indicate the permission state or cause a prompt to be shown to the user.
Not all APIs work this way. The Notifications API has its own way of allowing you to check the current permission state via Notification.permission.
As the web platform grows in API?s, there needs to be a single, standard way for developers to check the status of a permission rather than having to remember how each and every API works. The Permission API, available in Chrome version 43, is intended to be this single, standard way to check the permission status of an API.
Check the status of a permission using the permissions.query() method. This will return a status of granted (you have permission), denied (you are blocked from accessing the API) or prompt (user needs to be prompted). For example:
The query method takes a
object, where you define the permission?s name. The response is a Promise
resolving to a
object. From this object, you can check the status with
In the above example, we highlight how to query the permission state for
geolocation with the following permission descriptor:
The Notification permission descriptor is similar in that it only requires a
For the push permission, you can supply a
Midi allows a
Requesting permission from the user depends on the specific API. For example,
geolocation would show a permission prompt when you call
Whereas notifications would prompt the user when you call
The point here is that the Permission API allows a consistent way to monitor the status of permissions while being able to support the range of APIs currently on the web.
The big advantage of this is that it allows you to build better experiences for your users, only prompting when it?s obvious to the user why you need extra privileges and taking full advantage of these APIs when you know you have been granted permission.
Chrome is the first browser to implement this, Mozilla are planning on shipping this, and Microsoft have shown interest in the API.
Service Worker will revolutionize the way we build for the web. Learn about what it is, why it is important and how to use it.
Learn how North Kingdom built an immersive multimedia experience optimized for modern mobile browsers using Web RTC
Using CSS Shapes we can create experiences that we have never been able to create on the web before.
Take advantage of the new element and new features of in your next responsive website.
Updates to the Chrome Developer Tools: CSS property quick search, memory stats for heap snapshots, CodeMirror upgrade and more.