[css-fonts-4] font-variant-emoji: Consider broadening to all "color fonts" use-cases, not just emoji PPCP

[DeeDeeG]

Background

Regarding the font-variant-emoji draft CSS property:
https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-desc

This draft property is designed to deal with ambiguity in how to display "Presentation Participating Code Points." (PPCP)

The draft property font-variant-emoji came about after a request in #352

Why I'm filing this issue

However, in the comments of #1092 (comment), I started a mini-discussion about what the draft spec would likely lead to in terms of technical broad-strokes details of implementations.

Basically, I expect this proposed property will act as a toggle for explicit-color vs inherited-color-only font formats. As in, it will help content authors disable or explicitly specify the use of fonts with baked-in colors (such as with an SVG, SBIX, COLR/CPAL, or CBDT/CBLC OpenType table) most likely as a font fallback mechanism.

The meat of the issue

• I think disabling (or expressly requesting) color fonts is a pretty powerful feature.
• I think Presentation Participating Code Points are a niche (emoji code points with more ambiguous presentation than usual) within a niche (emoji usage on the web).
• Color fonts are not limited to displaying emoji

Given how powerful this feature is, I think it is mis-matched to a tiny use-case. This mechanism, I suggest, should be available for broader control of whether or not richly colorful font tables (such as sbix, CBDT/CBLC, COLR/CPAL, SVG) are displayed, vs traditional outline font tables.

I also posit that the only under-the-hood implementation difference between the draft spec as-is, and my suggestion, is that under my suggestion, browsers would not need to check if a character is a PPCP or not. Everything else (besides the property name, I guess) would be the same.

Potential downside to my suggestion

If users only ever want to use this property to control the appearance of emoji PPCP, then applying it more broadly will not be helpful, the property name will likely be less intuitive for that use-case, and not narrowing it to emoji PPCP might be seen as a mistake.

Essentially, I think the decision comes down to one question: "Would users want this mechanism to be applicable beyond emoji PPCP, or would they want it to be only applicable to PPCP?"

This has been talked about before

I'm basically agreeing with the broad strokes of John Dagget's post back in 2014: https://lists.w3.org/Archives/Public/www-style/2014Aug/0322.html

(Where this issue and John Dagget's post differ, I mean what I say here, rather than what he says there. I am not just +1ing that post, but I acknowledge that what I'm saying re-treads a lot of ground that has been talked about before. This issue I'm filing is still needed, as this subject hasn't reached a consensus, despite (sporadic, often a bit technically unclear) prior discussion.)

[litherum]

If this new behavior is used on a non-color font, it would (necessarily) have no effect. Otherwise, (if this new behavior is used on a color font), it would only allow the page author to opt-out of color rendering (because color rendering is the default). So, this issue is asking the question: should we let color fonts render in a non-color mode?

We should not allow color fonts to render in a non-color mode, because the presence of color is intrinsically linked to the design of the font. The design of these fonts incorporates color as an intentional design decision, not as a bolt-on addition.

Some examples off the top of my head:

• Harmony, which incorporates floral patterns around the text.
• Megazero which gives an impression that the computer's RGB display is uncalibrated.
• Every emoji font you've ever seen

You can see how these examples' designs require color; the color cannot be excised from the design.

Because of this, color font files often have insufficient or even entirely missing outline data. Having an option to render them in non-color form would lead to confused and unhappy users.

Similarly, there are no other apps on any other platforms that I'm aware of that let content opt-out of color font rendering. We also do not have a precedent for a web page to say "Use this font, but ignore table XYZ and pretend you are a dumb old browser which doesn't have great features."

If the goal is to allow page authors to use the color property, SVG and COLR both allow for this.

This is distinct from the concept of variation selectors, which are primarily implemented by font selection, not special tables inside the font file. Selecting a color font vs a non-color font, and rendering each of them in turn with maximum fidelity, is already enough control for authors that I've interacted with, and comes with no unfortunate behavior.

[DeeDeeG]

Okay, thanks for the feedback.

I do have an interest in a font-table-level toggle, but I am struggling to prove why that would be worth the trouble. And that gets to be a bit too far into the weeds for this discussion.

I actually meant this to be for a font fallback ("Font selection"?) mechanism. To technically describe what I meant by this suggestion:

1. The implementation could (as per usual) compile an ordered list of fonts to select from, irrespective of color
2. The implementation could determine whether a given font (or all the fonts, as necessary) in the font list is an "explicit-color" or "traditional" font
3. Based on the setting of this property (e.g. auto | rich | traditional) the implementation can select fonts by either preferring color fonts, preferring traditional fonts, or (for auto) don't do anything special.

[DeeDeeG]

P.S. The reason why I think my suggestion here would be a good idea, is that I think the implementators already have to do just as much work to implement the draft property discussed in #1092 (but implementors of that draft property must limit the property's behavior to affect only emoji PPCP codepoints).

