[css-fonts-4] Should emoji be restricted in its range?

[fantasai]

Should the emoji generic family be restricted to the emoji-relevant unicode range so that it can play well with fallbacks? E.g. 'font-family: emoji, sans-serif`.

If so, what is the range of relevant characters? Anything with the emoji property to be sure, but also variation selectors, ZWJ, anything else?

[svgeesus]

Variation selectors are FE00 to FE0F.

Note that two VS overlap with the font-variant-emojiproperty to control the same thing: U+FE0E (VARIATION SELECTOR-15) selects text presentation U+FE0F (VARIATION SELECTOR-16) selects emoji-style

We should include all characters with the Emoji_Modifier property, which are currently all in the Miscellaneous Symbols and Pictographs block.

From UTR51:

The Extended_Pictographic property is used to customize segmentation (as described in [UAX29] and [UAX14]) so that possible future emoji zwj sequences will not break grapheme clusters, words, or lines.

Maybe Extended Pictographic property is a better category than Emoji property (it is a superset of the latter).

I think that should be taken into account when defining a range for this generic family.

Also from UTR51 ED-14:

emoji flag sequence — A sequence of two Regional Indicator characters, where the corresponding ASCII characters are valid region sequences as specified by Unicode region subtags in [CLDR], with idStatus="regular" or "deprecated".

[svgeesus]

Oh and there are also valid sequences with keycaps.

U+20E3 = enclosing keycap

[css-meeting-bot]

The Working Group just discussed Restrict unicode range of emoji generic family, and agreed to the following:

• RESOLVED: a note should be added that ua should filter at the time the user selects the font, or warn the user of the consequences

The full IRC log of that discussion

<fantasai> Topic: Restrict unicode range of emoji generic family
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2855
<frremy> myles: generic font families sometimes map to more than on font
<frremy> myles: to match all the languages and codepoints
<frremy> myles: but should we restrict these fonts so that they cannot use the emojis
<frremy> fantasai: so if the emoji font can either use all of its glyphs some might not be emojis
<frremy> fantasai: or you might get emojis from other fonts that is not the preferred emoji font
<frremy> myles: (restated the problem)
<frremy> myles: are there any implementation doing this?
<frremy> koji: not in blink
<frremy> frremy: I really don't know
<frremy> astearns: we could make it do what you want, but make the whole thing at risk?
<fantasai> s/or you might get emojis from other fonts that is not the preferred emoji font/you would then get regular text (Latin, CJK, whatever) that use the emoji font, preventing any fonts further in the fallback list from taking effect/
<frremy> myles: if you implemented this, we would map it to the emoji font
<frremy> myles: I think implementations will select one font, and we will make sure this font doesn't include other chars
<frremy> myles: so I'm leaning towards closing no-change
<frremy> fantasai: but then if the user changes the font
<frremy> ?
<frremy> myles: well, they get what they asked for, all the glyphs in the emoji font will be emojis....
<frremy> myles: don't set a font that contains non-emojis chars in it as your emoji font
<frremy> fantasai: the proposal I read was to restrict to unicode emojis
<frremy> myles: that doesn't work because our fonts include things that are not unicode emojis
<frremy> koji: there are pua for examples
<chris_> s/koji/chris/
<frremy> astearns: if we set a particular range for the emoji font
<frremy> astearns: and the font doesn't support something?
<frremy> florian: you fallback as usual to the next font
<frremy> fantasai: right, that doesn't seem a concern
<frremy> chris_: the other problem is that there are combining sequences
<frremy> chris_: some elements in the sequence might not be emojis
<frremy> chris_: you still don't want to change font
<frremy> myles: every year except one, the set has changed
<frremy> florian: so it's more reasonable to provide ua filtering at the font selection time
<frremy> florian: and generate a font subset for the user
<frremy> florian: based on what it thinks is an emoji at the time
<frremy> fantasai: I'd be ok with a non-normative advice to warn the user or generate a subset font of the font selected by the user
<frremy> fantasai: "may wish to consider"
<frremy> astearns: ok, any objection to a note saying that?
<frremy> RESOLVED: a note should be added that ua should filter at the time the user selects the font, or warn the user of the consequences

[svgeesus]

With the recent resolution of issue: 4442 Don't require browsers to always match every generic font family to a concrete font family, it is now clearer that

a) the other (new) generic font families may not map to at one matched face b) even if they do, there may be no match for a given codepoint.

[frivoal]

While the resolution of #4442 says we can, I'm unsure as to whether and how much we should restrict the emoji generic font family to a particular unicode range, primarily because I remain confused as to what it is for. The description in the spec doesn't help a whole lot: it says what emoji are, but this is a description of what sort of characters they are, not a description of any distinctive property that the emoji font is supposed to have for these characters (or other characters) compared to any other font that would also have glyphs for them.

[Crissov]

emoji would indeed make more sense in a font descriptor than as a font family.

@font-face {
  font-family: Twemoji;
  unicode-range: emoji;
} 

[ExE-Boss]

I’ve opened https://github.com/w3c/csswg-drafts/issues/4573 to add emoji to unicode‑range.

[frivoal]

I'm still not 100% sure, but the note in https://github.com/w3c/csswg-drafts/commit/3180a465cf87596f308ba49695f69718f55d7926 did help me.

Let me check if I understand this right now:

• emoji isn't supposed to be an emoji font, but effectively the system's emoji font (possibly customized through UA settings), and given a time machine, could reasonably have been called ui-emoji
• It is meant to be used like this font-family: emoji, "Foo Roman"; when "Foo Roman" is the font you really want to use, but it contains glyphs for the emoji range which you don't actual want to use, and prefer keeping the system's default.

If so: 1) The description of the value should say that this is what it is 2) It needs to be restricted to a range that doesn't include U+0020 (so that it doesn't get considered as the first available font and influences line height of font relative units) nor non-emoji characters (so that it can be put at the top of the font stack without highjacking non emoji characters).

[svgeesus]

Closed because

• https://github.com/w3c/csswg-drafts/issues/9359