📚 Organizing stylelint recommended rules

[togami2864]

I was organizing and reviewing whether it's necessary to implement stylelint-config-recommended. I have marked some rules with a ? to indicate uncertainties or potential issues.

Should we consider using a parser or formatter instead of a linter for applying these rules?

rule	Need?	Difficulties	Note
at-rule-no-unknown	No	-	parser completely covers this
no-invalid-double-slash-comments	No	-	parser covers this
annotation-no-unknown	?	-	parser reports error but a little imperfect
color-no-invalid-hex	?	-	The parser covers some cases, but it's not perfect.
function-calc-no-unspaced-operator	?	-	style rule? It would conflict with formatter?
no-empty-source	?	-	syntax error occured https://stylelint.io/user-guide/rules/no-empty-source/
string-no-newline	?	-	style rule?
media-query-no-invalid	?	-	parser will panic

Full List

(Difficulties are based on my perspective)

rule	Need?	Difficulties	Note
block-no-empty	Yes	Easy	-
comment-no-empty	Yes	Easy	-
font-family-no-duplicate-names	Yes	Easy	Done
font-family-no-missing-generic-family-keyword	Yes	Easy	-
function-no-unknown	Yes	Easy	-
keyframe-block-no-duplicate-selectors	Yes	Easy	-
keyframe-declaration-no-important	Yes	Easy	-
media-feature-name-no-unknown	Yes	Easy	-
no-duplicate-at-import-rules	Yes	Easy	-
no-duplicate-selectors	Yes	Easy	-
no-irregular-whitespace	Yes	Easy	-
selector-pseudo-class-no-unknown	Yes	Easy	-
selector-pseudo-element-no-unknown	Yes	Easy	-
selector-type-no-unknown	Yes	Easy	-
unit-no-unknown	Yes	Easy	-
custom-property-no-missing-var-function	Yes	Mid	-
declaration-block-no-duplicate-custom-properties	Yes	Mid	-
declaration-block-no-shorthand-property-overrides	Yes	Mid	-
function-linear-gradient-no-nonstandard-direction	Yes	Mid	-
named-grid-areas-no-invalid	Yes	Mid	-
no-invalid-position-at-import-rule	Yes	Mid	-
property-no-unknown	Yes	Mid	-
selector-anb-no-unmatchable	Yes	Mid	-
declaration-block-no-duplicate-properties	Yes	Mid	-
no-descending-specificity	Yes	Hard	-
at-rule-no-unknown	No	-	parser completely covers this
no-invalid-double-slash-comments	No	-	parser covers this
annotation-no-unknown	?	-	parser reports error but a little imperfect
color-no-invalid-hex	?	-	The parser covers some cases, but it's not perfect. Should we handle this in the parser or in the linter?
function-calc-no-unspaced-operator	?	-	style rule? It would conflict with formatter?
no-empty-source	?	-	syntax error in test case https://stylelint.io/user-guide/rules/no-empty-source/
string-no-newline	?	-	style rule?
media-query-no-invalid	?	-	parser will panic

[Th3S4mur41]

@togami2864 would you also consider adding liberty/use-logical-spec to the list although it is not a stylelint recommended rule?

Logical properties is a great way to improve UIs with various language directions but it is not easy to get devs to switch their habits from the old properties and something that should not be checked manually

[togami2864]

Hi @Th3S4mur41. Thank you for your suggesting.

Unfortunately, the core/maintainer team won't implement this right away. Sorting order is often quite controversial and developers have varied preferences, so we need to be very careful when adding it to the official rules.

If there’s a possibility, it's to implement it as a plugin. We already have a workground, and it should be ready to use in the near future.