This is the umbrella for non-blocking HTML deprecation issues. We should address them as soon as possible, but they will not block the deprecation process. Each bullet is an issue, and the sub-bullets explain why it regresses due the HTML deprecation and why it's non-blocking:

• Switch to sliced CJK fallback fonts (Flutter web's TextField displays gibberish for Unicode inputs, such as Korean characters (CJK) #138288). Currently, CJK fonts are not sliced. To render a single character of, say, Korean, we fetch a 6MB font file. Instead, sliced fonts are 30-60kb per file, and you only need a few of them to cover text that fits on one screen.
  • Regression: because the HTML renderer can use browser built-in fonts, the 6MB fallback will be observed as a big regression.
  • Non-blocking: because developers can supply their own fonts, and employ strategies such as prefetching fonts based on the user locale/language preferences (e.g. window.navigator.languages).
• Switch to COLRv1 emoji font ([web][3.7] Emojis are not properly rendered #119536). The useColorEmoji is available, but it fetches a 24MB font file, which is not practical for most apps. The reason why it's so big is because the font bundles a bitmap for every emoji. Flutter supports COLRv1 vector format, which is orders of magnitude more compact:
  • Regression: same as with the CJK fonts, HTML renderer can use browser built-in emojis. Switching to CanvasKit would cause emojis to become grayscale, and useColorEmoji is too expensive.
  • Non-blocking: because the developer can provide their own trimmed emoji font, and not need our fallback.
• High-quality image scaling (CanvasKit Image downscaling is poor quality compared to HTML and Native #135655). Our current image options seem to be too confusing to get good image scaling results. On the web, as a developer, one rarely needs to do anything about images, and they just show up at high quality. The HTML renderer inherits it from the browser.
  • Regression: image quality can degrade when scaled in some situations, and CanvasKit needs hand-holding to get to the right quality.
  • Non-blocking: there is a way to get decent quality using the available options like FilterQuality. The developer can use browser APIs to scale the image and then render it into Flutter without scaling.
• Backdrop filter support in platform views (BackdropFilter does not blur platform views on the web #143747). This is simply not implemented in CanvasKit and Skwasm.
  • Regression: apps that rely on HTML renderer's BDF support will stop applying the effect to platform views.
  • Non-blocking: this only affects the case when BDF and platform views are used at the same time. The vast majority of apps are able to alter their UX in a way that does not hit this case. A good amount of prep work has been done to implement support in CanvasKit. Worse case, an app that critically needs this, can skip a Flutter SDK release, and get the feature in the next release.