Explanations for use cases, other review comments addressed

Author: drott

css-conditional-5/font-tech-format-explainer.md

@@ -8,32 +8,53 @@
 
 ## Introduction
 
-`font-tech()` and `font-format()` are extensions to the CSS Conditional Syntax
-which enable declarative syntax to use a different set of style rules depending
-on font format support, as well as programmatic feature detection of
+`font-tech()` and `font-format()` are extensions to the `@supports` rule CSS
+Conditional Syntax.  As such they enable declarative syntax for applying a
+different set of style rules depending on font format support. When used through
+the `CSS.supports()` method, they also enable programmatic feature detection of
 capabilities of the font stack. The latter covers a lack of functionality in web
-platform APIs, as most JS APIs and DOM functionality can be easily feature
+platform APIs because most JS APIs and DOM functionality can be easily feature
 detected, but the abilities of the font stack could not be queried in that way
 so far.
 
 The proposed syntax was introduced following discussion in [TAG review
 #666](https://github.com/w3ctag/design-reviews/issues/666) on a previous syntax
-for the `src:` descriptor, and subsequent [resolutions in the CSS
-WG](https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-947810568) to
-harmonize functionality between the `src:` descriptor parsing, and CSS
+for the `src:` descriptor on `@font-face`, and subsequent [resolutions in the
+CSS WG](https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-947810568)
+to harmonize functionality between the `src:` descriptor parsing, and CSS
 Conditional behavior with respect to font feature detection. This had been a
 [request of the
 TAG](https://github.com/w3ctag/design-reviews/issues/666#issuecomment-901220221)
-review.
+review. The syntax between the `src:` line and the `font-*()` conditional
+functions differs insofar as in the `src:` descriptor it is clear that the
+context is font-related, so the `font-` prefix is dropped, compare `font-tech()`
+vs `tech()`, and `font-format()` vs. `format()`. But the single keyword
+arguments to these functions are kept in sync between the two specifications.
+
+The intention of such a syntax and feature detection is to be able to determine
+whether a UA supports the different technologies that may be required by a
+specific font file.
+
+From a mime type and file signature point of view [OpenType font
+files](https://docs.microsoft.com/en-us/typography/opentype/spec/otff#table-directory)
+all appear the same. However, because the OpenType font file is a container
+format, such a font file can make use a number of different font technologies
+that have evolved over the years (
+[history](https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md#history-of-font-technologies).
+So the file signature or mime type for font files is not sufficient to identify
+whether a UA's font stack would support it. Instead it is necessary to
+distinguish what text layout (OpenType, AAT, Graphite) or rasterisation
+technologies (TrueType contours, variations, bitmap color font formats, vector
+color font formats etc.) are used by the respective font file.
 
 ## Use cases
 
-Background: The use cases listed below for are very similar to the `tech()` and
+Background: The use cases listed below are very similar to the `tech()` and
 `format()` extensions to parsing the `src:` line of the `@font-face`
 declaration, [see
 here](https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md#use-cases). There,
-the focus is on resource loading on the `@font-face` level. Here the focus is
-more on more general feature detection outside the `src:` line for progressive
+in the src: descriptor, the focus is on resource loading on the `@font-face`
+level. Here the focus is more on more general feature detection for progressive
 enhancement through style rule or programmatic detection of feature support.
 
 1. I want to progressively enhance my site depending on font format capabilities
@@ -65,6 +86,14 @@ Examples:
 
 ### Use Case 1 - Progressive Enhancement with color fonts
 
+By default, use a monochromatic icon font for icons. Only when font support for
+colored layers—such as in a COLRv0—font is available, upgrade to a COLRv0 font
+with multi-colored glyphs.
+
+Without feature detection, sending a COLRv0 font to to a UA with an incompatible
+font stack will lead to unexpected and potentially illegible results. Detecting
+the feature allows progressive enhancement.
+
 ```
 .icons {
   font-family: monochromatic_icons;
@@ -77,11 +106,25 @@ Examples:
 }
 ```
 
+
 ### Use Case 2 - Programmatic font support detection
 
-```
-let vectorColorFontsAvailable = CSS.supports("font-tech(color-COLRv1)") || 
-                                CSS.supports("font-tech(color-COLRv0)") || 
-                                CSS.supports("font-tech(color-SVG)");
+If a page wants to dynamically include additional stylesheets or content, it is
+desirable to select those based on font technology support to minimize download
+size. For example, if vector color font support and palette support is
+available, a stylesheet with palette information plus a vector color font may
+be loaded. If palette support is missing the stylesheet containing palette
+overrides is not needed.
 
 ```
+if (CSS.supports("font-tech(palettes)") {
+  // Load palette styleheet here.
+  if (CSS.supports("font-tech(color-COLRv1)")) {
+    // Load COLRv1 font here.
+  } else if (CSS.supports("font-tech(color-COLRv0)) {
+    // Load COLRv0 font here.
+  }
+} else {
+  // Don't include palette override stylesheet, load monochromatic font here.
+}
+```