[css-fonts-4] Clarify precedence of font-presentation versus lang/xml:lang

[brawer]

In CSS font-presentation, it should be clarified what happens when font-presentation and the content’s BCP47 language tag (lang, xml:lang) specify a different Emoji presentation style. BCP47 extension -u- can be used to select an Emoji presentation style; see section 4.2 “Emoji Locale Extension” of UTS51.

[SergeyMalkin]

I would expect 'text' or 'emoji' property values to have higher priority than language. Language may take part in resolving 'auto' value.

[litherum]

Does any browser currently support setting the presentation style from lang?

Given that there are already ways to specify text or emoji presentation, I’d like to propose normative text that specify lang should never be consulted when making an emoji/text presentation decision. Using lang for this purpose in HTML/XML/CSS is overloading a term and would be better specified elsewhere (variation selectors, font-presentation).

[svgeesus]

Unless some implementation already supports setting the auto value from lang, I agree with @litherum that it should be normatively barred from influencing the presentation.

[macchiati]

I would expect the precedence to be the following:

1. if there is a variation selector (text or emoji), follow it.
2. otherwise if there is a CSS property value of 'text' or 'emoji' (eg explicitly set and not 'auto'), then follow it.
3. otherwise if there is a BCP47 specification (eg en-u-em-emoji), then follow it.
4. otherwise use the default presentation for that character.

[aphillips]

If you mean to exclude Unicode/CLDR's -u- extension from influencing the presentation of emoji characters only, I could see that. But it might be better to just ignore it. Obviously you do not mean to ignore BCP 47 (lang, xml:lang) values for other presentational purposes. There are lots of other things in -u- that CSS already ignores.

[aphillips]

(P.S. please add one of the i18n- labels to this issue so the I18N Working Group can track this)

[duerst]

@brawer: It would be good to find out for what specific purpose the -u- extension pieces were added in UTS51. Can you tell us more?

[brawer]

I don’t know the history of UTS51, but Mark Davis (@macchiati) can tell.

[kojiishi]

Does any browser currently support setting the presentation style from lang?

As far as I know, Android does not have Emoji Locale Extension but Android fonts.xml has Emoji Script (Zsye/Zsym), and we pass them through.

Does this discussion cover both?

/cc @drott our best Emoji experts

[js-choi]

I sent a message to the Unicode Consortium’s main public mailing list a couple of days ago, inviting anyone from the Emoji Subcommittee or the Consortium in general to check out this issue and to give their insight into emoji-character rendering and the BCP47 extensions. Hope it’ll also help.

Also cf. #2166.

[aphillips]

The I18N WG discussed this in our 18 January teleconference and actioned me with this response.

We would support adding normative language forbidding the interpretation of the -u- emoji presentation subtags (and only those subtags) assuming that the fallback described by Mark (@macchiati) is not adopted. The WG members present noted that BCP 47 language tags are not a great mechanism for this kind of information--this doesn't really fit as a locale element, the way that, say, number shaping or sorting details do. While more clarity from the CLDR and emoji folks is possible, the greater complexity strikes us as unhelpful.