stylelint: Add `at-charset-rule-no-invalid`
What is the problem you’re trying to solve?
I went to fix this bug. And found out that @charset is not even an at-rule, but a special construct with much stricter syntax requirements than at-rules. And it doesn’t seem to be about choosing a formatting style at all. After all, if the quotes are single, the parser will just pass it by without recognizing it as an encoding declaration. It is good if the encoding is utf-8, which is the default encoding. But if another encoding is used, it will probably cause an error.
So it’s so much a matter of syntax (rather than formatting style) that the rule controlling @charset:
- should be in Stylelint itself, not in the plugin;
- should have one single option — the value
true; - should be added not even to the standard, but to the recommended config.
What solution would you like to see?
Add a separate rule to control the @charset syntax, which would take into account the character set of this declaration, its location in the style file, and maybe something else I may not know about yet.
About this issue
- Original URL
- State: open
- Created 5 months ago
- Comments: 17 (17 by maintainers)
Correct, the default is
utf-8anyway and I haven’t used@charsetin ages.The primary use case is:
environment encoding(this is extremely rare)environment encoding(this is extremely rare)In that very specific case you can use
@charset "utf-8"(or your encoding instead ofutf-8) to make sure your stylesheet is correctly read.Today it would be exceedingly rare to need this given that everything has become
utf-8by default.I think there can be general guidance that
@charsetis not something you need. While I also agree with @firefoxic that if people do include it that it must be correct.I have already started to think about how much, what and how I will have to change in the plugin in view of everything discussed here.
But I decided to take a look at the Stylelint code — it turns out that it also needs a lot of changes. For example:
And if in the readme files in the code examples
@charsetcan easily be replaced by any@layerwithout losing much of its meaning, then the code where the logic relies on the fact that@charsetcan be written in different ways will also need to be corrected somehow.Also, considering that
@charsetis not an at-rule at all, it might be better to ignore@charsetin the linter rules that regulate the at-rules.Looks like I’ve opened a closet whose junk has us all in over our heads 🤪
I’ve opened an issue to ask the spec editors directly : https://github.com/w3c/csswg-drafts/issues/9838
As far as I understand it, if the developer even crookedly wrote something like
charsetsomewhere, he wanted to rely on what he specifies. And the linter needs to see to it that it’s spelled correctly (including the location of that declaration, yes).There is no necessity for
@charsetof course.And preceding content :
Given the answer, it seems that the rule would still make sure that
@charset "...";is spelled correctly in the presence of something like it (disallow single quotes, upper case, spaces greater than one, no semicolons, etc.). Am I understanding this correctly?I think this is an error/ambiguity in the mdn docs.
In CSS 2.1
@charset ...would be parsed as an atrule contruct. Later specifications require it to be dropped instead.https://www.w3.org/TR/css-syntax-3/#charset-rule
So the deprecation is limited to how
@charset ...is exposed or not to further parser internals and thereby to things like CSSOM.If I am reading everything correctly