OpenType's string names for palettes and the colors inside them are meant to be displayed to the user, not the developer/author. The idea is for software to show a picker which displays the string names, and allow the user to interact with the picker. Then, the picker's internal logic would map the string names to indices internally, and supply the indices to CSS. The developer's/author's interface with these palette things in fonts is intended to be by index.
If a developer is hardcoding a particular palette or color in their CSS (rather than showing a picker), then they have already read the documentation for their font, and they know indices as well as names. (If they haven't read the documentation, neither string names nor indices will help them.) So, strings don't actually help in this use case.
The problem with the strings is that they are localized, so each of these strings actually has many different options inside the file to be compared with. Implementing the string comparison involves an O(n) search over the palettes, and for each of those, an O(m) search over the localizations. You could improve this performance with preprocessing, but that's preprocessing that would almost entirely be wasted work, since any given webpage would likely use only a small fraction of the number of localized strings in the font. The strings also don't have to be unique, so there would need to be some kind of tiebreaker scheme.
This is realized by a platform API exposing this information as something like getPaletteData(locale) -> map<index, localizedNameString>. Here, the platform API doesn't tell the browser about all the localized strings; but instead it just maps from index to the best (one) localized string - this one string is what the picker would display. Indeed; with this kind of platform API, a browser actually can't implement the <string> values in override-color and base-palette.
An additional problem is with author expectation, because different fonts will localize into different localizations. Would a French CSS author expect “rouge” to match “red?” It might for some fonts, but not others. Either the author actually knows specifically which strings will do what in their specific font (in which case they will also know which indices they could be using), or they don't know exactly what strings to use, and the strings will entirely end up being confusing. If the author says override-color: "red" blue; it's totally non-obvious why that replaces red with blue in one font but not another.
All this is just to support a feature that is rare in the wild - most CPAL tables don't actually have any of these strings at all. Instead of CSS accepting these string values directly, we should work on #6628.
OpenType's string names for palettes and the colors inside them are meant to be displayed to the user, not the developer/author. The idea is for software to show a picker which displays the string names, and allow the user to interact with the picker. Then, the picker's internal logic would map the string names to indices internally, and supply the indices to CSS. The developer's/author's interface with these palette things in fonts is intended to be by index.
If a developer is hardcoding a particular palette or color in their CSS (rather than showing a picker), then they have already read the documentation for their font, and they know indices as well as names. (If they haven't read the documentation, neither string names nor indices will help them.) So, strings don't actually help in this use case.
The problem with the strings is that they are localized, so each of these strings actually has many different options inside the file to be compared with. Implementing the string comparison involves an O(n) search over the palettes, and for each of those, an O(m) search over the localizations. You could improve this performance with preprocessing, but that's preprocessing that would almost entirely be wasted work, since any given webpage would likely use only a small fraction of the number of localized strings in the font. The strings also don't have to be unique, so there would need to be some kind of tiebreaker scheme.
This is realized by a platform API exposing this information as something like
getPaletteData(locale) -> map<index, localizedNameString>. Here, the platform API doesn't tell the browser about all the localized strings; but instead it just maps from index to the best (one) localized string - this one string is what the picker would display. Indeed; with this kind of platform API, a browser actually can't implement the<string>values inoverride-colorandbase-palette.An additional problem is with author expectation, because different fonts will localize into different localizations. Would a French CSS author expect “rouge” to match “red?” It might for some fonts, but not others. Either the author actually knows specifically which strings will do what in their specific font (in which case they will also know which indices they could be using), or they don't know exactly what strings to use, and the strings will entirely end up being confusing. If the author says
override-color: "red" blue;it's totally non-obvious why that replaces red with blue in one font but not another.All this is just to support a feature that is rare in the wild - most CPAL tables don't actually have any of these strings at all. Instead of CSS accepting these string values directly, we should work on #6628.