Here's what you need to know:
- The
hwb()color notation gives you a new way to specify color according to hue, whiteness, and blackness. - Fetch Priority give you a way to hint to the browser in which order resources should be downloaded.
- And there's plenty more.
Let's take a look at what's available in Chrome 101.
hwb() color notation
Described in an article by Stefan Judis as a "color notation for humans", hwb() specifies color according to hue, whiteness, and blackness. As with other color notations, an optional alpha component specifies opacity.
h1 {
color: hwb(194 0% 0% / .5) /* #00c3ff with 50% opacity */
}
This method of specifying color is now well-supported, with Firefox supporting it from version 96, and Safari from version 15.
Fetch Priority
Fetch Priority gives you a way to hint to the browser which order resources should be downloaded in, by using the fetchpriority attribute. This accepts values of "high", "low", and "auto".
"high": You consider the resource a high priority and want the browser to prioritize it as long as the browser's heuristics don't prevent that from happening."low": You consider the resource a low priority and want the browser to deprioritize it if its heuristics permit."auto": This is the default value that lets the browser decide the appropriate priority.
In the example below, a low priority image is indicated with fetchpriority="low".
<img src="/images/in_viewport_but_not_important.svg" fetchpriority="low" alt="I'm an unimportant image!">
Read more about the various use cases in Optimize resource loading with the Fetch Priority API.
Also in this release
There is a new method of forget() for USBDevice objects. This enables the forgetting of a device that previously had permission granted. For example, if this is an application used on a shared computer with many devices.
Also for Web USB, a fix to support [SameObject] for related attributes within USBDevice. The specification change can be found in a PR to the draft spec.
Dedicated workers loaded from a secure (HTTPS) origin, yet instantiated by insecure (non-HTTPS) contexts, are no longer considered secure. This means that inside such worker contexts:
- self.isSecureContext is now false.
- self.caches and self.storageFoundation are no longer available.
The popup argument for window.open() now evaluates to true, following a recent change to the spec for parsing this argument. Previously, when popup was set equal to true, window.open() was interpreted to mean false. This change makes boolean features easier to use and understand.
Further reading
This covers only some key highlights. Check the links below for additional changes to Chrome 101.