The only difference is, given my suggestion is added to the spec, authors can use that color font selection behavior on arbitrary text (arbitrary codepoints), not just emoji PPCP codepoints.

It expands the font selection toggle to all text / all codepoints. Outside of emoji PPCP codepoints, this would allow a more generic font-family value to be assigned to lots of elements, but some elements designated as rich and other elements designated as traditional, so as to select an explicit-color or else traditional font.

It's a higher-level, more abstracted way of selecting explicit-color vs traditional fonts, compared to simply ensuring the correct font is toward the from in font-family value for a given element. (And it is just as capable of sorting out emoji PCCP issues as is the draft discussed in #1092).

[litherum]

I don't think you've motivated the reason for this change. You said

the implementators already have to do just as much work to implement the draft property

but saying it's easy to implement is not sufficient to add a new feature to the Web platform.

As I understand it, the request is to open this property up to color fonts, not just emoji. However, the problem we're dealing with really is emoji-specific. There are two situations where color fonts (not emoji) may be used:

• If the content author specifies a color web font in their font-family list
• If the browser falls off the end of the font-family list and needs to pick something from the set of installed fonts

If the content author doesn't want color fonts in the first case, they should just remove the item from the font-family list. The second case will never occur because no OSes (that I know of) come installed with non-emoji color fonts. Therefore, this problem is only about the style of emoji, not about color fonts in general.

Or, stated differently: I haven't ever heard content authors complaining about how a color font is being used accidentally. On the other hand, I have heard content authors complaining about how their unicode snowmen don't look like emoji.

Lastly, the existing property has specific semantics around treating text as if it has variation selectors. However, the Web platform does not have interop regarding variation selector behavior. It's under-specified, and it's conceivable (desirable?) that the behavior may change or be standardized in the future. If CSS uses the same signal for both variation selectors and color fonts, we lose the freedom to create standard compatibility for the behavior of variation selectors in the future.

[DeeDeeG]

Thank you for the response.

I agree with what you say in your comment.

And some of these things (problems with my proposal) stuck out at me as I was writing this up. But I think this goes a long way to laying this concept of the general color font toggle to rest.

(More specifically: this seems conclusive to me regarding a whole-font level of selection mechanism, as opposed to a font-table level of selection, which I am not going to pursue at this time... And which this discussion is also critical of.)

I think this issue is resolved/can be closed.

---

I don't think you've motivated the reason for this change.

I concede the technical case is weak for my suggestion in this issue.

For the record, my motivation was this: I personally thought this suggestion might be a good idea for the property (before this discussion), and I was also trying to address some prior comments in other issues that suggested the same thing. I never felt those comments were resolved.

Comment by RoelN: #1144 (comment) (and resulting discussion in that issue)
This whole issue, basically: #352

But I do now feel like this issue, #2304 lays out the technical case better for a general (whole-font-selection, not table-selection) color font toggle, and contains a clear discussion as to why that's not a good idea, which I hope can lay that suggestion to rest and/or help build consensus along the way.

[css-meeting-bot]

The Working Group just discussed [css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji), and agreed to the following resolutions:

• RESOLVED: No change for issue #2304

The full IRC log of that discussion

