[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.

[Crissov]

Sad to see it didn't make the FPWD. I hope it'll get figured out soon.

[css-meeting-bot]

The CSS Working Group just discussed Override (Emoji) Variation Selectors, and agreed to the following resolutions:

• RESOLVED: Close issue 1144 no change

The full IRC log of that discussion

<dael> Topic: Override (Emoji) Variation Selectors
<dael> Github: https://github.com//issues/1144
<dael> fantasai: Some discussion about having font-varient-emoji give the default presentation for emoji in the text. Text can have a variation to say display as graphic or text and that overrides the font-varient default.
<dael> fantasai: This was opened to say the author should be able to override the text and they suggested syntax was to add an override keyword.
<dael> fantasai: Is this a feature we want? If so, is this the syntax?
<dael> TabAtkins: I'm not seeing the use case in the GH issue. We often let specific override general here.
<dael> Chris: I agree with TabAtkins. This is a lot like changing what the text content is which is not styling's job.
<dael> fantasai: I"m also skeptical there's a use case. One I can think of is in the user style sheet. I would lean toward not unless there's a clear use case.
<fantasai> s/not/not adding/
<dael> TabAtkins: I'm seeing a bunc hof specific use of the override character and I want to fix that. I suspect the use of the override is nil. That can be added in the future so no loss on not doing it now.
<dael> Chris: Right..
<dael> Chris: I also see Christoph asking us to liase with unicode. Does he think they have a different solution? I can't follow the argument.
<dael> fantasai: HIs original idea was it's a text tranformation that inserts the variation selector, but I don't see why we care.
<dael> fantasai: I'm not seeing a strong use case and I think we should close until we get an actual use case.
<dael> Chris: Suggesting close no action?
<dael> fantasai: Yeah, with that we would reconsider with an actual use case.
<dael> fantasai: That made it worth impl and testing time.
<dael> Chris: mmmmm.
<dael> Chris: I also see Raul asking about using this in general. Do we have an answer for him for how to do that? It seems like a seperate sub-issue.
<dael> fantasai: Is there a reason they won't be controlled by this prop?
<dael> Chris: Yeah, they're not variation selectors to do that. At the moment if you support color glyphs and this format you just display in color and maybe the user wants monochrome. That sounds more style-like.
<dael> Chris: I guess I could ask him to re-raise that as a seperate issue.
<fantasai> https://github.com//issues/1144#issuecomment-291458684
<dael> fantasai: This comment ^?
<dael> fantasai: That's a good quesiton because is the current feature restricted to emoji or effect all glyphs?
<dael> Chris: Right. I'm not fully up on variation selectors.
<dael> fantasai: If font-varient-emoji effects more than emoji we need a different name.
<dael> Chris: That one is only emoji according to unicode.
<dael> ACTION Chris ask Raul to re-raise https://github.com//issues/1144#issuecomment-291458684 in a seperate issue
<trackbot> 'Chris' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., chris, ChrisWilson).
<fantasai> https://github.com//issues/1144#issuecomment-294369645
<dael> Chris: Myles had agreed to this and wanted to add the override. Do you think he'd be okay with closing it?
<dael> ACTION ChrisL ask Raul to re-raise https://github.com//issues/1144#issuecomment-291458684 in a seperate issue
<trackbot> Created ACTION-861 - Ask raul to re-raise https://github.com//issues/1144#issuecomment-291458684 in a seperate issue [on Chris Lilley - due 2017-08-23].
<dael> Chris: I see Myles removed the needs edits. I'm feeling less comfortable about just closing. What's the sense of the people in the room? Do we close and let Myles object?
<dael> TabAtkins: I believe so. I've read through more and the jutification of the override is really choosing the defaults.
<dael> RESOLVED: Close issue 1144 no change
<dael> gsnedders: We missed Definiteness of flex items' main size depend on flex-basis's definiteness
<Chris> ??
<Chris> oh right

[Crissov]

