Masafumi Koba

FYI. #5999 was closed because we planned to remove `custom-property-empty-line-before` as a stylistic rule (ref: [migration guide to 15.0.0](https://stylelint.io/migration-guide/to-15#deprecated-stylistic-rules)). But we found out Prettier didn't address the rule, so we...

Let's keep it open to prevent someone from reporting similar issues for a while. Also, possibly, a solution may be found.

Hum, I think it's still worth to support `text-decoration-thickness` in the following case: ```css a { text-decoration-line: underline; text-decoration-style: solid; text-decoration-color: green; text-decoration-thickness: 1px; /* ↓↓↓ autofixed */ text-decoration: underline...

Currently, [caniuse shows 93% coverage](https://caniuse.com/mdn-css_properties_text-decoration-thickness) at the global: It may make sense to wait until this coverage increases more. We can revisit this issue when the coverage is enough.

@Mouvedia You mean a new option like `ignoreProperties`, right? To be honest, I'm concerned that a new option may be confused with [`ignoreShorthands`](https://stylelint.io/user-guide/rules/declaration-block-no-redundant-longhand-properties/#ignoreshorthands-regex-regex-string).

Make sense. Adding a new `ignoreLonghands` option sounds good to me. 👍🏼 > Should I create a new issue for that option? No need. Let's continue the discussion here so...

@Mouvedia It still makes sense to implement the new option `ignoreLonghands`. Let's switch to "ready to implement". @jeddy3 Please comment if you have any concerns.

> add a new `ignores` property with that behaviour and deprecate `ignoreFiles: []` I agree with the former. 👍🏼

I looked into the introduction of `postcss-safe-parser`. The PR was #2886. `postcss-safe-parser` can fix syntax errors like this: ```sh-session $ echo 'a {' | npx stylelint 1:1 ✖ Unclosed block...

For reference, an incomplete comment like `/* comment` is fixable: ```sh-session $ echo '/* comment' | npx stylelint --fix /* comment */% ```