Csswg-drafts: [css-fonts-4] font-variant-emoji property lacks an unopinionated, standardized default

[DeeDeeG]

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 \ 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 auto in 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 with auto, and hard to predict web content authors' choices, so I don't really know.

• auto and strict might be too similar, or identical, if browsers follow the standard guidance for auto. They might not be distinctly useful apart from one-another.

• strict would 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.

[litherum]

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.

I do agree that there are competing goals of "make it match the platform behavior" and "make it have the same behavior on all platforms." Having a "follow the Unicode spec" value sounds fine to me, though I disagree with your choice of names. We definitely can't eliminate the auto value, because platform integration is important too. Also, auto needs to be the default value because of existing emoji on the Web: we can't make all these emoji look different because we started implementing a new property.

[litherum]

We should ask implementors if there is interest in a "follow the Unicode spec" value. (It's fine with me, but if no one wants to implement, we shouldn't bother adding it to the spec.)

[js-choi]

On the other hand, is there a reason why a auto option that would leave presentation to the browser/platform would be desirable? Is this something that vendors want?

Inconsistencies with Unicode TR 51 have caused unexpected changes to previously authored content on the web. For instance, in 2015, WebKit unexpectedly started to render U+21A9 LEFTWARDS ARROW WITH HOOK “↩” as emoji, rather than text, in many pages that had already been using it as text, even for decades. See this Daring Fireball note and this Matias Singers post for real-world examples of this unexpected behavior change.

Had WebKit been following Unicode TR 51, this author-unexpected behavior would not have happened. The same goes for other browsers. Unicode provides a Unicode_Presentation property for precisely reason: to prevent author-unexpected default behavior in cases just like this. Is there a reason why vendor-dependent loose “auto” emoji-presentation behavior is even desirable, from an author’s point of view?

Edit: Made another post at [email protected] inviting the experts or authors of UTR51 to contribute to this thread.

[DeeDeeG]

I thought about this some more. I don't think this value would be much harder to implement than the others.

My reasoning is: implementations already need to know the list of Presentation Participating Code Points (PPCP) to implement the other values for font-variant-emoji. The hard part is just knowing the up-to-date list of PPCP (and wiring up the logic to have this affect font selection). Beyond the requirements of the other values, this value would only require a binary/boolean value associated with each PPCP. Each PPCP just needs to be noted as "default text" [per Unicode] or "default graphic" [per Unicode].

Thinking as an [amateur] programmer, I predict that a each PPCP codepoint number, and its corresponding default presentation per Unicode, can be thrown in an array, and there you go. (The programming logic to have this affect font selection shouldn't be much of a stretch beyond what it takes to do "always text-style" font selection, and "always graphic-style" font selection.)

Again, getting the list of PPCP (and being set up to do logic based on the list of PPCP) apears to be the bulk of the work, and I suspect adding a value to use the text/graphic default presentaion [per Unicode] would not be very hard.

[svgeesus]

Correct link to the property
https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-prop

[svgeesus]

It seems clear that we should have a value which means "follow UTR 51" (name to be decided) and that newer content might want to use that value site-wide to set a sensible default.

Once again we have an auto value which might not be trustworthy, and whose interpretation depends on the OS and browser (and browser version). I would still argue that this needs to be the initial value, agreeing with @litherum while also agreeing with @js-choi that authors should be able to opt-out of the non-web-compatible changes that platforms have suffered from in the past (it isn't clear to me if the ARROW WITH HOOK example was a bug or a deliberate change).

[svgeesus]

Also, I would prefer to avoid references to RFC 6919 where at all possible.

The phrase "MAY WISH TO" indicates a behavior that might seem
appealing to some people, but which is regarded as ridiculous or
unnecessary by others. This phrase is frequently used to avoid
further delay in approval of a document.

[DeeDeeG]

Is there some ongoing discussion about this? An IRC log or something like that? I'm curious where this is going, since I am kind of in the dark.

If not, that's fine too.

[svgeesus]

This issue is the ongoing discussion. Any discussion on a phone conference also gets posted here.

[css-meeting-bot]

The Working Group just discussed font-variant-emoji property lacks an unopinionated, standardized default, and agreed to the following:

• RESOLVED: Have auto follow platform conventions and add a new value called unicode to follow unicode conventions

The full IRC log of that discussion

<dael> Topic: font-variant-emoji property lacks an unopinionated, standardized default

<chris> q+

<dael> github: https://github.com/w3c/csswg-drafts/issues/1223

<astearns> ack chris

<dael> chris: Basically the thing with this is we describe auto which tries to do 2 things. User agents may follow unicode or ignore them and do what platform does. Seems like 2 use cases and you'll have UA and platform variations. Some people might want to say unicode is what we want, but you can't do that. You can say mostly I have text or mostly I have emoji. WE lack a 4th value that says do what unicode does

<dael> myles: I thinkt he idea of a new value is fine. It's fairly important that our default matches platfor so I agree can't be default, but a new value for follow unicode is fine

<dael> chris: myles does that sound like it has impl complexity?

<chris> ok

<dael> myles: I don't think that much. Prop has some complexity, but additional complexity isn't much bigger

<dael> myles: Can't speak for other browsers

<chris> other immplementors?

<dael> astearns: Do we also need a follow platform?

<dael> myles: Isn't that what auto is?

<dael> chris: At the moment auto isn't clear, but it I agree ti should be do what the platform does. THat's closes to current impl

<dael> myles: Sounds good

<dael> astearns: All engines or is there an engine that's been taking ambig in spec and it follows unicode

<dael> myles: As far as I know there are 0 impl

<dael> astearns: Prop: Have auto follow platform conventions and add a new value to follow unicode conventions

<chris> bikeshed the name?

<dael> fantasai: Call it normal? The new one. Auto is more magic, normal is follow a convention. There's prob a better name

<dael> myles: Unicode? OR resolve without name?

<dael> chris: Let's not resolve unless we're stuck. I think unicode is better

<dael> astearns: Objections to unicode as the name?

<dael> astearns: Prop Have auto follow platform conventions and add a new value called unicode to follow unicode conventions

<dael> RESOLVED: Have auto follow platform conventions and add a new value called unicode to follow unicode conventions

[Crissov]

unicode feels a bit odd, I would prefer normal or standard, but thatʼs really no showstopper.

[litherum]

The normal and standard way emoji is shown is according to platform conventions, not according to Unicode. Emoji is already shown on the web today.

[Crissov]

Unicode is the respective standard, hence standard.

[svgeesus]

Since @litherum and @Crissov used the terms normal and standard with different meanings, and both used unicode with the same meaning, it is clear that the CSS WG decision on naming was the correct one.