CSS Remedy without specificity

[Th3S4mur41]

It would be great if every definition in the remedy.css could be enclosed in a :where() to remove the specificity.
Although the fallback for IE would probably mean duplicating the code with an hack 😩

The reason for this issue is the following:
In styles written for e.g. design systems in a way that they can easily be overwritten (e.g. for instance like in open-props from @argyleink) css remedy takes precedence.

Another solution for the problem could also come from Cascade layers, but we're not there yet with the browser support

[Sora2455]

Given that global usage of Internet Explorer is sitting at around 1%, do we really need to worry about it? Old versions of Firefox, Chrome and Safari also don't support where(), and they make up a noticable amout of traffic (at least on the site I work on). We don't support them - and Microsoft will be doing it's hardest to "auto-upgrade" Internet Explorer into Edge on June 15.

[Th3S4mur41]

The IE support was actually mostly because CSS Remedy currently does support it as stated in the README

[BassOfBass]

Even without IE in mind this pseudo-class is too fresh support-wise to base/migrate entire libraries around.

[WesCook]

Another consideration is cascade layers. Even less well-supported than :where(), but a much better solution to the problem.

[Th3S4mur41]

Even without IE in mind this pseudo-class is too fresh support-wise to base/migrate entire libraries around.

@BassOfBass is it though? 🤔

At this point, this couldn't even be improved with @supports

If remove dead browsers and consider the browserslist default of >.5%, it doesn't look all that bad

[BassOfBass]

@Th3S4mur41
What exactly do you expect to do with supports()? Write the base stylesheet which can randomly have 0 or 1+ specificity across the board? I am sure it's going to be very fun to work with such a library.
Another issue is migrating the existing CSS libraries (and the projects using those). The change like this has a huge implications on how library creators and consumers write styles. I myself stumbled into a situation where I had to prefix a to my BEM class selectors because I had a bunch of attribute selectors on <a> elements which resulted in higher specificity over BEM classes. But styling links upon their href value is just too much of a QoL so I went for a hack rather than conforming to BEM ruleset. And that was a pretty simple flat stylesheet with complete control over all styles. I imagine it's a lot worse in more complex setups.

[Th3S4mur41]

I'm not saying that @supports would have been a solution. I was merely mentioning that its browser support compared to :where discards it as an option anyway.

As @WesCook mentioned, cascade layers might even be a more flexible solution to reach the same goal. But browser support for that is worse so far.

The :where change would indeed be a breaking one which would call for a major version update.
That would help mitigate potential migration issues.

But this library being supposed to be the base class, reducing the specificity should not have any impact in most cases.
The only styles css remedy needs to overwrite are user-agent styles. And it doesn't need specificity to do so.
On the other hand, projects using this library needs same or higher specificity to overwrite the defaults set here. Removing specificity, makes that task easier, not mor difficult.

So, I'd say that the only downside to this so far would be browser support.
Or do you see a use case where the specificity change would be a problem?

[BassOfBass]

The major version upgrade would indeed be the only feasible solution. Except the next major version would be "1.0.0" in context of this repo, which would give it a "released" impression, not just a major version up.