New in Chrome 108

Here’s what you need to know:

It is easier to create adaptive UIs with new viewport size units.
Color vector fonts now include support for variable fonts.
The methods in the interface FileSystemSyncAccessHandle, part of the File System Access API, are now synchronous.
And there’s plenty more

I’m Adriana Jara. Let’s dive in and see what’s new for developers in Chrome 108.

New viewport size units

The new viewport units give you more control to create adaptive UIs.

These units measure the viewport area differently, as they take into account UI elements in the browser that can be expanded or collapsed. For example, the address bar.

The large units provide the viewport size assuming that those user agent interfaces are collapsed.

On the other hand the small units provide viewport size assuming the interfaces are expanded.

And with dynamic units the viewport size will automatically adjust itself in response to browser interface elements being shown or not.

The value will be anything within the limits of the large unit (the maximum) and small units (the minimum).

The different parts of the viewport for each type of viewport unit.

Check out this article for more details. Also checkout the change on Android viewport resizing behavior to handle your viewport appropriately .

Variable fonts now supported in COLRv1.

COLRv1 color vector fonts have been supported since Chrome 98, but the initial release supported only static functionality of the COLRv1 table.

But COLRv1 specification also includes OpenType Variations, which means allowing changes to font properties by changing variable axis values. Such variations are supported now.

This release also includes the font-tech() and font-format() condition extensions to CSS @supports .

With these conditions the developer can detect when the font features are available to give the user the latest experience and also create a fallback if the support is not available.

Play with the demo here and add impact to your words with variable fonts.

FileSystemSyncAccessHandle methods are now synchronous.

The origin private file system provides access to a special kind of file that is highly optimized for performance, developers can get access to such files by calling createSyncAccessHandle(), which is a method exposed on FileSystemFileHandle objects.

This call results in a FileSystemSyncAccessHandle.

The methods truncate(newSize), getSize(), flush(), and close() in that access handle, used to be asynchronous, but they are synchronous as of Chrome 108.

There is a good reason for the change, it makes FileSystemSyncAccessHandle match the synchronous, POSIX-like file API that Wasm-based applications expect; making the API more ergonomic while bringing substantial performance gains.

This is a potentially breaking change, if you are using the methods above, any use of Promise.then() will break. If you chain a then() call on the result of any of the previously asynchronous and now synchronous methods, you need to change your code.

// ⛔️ This will break, and you need to restructure your code:
accessHandle.flush().then(/* Follow-up code */);
// ✅ Correct:
accessHandle.flush();
/* Follow-up code */

For more detailed instructions visit this article

And more!

Of course there’s plenty more.

A change in the behavior for overflow on replaced elements is being rolled out.
If you are an identity provider check out the Federated Credential Management API.
The Media Source Extensions API is now available in the worker context.