- From: ChangSeok Oh via GitHub <sysbot+gh@w3.org>
- Date: Sat, 02 Sep 2023 14:56:28 +0000
- To: public-css-archive@w3.org
I want to add a demo to Dominik's description, which is not directly related to `font-variant-emoji`. However, `font-variant-emoji` may follow the same font fallback algorithm of VS-15/16 handling, so it would help understand the current issue. Please try https://jsfiddle.net/92jg6dLw/ with Blink, Gecko, and WebKit on Mac. The demo contains two smile emoji Unicode code points with VS-16, and we expect to see two color emojis. The result, interestingly, varies depending on user agents. The used fonts per engine are as follows. * Blink: Times New Roman and Times New Roman * Gecko: Noto Color Emoji and Apple Color Emoji * WebKit: Apple Color Emoji and Apple Color Emoji Gecko was my expectation initially, but I found other rendering engines also had a reason for their behavior while perusing the related spec. Gecko follows the general rule of the fallback glyph lookup. Since Times New Roman does not support the variant smile emoji glyph, Gecko falls back to the next font, Noto Color Emoji, in the given font-family for the first emoji. Gecko applies the same rule to the second glyph, so it chose the system fallback font, Apple Color Emoji. This behavior may meet most web developers' expectations. WebKit seems to follow the [Cluster matching rule](https://www.w3.org/TR/css-fonts-4/#cluster-matching:~:text=For%20sequences%20containing%20variation%20selectors%2C%20which%20indicate%20the%20precise%20glyph%20to%20be%20used%20for%20a%20given%20character%2C%20user%20agents%20always%20attempt%20system%20font%20fallback%20to%20find%20the%20appropriate%20glyph%20before%20using%20the%20default%20glyph%20of%20the%20base%20character.). > For sequences containing variation selectors, which indicate the precise glyph to be used for a given character, **user agents always attempt system font fallback to find the appropriate glyph** before using the default glyph of the base character. So, Mac's system fallback emoji font, Apple Color Emoji, is selected for two emojis regardless of the font-family. Blink's behavior might be the least wanted result in the user's view. And many related bug reports have been filed on crbug.com. It ignores VS-16 and uses the base codepoint glyph instead as the primary font does not support emoji variations. This might be based on the following description of the spec. > Variation selectors other than FE0E VARIATION SELECTOR-15 and U+FE0F VARIATION SELECTOR-16 must not have any affect on font selection. If one of these variation selectors is present, but unsupported by the font previously selected, the variation selector is ignored. I am trying to fix Blink to fall through the font-family and system fallback fonts as Gecko does, but I found the spec is inconsistent on the font fallback algorithm, as Dominik described. For examples, > This property is expected to affect font fallback; however, the exact nature of the interaction of font fallback with font-variant-emoji is explicitly unspecified. However, a variation selector must be included in a previous cluster as defined by the cluster matching section above. Therefore, the presence of a variation selector is treated as ancillary data to inform the font fallback routine. So... does the spec specify font-variant-emoji's font fallback or not? Does the font-variant-emoji fallback follow the cluster matching rule? > Note: Different platforms have different conventions about how to handle emoji presentation sequences. A cross-platform UA might wish to follow the conventions of each individual platform, or it might wish to use the same approach on all platforms. When tasked with a request for an emoji style rendering, a UA might wish to disregard fonts which do not include color tables. A different UA might wish instead to use the same mechanical cluster fallback algorithm that it would use for any arbitrary cluster. This sounds more puzzling to me. So, the spec says there is no rule for emoji font fallback, and it is up to UAs; they could follow system conventions or decide the fallback at their discretion. In other words, not specified? What is the expected behavior for the demo? Personally, I lean toward Gecko's behavior. However, as I read so far, WebKit's behavior looks like a correct implementation. Assuming font-variant-emoji follows the cluster matching rule for VS-15/16, font-variant-emoji also implements WebKit's behavior, right? The spec needs to clarify this. -- GitHub Notification of comment by shivamidow Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9291#issuecomment-1703856211 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 2 September 2023 14:56:31 UTC