Selector lists should be split if some parts are unsupported

[chris-morgan]

This is related to #3, which said “don’t merge rules if there are compatibility problems in their selectors”. I want to go beyond that: I want it to split rules if there are problems in their selectors.

If I write this:

:hover, :focus-visible {
    color: red;
}

Then I expect to receive this if I specify a target that doesn’t support :focus-visible:

:hover {
    color: red;
}

:focus-visible {
    color: red;
}

In times long past, the unforgiving nature of selectors was occasionally used deliberately to target specific browsers, normally based on vendor-prefixed pseudoclasses, but I feel like that technique is very rare now, and @supports selector() would be the proper way of doing that now (though it’s certainly new enough to be of some concern). I think that defaulting to splitting for compatibility is going to solve far more problems than it causes.

I’ve chosen :focus-visible as my motivating example here, and it’s the case I’m most interested in, but this is a general matter, and #24’s replacing :focus-visible with a class is not what I want—I’m interested in pure-CSS techniques and optional enhancements where supported, but without having to think about whether you have to split it manually if not all of your target browsers support it.

[chris-morgan]

One thing worth mentioning here is :is() support for forgiving selector list. If the target supports that, then you can wrap the poorly-supported part in :is(…), which is much more compact that repeating the rule body.

In the specific case of :focus-visible, this would provide a more compact result for Safari 14–15.3 only—enough for me to think it worthwhile personally spelling it :is(:focus-visible) or similar for the next couple of years (since my baseline just barely covers proper :is()), even if Lightning CSS doesn’t do the transformation automatically. But I do think this would be a useful trick to implement for possible future pseudoclasses.

[devongovett]

Implemented in the above commit. When :is() is supported by targets it will be used, otherwise multiple rules will be generated. One edge case is that :is() does not allow pseudo element selectors in its arguments, so if that is detected, we will also generate multiple rules.