<dael> Topic: [css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji)
<dael> github: https://github.com//issues/1092
<dael> myles: This topic was discussed a few weeks ago but a commentor brought up new points. Because previous issue was resolved we moved to a new issue. So jsut the new parts.
<dael> myles: THis is a property that renders characters as if they have variation selectors. This property sets the default so if you don't have a selector CSS can say emoji or text style
<dael> myles: Question was if this property should effect color fonts.
<dael> myles: Color font formats have been increasingly common. The request was...the CSS should be able to turn those on and off.
<dael> myles: THat's the background. ANything anyone wants to say before I give an opinion?
<astearns> github: https://github.com//issues/2304
<dael> myles: Should we allow the selector to effect regular color fonts?
<AmeliaBR> q+
<dael> myles: I haven't heard an author say they used color fonts accidently. Person raising this hasn't brought a case where this is needed, jsut that it's easy to impl.
<dael> myles: I haven't heard an author need. Also there isn't full itnerop on varation selectors and if we added more sematics it would limit our ability to standardize. THis issue is not motivated and would hinder standardization.
<Rossen_> ack AmeliaBR
<Rossen_> bradk, lol
<dael> AmeliaBR: On the question of is there a use case. When it comes to color web fonts I don't think anyone is using and wanting to turn them of fin general. When it comes to native emojis there is an issue where we have inconsistancy as to how to handle interaction of fill and stroke with a native color font like and emoji
<tantek> uh, turning off color (or picking different contrasts) is a pretty accepted a11y use-case
<dael> AmeliaBR: As color fonts become more common it might be useful to use a font consistantly but turn off the color for cetain elements. But I don't have as much of a use case as I do for the emoji.
<dael> myles: That's a good point. It is important that we should spec interaction between fill/stroke and the color fonts.
<dael> myles: THis proposal could go 2 ways. Way #1 is this would effect font selection and you'd just turn off the color parts. Option #2 is when you select font you skip the color. This was about option 2 but it sounds like you're interested in 1.
<dael> myles: Main concern with turning off tables in the font file is 1 that we don't have a presedent. and 2 is if they want the color to work it's possible using 2 of the font formats.
<liam> +1 to tantek but not clear that's at the font level but at the UA level overall
<dael> myles: Lastly color is part of the design of these fonts. If you took the color out it would hamper the design and the font would be useless. I list fonts in the issue where you can't remove the color. It would be unfortunate for users to...it would lead to confused users.
<dael> AmeliaBR: Many of these color fonts are shipping with fallback plain outlines. BUt some aren't. If the font has a built in monochrome fallback it seems logical to allow web page authors a way to access it. If there is no fallback logical is to fallback to a different font. It's hard to integrate both into the font selection algo.
<dael> myles: Yeah and this is a case where the browser should be in the business of looking at hte outline and say if it should be able to be used.
<Rossen_> +1 to what myles said
<dael> myles: And the fallback is requred, there has to be a table. but the contents may be empty or garbage.
<dael> Rossen_: I agree with myles. I want to see if there are any other options or idea.
<fremy> @myles: just throwing a random idea here, how about we render the glyph, convert to grayscale, and use this an opacity mask on a background of the color of the "color" property?
<dael> Rossen_: From IRC I want to voice tantek's point about this being a a11y lever. I agree with liam this shouldn't be the thing of font selection. We normally handle high contrast etc. on a much higher level for style or a lower level for color inversion.
<dael> Rossen_: Back to myles what do you want to do? Close no change?
<dael> myles: Right.
<dael> Rossen_: ANy objections or alternative proposals?
<tantek> Rossen: TBH it's both system level and app/site level. e.g. both mobile OS's and mobile sites have "night mode" features that alter such things
<dael> AmeliaBR: If we close no change we keep this property that will only effect on the specific unicode characters designated as having plain text or emoji presentation?
<dael> myles: Right
<dael> AmeliaBR: And it would effect font selection to render those characters?
<dael> myles: It might. That's why I phrases the property as I did. In mac and iOS it does. I believe on every platform it might effect font selection.
<dael> Rossen_: Does that answer you AmeliaBR ?
<dael> AmeliaBR: Pretty much. I still agree it would be nice to have a toggle to turn off color font on generic text but I realize right now use cases aren't clear.
<dael> myles: If a web author wants to turn off color font they should remove it from the font family list.
<dael> AmeliaBR: I htink we need to wait in see how things like font variations and ways to work with existing font files. Like people making color and monochrome and swapping between the two. It's still hypotetical.
<dael> myles: That tech doesn't exist for any font format right now.
<dael> Rossen_: Okay, objections to resolve no change?
<dael> Rossen_: If there are more compelling use cases or additional information we'll of course reconsider.
<dael> RESOLVED: No change for issue #2304

[DeeDeeG]

Re: "Fonts with useful color content and useful traditional outline content don't exist in the wild"

I just want to point out that any color fonts produced with SCFBuild have fairly high-quality black and white, traditional outline glyphs for all characters. The design intent with SCFBuild is, "yeah users probably want explicit color with these fonts, but for backward-compatibility we want to give them the traditional outlines if that's all they can see."

The traditional outline glyphs are considered valuable, because they allow the font (and the unique emoji renderings by the various companies) to be used even where color font support is poor.

Furthermore, if it helps with accessibility, as an author of one of these fonts, I am all for making use of the traditional outlines in these fonts for the good of the public.

Such as:

• https://github.com/eosrei/emojione-color-font
• https://github.com/eosrei/twemoji-color-font
• my own: https://github.com/DeeDeeG/noto-color-emoji-font

I think of this as being relevant to a font-table level control, but I don't have the interest in earnestly proposing that mechanism myself at this time.

[DeeDeeG]

I hope it's okay to comment here again, even though this has been discussed and set as "resolved" and "closed."

I would understand if it gets ignored or declined to be considered, for that reason. But anyways, I can articulate better why I thought this was a good idea:

• There are content authors who currently do not specify a font family in their websites, or who only specify "serif" or "sans-serif".
  • For these authors, a color font toggle would offer meaningful control over colorful vs plain presentation style, without having to begin naming specific fonts.
• There are "traditional outline" emoji fonts that cover much of the emoji unicode ranges, such as Symbola, and Noto Emoji (The Android emoji font from early KitKat).
  • These fonts considered, the range of emoji codepoints for which color/plain presentation is ambiguous is effectively "all of them."
• Rather than try to chase an annual update of the Unicode spec, this would apply cleanly irrespective of what direction Unicode takes withemoji standards.
  • emoji standards at Unicode are complex, have a tendency toward inventing new parameters and ret-conning existing but outmoded conventions in favor of new ones. Being agnostic to these standards is a boon to implementation/maintenance complexity for vendors, and shields against unpredictability from the Unicode side of things.