Importing a CSS file that contains @charset declaration

[ivantcholakov]

I am making a theme (one big compiled CSS as a result) that is built from less sources (Bootstrap 3, etc.) and some original CSS sources from GitHub. And here is an example: https://github.com/daneden/animate.css/blob/3.4.0/animate.css#L1 When I import this file, somewhere at the middle of the compiled result CSS the declaration @charset "UTF-8"; appears and it is not valid there.

Is it possible for imported CSS files the compiler simply to ignore the declaration @charset and not to put it within the result CSS?

Edit: Or, a more generalized way, @charset to be ignored if it is not going to be right at the beginning of the result CSS file.

[renaatdemuynck]

Since this is a port of less.js, I believe it should match its behavior. In less.js the @charset is moved to the top of the file. I don't know how it behaves when there are multiple, different @charset rules however...

[ivantcholakov]

Several @charset declarations simply are not recognized by the browser as valid, so I don't see the point of implementing exactly the behavior of less.js in this regard.

[renaatdemuynck]

I did a simple test with three files that have different encodings. If the calling less file doesn't contain a @charset rule already, less.js takes the encoding of the first imported file and moves that one to the top of the compiled CSS file. It will ignore all following @charset rules it encounters so the resulting CSS file will contain just one @charset rule. This is how it should be according to CSS specs and how less.php should implement it as well. I do believe however that if the compiler finds different, conflicting encodings it should throw an exception or generate a warning, but that is an issue that should be addressed in the less.js repo...

[seven-phases-max]

I do believe however that if the compiler finds different, conflicting encodings it should throw an exception or generate a warning,

Not really since those directives specify the encoding of Less compiler input files, while the compiler itself outputs all of content in the same encoding (usually UTF-8 if I recall correctly) - so strictly speaking a compiler should simply eliminate all of those directives at the output.

---

As for the less.php and less.js differences, don't forget the former is at v1.7.x while the latter is at v2.5.x hence the different behavior.

[renaatdemuynck]

I see your point. I agree now that the charset should not be copied to the compiled CSS file. But what if one of the imported files does contain a non-ASCII character, shouldn't the resulting CSS file have @charset 'utf-8'; at the top (W3C strongly recommends to only use UTF-8)? Although it isn't strictly necessary to include a @charset declaration in your CSS file (it will use the same encoding as the calling HTML file, which should be UTF-8 as well, or the encoding in the HTTP Content-Type header) they do recommend to still include it anyway.

[seven-phases-max]

they do recommend to still include it anyway.

This is where practice > recommendations thing comes in. All modern browsers handle UTF-8 sheets w/o @charset just fine (even if the encoding is different from the HTML they belong to), while some older browsers may fail if they see the directive. In other words, it's more like a "don't fix what isn't broken" case.

[renaatdemuynck]

So, back to @ivantcholakov's original issue: ignore all @charset rules except for the one defined at the top of the calling LESS file? I'm all for it!

[seven-phases-max]

ignore all @charset rules except for the one defined at the top of the calling LESS file?

Yes, I also agree this to be the most reasonable behaviour.

[ivantcholakov]

@renaatdemuynck

ignore all @charset rules except for the one defined at the top of the calling LESS file?

I agree. Sorry for seeing this discussion so late.