W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

Re: [csswg-drafts] [css-text][css-fonts] Override (Emoji) Variation Selectors

From: Christoph Päper via GitHub <sysbot+gh@w3.org>
Date: Fri, 07 Apr 2017 14:24:42 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-292550791-1491575081-sysbot+gh@w3.org>
Most symbol fonts like Font Awesome are using PUA characters (exclusively) because authors that use them wish for consistent symbol design and do not want the characters which have Unicode emoji equivalents to be displayed with the OS default emoji font or graphics.

The text of https://github.com/w3c/csswg-drafts/issues/352#issuecomment-290394262 paraphrases an email I received from Mark Davis. I could cite it here verbatim if that's considered okay. 


> Certain emoji have defined variation sequences, in which an emoji character can be followed by an invisible emoji presentation selector or text presentation selector. [&hellip;] Some systems may also provide this distinction with higher-level markup, rather than variation sequences.

It's unrealistic to assume a closed system where either only VSs or &ldquo;higher-level markup&rdquo; controls the display. The web platform has to deal with a mix of both.

> However, even for cases in which the emoji and text presentation selectors are available, it had not been clear for implementers whether the default presentation for pictographs should be emoji or text. That means that a piece of text may show up in a different style than intended when shared across platforms. While this is all a perfectly legitimate for Unicode characters—presentation style is never guaranteed—a shared sense among developers of when to use emoji presentation by default is important, so that there are fewer unexpected and "jarring" presentations. 

> [&hellip;] every emoji character with a default text presentation allows for an emoji or text presentation selector. Thus the presentation of these characters can be controlled on a character-by-character basis. [&hellip;]
> In addition, the next [&hellip;] sections describe [&hellip;] other mechanisms for globally controlling the emoji presentation [&hellip;]

These are currently limited to specifying a baseline preference, not overrides.

> [&hellip;] in some CSS implementations, if any font in the lookup list is an emoji font, then emoji presentation is used whenever possible.

This is the status quo. The [original UTC request](https://lists.w3.org/Archives/Public/www-style/2016Mar/0370.html) from 2015 is based upon [L2/15-314](http://www.unicode.org/L2/L2015/15314-css-ctrl-emoji.pdf):

> There is a need for a mechanism in CSS to indicate a preference for the presentation style of characters that can have either a “text” or an “emoji” style of presentation. The preference should permit three values:
>* For all such characters, use the “text” presentation style if supported.
>* For all such characters, use the “emoji” presentation style if supported.
>* For all such characters, use the default presentation style (e.g. as specified in emoji­data) if supported.

This is also only about the default presentation, as noted by [i18n WG](https://www.w3.org/2016/03/24-i18n-minutes.html#item05). 

The [question from Stackoverflow](http://stackoverflow.com/questions/32413731/color-for-unicode-emoji) I already cited shows that some authors want to be able to reliably treat emoji glyphs like any other monochrome text glyph and not like a bitmap with inherent, fixed colors.

GitHub Notification of comment by Crissov
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1144#issuecomment-292550791 using your GitHub account
Received on Friday, 7 April 2017 14:24:49 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:11 UTC