[css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji)

[litherum]

font-presentation doesn't have a great name.

For an initial proposal, I chose the name because that's what Unicode calls this stuff - "Presentation Styles". But maybe there is a better name.

[Crissov]

• font-glyph-design
• font-glyphs
• font-glyph-selection
• font-glyph-variation
• font-emoji
• font-pictogram
• font-picture
• font-pictorial
• font-symbol
• text-transform-emoji

[fantasai]

Just for context: “This property (font-presentation) allows web authors to select whether emoji presentation or text presentation is used for certain emoji code points.”

[patrickdark]

font-emoji or font-variant-emoji seem to be the most straightforward. Given that change, the value text might be better renamed to none even though text aligns with Unicode.

Anything that refers to "presentation" or "glyphs" is too generic since things like font-variant-east-asian could also fall under those descriptions.

[DeeDeeG]

emoji-presentation would be very similar to how this terminology is handled by Unicode on their site. Makes sense to me. (I am a bit biased after flipping through the Unicode documentation so much.)

e.g. emoji-presentation: text emoji-presentation: auto emoji-presentation: emoji

For places where Unicode has used this phrasing/terminology:
http://unicode.org/reports/tr51/#Emoji_Presentation
http://unicode.org/emoji/charts/emoji-variants.html
http://unicode.org/emoji/charts/text-style.html

Alternatives based on their (Unicode's) usage:

emoji-presentation-style, emoji-text-presentation

And on a different note, I give a +1 to font-variant-emoji which is both a very CSS way to do it, and pretty readable/intuitive for a person who has never seen it before.

[fantasai]

I'm gonna suggest font-iconography here!

[Crissov]

I prefer something with pictogram or pictograph(ic), or picture if you must.

[svgeesus]

+1 to font-variant-emoji

[Crissov]

Property-value combos like x-y: y; and x-y: x; always feel a bit strange. The values currently are auto | text |emoji.

[css-meeting-bot]

The CSS Working Group just discussed font-presentation doesn't have a great name, and agreed to the following resolutions:

• RESOLVED: property name is font-variant-emoji

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 text | emoji so far included color | monochrome , chromatic | monocolor, symbol | graphic, plain | graphic; more suggestions are welcome.

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.
<leaverou> +1
<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.
<tantek> line-art
<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.
<dbaron> s/back/bad/
<dael> s/back/bad
<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

[patrickdark]

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.

[tabatkins]

Then I decided it wasn't a good idea since some emoji can be one color.

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. ^_^

[Crissov]

text-like, image-like

[DeeDeeG]

font-variant-emoji: emoji could refer to "text style" or "image style," so that could be confusing.

I would go with text | image (because it is very pragmatic and clear.)

I feel these are intuitive and harder to misconstrue.

I would also support plain | graphic, particularly because it is pleasant to read these words (so, it's user-friendly in that way), but I am afraid "plain" is vague, and "graphic" could be a noun or an adjective.

Perhaps text | graphic?

[fantasai]

The name of the property was resolved already. Agenda+ is for the value names, which were deferred from that decision. See #1092 (comment) and ensuing discussion.

[svgeesus]

I quite like the value names suggestion from @DeeDeeG text | graphic which is clear and readable.

[DeeDeeG]

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 font-variant-emoji: text value, and prefer using tables that can display multiple colors when implementing font-variant-emoji: graphic)

---

Given that browsers tend to support the TrueType spec, and/or OpenType spec ^[1], which is a superset of TrueType, everything below here in this comment is in the context of the OpenType spec.

• glyphs can be defined in a "fill"/"not-fill" binaristic way.
  • This can be an exclusively vector (curve) data format, as in these OpenType font tables: glyf, CFF or CFF2 and potentially SVG.
  • Or this can be in a grayscale or b/w bitmap format, as in the EBDT table.
    • EBDT can also support full grayscale bitmaps, apparently. (not just "fill"/"not-fill" per pixel in the bitmap, but a multi-bit "fill intensity" per pixel in the bitmap.)
  • I would expect these tables to correspond to a "text" or "monochrome" or "plain" value for this draft CSS property.
    • Sticky point for implementors?: SVG table is able to host binaristic fill/not-fill outlines, OR multicolor glyphs. So, it is the only one of these tables that is not always single-color.
• glyphs can be defined in a few different potentially-multicolor formats.
  • COLR + CPAL as in Segoe UI Emoji, and EmojiOne Mozilla which is bundled with Firefox
    • Outline layers+ color pallet (one color per outline, stack them -> potentially-multicolor composed glyph)
  • CBDT
    • Color bitmap data in one size (width x height) of bitmap per glyph
  • SBIX
    • Color bitmap data, potentially multiple sizes (width x height) per glyph
  • SVG again
    • Complex image format, one "SVG element" (with sub-elements, XML-based) per glyph. Edge decided to support only some features of SVG spec within fonts for their browser implementation. Mozilla seems to try to support the whole SVG spec.
  • I would expect these to correspond with "graphic", "image", or "fancy" or what-have-you in this draft CSS property.

[tabatkins]

@DeeDeeG

(To summarize, I think browsers might use black/white only OpenType tables when implementing the font-variant-emoji: text value, and prefer using tables that can display multiple colors when implementing font-variant-emoji: graphic)

No, paletted characters (which respond to 'color') will be covered by the "text" value. The distinction really is what I said before:

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" (and ignore any color-defining properties), thus the current names.

[DeeDeeG]

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 #000000) color will take color from CSS color property, but any portion of an SVG with defined (eg #0101ff) color will not take on the CSS color.

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 color without being a "palleted-only" glyph: 13rac1/emojione-color-font#21 (comment)

I guess browsers could do (psuedo-code):

if [
  glyph_has_any_non-palleted_color_feaures_at_all) then[
    glyph_is_graphic(); ]
  else[
    glyph_is_text(); ] ]
