Experimental Chromium Web Platform Features

The prototype implementation (which was shipped in 2020 and then shape-changed in 2023) contained a method called `getInnerHTML()` that could be used to serialize DOM trees containing shadow roots. That part of the prototype was not standardized with the rest of declarative shadow dom, and only recently has it reached spec consensus (https://github.com/whatwg/html/issues/8867). As part of that consensus, the shape of the getInnerHTML API changed. This feature represents the desire to ship the new, agreed-upon shape, which is: - getHTML({serializableShadowRoots:bool, shadowRoots:[roots]}).

The prior behavior caused issues if a top layer element (dialog, fullscreen, etc.) was DOM-nested within a popover. The inner element, when promoted to the top layer, would cause the outer popover to be hidden, which also (via CSS display:none) hid the inner element. That, in turn, caused issues at least for dialogs, which inert the entire page. This change makes top layer elements "nestable" within popovers.

This enables individual control over whether a shadow root is clonable (via standard platform cloning commands such as `cloneNode()`). Imperative shadow roots can now be controlled via a parameter to `attachShadow({clonable:true})`. Declarative shadow roots can be controlled via a new attribute, `<template shadowrootmode=open shadowrootclonable>`.

Functionality added to the WebGPU spec after its first shipment in a browser. ServiceWorker and SharedWorker support is added to WebGPU, aligning with existing WebGL capabilities.

UAs are starting to provide writing suggestions to users as they type on various editable fields across the web. While this is generally useful for users, there are cases when developers may want to turn off UA-provided writing assistance, such as extensions or sites that wish to provide similar functionality on their own. To that end, developers need a solution that would turn on/off UA-provided writing assistance. The new attribute 'writingsuggestions' has values 'true'/'false' that would allow developers to turn on/off browser-provided writing suggestions. The attribute's state for an element can also be inherited from ancestor elements, thereby allowing developers to control this functionality at a per-element or per-document/sub-document scale.

CSS property writing-mode allow elements to go vertical, but users cannot set the direction in which value changes. With this feature, we are allowing the form control elements meter, progress and range input type to have vertical writing mode and choose the form control's value direction. If direction is rtl, the value is rendered from bottom to top. If direction is ltr, the value is rendered from top to bottom. For Web compatibility, we plan to slowly rollout the change in 123 and enable in stable in 124.

Improves accessibility by making scroll containers focusable using sequential focus navigation. Today, the tab key doesn't focus scrollers unless tabIndex is explicitly set to 0 or more. By making scrollers focusable by default, users who can't (or don't want to) use a mouse will be able to focus clipped content using a keyboard's tab and arrow keys. This behavior is enabled only if the scroller does not contain any keyboard focusable children. This logic is necessary so we don't cause regressions for existing focusable elements that might exist within a scroller like a <textarea>.

This is about adding support in Chrome for the VoiceIsolation getUserMedia constraint (https://w3c.github.io/mediacapture-extensions/#voiceisolation-constraint). The constraint only takes effect on platforms where there is low-level support for voice-isolation style denoising. Currently this is limited to a selected number of ChromeOS devices, but further platforms will be added.

Allows <button> and <datalist> in <selectlist> which replace the default button and listbox respectively, as well as introducing a new <selectedoption> element that shows the chosen value.

This feature allows web developers to create WebAuthn[0] credentials (that is, "publickey" credentials, aka passkeys) in cross-origin iframes. Two conditions are required for this new ability: 1. The iframe has a publickey-credentials-create-feature permission policy. 2. The iframe has transient user activation. This will allow developers to create passkeys in embedded scenarios, such as after an identity step-up flow where the Relying Party is providing a federated identity experience. [0]: https://w3c.github.io/webauthn/