The configuration would look like this:
'selector-property-whitelist': {
'/^.a-space-children.*/': [
'margin-top',
'margin-left',
'display',
'--a-space-children-spacer',
'flex-wrap'
],
'/^.pmc-a-glue.*/': [
'top',
'right',
'bottom',
'left',
'position',
'z-index',
'--a-glue-bottom',
'--a-glue-top',
'--a-glue-right',
'--a-glue-left'
]
}The regular expressions in the keys essentially say “find all classes beginning with .pmc-a-glue, etc. Regular expressions here are nice because you can test a pattern with multiple selectors, but you could also update it to be a single class, a data attribute, or even a pseudo-element. I think this could also be a nice means of documentation!
If you aren’t using the algorithm naming like I have above, this example might make more sense is:
'selector-property-whitelist': {
'.l-article': [
'display',
'grid-template-columns',
'grid-gap',
'grid-column'
],
'.c-heading': [
'font-size',
'color',
'line-height
'font-family',
'letter-spacing'
]
}Why would this be useful? It’s largely a way to protect the rule-set from modification by others (or a future you) in a way you hadn’t intended, and would provide good friction to encourage someone to look into an existing solution to their problem, or to author a new class for the declarations.
To take this further, there would absolutely be a way to group properties of certain intent so that you don’t need to list all of the possible CSS grid properties, for example, or all of the possibly properties related to typography.
My question to you, whoever may be reading this: would you find this useful in your work?
I have this working as a Stylelint plugin for Larva (the PMC design system) and I think this could be a useful in the main Stylelint rules! And more amazingly, I think I understand the Stylelint code-base enough to be able to contribute a PR!!
2 responses to “selector-property-whitelist: a potential CSS algorithms rule for Stylelint”
Interesting idea, but I don’t see any use for it. If there are any properties assigned to classes, that I don’t wish to be assigned, I will notice it or it will have no effect.
But the most important part is that you would have to configure any intersting classes. It will be hard to decide, wether a classs is imprtant enough. And given the importance you’ll have to write all the configuration down and maintain it. For how many classes? 100? 200?
And what about adding general modificator classes to a module? Do those properties count for the module, too? THIS will be hard to maintain.
In the end you’ll have to pay attention if the look of your modules is fine or not. If they have two properties more than they should is of no interest, if the have no visual impact.
Greetings from Germany,
Jens
Thanks for your comment! Using a regular expression as the key would address most of your concerns about maintainability, but more important: your comment brings up critical prerequisites for using a tool like this: strict and predictable naming conventions and an existing UI or CSS utility library that handles the majority of styling that don’t involve a lot of logic.