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

DeeDeeG has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts-4] font-variant-emoji: Consider broadening to all "color fonts", not just emoji PPCP ==
## 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  https://github.com/w3c/csswg-drafts/issues/352

## Why I'm filing this issue

However, in the comments of https://github.com/w3c/csswg-drafts/issues/1092#issuecomment-363911362, 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 `+1`ing 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.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2304 using your GitHub account

Received on Monday, 12 February 2018 20:22:33 UTC