W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [css-fonts-4] Should emoji be restricted in its range?

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Tue, 03 Jul 2018 07:14:49 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-402036837-1530602088-sysbot+gh@w3.org>
The Working Group just discussed `Restrict unicode range of emoji generic family`, and agreed to the following:

* `RESOLVED: a note should be added that ua should filter at the time the user selects the font, or warn the user of the consequences`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Restrict unicode range of emoji generic family<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/2855<br>
&lt;frremy> myles: generic font families sometimes map to more than on font<br>
&lt;frremy> myles: to match all the languages and codepoints<br>
&lt;frremy> myles: but should we restrict these fonts so that they cannot use the emojis<br>
&lt;frremy> fantasai: so if the emoji font can either use all of its glyphs some might not be emojis<br>
&lt;frremy> fantasai: or you might get emojis from other fonts that is not the preferred emoji font<br>
&lt;frremy> myles: (restated the problem)<br>
&lt;frremy> myles: are there any implementation doing this?<br>
&lt;frremy> koji: not in blink<br>
&lt;frremy> frremy: I really don't know<br>
&lt;frremy> astearns: we could make it do what you want, but make the whole thing at risk?<br>
&lt;fantasai> s/or you might get emojis from other fonts that is not the preferred emoji font/you would then get regular text (Latin, CJK, whatever) that use the emoji font, preventing any fonts further in the fallback list from taking effect/<br>
&lt;frremy> myles: if you implemented this, we would map it to the emoji font<br>
&lt;frremy> myles: I think implementations will select one font, and we will make sure this font doesn't include other chars<br>
&lt;frremy> myles: so I'm leaning towards closing no-change<br>
&lt;frremy> fantasai: but then if the user changes the font<br>
&lt;frremy> ?<br>
&lt;frremy> myles: well, they get what they asked for, all the glyphs in the emoji font will be emojis....<br>
&lt;frremy> myles: don't set a font that contains non-emojis chars in it as your emoji font<br>
&lt;frremy> fantasai: the proposal I read was to restrict to unicode emojis<br>
&lt;frremy> myles: that doesn't work because our fonts include things that are not unicode emojis<br>
&lt;frremy> koji: there are pua for examples<br>
&lt;chris_> s/koji/chris/<br>
&lt;frremy> astearns: if we set a particular range for the emoji font<br>
&lt;frremy> astearns: and the font doesn't support something?<br>
&lt;frremy> florian: you fallback as usual to the next font<br>
&lt;frremy> fantasai: right, that doesn't seem a concern<br>
&lt;frremy> chris_: the other problem is that there are combining sequences<br>
&lt;frremy> chris_: some elements in the sequence might not be emojis<br>
&lt;frremy> chris_: you still don't want to change font<br>
&lt;frremy> myles: every year except one, the set has changed<br>
&lt;frremy> florian: so it's more reasonable to provide ua filtering at the font selection time<br>
&lt;frremy> florian: and generate a font subset for the user<br>
&lt;frremy> florian: based on what it thinks is an emoji at the time<br>
&lt;frremy> fantasai: I'd be ok with a non-normative advice to warn the user or generate a subset font of the font selected by the user<br>
&lt;frremy> fantasai: "may wish to consider"<br>
&lt;frremy> astearns: ok, any objection to a note saying that?<br>
&lt;frremy> RESOLVED: a note should be added that ua should filter at the time the user selects the font, or warn the user of the consequences<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2855#issuecomment-402036837 using your GitHub account
Received on Tuesday, 3 July 2018 07:14:55 UTC

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