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:57:21 CST 2018


Apologies for the duplicate threads; I accidentally sent the email as rich text. Here’s a version without the duplicate links.

> On Mar 6, 2018, at 12:52 PM, J. S. Choi via Unicode <unicode at unicode.org> wrote:
> 
> 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
> Current draft at 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 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 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 and also 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 and 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, but 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




More information about the Unicode mailing list