Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji) #1092
Anything that refers to "presentation" or "glyphs" is too generic since things like
referenced this issue
Mar 30, 2017
For places where Unicode has used this phrasing/terminology:
Alternatives based on their (Unicode's) usage:
And on a different note, I give a +1 to
The CSS Working Group just discussed
There was also some discussions of what to name the value keywords, but no conclusion, so that issue was returned for further discussion in GitHub. Suggestions to replace
The full IRC log of that discussion<dael> Topic: font-presentation doesn't have a great name
<dael> Github: https://github.com//issues/1092
<dael> Chris: It's if you present emoji as visual emoji or text.
<dael> Chris: There has been some discussion on this. Who wants to speak to this?
<dael> fantasai: There were suggestions in the issue. I think we should pick one.
<dael> Chris: Yes, tantek emoji are text, but you can present a smily face as a graphic or smily-face-emoji (or something like that) Unicode allows both.
<dael> TabAtkins: It's a monocolor glyph or a colored glyph for this.
<dbaron> I'd suggest maybe the property name isn't being very good at describing what this does...
<dael> Chris: Oh. THat's different actually. Unicode values are text and emoji which is wierd. Shouldn't it be chromatic and monocolor? I hand't got from text that it's black and white.
<dael> Chris: dbaron agrees with me.
<dael> dbaron: I was thinking it was the name of the property.
<dael> Chris: It's the name of the property we're bikeshedding. There are various suggestions.
<dbaron> not the names of the values?
<dael> TabAtkins: I know someone suggested font-emoji. monochrome and color seem reasonable.
<dael> fantasai: If you have multi-color fonts they're not monochrome.
<leaverou> +1 for monochrome and color. monochrome is also consistent with the MQ value
<dael> TabAtkins: Truuuuuuuue. Are they painted like normal text or tiny images.
<dael> Chris: It's a strange way to present it.
<dael> Chris: If we have values that are monochrome and color it seems font-varient: emoji would be reasonable.
<dael> Chris: That's my personal pick.
<leaverou> what about symbol and graphic?
<dael> fantasai: Makes sense to me.
<fantasai> s/font-variant: emoji/font-variant-emoji/
<Chris> font-variant-emoji: monochrome | chromatic
<dael> fantasai: It's definitely better. Unless someone has a defferent prefence we should resolve.
<dael> TabAtkins: Property name is an improvement.
<tantek> agreed with the change to monochrome - much more descriptive than "text"
<dael> Chris: Support on property name, still discuss values.
<dael> Chris: leaverou suggested symbol and graphic
<dael> fantasai: I like that.
<dael> TabAtkins: I'm not sure I like symbol. Graphic or image is good for full color.
<dael> leaverou: Line art and graphic?
<dael> TabAtkins: It could be fully filled pictures.
<dael> fantasai: Glyph vs graphic?
<dael> Chris: They're both glyphs.
<dael> leaverou: Rich and plain?
<dauwhe> plain and fancy :)
<dael> TabAtkins: Plain's not back.
<dael> TabAtkins: plain and image maybe.
<dael> TabAtkins: We have ideas. We can continue value name in the thread.
<dael> Chris: Let's resolve on property and leave values for bikeshedding.
<dael> RESOLVED: property name is font-variant-emoji
I've used the terms "chromatic" and "monochromatic" for this dichotomy before. Then I decided it wasn't a good idea since some emoji can be one color. The Symbols block of Noto Color Emoji provides some good examples of monochrome emoji: https://www.google.com/get/noto/help/emoji/symbols.html.
A lot of people don't realize that arrows and media playback buttons can also be emoji or that some emoji can be achromatic (e.g., Yin Yang). (Yin Yang is inexplicably purple in Segoe UI Emoji though.)
IMO, the suggestion of "plain" is better than "text". "sans-emoji" is another alternative.
As for the other keyword, if "emoji" is already in the (new) property name, it seems most consistent to leave that keyword as is.
Not only that, with paletted fonts, the "text" emoji can be multicolor too. ^_^ The distinction really is "does it get painted like text (and respond to 'color')" or "does it get painted like an image", thus the current names. ^_^
I would go with
I feel these are intuitive and harder to misconstrue.
I would also support
added a commit
Feb 3, 2018
There seems to be a lot of, um "un-clarity" about what these values would actually do.
I can guess/infer what these would mean, from a present-day implementation standpoint, by looking at current color font support in browsers.
(To summarize, I think browsers might use black/white only OpenType tables when implementing the
No, paletted characters (which respond to 'color') will be covered by the "text" value. The distinction really is what I said before:
Ah, okay. Very interesting.
Isn't there a bit of an overlap between those categories, namely SVG, though? Opentype SVG is capable of being "paletted" per the spec and per my actual obervations of browser behavior: An outline with an unspecified (or sometimes
As such, SVG is acceptable as a vehicle for a purely "palletted" font; or a font with only baked-in, explicitly set colors; or some combination within the same font or within the same glyph.
I do think that black/white (exclusively "palleted") SVG fonts aren't very popular at the moment, but they do stlil exist. And a glyph can "respond" partly to CSS
I guess browsers could do (psuedo-code):
P.S. The whole
Yeah, SVG's complicated and annoying here.
You can opt into specific hardcoded palletes, or just provide your own, associating colors to indexes directly.
Sigh. Both SVG-in-OpenType and also COLR in OpenType can use palettes (CPAL). SVG-in-OpenType can also explicitly use inherited values (with
CPAL also has a way to inherit the color: a reserved palette index:
Which means it will, in a CSS context, respond to
In conclusion, the ability to specify hard-coded colors, or overrideable color defaults, or to inherit the surrounding text color, or to mix them in whatever way the designer sees fit, is a property of chromatic OpenType fonts. If you happen to find that 'complicated and annoying' then so be it, but quit blaming SVG here.
I meant "complicated and annoying" because it breaks the boundaries here. As @DeeDeeG said, and you confirmed with details, SVG fonts can pay attention to color, or not do so, up to the designer's whims, yes? While I think other ways of creating the font are all-or-nothing user-controllable or preset. (Maybe that's just a convention, and you could mix some predefined colors with some overridable colors, but that's not common?)
Oh - yes, agreed. If you squint a bit there are two disjoint categories; but when seen clearly they are mostly but not completely distinct.
Remember the typeface used in Jurassic Park? Yellow with a red inner line? As an example, that could be done so that the inner part is always that red, but the outer part takes on the surrounding text color.
Since we renamed the property to refer specifically to emojii, it seems it would not apply to other character ranges so that example (with latin text) would not be affected by this property anyway?
[Edit: Happy to move this to its own separate issue if this is too off-topic for the current issue. Sorry for going off on a tangent.]
Hi all, I hope it's not too late to bring this up: Given that the technical aspects this property would depend on, and the aspects of font tech it would toggle on/off, are not emoji-specific, I'd like to suggest the Working Group consider not limiting the property to emoji only.
I think the approach in this draft property is just as good a match for generally toggling on/off new color font tech for all text (all codepoints), rather than being emoji-specific. I also laid out my reasoning below.
As far as I can tell, a "baked-in" (
The fonts that web authors currently work with are generally OpenType (and all the new "color font" formats are OpenType). And the color font formats in OpenType are designed to seamlessly host both emoji and whatever other arbitrary multicolor content authors want to include. So it seems unnecessarily complicated to check if a codepoint is emoji before applying this property. It also seems like this draft is effectively going out of its way to make the property do less, not more.
The case I could see for keeping it limited to emoji are:
Some more of the case for broadening this to handle text in general: