starred/flag-icons

Fork 0

mirror of https://github.com/lipis/flag-icons.git synced 2026-04-26 01:15:55 +03:00

[GH-ISSUE #943] Letter rendered over flag #449

New issue

Closed

opened 2026-03-03 14:38:28 +03:00 by kerem · 9 comments

kerem commented

2026-03-03 14:38:28 +03:00

Owner

Originally created by @larsk2009 on GitHub (Mar 16, 2022).
Original GitHub issue: https://github.com/lipis/flag-icons/issues/943

Sometimes a sort of A character gets rendered over top the flag. I figured this is due to the :before content (which is 00a0) being interpreted as ISO-8859-1 instead of UTF-8 which results in a sort of A character instead of nbsp. I have found this stackoverflow issue about it. I can confirm that the CSS output from webpack does have 0xC2 in front of 0xA0 which, again, sometimes gets rendered as that A character.

Have you seen this before? I tried setting the @charset in my base SCSS file but that didn't seem to solve it.

Originally created by @larsk2009 on GitHub (Mar 16, 2022). Original GitHub issue: https://github.com/lipis/flag-icons/issues/943 Sometimes a sort of A character gets rendered over top the flag. I figured this is due to the :before content (which is `00a0`) being interpreted as ISO-8859-1 instead of UTF-8 which results in a sort of A character instead of nbsp. I have found [this stackoverflow issue](https://stackoverflow.com/questions/1461907/html-encoding-issues-%C3%82-character-showing-up-instead-of-nbsp) about it. I can confirm that the CSS output from webpack does have 0xC2 in front of 0xA0 which, again, _sometimes_ gets rendered as that A character. Have you seen this before? I tried setting the @charset in my base SCSS file but that didn't seem to solve it.

kerem

2026-03-03 14:38:28 +03:00

closed this issue
added the
bug

help needed
labels

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@lipis commented on GitHub (May 16, 2022):

Can you tell us on which flag (or flags) it's happening?

@lipis commented on GitHub (May 16, 2022): Can you tell us on which flag (or flags) it's happening?

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@NotTsunami commented on GitHub (May 22, 2022):

It would happen for every flag because we set this, assumably for spacing:

.fi:before {
  content: '\00a0';
}

In his specific case, he can either remove that from the file or override that from another rule:

.fi:before {
  content: none !important;
}

But that still isn't the right solution, and might have unintended consequences. Enforcing a charset should be the right solution.

@NotTsunami commented on GitHub (May 22, 2022): It would happen for every flag because we set this, assumably for spacing: ```css .fi:before { content: '\00a0'; } ``` In his specific case, he can either remove that from the file or override that from another rule: ```css .fi:before { content: none !important; } ``` But that still isn't the right solution, and might have unintended consequences. Enforcing a charset *should* be the right solution.

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@patrykwojtasik commented on GitHub (Jun 1, 2022):

@lipis: same issue happens on our end as well. We can randomly see the "A" on top of the flags. E.g. France:

This issue happens either on all flags or does not happen at all (mostly it works OK).

@patrykwojtasik commented on GitHub (Jun 1, 2022): @lipis: same issue happens on our end as well. We can randomly see the "A" on top of the flags. E.g. France: ![image](https://user-images.githubusercontent.com/16756131/171386629-601a708c-c659-4c65-b848-e510d2f8e3f9.png) This issue happens either on all flags or does not happen at all (mostly it works OK).

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@NotTsunami commented on GitHub (Aug 22, 2022):

Hi @larsk2009 and @patrykwojtasik, I have recently revisited this. It appears that @charset "utf-8"; must be the first byte of the CSS file, according to W3. I made a patchset that adds a charset rule for each configuration. If this bug is still relevant to you, can you let me know if this commit fixes it? It's not in the repo here so you'll have to cherry-pick from my fork. If it works, I'll push it to main branch.

271ab9637ff15c45dc4f61fcbca3842650a3d800

@NotTsunami commented on GitHub (Aug 22, 2022): Hi @larsk2009 and @patrykwojtasik, I have recently revisited this. It appears that `@charset "utf-8";` **must** be the first byte of the CSS file, according to [W3](https://www.w3.org/International/questions/qa-css-charset.en). I made a patchset that adds a charset rule for each configuration. If this bug is still relevant to you, can you let me know if this commit fixes it? It's not in the repo here so you'll have to cherry-pick from my fork. If it works, I'll push it to main branch. 271ab9637ff15c45dc4f61fcbca3842650a3d800

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@larsk2009 commented on GitHub (Aug 22, 2022):

Hi @NotTsunami, I did see that as a potential fix. I think I tested it, though I am not sure if I also tried to patch the NPM package itself. Regardless, I ended up fixing it in another way. I overwrote the content in my SCSS with this change:

.fi::before {
  content: "" !important;
}

and then set the height manually in my own scss like this:

.fi {
  height: 1em;
}

Because normally I think the flag gets rendered at line-height because of the content of the flag, but because we set the content to empty like this, you have to manually set the height.

@larsk2009 commented on GitHub (Aug 22, 2022): Hi @NotTsunami, I did see that as a potential fix. I think I tested it, though I am not sure if I also tried to patch the NPM package itself. Regardless, I ended up fixing it in another way. I overwrote the content in my SCSS with this change: ```scss .fi::before { content: "" !important; } ``` and then set the height manually in my own scss like this: ```scss .fi { height: 1em; } ``` Because normally I think the flag gets rendered at line-height because of the content of the flag, but because we set the content to empty like this, you have to manually set the height.

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@NotTsunami commented on GitHub (Aug 22, 2022):

Thanks for the response. I'm currently unable to reproduce on my end unfortunately, so I can't verify if my fix is appropriate or not. Take care!

@NotTsunami commented on GitHub (Aug 22, 2022): Thanks for the response. I'm currently unable to reproduce on my end unfortunately, so I can't verify if my fix is appropriate or not. Take care!

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@NotTsunami commented on GitHub (Dec 21, 2022):

Marked this as help needed, if anyone that is able to reproduce the issue the original ticket author had, please let me know if the linked commit helps:

github.com/lipis/flag-icons@271ab9637f

@NotTsunami commented on GitHub (Dec 21, 2022): Marked this as help needed, if anyone that is able to reproduce the issue the original ticket author had, please let me know if the linked commit helps: https://github.com/lipis/flag-icons/commit/271ab9637ff15c45dc4f61fcbca3842650a3d800

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@NotTsunami commented on GitHub (Aug 23, 2023):

Closing this as there has been no activity. If the issue pops up again, I will look at promoting the linked commit to the main branch.

@NotTsunami commented on GitHub (Aug 23, 2023): Closing this as there has been no activity. If the issue pops up again, I will look at promoting the linked commit to the main branch.

kerem commented

2026-03-03 14:38:29 +03:00

Author

Owner

@lipis commented on GitHub (Aug 23, 2023):

@NotTsunami Hey man.. ping me on Twitter or somewhere: https://lipis.dev

@lipis commented on GitHub (Aug 23, 2023): @NotTsunami Hey man.. ping me on Twitter or somewhere: https://lipis.dev