Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add selector-pseudo-class-focus rule #3355
@jeddy3 what is your reason for moving it to a plugin?
Here are my thoughts:
I'm going to have to dig into my memory and recall some original design decisions, so bear with me...
When we first starting working on stylelint we looked to CSSLint for inspiration. We noticed that quite a few of the rules were now redundant as they were based on "best practises" that were, well, no longer best practice. As such, we made an early design decision to avoid adding such rules to stylelint, instead, we'd favour rules that could be configured to enforce whatever a team needs (or deems the best practice at the time) by applying limits to targeted constructs within the language.
This design decision is captured in the VISION doc.
A little later we realised that not everything a team might need could be achieved using just these configurable rules, so we added a plugin system. This allowed users to create rules which could do more than just apply limits to targeted constructs, whilst keeping the core stable and relevant.
In this particular instance, it looks like there are two ways to maintain accessibility:
I don't believe this rule can account for the latter, which is why it might not meet the "Has a clear and unambiguous finished state" rule of inclusion. Anyway, I think this point is moot as this is the kind of stuff that can get experimented on (and quickly iterated on) within a plugin.
It sounds like we need to do a better job of promoting the possible errors and limiting rules. I'm writing an article at the moment that highlights the value of the limiting rules. When I get around to finishing it it will hopefully help us promote this feature of stylelint.
There are some excellent plugins that I see in regular use.
We went through the pain of doing it that way around circa 7.8.0. I thought the lesson we learnt was that it's less painful to move plugins to core than to move built-in rules out.
I'm not seeing any arguments in the comments above that invalidate the original design decisions. Unless I'm missing something here? I agree there is a user education issue, though. We need to do a better job at promoting and signposting (within the docs and outside of them) the possible errors and limiting rules, as well as the plugin system (and this
It feels like this is approach will balance the user's need with the still valid original design decisions that have kept the built-in rules relevant. Thoughts?
And only 1/5 of Stylelint users use these plugins http://www.npmtrends.com/stylelint-vs-stylelint-order-vs-stylelint-scss
I am making slides about PostCSS and want to promote Stylelint. Here is an overview of our “Possible errors” rules:
Only 2 and 3 issues are really popular. Error 1 happens sometimes.
Unfortunately, it doesn’t compete with ESLint “Possible Errors” rules.
This is why I still believe that a11y rules in the core will be extremely good for promotion. We need more rules to prevent errors.
It is close, ESLint has 34 , stylelint has 24
@evilebottnawi I would like to see more error targeted rules, rather stylistic, as well (we might cover all stylistic rules already :)).
Please, create new issues for your rules ideas. New contributors are more willingly work on new stuff rather fixing bugs, in my opinion.
@ntwb when we compare ESLint and Stylelint rules by the number we are making mistakes. Stylelint has 10 rules just to check syntax errors (unknown properties, selectors, etc). If you group rules by error type we will have only 4 errors, which STylelint prevents
@hudochenkov we have JS in Stylelint to be smart. Simpler CSS syntax should even help us in finding real errors.
For me personally, I find that inconsistency is the biggest hurdle to maintaining a stylesheet within a team. There are so many ways for a developer to achieve the same outcome in CSS. As such, a large proportion of stylelint rules were specifically built to help teams combat these inconsistencies.
For example, a team might:
These are just three examples. Hopefully, it's clear how stylelint can help a team enforce the consistent use of any number of other methodologies.
There are over 50 limiting rules in stylelint, including fine-grained ones like
I think we can close these PRs and issues now that #3364 has been merged.
We can continue the discussion about how best to promote the plugin system (and plugins themselves) in #3362.
@YozhikM Thanks again for your work on these rules and porting them to the