Twitter (on its web site) replaces every character that can have an emoji representation by its respective Twemoji image, regardless of Variation Selectors. This is effectively like font-presentation: emoji override (or font-variant-emoji: chromatic override or whatever #1092 resolves to), but with Javascript and custom images. Their code is open-sourced and used on many other sites. Characters can be excluded from this aggressive conversion to images and Twitter does so for three of them: © ® ™.

If that does not prove demand, I don't know what would.

[tabatkins]

"Effectively", but not actually. They're doing something completely different by replacing with their own images; the question of variation selectors becomes moot.

If they were using native emoji, but wanted to make sure that they showed up in image form when possible, we don't know if emoji would be sufficient for them or not - they might be totally fine with people manually overriding the presentation if they want. Why not, after all?

Until/unless variation selectors actually become widespread enough that sites start wanting to care about them, we have no idea what the demand would be, and the WG doesn't think there's a strong reason to pursue this absent any active author interest; right now the demand is purely theoretical.

[Crissov]

Yes, they are using their own images, because there is no way to supply a custom emoji font to browsers across platforms. They could easily honor VS-15 and VS-16, but they do not. This is a very strong indication that Twitter et al. would prefer the same behavior if they could rely on emoji fonts. The emoji value does not provide this.

Hardly anybody ever enters variation selectors deliberately and manually, at least not for emojis. Everybody relies on emoji picker GUIs to inject them, some of which don't do that. Then you get ❤ instead of ❤️, whereas the other heart emojis always retain their color.
I agree, though, that it's rather unlikely to encounter VS-15 in the wild, i.e. ૌ︎. Like using text-transform to override the case of a letter the author entered, it is a valid design decision to override the presentation style of an emoji, without having to alter the underlying data. JFTR, that's why I always preferred a solution in CSS Text like text-transform-variant: emoji.

However, I have shown evidence that designers sometimes want to force emojis to render in a monochrome style, so they can use CSS effects and tricks on them like they can do on any other (printing) character – or just print them better/cheaper. Take the hearts again, they would all look indistinguishable from each other if all colors just became black, but as a text glyph they usually feature unique hatching patterns.

iOS also very aggressively enforces its colorful emoji glyphs, by the way. This can be obtrusive, especially in the case of icon fonts (like Font Awesome) which circumvent this problem by using PUA code points. Non-standard code points can negatively affect accessibility. If CSS allowed designers to enforce text style with glyphs from a web font, this problem would go away, assuming their font choice would then be honored. Apple could still only support their native design of emoji style, i.e. not support custom sbix fonts for that. The situation is not much different on Android (which uses a different font format for its emojis).

[tabatkins]

I agree, though, that it's rather unlikely to encounter VS-15 in the wild

That's the sticker here. The only point of an override option is to override usage of the VS-15/16 selector; as far as we can tell, approximately nobody is using those.

Any pointer to some application currently wanting all their emoji in one form vs another is, currently, just an argument that this property is wanted in its current form, where it can switch the emoji into one form vs the other. It's not immediately obvious whether any particular usage would want to specifically override the variation selector if it was specified; many might very well be fine with honoring them.

And even if they'd want to, the question is still how necessary/common it is, vs just letting the display occasionally be weird, or requiring the author to clean the data they're displaying to remove the variation selectors. We don't provide all possible text-transforms, after all, just a handful that seem sufficiently useful to justify speccing, implementing, and testing. Currently we don't think overriding variation selectors qualifies here; we're open to changing our mind if/when authors start actually experiencing variation selectors in user-entered content and complaining about it.

[Crissov]

Unlike VS-15, VS-16 is used a lot in the wild. Anyway, maybe text will indeed be enough for the icon font use case, because authors usually can control the presence of variation selectors there.

If @litherum agrees with this resolution (and if font-presentation becomes font-variant-emoji), I expect and prefer this would go into the Text module instead if the WG ever changes their minds.

[litherum]

I agree with the resolution.