Lightning CSS doesn't escape `content: "\..."`

We have @charset "UTF-8"; in our CSS which Lightning CSS is skipping when bunding/minifying the styles.
Without it, it's possible to encounter issues with displaying unicode like in #164.
There are other ways to insert the character encoding like HTTP headers and the HTML but this is not possible for people in some use cases.

Is it possible to respect the @charset rule?

I've also prepared a Playground link demonstrating the issue.

At least from my understanding, this conversion of the Unicode is due to the missing @charset but I may be mistaken. It would be great if we could respect the Unicode.

[devongovett]

UTF-8 is the default character set for CSS, so I don't think this is necessary?

UTF-8 is the default character set for CSS, so I don't think this is necessary?

I might be misunderstanding the problem then but isn't this causing the change from content:"\f67f" to content: "";?

[devongovett]

Escaping isn't necessary since the output is utf8.

Something must be going on because the content doesn't always render correctly:


And I've only managed to trace it to this difference in the CSS. If I minify the CSS with SWC, it escapes the content and I can't reproduce the rendering issue. But that product is not mature enough in my opinion.

[neoGeneva]

This is something I've encountered too. I'm currently unsure what causes Chrome to suddenly think that the CSS file isn't UTF-8, but I have a hunch that it's something to do with devtools.

There's a discussion over in the Font Awesome repo about a similar issue: FortAwesome/Font-Awesome#17644 The consensus there seems that @charset "UTF-8"; doesn't always solve the issue, so it would be good if Lighning CSS left characters in their encoded form or had an option to toggle it.

This is something I've encountered too. I'm currently unsure what causes Chrome to suddenly think that the CSS file isn't UTF-8, but I have a hunch that it's something to do with devtools.

There's a discussion over in the Font Awesome repo about a similar issue: FortAwesome/Font-Awesome#17644 The consensus there seems that @charset "UTF-8"; doesn't always solve the issue, so it would be good if Lighning CSS left characters in their encoded form or had an option to toggle it.

Our QA also managed to narrow it down to having DevTools open and refreshing the page.
The surest way of avoiding this that I've found is avoiding escaping content:"\f67f" to content: ""; but Lightning is not giving us an option to do that.
Hopefully, with this issue, they will consider it.

[rkumorek]

We've had the same issue recently with migrated sites that were still using font icons. Had to revert back to nanocss for the time being as clients reported issues with icons.

Same thing:
content:"\f67f" becomes content: "" (square bracket) which seems not to work on some browsers... for some clients... sometimes.

[devongovett]

See https://developer.mozilla.org/en-US/docs/Web/CSS/@charset for the rules of how a charset is chosen by browsers when loading a CSS file. The problem could be that you are setting a non-UTF8 charset as part of the Content-Type HTTP header, as that would override other methods such as @charset. You could also prepend a @charset rule to the file, but this is usually unnecessary because if no other value is overriding it, the default is UTF-8.

[domenkozar]

I've hacked around parcel bug to include @charset "UTF-8" at the beginning of the main.css, but it still sometimes just renders it in correctly. Opening the debugging tools triggers the bug almost always.

[devongovett]

Honestly this sounds like a chrome dev tools bug? Has anyone filed an issue there?