Masafumi Koba

@romainmenke Thank you so much. I now understand what you mean. 👍🏼 At this moment, I feel "Extended range" is better because of a single `EditInfo`. @Mouvedia What do you...

To make sure, we have eventually agreed on the following type: ```ts type EditInfo = { replacement: string; range: Range; }; type Warning = { fix?: EditInfo; }; ``` Based...

This need seems not so common for me. And, the following formatter seems enough for now: https://www.npmjs.com/package/stylelint-junit-formatter

How about the following packages? - https://www.npmjs.com/package/stylelint-gitlabci-formatter - https://www.npmjs.com/package/stylelint-formatter-junit Found on https://www.npmjs.com/search?q=stylelint%20junit%20formatter

@MrHBS Thanks for the proposal. This new rule might be placed in the ["Pattern" section](https://stylelint.io/user-guide/rules#pattern) to enforce conventions. That sounds interesting to me, but we already have similar rules: -...

@MrHBS For `@keyframes`, have you already used the `keyframes-name-pattern` rule? If no, any reason not to use?

@romainmenke I might be wrong, but will this new rule detect unexpected names/identifers in at-rule definitions, right? ```css @ /* some definition... */ ``` ```css @custom-media --foo { /*...*/ }...

Nevermind. Like it was on https://github.com/stylelint/stylelint/issues/7732#issuecomment-2144582174, this new rule name of `at-rule-name-pattern` might cause misunderstandings. 😃

It's possible to start with each at-rules, but I am concerned that we would have to add a similar rule once a new CSS spec appears; `foo-name-pattern`, `bar-name-pattern`, ... Would...

`*-no-unknown` rules seem different from this issue case because they have different subjects to be applied, for example, at-rule, function, etc. Rather, I think this issue is similar to the...