- From: DeeDeeG via GitHub <sysbot+gh@w3.org>
- Date: Sat, 15 Apr 2017 08:14:48 +0000
- To: public-css-archive@w3.org
Note also that some code-points can't be rendered as plain text, (without supplying a novel font that shows these codepoints in plain text) because the codepoints are new, only ever been intended to be emoji, and no major font has encoded them plain-text-style. The technical barrier to them being "reliably rendered as plain text" is a lack of glyphs of the plain-text (only curves, no color data) variety. Likewise, some code-points can't be rendered as emoji, (without supplying a novel font to do so) because no major font has ever treated the code-points as emoji, and they are only available in extant fonts as plain text. Thus, the hopes for a "reliable way" to render a code point as plain text or as emoji require a sufficiently designed font. What's left between those two categories, by Unicode's design, are the code-points where variation selectors have been allowed... That said, it would be good to have the browser be able to look for plain text glyphs even for code-points that are supposedly "always emoji according to Unicode," in my opinion. And likewise, it would be good for the browser to be able to look for emoji glyphs for code-points that are supposedly "only ever plain text according to Unicode." That lets font designers step in to solve the technical problem of insufficient glyphs, and thus solve the web design problem of un-colorable emojis, or un-emoji-able codepoints. But of the five css values they suggested for the property, three (default, text, emoji) are redundant. (as I went through in my comment above). -- GitHub Notification of comment by DeeDeeG Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1144#issuecomment-294279442 using your GitHub account
Received on Saturday, 15 April 2017 08:14:57 UTC