Chrome 97 arrived on the Stable channel early in January bringing along with it a bunch of new features including an updated Keyboard API which was dismissed by Apple and Mozilla for being too invasive of user privacy. Following a four-week development cycle, today we have the release of Chrome 98 to look forward to, and while it is not as controversial, one feature definitely sticks out.
.jpg){kind=link}
Chrome 98 is adding support for COLRv1 color gradient vector fonts, which are an evolution from their COLRv0. They bring more expressive visual capabilities in the form of gradients, compositions, transforms, multi-colored letters, even at very small font sizes. Google boasts that it was able to render the Noto Color Emoji using the COLRv1 font format with the size coming in at 1.85MB after WOFF2 compression. Meanwhile, the standard bitmap font takes up 9MB for the same emoji, making this a significant improvement.
As with any new browser feature, it is somewhat important to get a buy-in from other web browser vendors and web developers to ensure seamless cross-compatibility. Although Mozilla and web developers have cited their support for the new vector font, Apple"s WebKit and Core Text team have provided a negative signal for the proposal. Their reasons for opposing COLRv1 are as follows:
- It re-invents the wheel. This new format is as expressive and powerful as any general-purpose 2D graphics serialization format. There are many, many existing serialization formats for general-purpose 2D graphics.
- It doesn’t exist yet (outside of a development configuration of Chrome). OT-SVG, which is just as expressive, exists and has shipping implementations in DirectWrite, Core Text, Firefox, and many (most? all?) of Adobe creation apps. Many OT-SVG fonts already exist.
- Because this proposal doesn’t exist yet outside of Chrome, there is no ecosystem in existing authoring tools. Conversely, many design authoring tools already export SVG.
- Supporting both OT-SVG and this new proposal is twice (-ish) the maintenance burden, for a format that isn’t any more expressive than the format we support already.
- Supporting both OT-SVG and this new proposal increases 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 does involve an XML parser, but WebKit already links with an XML parser, so we expect the size of this new proposal to be roughly equal to the size increase we saw after implementing OT-SVG. This proposal would require its own novel parsing / overflow detecting / interpretation code.)
- Supporting both OT-SVG and this new proposal roughly doubles the surface area for security attacks for vector-based color fonts.
- Even considering an engine that only supports this proposal and not SVG, we haven’t seen any evidence that avoiding XML will reduce security bugs compared to a novel binary format. Historically, in WebKit, we’ve observed that opaque binary formats (like image formats) have plenty of their own security bugs.
- The spec has over 2,500 lines, and the images/ directory of the spec has 77 figures, and there is only a single implementation of this proposal. It’s complicated enough that we’re not confident that it can be implemented interoperably. We’re worried the behavior of the drawing operations may be specific to Skia, and difficult/impossible to implement on Core Graphics. For example, at first glance, we are not sure that the radial gradients in this proposal can be implemented on Core Graphics. As far as we’re aware, this proposal has not undergone a rigorous standardization process from many independent stakeholders.
- Embedding raster image data inside color font tables is common today, but this new proposal has no affordances for allowing it, despite its vector facilities being as expressive as any general-purpose 2d graphics serialization format. Therefore, it doesn’t actually improve upon the color font table fragmentation situation, which is widely regarded as one of the biggest drawbacks to color fonts today.
Regardless, the COLRv1 font format will be supported in Chrome 98.
Apart from this, other smaller improvements and enhancements are included in Chrome 98. Simple Data Encryption Standard (SDES) for key exchange is being phased out too because it has been dubbed as "historic" and is thus, a security risk.
A CSS media query is also being made available to web developers so that they can automatically detect HDR displays and render their content accordingly. For color adjustment, the "only" keyword has been reintroduced to the CSS color-scheme specification.
In lieu of a potential performance benefit and ease of development for some use-cases, support for Promises is being added for "ClipboardItem" objects. Moreover, developers can also utilize the "self.structuredClone()" method to clone and transfer objects. To avoid confusion and enable interoperability with standard specifications, some APIs for window popups are being changed too.
Stream writes can now be terminated immediately and Cross-Origin Resource Sharing (CORS) preflight requests can also be sent to target servers on private networks to first explicitly ask for permissions before subresources are accessed. Another method empowers developers to enable easier deletion of files using a file handle instead of being forced to get the parent directory first.
But that"s not all, there"s also a bunch of new stuff in DevTools for Chrome 98, be sure to check out all of them here.
Chrome 98 will start rolling out in the later hours of today. If it does not update to version 98 automatically for you throughout the course of the day, head over to Help > About Google Chrome to trigger the update once it becomes available. Next up is Chrome 99 which will hit the Beta channel on February 3, and will land on Stable on March 1.