Chrome version: 132, 131, 130, 129, 128, 127, 126, 125, 124, 123, 122, 121, 120, 119, 118, 117, 116, 115, 114, 113, 112, 111, 110, 109, 108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, 96, 95, 94, 93, 92, 91, 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 74, 73, 72, 71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
This release of Chrome had 16 new features.
Adds "window-management" as an alias for "window-placement" permission and permission-policy strings. This is part of a larger effort to rename the strings by eventually deprecating and removing "window-placement". The terminology change improves the longevity of the descriptor as the Window Management API evolves over time. #
This feature was specified in this Spec.
Docs: https://github.com/w3c/window-placement/blob/main/EXPLAINER_spec_and_permission_rename.md
No linked samplesAll features described in CSS Color 4 (https://www.w3.org/TR/css-color-4/) are now enabled! This includes four device-independent color types (lab, Oklab, lch and Oklch), the color() function and user-defined color spaces for gradients and animations. The incredibly useful color-mix() function from CSS Color 5 (https://www.w3.org/TR/css-color-5/#color-mix) has also been included as a bonus! #
This feature was specified in this Spec.
Samples: https://codepen.io/argyleink/pen/RwyOyeqhttps://2021-hd-color-at-css-camp.netlify.app
Adds root font units. Previously, only 'rem' has been supported in Chrome. This feature adds root element variants of ex, ch, ic, and lh. #
This feature was specified in this Spec.
Extend :nth-child(an + b) to take a selector, and the same with :nth-last-child. So e.g. :nth-child(3 of .c) is the third .c under a given parent. (This is not the same as .c:nth-child(3), which is a .c that must also be the third element under a given parent.) #
This feature was specified in this Spec.
Add trigonometric functions sin(), cos(), tan(), asin(), acos(), atan(), atan2() to CSS math expressions. MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Functions#trigonometric_functions #
This feature was specified in this Spec.
Adds "previousslide" and "nextslide" actions to the existing Media Session API. #
This feature was specified in this Spec.
Samples: https://googlechrome.github.io/samples/media-session/slides.html
Extend the ArrayBuffer constructors to take an additional maximum length that allows in-place growth and shrinking of buffers. Similarly, SharedArrayBuffer is extended to take an additional maximum length that allows in-place growth. #
This feature was specified in this Spec.
This extends the speculation rules [1] syntax to allow developers to specify the referrer policy to use with speculative requests triggered by speculation rules. This also reintroduces the "sufficiently-strict referrer policy" requirement [2]. [1] https://chromestatus.com/feature/5740655424831488 [2] https://github.com/WICG/nav-speculation/blob/main/fetch.md#stripping-referrer-information #
This feature was specified in this Spec.
Chromium has shipped [1] a version of declarative shadow DOM in M90 which currently has 0.014% usage [2]. Mostly, that is due to the spec PR being stalled with no input from other implementers. Recently, there has been renewed interest in the feature, and discussions have resumed. As part of those discussions, two changes have been generally agreed upon: 1. Rename the `<template>` attribute from `shadowroot` to `shadowrootmode`. 2. Support streaming, by attaching the shadow root on the opening, rather than the closing, template tag. While the PR hasn't landed, and there is still an open issue (related to the DOMParser), we would like to ship the agreed upon behavior listed above. [1] https://chromestatus.com/feature/5191745052606464 [2] https://chromestatus.com/metrics/feature/timeline/popularity/3196 #
This feature was specified in this Spec.
Add two String.prototype methods for working with well-formed UTF-16 strings. A JavaScript string value is well-formed UTF-16 if it has no unpaired surrogate code points. By default, JavaScript strings may be ill-formed. - String.prototype.isWellFormed returns whether the receiver string is well-formed UTF-16. - String.prototype.toWellFormed returns a string that is identical to the receiver string, except all unpaired surrogate code points are replaced with U+FFFD (REPLACEMENT CHARACTER). #
This feature was specified in this Spec.
Adds a style() function to @container rules to make it possible to apply styles based on the computed values of custom properties of an ancestor element. style() queries can be combined with size container queries which shipped in M105. #
This feature was specified in this Spec.
Samples: https://www.bram.us/2022/10/14/container-queries-style-querieshttps://una.im/style-queries
View Transitions is an API that enables the creation of polished transitions. Web developers only need minimal effort to make transitions look nice. They can choose to use some default animation properties, or they can customize their own transition effects to achieve a desired transition experience. This is accomplished by leveraging user-agents’ ability to persist visual representations of rendered output (i.e. snapshots) and blend them with the live DOM state’s rendered output. The API also allows these animations to be customized via standard CSS animation properties. #
This feature was specified in this Spec.
Docs: https://github.com/WICG/view-transitions/blob/main/explainer.md
Samples: https://developer.chrome.com/docs/web-platform/view-transitions
This extension defines a standard method for picking between possible Scalable Video Coding (SVC) configurations on an outgoing WebRTC video track. #
This feature was specified in this Spec.
Docs: https://w3c.github.io/webrtc-svc/
No linked samplesReturns the set of features that were enabled for this XRSession as specified by XRSessionInit and the Implied Features required by the spec for the given mode/features. For a granted Session, this will contain all "requiredFeatures", but may be a subset of optionalFeatures. Most features have alternate ways to detect if they were granted; however, for some features the signal of whether or not a feature was enabled may tie closely with data for a feature just not being available "right now", rather than data not being available "ever". By querying enabledFeatures, you can determine if any helpful hints (e.g. to improve/start tracking) should be shown, or if a feature will never be supported in the current session. Future WebXR features may not have other signals to detect whether or not they were enabled, and would require querying this attribute. #
This feature was specified in this Spec.
The "baseline-source" properties allows web developers to specify if an inline-level box should use the "first" or "last" baseline for alignment within an linebox. Today the default behaviour is confusing for web developers. Consider: test <div style="display: inline-block;">line1<br>line2</div> test <div style="display: inline-flex;">line1<br>line2</div> The "inline-block" will align to the last baseline, and the "inline-flex" will align to the first baseline. "baseline-source: auto" is the existing (confusing) behaviour. Web developers can specify "baseline-source: first" or "baseline-source: last" to directly determine how they want these boxes to align within a line-box. #
This feature was specified in this Spec.
font-variant-alternates enables simpler access to glyph alternates in fonts such as as a swashes, character-variants, ornaments and more. It provides an easier method over having to use 4-letter-codes as arguments to `font-feature-settings`. font-variant-alternates refers to the @font-feature-values at-rule to map speaking feature names to OpenType feature numbers. In the font-variant-style rule, the requested feature activation becomes easy to use and to read and allows flexible combination of font features. #
This feature was specified in this Spec.
Samples: https://roettsch.es/montecarlo.html
This release of Chrome had 0 new origin trials.
This release of Chrome had 0 are available behind a flag.
To keep the platform healthy, we sometimes remove APIs from the Web Platform which have run their course. There can be many reasons why we would remove an API, such as:
Some of these changes will have an effect on a very small number of sites. To mitigate issues ahead of time, we try to give developers advanced notice so they can make the required changes to keep their sites running.
Chrome currently has a process for deprecations and removals of API's, essentially:
You can find a list of all deprecated features on chromestatus.com using the deprecated filter and removed features by applying the removed filter. We will also try to summarize some of the changes, reasoning, and migration paths in these posts.
This release of Chrome had 0 features deprecated.
This release of Chrome had 3 features removed.
PaymentInstruments is the Web API that backs non-JIT install of payment apps (see https://w3c.github.io/payment-handler/). It was designed with the assumption that the browser would store the actual payment instrument details, which has not turned out to be true, and has some privacy leaks. It also has not shipped on any other browser, not have we seen any interest from other browser vendors. As such, this API has been deprecated and removed. #
This feature was specified in this Spec.
Deprecate the ability for Web Payment API to bypass the connect-src CSP policy when fetching the manifest. After this deprecation, a site's connect-src CSP policy will need to allow for the payment method URL specified in a PaymentRequest call, as well as any other URLs that the method chains to fetch its manifest. #
This feature was specified in this Spec.
The “canmakepayment” service worker event lets the merchant know whether the user has a card on file in an installed payment app. It used to silently pass the merchant's origin and arbitrary data to a service worker from payment app origin. This cross-origin communication happened on PaymentRequest construction in JavaScript, did not require a user gesture, and did not show any user interface. This silent data passage has been removed from the "canmakepayment" event (and the Android IS_READY_TO_PAY Intent). #
This feature was specified in this Spec.
Samples: https://rsolomakhin.github.io/pr/apps/romantic-dirt-jaguar