[css-fonts-4] font-variant-emoji property lacks an unopinionated, standardized default #1223
Description
Background
This issue is regarding the draft "font-variant-emoji" property, which specifies how to handle text-style or emoji-style rendering of otherwise ambiguous, "emoji-or-text" code-points.
(background from Unicode: http://unicode.org/reports/tr51/#Presentation_Style)
Draft: https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-desc
With this draft property we have 3 values:
Value: auto | text | emoji
and auto is the default:
Initial: auto
Auto is understandably rather flexible, allowing the browser some discretion with how to render emoji code-points and still be compliant with the spec. This lets platforms innovate more readily, or project their desired brand image/make style choices as they wish. (Indeed, the entire auto value is defined with MAY statements, and can behave fully arbitrarily and still be technically compliant with the draft spec.)
Unfortunately, though, users must specify that they broadly prefer text presentation, or that they broadly prefer emoji presentation, in order to be guaranteed any actually standard behavior. (i.e. font-variant-emoji:text, or font-variant-emoji:emoji).What if a web author just wants a standard default, and decides to follow the Unicode guidance? Right now the author must "pick a side" (text or emoji default) or expose themselves to deliberately unstandardized implementations of font-variant-emoji:auto. Where is the "just make it work" aka "just follow the Unicode spec" option?
Suggestion
I would advocate for an additional ("strict," or "unicode," "fallback," etc. whatever name) value for the font-variant-emoji property, which behaves as follows: the browser first understands any VS 15 to mean text presentation, understands any VS 16 to mean emoji presentation, and then otherwise falls back on the default guidance by Unicode. This allows developers to count on a sane default, and banish platform inconsistencies, without having to be opinionated about wanting to err on the side of text or err the side of emoji. And to put it another way, allows content authors to have the option to consistently follow the Unicode guidance.
One could apply font-variant-emoji:strict to the <body> and have access to easy standardized emoji behavior throughout their site, in a general-purpose kind of a way. One line of css and you're done.
Ideally auto might come to be seen as the "integrate better with the platform/browser" option, and strict could be seen as a no-fuss unbranded fully-standard choice.
Issues
-
This kind of shoots
autoin the foot, making "strict" seem like the obvious choice for content authors in my opinion. But it's hard to predict what browser vendors would do withauto, and hard to predict web content authors' choices, so I don't really know. -
autoandstrictmight be too similar, or identical, if browsers follow the standard guidance forauto. They might not be distinctly useful apart from one-another. -
strictwould be the only value requiring knowledge of the Unicode default presentations of emoji, so slightly more technically complex to implement. Browsers might not find this worthwhile enough to implement, opting to just support the other values. Or might be the part of the spec with the most typo-related bugs in browsers. Or default presentation list might become out of date with new unicode versions, etc.