-
Notifications
You must be signed in to change notification settings - Fork 637
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-fonts-4] font-variant-emoji
lacks fallback algorithm or outcome definition
#9291
Comments
I want to add a demo to Dominik's description, which is not directly related to 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.
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.
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.
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,
So... does the spec specify font-variant-emoji's font fallback or not? Does the font-variant-emoji fallback follow the cluster matching rule?
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. |
Let me correct myself. Gecko's behaviors seem still correct. The algorithm below clarifies the font fallback procedure. The user font-family list should be respected first. |
Looking closer at UAX 29 I think what this means is that a variation selector extends a grapheme cluster and does not cause a cluster break, because |
@drott we didn't get to this at TPAC. where are we on Lack of algorithmic description or precise outcomes, do you have a concrete and testable suggestion here? |
Did you mean to ask "where are we...?"? I find the wording:
too broad and I think we otherwise already have tighter rules in the 5.3 cluster matching section, which @shivamidow also points out. What I established in the comments above from UAX 29 is that the variation selectors belong to the clusters according to Unicode cluster rules and we specify cluster matching as an addition to fallback in the specification. (The integration of cluster matching with fallback and font matching algorithm could be improved in the spec, as a side note). So IMHO a good outcome would be if we could lift the requirements here to saying something like: The property causes font fallback to behave as if the respective VS was appended (as in the values description), then font fallback, including the cluster fallback rules is performed, which must take the presentation preference / "appended" variation selectors into account. |
PS: I imagine, roughly, what should become testable:
WPT testing is not very good at interacting with system fonts or having definitions for a fixed set of those. So anything where the fallback descends into system fonts is harder to test. |
That sounds good to me. Want to make a pull request? |
Added the suggested text. |
https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-prop
Then further below:
I might be missing something, but I don't think Unicode defines the fallback algorithm for VS-15 and VS-16. To my understanding it's only well-defined for what glyphs should be selected within a font according to cmap format 14 in combination with the use of variation selectors.
Unclear sentence
I fail to understand what that means - any pointers?
Lack of algorithmic description or precise outcomes
So, if the
font-variant-emoji
property itself does not specify the fallback but relies onwe don't have any well-defined behavior here.
Can we find algorithmic proposals for fallback in combination with variation selectors? I think that would be a valuable addition to the spec.
If we can't succeed or agree on that, can we define a set of clear testable outcomes (preconditions and postconditions) or further details on how fallback should change with respect to this property?
The text was updated successfully, but these errors were encountered: