AnkiMobile CSS color not working as expected

I have css styles below which works fine on MAC and Windwos

.tag {
    border-radius: calc(var(--ui-normal-radius)*1.5);
    background-color: #3c7eda;
    color: white;
    font-size: calc(var(--default-font-size)*0.8);
    padding: 2px 4px 2px 4px;
    min-width: 1.2rem;
}


.tag::before {
    content: var(--tag-content);
    font-family:emoji;
    background-image: linear-gradient(#fff, #fff);
    background-size: 1px 80%;
    background-repeat: no-repeat;
    background-position: right center;
    padding-right: 4px;
    margin-right: 4px;
}

.tag#level{
    --tag-content: "🔰";
    background-color:#00b294;
}

But on IOS AnkiMobile, things are messed up, colors of tags’ text are not correct
I’m new to css, could someone please help me with this?

1 Like

It’s hard to tell what exactly is going on without inspecting the source, and I’m not sure if Anki Mobile has tools for that, but I’ll take a guess that it might be using some predefined styles for .tag class for displaying Anki own tags somewhere and that interferes with the styles you are trying to define.

There is a couple of things to try:

  1. You can simply add !important to your color rule to try and make it take precedence over potential built-in styles:
    ...
    color: white !important;
    ...
    
  2. You can try choosing a different class name, like .mytags or something else that is unlikely to be used by Anki Mobile itself, and update both the styles and the HTML code accordingly.
4 Likes

thanks so much for your help, i tried your suggestions but they don’t work

I did some testing and found that deleting this font-family:emoji;, which is actually Microsoft’s Segui Emoji.tff, makes the font color display normally, but I do want to use this font.

I guess a missing font can cause this as well, if the default substitute Anki Mobile falls back to somehow has colored characters. In that case, you can try installing your font into your collection:

2 Likes

the font isn’t missing, it’s already synced in the collection
as you can see in the picture above, the emoji is rendered correctly using the font segui emoji, the problem is about the color of the text followed

You’d have to include the src attribute in the css though, which you didn’t do in your above code. Maybe that’s your issue?

You can see how to do that by clicking on Eltaurus’ link and reading “Update Template to Use That Font”.

sorrymy previous explanation might not be clear.
The font was already included in my code from the very beginning — I just didn’t post that part.

@font-face {
    font-family: emoji;
    src: url("_seguiemj.ttf");
}
2 Likes

Could you share your card and the font file in some way? I have one more idea, but it would probably be faster to check myself and write here if I find anything than to describe the whole process.

sure! Here it is. Mega Obsidian-test.apkg, the font file is already included in the apkg file.
Allow me to express my profound gratitude once again.

Since the font families for the text in the tags themselves are not explicitly set anywhere, this still leaves them open to be automatically selected by the platform, based on what is available in the system. I suppose one more thing to try is adding a rule for that in the style for .tag itself, making sure you are using font faces that include the required characters and are available on your phone (and also using !important during the tests for good measure).

Although I am beginning to wonder if this might be a bug:

  1. I see that the emoji font is not used anywhere except that ::before pseudo-element, so the presence of that rule should not affect other elements regardless.
  2. It looks almost as if the unwarranted color of the text was inherited from the last color used in rendering of the preceding emoji:
2 Likes

Is there a particular reason why the teal (?) colour was picked for the first one instead of yellow?

The colors being picked up by itself is a wild guess, so who knows? Because the colors there are the same in text and its background, it might be that the “N3” text is not rendered at all for some completely different reason. But the fact that in both tags the potential color of the text is present in the emojis says that inheritence of the color is at least a possibility.
It might be that this is simply the color of the last layer in the emoji vector image, and it does not get reset after the rendering is finished, resulting in it continuing being used in the next rendering until a new color is explicitly selected.
It would be interesting to test other emojis and see if any of their colors appear in rendering of text to check if this wild hypothesis holds any water at all.

2 Likes

@Eltauru

I also tend to agree that this is a bug.

  1. “N3” is actually rendered as you can long-press and copy the text.
    After testing some other emojis with this font, it turns out that the text color is indeed linked to the colors within the emojis.

  2. If you use the Segoe UI Emoji font in CSS .tag, even when you manually specify the text color as shown below, the color still doesn’t appear correctly.

    <span class="tag" id="tags">
    	<span style="color:white;font-family:arial;">{{Tags}}</span>
    </span>
    
  3. If you don’t specify the Segoe UI Emoji font or use a different font, then everything works as expected.

It’s really frustrating, since I really like the emoji design of this font.

2 Likes

I guess it’s time to tag @dae ?
Although, if it is a rendering issue, it’s likely the problem is not in Anki Mobile itself, but in the iOS web engine. How does your card look when viewed on ankiweb from your mobile browser?


In the meantime, there are still a few things to try to avoid this bug:

  1. I don’t think this font specification is working for two reasons:

    • Arial is not typically a system font on iOS, so the “N3” part would still get rendered by a different font autopicked by the system
    • Arial does not have Chinese characters, so â€œćœąćŒćèŻâ€ is still rendered with a different font on either system.

    As I suggested previously, try using a font, that you’re sure you have on your mobile device and/or try including the font file for this into anki collection the same way you did emoji file. (also keep in mind that you can use several font families in CSS rule to serve as fallbacks and have a better chance of enforcing the directive.)

  2. Since the bug is not widely known (at least a quick search did not reveal anything similar), and also because you say the fonts are rendered fine with a default iOS emoji font, the font file you are using might be partially to blame. If it is corrupted, finding a different source file for Segoe UI might help. You can also try repairing the file you have by opening it in a font editor (e.g. https://www.glyphrstudio.com/), making some minor change, like deleting a character you won’t need, and exporting it as a new file.

  3. You can try putting an empty <span> into each tag and attach the ::before style with the emoji to it instead of the whole .tag container. Maybe it will encapsulate the emoji character and prevent it from affecting the text

  4. You can try changing ::before to ::after. This way, the text should render first, which might save it from being affected by the emoji font. If it works, some other modifications to CSS would have to be made to make the pseudo-element appear to the left of the text as intended, but that should be doable.

2 Likes

I don’t get the impression that this is an Anki related bug, since the flashcards are rendered within a webview based on your predefined OS browser, but rather a difference in how your CSS styles are declared or rendered.

However, I was not able to reproduce the same error you’re experiencing with the file you shared above, so I suggest using one of these following options so you can easily investigate on your devices:

  1. If you set the QTWEBENGINE_REMOTE_DEBUGGING environment variable to 8080 prior to starting Anki, you can navigate to http://localhost:8080 to debug the visible webpages, alternatively, you can try to install this add-on to open the inspector inside the main app.
  2. If the problem is exclusively on your smartphone, enable HTML inspection in Ankidroid and then navigate to chrome://inspect to open a remote debug window.

EDIT: I just noticed that you’re using AnkiMobile for iOS and not AnkiDroid, which might explain why I couldn’t reproduce your error; however, I believe you can achieve the same results through Eruda console for mobile browsers.

However, even if this doesn’t allow you to reach a satisfactory solution, I agree with @eltaurus that it may be possible to achieve the same aesthetics by slightly modifying your card’s markup.

I’m looking forward to seeing if we can help you with that.

4 Likes

It looks like that this is an IOS bug since AnkiWeb has the same problem

After further investigation, i found that any text specified as white(#ffffff) and preceded by an emoji —even if the emoji and the text are not on the same level— ends up being rendered in a strange color.

Finally the very weird solution, if I set the .tag color to something close to white and assign a different color to .tag::before (i don’t know why, but this step is necessary—otherwise, the text color still ends up being affected by the emoji), then the text renders in the color I specified.

.tag {
    border-radius: calc(var(--ui-normal-radius)*1.5);
    background-color: #3c7eda;
    color: #fffffe;   /* specify a color close to white*/
    font-size: calc(var(--default-font-size)*0.8);
    padding: 2px 4px 2px 4px;
    min-width: 1.2rem;
}


.tag::before {
    content: var(--tag-content);
    font-family:emoji;
    background-image: linear-gradient(#fff, #fff);
    background-size: 1px 80%;
    background-repeat: no-repeat;
    background-position: right center;
    padding-right: 4px;
    margin-right: 4px;
    color:yellow; /* any color except #fffffe */
}
2 Likes

Thanks for your suggustion.

I tried the Eruda console on IOS AnkiMobile, the console did pop up, swiping works, clicking the button shows a shadow effect, but other than that, the console’s buttons don’t respond at all.

1 Like

As I said before, this bug likely comes from your OS browser which is why we were not able to reproduce and further debug it. Safari on iOS is widely known for having many rendering quirks and inconsistencies, especially compared to other major browsers like Chrome and Firefox.

Nevertheless, even though I don’t understand how it works, I’m glad you found a proper fix that works for you.

:tada:

1 Like

In Android at least you can change the default browser. If you can, you should probably start using something like Firefox instead.