New default emoji presentation in CSS: non-conformance with UTR 51 by web browsers

"J. S. Choi" via Unicode unicode at unicode.org
Tue Mar 6 14:52:30 CST 2018


The W3C CSS Working Group is continuing to work on standardizing the default emoji presentation in perhaps the most ubiquitous application of Unicode today, the world wide web. Some recent logs:

https://github.com/w3c/csswg-drafts/commit/7a5e0d702b00f8d3df5f2b43c9c65d1c2a2284f6
https://github.com/w3c/csswg-drafts/issues/2304#issuecomment-369323232 <https://github.com/w3c/csswg-drafts/issues/2304#issuecomment-369323232>
Current draft at https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-desc <https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-desc>

Currently, the CSS draft specifies three values for emoji that a web author may use to style their content: auto, text, and emoji. The auto value (which is the default) leaves emoji presentation to the discretion of the web browser and system platform itself, rather than conforming strictly to UTR 51. https://github.com/w3c/csswg-drafts/issues/1223 <https://github.com/w3c/csswg-drafts/issues/1223> proposes that a strict 

If the authors or experts of UTR 51 believe that the Emoji_presentation property is useful, then they may want to chime in at Issue w3c/csswg-drafts#1223 <https://github.com/w3c/csswg-drafts/issues/1223> with their expertise. My opinion is that standardizing the default presentation is important enough to strictly conform to UTR 51. Breakage has already occurred in the past, such as when WebKit in 2015 unexpectedly switched the default presentation of U+21A9 LEFTWARDS ARROW WITH HOOK “↩” from text to emoji, which unexpectedly broke existing websites such as Daring Fireball (see https://daringfireball.net/linked/2015/04/22/unicode-emoji <https://daringfireball.net/linked/2015/04/22/unicode-emoji> and also http://mts.io/2015/04/21/unicode-symbol-render-text-emoji/ <http://mts.io/2015/04/21/unicode-symbol-render-text-emoji/>).

See also https://www.unicode.org/mail-arch/unicode-ml/y2018-m01/0016.html <https://www.unicode.org/mail-arch/unicode-ml/y2018-m01/0016.html> and https://github.com/w3c/csswg-drafts/issues/2138 <https://github.com/w3c/csswg-drafts/issues/2138>. To give an update on this issue: The CSS WG recently resolved to make all web browsers completely ignore BCP47’s -u- extension. If the authors/experts of the BCP47 extension believe that the extension is at all useful, they still may wish to chime in at https://github.com/w3c/csswg-drafts/issues/2138 <https://github.com/w3c/csswg-drafts/issues/2138>, but https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-desc <https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-desc> has now been updated to specify the ignoring of the BCP47 extension.

Cheers,
J. S. Choi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20180306/735b4270/attachment.html>


More information about the Unicode mailing list