Re: [csswg-drafts] [css-fonts] Clarification font-variant-emoji should not affect characters `0-9#*` (#11014)

The CSS Working Group just discussed ``[css-fonts] Clarification font-variant-emoji should not affect characters `0-9#*` ``.

<details><summary>The full IRC log of that discussion</summary>
&lt;chrishtr> fantasai: this issue was opened by someone pointing out that font-variant-emoji currently has values to say do-default or change emoji to more text-like or more emoji presentation-like<br>
&lt;chrishtr> fantasai: this makes it easy for people to ask for emoji to look the way they want<br>
&lt;chrishtr> fantasai: problem is digits have emoji versions, and authors are usually not asking for those be emojified<br>
&lt;chrishtr> fantasai: request is to accept the digits, # and &amp; to be excluded from font-variant-emoji<br>
&lt;chrishtr> s/&amp;/*/<br>
&lt;chrishtr> fantasai: we could also add a keyword saying include everything, but they can already do that via variation selectors<br>
&lt;chrishtr> florian: possible in content, not styling<br>
&lt;chrishtr> fantasai: correct<br>
&lt;moonira> q+<br>
&lt;chrishtr> fantasai: think it's reasonable to emojify things that aren't digits. Marking up all digits is annoying.<br>
&lt;Rossen1> ack moonira<br>
&lt;chrishtr> moonira: Elika, you said we only can do that in content, not styles, but I'm not sure I understood that properly.<br>
&lt;chrishtr> moonira: dominik mentioned in his last comment we can also use span elements on those digits to achieve the desired outcome<br>
&lt;chrishtr> fantasai: yes, but the commenter is saying that digits are commonly used and rarely do they want emoji styling. Forcing the author to put spans around every digits is a lot of extra work.<br>
&lt;fantasai> (and might not even be possible in their system)<br>
&lt;chrishtr> moonira: also, the are other code points that are defined by unicode as emojis, like the hash sign, asterisk, that are commonly used as text and not emoji<br>
&lt;chrishtr> fantasai: we should have a value that makes exceptions for these characters, so they can request extra<br>
&lt;chrishtr> florian: the point is interesting because there is stuff in-between.<br>
&lt;chrishtr> florian: for digits you almost always want to exclude, but less often for these other ones<br>
&lt;chrishtr> fantasai: request includes digits, # and *<br>
&lt;chrishtr> moonira: I don't understand users want to use digits and other symbols mentioned mostly as text from, the point was made that some emojis are more ambiguous. For example, we can use font-variant-emoji Unicode, but digits in text presentation and Unicode presentation for others?<br>
&lt;chrishtr> moonira: there is an option to do that with Unicode keywords...<br>
&lt;chrishtr> fantasai: the problem is that the Unicode keywords use the Unicode defaults, which are oriented around backwards compatibility in text.<br>
&lt;chrishtr> fantasai: e.g. to avoid emoji staring to show up in math and science textbooks<br>
&lt;moonira> q+<br>
&lt;chrishtr> fantasai: in cases where you want to emojify your text font-variant-emoji does that, but the commenter is saying that this is too aggressive and a better default is to exclude some of those symbols<br>
&lt;chrishtr> fantasai: think it makes sense to accommodate this request, but in CSS instead of Unicode<br>
&lt;Rossen1> ack moonira<br>
&lt;fantasai> The 'unicode' value is a good default, but it is necessarily conservative.<br>
&lt;fantasai> This is a request to be more aggressive in emojification, but the 'emoji' value as currently defined is too aggressive.<br>
&lt;chrishtr> moonira: also, implementation-wise we use commonly used libraries like ICU that follow unicode standards. It makes more sense to raise the same issue in the  Unicode standard. That would allow us to avoid performance problems due to these exclusions.<br>
&lt;jfkthame> q+<br>
&lt;chrishtr> moonira: should we raise it in the Unicode group instead?<br>
&lt;Rossen1> ack joshtumath<br>
&lt;Rossen1> ack jfkthame<br>
&lt;fantasai> s/aggressive/aggressive for these common uses/<br>
&lt;chrishtr> jfkthame: wanted to comment that while I am sympathetic to the request, I am sympathetic to Dominik's comment in the issue expressing an unwillingness to create exceptions to Unicode.<br>
&lt;chrishtr> jfkthame: I'm uneasy about that, and where to draw the line<br>
&lt;Rossen1> joshtumath 😁<br>
&lt;chrishtr> jfkthame: there are other symbols used in text that have the emoji setting, such as trademarks, copyrights, make/female symbols. not sure we want to be in that business.<br>
&lt;fantasai> s/not sure/it's a difficult line to raw, and not sure/<br>
&lt;chrishtr> rossen: let's continue the discussion in the issue<br>
&lt;chrishtr> florian: do you mean that therefore it's an insoluble problem (or best solved in Unicode as Munira suggests)?<br>
&lt;chrishtr> florian: is it possible for Unicode to solve this or impossible for them too?<br>
&lt;chrishtr> jfkthame: I would be happier to see it solved in Unicode than patched in CSS. Not sure any solution would be perfect, but there could be a Unicode property to represent this.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11014#issuecomment-2504510927 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 27 November 2024 18:03:02 UTC