2

We use SonarQube against our application. One of the SonarQube rules says:

Selectors of lower specificity should come before overriding selectors of higher specificity

The details are here. As my application has many violations, changing the order by hand isn't really feasible. I'm wondering if there's a way to use scss-lint, stylelint or something else in a "fix" mode that could change the order of the selectors. I looked but couldn't find anything in stylelint. Maybe it can't safely be done automatically, as changing the order could affect specificity and therefore change the application behaviour...

Notre
  • 1,093
  • 3
  • 13
  • 26
  • how did you fix this selector issue, can you post your answer here, then it will helpfull to all – web_in Feb 03 '23 at 12:02

1 Answers1

1

As I personal! know there is no Linter which provide that. (I am curious about it.) But just some thoughts about the need of following that 'rule':

Indeed: writing SASS/CSS the way Selectors with lower specifity comes first is a good practicse. The CSS structure becomes more readable and it is easier to build up your code structure as there is a clearer systematic in your head (and the code).

But just up from the mechanic CSS works there is REALLY NO NEED to do it this way. The code simply doesn't become safer doing so or less safe and the pages don't load slower not doing it. That is what the mechanic of specifity has been done for: as of the specifity not the order of the selectors counts and you are able to write your code in the order you need it. Only if the specifity is the same the order counts.

So, maybe this rule leads to 'better' code. But: NOT ALL RULES NEEDS TO BE FULLFILLED. Not all rules Google tries to establish with their best practice rules they offer in their browser, nor all rules other analysis tools provide needs to be followed.

And if not in this project as it needs resources to correct it ... it maybe could but has not be a target for next project ;-)

Brebber
  • 2,986
  • 2
  • 9
  • 19
  • Agree, it's not technically needed. Also agree that it is cleaner, and that's probably the motivation of the tool's rule. I'm trying to tool happy by fixing the rule. Our group is trying to apply the same ruleset to all code, hence the motivation to autofix the issues in this older codebase. – Notre Apr 05 '21 at 15:26
  • @Notre how did you fix this selector issue, can you post your answer here, then it will helpfull to all – web_in Feb 03 '23 at 12:01
  • @web_in, I was unable to fix it. I had to ignore the SQ complaint – Notre Feb 10 '23 at 18:44