[css-text][css-fonts] Override (Emoji) Variation Selectors

[Crissov]

 font-presentation: auto | text | emoji

• CSS Fonts Level 4

Even when font-presentation is used, the presence of Variation Selector 15 (U+FE0E) or Variation Selector 16 (U+FE0F) in the contents of an element override the rendering specified in font-presentation. Therefore, font-presentation sets a default presentation which the text being rendered can opt out of.

Continuing #352 and leaving #1092 aside for now, the draft Fonts property could be left as is, but then should be accompanied by a Text property able to override variation selectors 15 and 16 (and possibly others as well).

Possible solution with CSS-Text

text-transform-variant: none | emoji | text | <integer>

• none: no changes
• <integer>: apply Unicode variation selector
• text: same as 15
• emoji: same as 16

---

• Issue: There are 256 general-purpose variation selectors in two different Unicode blocks (U+FE0x and U+E010yz, y != F) that could be accessed this way, but also some script-specific ones – U+180B–D for Mongolian in particular – that would need additional keywords to be covered.
• Note: VS-4 through 14 are not used yet in StandardizedVariants.txt

Possible solution without CSS-Text

 font-presentation: auto | text | emoji | text-override | emoji-override

or

 font-presentation: auto | (text | emoji) override?

[AmeliaBR]

The question of whether to have a text-transform sub-property, or additional keywords to the font-presentation property, should be addressed in the context of the font selection algorithm. font-presentation is intended to affect font selection, text-transform does not.

I personally like

font-presentation: auto | (text | emoji) override?

[RoelN]

Is the restriction to emoji intentional? I would be useful to be able to apply this to color fonts as well. In other words, be able to turn color glyphs on or off:

<h1>
  Welcome to <span>our redesigned website!</span>
</h1>

h1 {
  font-family: MyColorFont;
  font-presentation: no-color;
}

h1 span {
  font-presentation: color;
}

[Crissov]

@RoelN The overriding variation selectors part is special to emojis (although it could be applied to other sequences in StandardizedVariants.txt). In #352, I originally wanted to cover color fonts as well, but that was not considered helpful: WG members and other participants – myself included – got confused, the discussion got side-tracked. That's not saying it's a bad idea per se.

[litherum]

text-transform-variant: none | emoji | text | <integer>

Variation sequences are assigned such that accessing the glyphs in a particular collection might use VS01 for one base character but VS02 for another. What’s more, a particular VS might result in a different glyph depending on the region. Therefore, rendering as if a non-VS15-non-VS16 variation selector was applied to every character is meaningless and is author-hostile. (VS15 and VS16 are special because their meaning is consistent across characters and regions, but this isn't true of the other variation selectors.)

[litherum]

Why would you want to override the source content's use of VS15 or VS16? Are authors asking for this? I've heard authors asking for a default, but not for an override.

[Crissov]

Even the editors of UTS#51 are asking for this. We've been there before, e.g. #352 (comment) and #352 (comment).

You are right that VS 15 and 16 are special in that they have defacto semantics, whereas the other variation selectors are arbitrary for math characters, but VS-1 consistently selects the dotted form in Burmese, reversed shaping behavior for Phags-Pa, and an alternate form for isolate Manichaean letters. Mongolian VSs are also somewhat regular, but are not part of the enumerated series of generic VSs.

[kojiishi]

Can you point to the specific text you're referring to? I can't find them from the links. They read to me that requesting the ability to choose, not the ability to override the source.

[Crissov]

Most symbol fonts like Font Awesome are using PUA characters (exclusively) because authors that use them wish for consistent symbol design and do not want the characters which have Unicode emoji equivalents to be displayed with the OS default emoji font or graphics.

The text of #352 (comment) paraphrases an email I received from Mark Davis. I could cite it here verbatim if that's considered okay.

UTR/UTS#51:

Certain emoji have defined variation sequences, in which an emoji character can be followed by an invisible emoji presentation selector or text presentation selector. […] Some systems may also provide this distinction with higher-level markup, rather than variation sequences.

It's unrealistic to assume a closed system where either only VSs or “higher-level markup” controls the display. The web platform has to deal with a mix of both.

However, even for cases in which the emoji and text presentation selectors are available, it had not been clear for implementers whether the default presentation for pictographs should be emoji or text. That means that a piece of text may show up in a different style than intended when shared across platforms. While this is all a perfectly legitimate for Unicode characters—presentation style is never guaranteed—a shared sense among developers of when to use emoji presentation by default is important, so that there are fewer unexpected and "jarring" presentations.

[…] every emoji character with a default text presentation allows for an emoji or text presentation selector. Thus the presentation of these characters can be controlled on a character-by-character basis. […]
In addition, the next […] sections describe […] other mechanisms for globally controlling the emoji presentation […]

These are currently limited to specifying a baseline preference, not overrides.

[…] in some CSS implementations, if any font in the lookup list is an emoji font, then emoji presentation is used whenever possible.

This is the status quo. The original UTC request from 2015 is based upon L2/15-314:

There is a need for a mechanism in CSS to indicate a preference for the presentation style of characters that can have either a “text” or an “emoji” style of presentation. The preference should permit three values:

• For all such characters, use the “text” presentation style if supported.
• For all such characters, use the “emoji” presentation style if supported.
• For all such characters, use the default presentation style (e.g. as specified in emoji­data) if supported.

This is also only about the default presentation, as noted by i18n WG.

The question from Stackoverflow I already cited shows that some authors want to be able to reliably treat emoji glyphs like any other monochrome text glyph and not like a bitmap with inherent, fixed colors.

[DeeDeeG]

I'm for overrides. Authors should be able to style text the way they want. This could definitely come in handy.

For example, I might be designing a social media oriented site, with an expectation of showing emoji, but users might copy/paste and submit text that includes vs-15 unwittingly. Most users do not know about or understand how to type/delete variation selectors, so this could cause a problem where users complain they aren't seeing emoji when they should be.

Or, I could be designing a site (or a blog theme, to be redistributed freely) where headers should always display emoji, as a deliberate style choice, regardless of whether a vs-15 was accidentally included.

On the contrary, as Crissov linked to, some folks really do need to be able to style things as text, to make sure they have the expected visual, and to aid accessibility by ensuring high contrast, or even just to be consistent with surrounding text. Being able to style with color:#fffaaa is a big deal, and required for some use cases.

And typing/deleting variation selectors is cumbersome. Many I would presume don't know how. A css style should be able to force consistency.

(On the other hand, once these proposed CSS controls are implemented, and VS-16/VS-16 behavior is properly standardized, it might be more obvious that the VS characters need to be entered correctly, and the impetus could be on the person who provides the text to make sure they are providing the correct presentation (i.e. Typing correctly, or else copying/pasting from the right source). I prefer that site operators have the option of overriding, though.)

(Deleted my comments from before, as they were based on a misunderstanding.)

[litherum]

Unless @kojiishi has anything to add, it seems like there's consensus about overrides. I'll add the following syntax to the spec:

font-presentation: auto | (text | emoji) override?

... and then close this issue.

[kojiishi]

I'm good to add, but I can't read what i18n/UTC wants about priority.

Could we ask them back about their recommendation?

I think we have 2 or 3 mechanism to choose; VS, this property, emoji generic family (is this still alive?)

I just want we agree on priority with UTC.

[Crissov]

Great to see progress on this, but W3C should definitely consult UTC again before deciding on a Fonts-only solution. They might favor an approach that allowed higher-level control over variation selectors, because it's somewhat similar to case transforms.