You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.b, .a .b { background: initial; color: initial }
.b { background: red }
.a .b { color: blue }
Before being run through postcss-autoreset, div.b is background: red. But afterwards, it becomes background: initial because the reset rule for .a .b has higher specificity. That smells like a bug to me.
I think this plugin should only reset selectors that have a single component. There's no reason to reset .b and then also reset .a .b – it's just a waste of bytes.
In the meantime, I was able to work around the issue with this config:
Hi, and thank You for the suggestion.
As the main idea of this plugin is the isolation of all CSS rules, we could not change its default behavior to match Your concrete case. I mean, we could have an outer rule with the same selector (i.e. .a .b), and the most expectable for plugin behavior is to add all mentioned in project rules into reset until you decide to change this behavior. rulesMatcher is aimed to solve this case and You used it properly.
I found some behavior that I think is incorrect.
Example HTML:
Example input CSS:
Example output CSS:
Before being run through
postcss-autoreset
,div.b
isbackground: red
. But afterwards, it becomesbackground: initial
because the reset rule for.a .b
has higher specificity. That smells like a bug to me.I think this plugin should only reset selectors that have a single component. There's no reason to reset
.b
and then also reset.a .b
– it's just a waste of bytes.In the meantime, I was able to work around the issue with this config:
The text was updated successfully, but these errors were encountered: