Google Chrome 98 will support the new version of vector color fonts

Google Chrome 98 will support the new version of vector color fonts,  Apple and Mozilla explicitly objected

Google Chrome 98 will support the new version of vector color fonts,  Apple and Mozilla explicitly objected. 

In early January, Google Chrome 97 landed on the stable channel, bringing a slew of new features, including an updated keyboard API, which was rejected by Apple and Mozilla for being too easy to violate user privacy.

After a four-week development cycle, we can expect the release of Chrome 98 in February , and while it’s not as controversial, there’s one feature “COLRv1” that definitely stands out, and not only that, it’s sparked controversy.

Google Chrome 98 adds support for COLRv1 color gradient vector fonts, an evolution of its COLRv0.

They bring more expressive visual power in the form of gradients, composites, transformations, multicolor letters, even at very small font sizes.

According to Google, it can render the Noto color emoji using the COLRv1 font format, which is 1.85MB in size after WOFF2 compression.

At the same time, for the same emoji, the standard bitmap font takes up 9MB, which is a significant improvement in saving system resource overhead.

As with any new browser feature, it is important to gain support from other web browser vendors and web developers to ensure seamless cross-compatibility.

While Mozilla and web developers have mentioned their support for the new vector fonts, Apple ‘s WebKit and Core Text teams have opposed the proposal, arguing against COLRv1 for the following reasons:

It reinvents the wheel. This new format is as expressive and functional as any general 2D graphics serialization format.

There are many, many, many serialization formats for general-purpose 2D graphics.

It also doesn’t exist outside of Chrome’s developer ranks. OT-SVG is equally expressive, and exists and has transport implementations in DirectWrite, Core Text, Firefox, and many (most) Adobe authoring applications. Many OT-SVG fonts already exist.

Because this advice doesn’t yet exist outside of Chrome, there is no ecosystem in existing authoring tools. Instead, many design authoring tools already export SVG.

Supporting both OT-SVG and this new proposal is twice the (-ish) maintenance burden, and this format is no more expressive than what we already support.

Supporting both OT-SVG and this new proposal will increase our binary size.

We expect the additional binary size increase to be roughly equivalent to the binary size increase we observed after implementing OT-SVG. (OT-SVG involves an XML parser, but WebKit already has an XML parser associated with it, so expect this new proposal to be roughly equal in size to the size increase we see after implementing OT-SVG, which requires its own new parsing/overflow detection/interpretation code).

Supporting both OT-SVG and this new proposal doubles the surface area of ​​security attacks for vector-based color fonts.

Even considering an engine that only supports this recommendation and not SVG, we haven’t seen any evidence that avoiding XML would reduce security vulnerabilities compared to a new binary format. Historically, in WebKit, we have observed that opaque binary formats such as image formats have many security holes of their own.

The spec is over 2500 lines long, the spec’s images/ directory has 77 numbers, and there is only one implementation of this proposal.

It is complex enough that we have no confidence that it can be implemented interoperably.

We’re concerned that the behavior of drawing operations might be Skia-specific and difficult/impossible to implement on Core Graphics.

For example, at first glance, we are not sure whether the radial gradient in this proposal can be implemented on Core Graphics.

To the best of our knowledge, this proposal has not gone through a rigorous standardization process by many independent stakeholders.

Embedding raster image data in color font tables is common today, but this new proposal has no ability to allow that, although its vector facilities are as expressive as any common 2D graphics serialization format.

So it doesn’t actually improve the situation of color font table fragmentation, which is widely regarded as one of the biggest drawbacks of color fonts today.

However, regardless of Apple’s objections, the COLRv1 font format will be supported in Chrome 98 first.

In addition to this, Chrome 98 also includes other smaller improvements and enhancements.

The Simple Data Encryption Standard (SDES) for key exchange is also being phased out because it is called “historic” and therefore a security risk.

A CSS media query is also provided to web developers so that they can automatically detect HDR displays and render their content accordingly.

For color adjustments, the “only” keyword has been reintroduced into the CSS color mode specification.

In lieu of potential performance benefits and ease of development for some use cases, support for promises is being added to the “ClipboardItem” object.

Additionally, developers can use the “self.structuredClone()” method to clone and transfer objects.

To avoid confusion and achieve interoperability with standard specifications, some APIs for window popups have also been changed.

Streaming writes can now be terminated immediately, and Cross-Origin Resource Sharing (CORS) preflight requests can also be sent to target servers on private networks, which explicitly ask permission first before accessing subresources.

Another approach enables developers to use file handles to delete files more easily, rather than being forced to visit the parent directory first.

Learn more about COLRv1:

https://developer.chrome.com/blog/colrv1-fonts/ 

But that’s not all, there are quite a few improvements in Chrome 98’s DevTools, you can see them all here:

https://developer.chrome.com/blog/new-in-devtools-98/

Chrome 98 will start rolling out later today. If you don’t automatically update to version 98 during the day, go to Help > About Google Chrome to trigger an update once it is available. Next up is Chrome 99, which will enter the Beta channel on February 3rd and will hit the stable release on March 1st.