Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Android WebView, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 74 on
ChromeStatus.com. Chrome 74 is beta as of March 22, 2019.
CSS prefers-reduced-motion media query
Some users have reported getting motion sick when viewing parallax scrolling, zooming, and other motion effects. To address this, many operating systems like Android depicted in the screenshot below provide an accessibility option to reduce motion whenever possible.
Chrome now provides a media query, prefers-reduced-motion (part of
Media Queries Level 5), that allows websites to honor these options when they are available.
Here's a short example to give you a taste of how it works. Imagine I have a sign-up button that draws attention to itself with a slight motion. The new query lets me shut off the motion for just the button.
@media (prefers-reduced-motion: reduce) {
button {
animation: none;
}
}
For all the details and options, read
Move Ya! Or maybe, don't, if the user prefers-reduced-motion!.
Private class fields
Chrome 72 introduced ECMAScript's new public class fields. Class fields simplify class syntax by avoiding the need for constructor functions just to define instance properties. Starting in Chrome 74, you can mark a field as private and no consumer of the class can ever access its value.
To mark a field as private, prepend it with a pound sign (
#). As with public class fields, your properties do not need to be in a constructor.
class IncreasingCounter {
#count = 0;
get value() {
console.log('Getting the current value!');
return this.#count;
}
increment() {
this.#count++;
}
}
Unlike public fields, private fields are not accessible outside of the class body. To read more about private class fields as well as the existing public class fields, read
Public and private class fields. See Specification Compliance in this article for more on CSS changes.
JavaScript API for feature policy
Feature policies, which were introduced in Chrome 60, allow websites to selectively enable, disable, and modify the behavior of APIs and other web features. This is done either through the
Feature-Policy header or through the
allow attribute on an iframe.
In Chrome 74, feature policies are enhanced with the addition of a JavaScript API, available from document.featurePolicy and frame.featurePolicy. The new API encompasses three functions:
- allowedFeatures() returns a list of features allowed by the current domain.
- allowsFeature() returns a boolean indicating whether a specific feature is allowed by either the current domain or by the specified domain.
- getAllowlistForFeature() returns a list of domains used on the current page that allow a specified feature.
For examples of these methods and for information about feature policy in general, read
Introduction to Feature Policy.
Other features in this release
sampleRate option for the AudioContext constructor
Sets the "sampleRate" to a particular value for an
AudioContext that will be created. This allows developers to set an arbitrary sample rate for audio processing in Web Audio API that is separate from the hardware rate. Use this to reduce complexity (by using a lower sample rate) or make the sample rate consistent across all devices by using a fixed rate and letting WebAudio resample appropriately for the hardware rate.
Intl.Locale
Chrome
now supports the Intl.Locale class, which allows the following:
- Parsing and manipulating the language, region, and script of a locale
- Reading or writing the Unicode extension tags in a locale
- Storing user locale preferences for this API in a serializable, standard format (rather than using a combination of language and the options object).
Signed exchange reporting for distributors
Signed Exchange Reporting for distributors extends
Network Error Logging to enable the distributors of signed exchanges to investigate signed exchange loading errors such as certificate verification errors.
TextEncoder encodeInto() method
Chrome
now supports TextEncoder.prototype.encodeInto(), which allows an encoded string to be written directly "into" a supplied pre-allocated buffer, offering a performant alternative to using
encode() to produce a buffer, and copying its contents into an existing buffer.
Service worker: client.postMessage() is buffered until the document is ready.
To
prevent messages from being delivered before the destination is ready,
client.postMessage() does not dispatch the message until one of the following has occurred on the destination:
- DOMContentLoaded event is fired.
- onmessage is set.
- startMessages() is called.
Specification compliance
CSS transition events
The CSS Transitions specification requires that transition events are sent when a transition is enqueued, starts, ends, or is canceled as
transitionrun,
transitionstart,
transitionend, and
transitioncancel respectively. These events mirror the CSS animation events which allow developers to observe CSS animations. Chrome
now follows the specification.
RTCIceCandidate and RTCIceCandidateInit
RTCIceCandidate and
RTCIceCandidateInit now comply with the specification. The
RTCIceCandidate interface describes an ICE candidate in WebRTC. It is available in Chrome, but it is not spec compliant as it is missing some fields. There are also some deviations from the specification in terms of nullable and read-only attributes and errors thrown by the constructor.
XHR falls back to UTF-8 when invalid encoding is specified
When an invalid encoding is specified for an XMLHttpRequest (via
overrideMimeType() or the response's MIME type),
UTF-8 is used in conformance with the specification. Previously Latin-1 was used.
Note: This applies to desktop Chrome only.
Deprecations and removals
Remove PaymentAddress's languageCode property
The PaymentAddress's languageCode property has been
removed from the Payment Request API. This property is the browser's best guess for the language of the text in the shipping, billing, delivery, or pickup address in Payment Request API. The languageCode property is marked at risk in the specification and has already been removed from Firefox and Safari. Usage in Chrome is small enough for safe removal.
Deprecate drive-by downloads in sandboxed iframes
Chrome will soon
prevent downloads in sandboxed iframes that lack a user gesture, though this restriction could be lifted via an
allow-downloads-without-user-activation keyword in the sandbox attribute list. This allows content providers to restrict malicious or abusive downloads.
Downloads can bring security vulnerabilities to a system. Even though additional security checks are done in Chrome and the operating system, we feel blocking downloads in sandboxed iframes also fits the general thought behind the sandbox. Apart from security concerns, it would be a more pleasant user experience for a click to trigger a download on the same page, compared with downloads starting automatically when a user lands on a new page, or started non-spontaneously after the click.