end_if

P.S. The whole COLR + CPAL combo is based around pallets, but seems to require explicit colors so as not to take on CSS color.

[tabatkins]

Yeah, SVG's complicated and annoying here.

P.S. The whole COLR + CPAL combo is based around pallets, but seems to require explicit colors so as not to take on CSS color.

https://drafts.csswg.org/css-fonts-4/#color-font-support

You can opt into specific hardcoded palletes, or just provide your own, associating colors to indexes directly.

[svgeesus]

Yeah, SVG's complicated and annoying here.

Sigh. Both SVG-in-OpenType and also COLR in OpenType can use palettes (CPAL). SVG-in-OpenType can also explicitly use inherited values (with inherit or currentColor or color) as an intentional part of the glyph design.

CPAL also has a way to inherit the color: a reserved palette index:

the palette entry index of 0xFFFF if specified in the COLR table represents the foreground color used in the system
https://www.microsoft.com/typography/otspec/cpal.htm

Which means it will, in a CSS context, respond to color.

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.

[tabatkins]

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?)

[svgeesus]

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?

[DeeDeeG]

[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" (graphic) /"inherited" (text) / auto color split is what this property is looking like it will specify. Given how broadly applicable a "baked-in color" (graphic) / "inherited color" (text) logical split is (beyond emoji), it seems like there is a nice opportunity to apply the property for text in general, rather than limiting it to just emoji.

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:

1. usage of this property might turn out to be emoji-specific for this property, and in that case matching author expectations/demand could make the property a better match to authors' expectations of how it will work
2. narrow scope may have a smaller "domino effect" impacts on font rendering implementations, (narrower performance implications, cause fewer adjustments to existing web dev habits)
3. A meta-reason: The working group has already decided on the property name, too late to change it now?

Some more of the case for broadening this to handle text in general:

1. It seems like it's already been decided not to override Variation Selectors (VS-15, VS-16) so there's not much tying this down to needing to be an emoji-only feature. (Ignoring VS-15 and VS-16 is another GitHub issue, which seems to be separate from this draft property)
2. From an implementation perspective, doing this for all code points woud be simpler than only doing it for emoji code points (although applying it over potentially more text could make it worse for performance?? speculating here.)
3. Doing it more-broadly now addresses more use-cases; Down the line, an emoji-specific version of this property might overlap with a future, broader CSS property for controlling (not necessarily emoji) baked-in-color vs inherited-color content.

[astearns]

Removing agenda+ label as we discussed it here: #2304 (comment)

[litherum]

7a5e0d7

[DeeDeeG]

Wasn't Agenda+ for the value names? Per: #1092 (comment).

Edit: Also, the draft spec still links to this issue:

ISSUE 11 Bikeshed the values.