New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
litherum opened this Issue Mar 9, 2017 · 26 comments

Comments

Projects
None yet
9 participants
@litherum
Contributor

litherum commented Mar 9, 2017

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.

@litherum litherum added the css-fonts-4 label Mar 9, 2017

@Crissov

This comment has been minimized.

Contributor

Crissov commented Mar 15, 2017

  • 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

This comment has been minimized.

Contributor

fantasai commented Mar 17, 2017

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

This comment has been minimized.

Contributor

patrickdark commented Mar 21, 2017

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

This comment has been minimized.

DeeDeeG commented Apr 15, 2017

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

This comment has been minimized.

Contributor

fantasai commented Aug 3, 2017

I'm gonna suggest font-iconography here!

@Crissov

This comment has been minimized.

Contributor

Crissov commented Aug 3, 2017

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

@svgeesus svgeesus added the Agenda+ label Aug 16, 2017

@svgeesus

This comment has been minimized.

Contributor

svgeesus commented Aug 16, 2017

+1 to font-variant-emoji

@Crissov

This comment has been minimized.

Contributor

Crissov commented Aug 16, 2017

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

This comment has been minimized.

Member

css-meeting-bot commented Aug 16, 2017

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

This comment has been minimized.

Contributor

patrickdark commented Aug 18, 2017

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

This comment has been minimized.

Member

tabatkins commented Aug 18, 2017

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

This comment has been minimized.

Contributor

Crissov commented Aug 18, 2017

text-like, image-like

@DeeDeeG

This comment has been minimized.

DeeDeeG commented Aug 19, 2017

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 fantasai added the Agenda+ label Feb 3, 2018

@fantasai fantasai removed the Needs Edits label Feb 3, 2018

@dbaron dbaron changed the title from [css-fonts-4] font-presentation doesn't have a great name to [css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji) Feb 7, 2018

@fantasai

This comment has been minimized.

Contributor

fantasai commented Feb 7, 2018

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

This comment has been minimized.

Contributor

svgeesus commented Feb 7, 2018

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

@DeeDeeG

This comment has been minimized.

DeeDeeG commented Feb 7, 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 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

This comment has been minimized.

Member

tabatkins commented Feb 7, 2018

@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

This comment has been minimized.

DeeDeeG commented Feb 7, 2018

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: eosrei/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

This comment has been minimized.

Member

tabatkins commented Feb 7, 2018

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

This comment has been minimized.

Contributor

svgeesus commented Feb 7, 2018

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

This comment has been minimized.

Member

tabatkins commented Feb 7, 2018

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

This comment has been minimized.

Contributor

svgeesus commented Feb 7, 2018

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

This comment has been minimized.

DeeDeeG commented Feb 9, 2018

[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

This comment has been minimized.

Member

astearns commented Mar 6, 2018

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

@litherum

This comment has been minimized.

Contributor

litherum commented Mar 6, 2018

@litherum litherum closed this Mar 6, 2018

@DeeDeeG

This comment has been minimized.

DeeDeeG commented Apr 18, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment