Multiple implementations want to ship the :has() selector with a variety of limitations in order to prevent performance footguns and complexity:

• [selectors-4] Remove the :scope dependency from the relative selectors definition #6399
• [selectors-4] Consider disallowing logical combination pseudo-classes inside :has() #6952
• [selectors-4] Consider disallowing :scope inside :has() #7211
• [selectors-4] Consider disallowing :host, :host(), :host-context() inside :has() #7212

However, since :has() has forgiving parsing like :is() / :where(), it's not possible to detect these limitations easily, and it won't be possible to do so if we ever remove these limitations.

For :is() / :where() it's not a problem since it's generally assumed that if the selector is valid outside of them it'll be valid inside of them... But for the limitations that folks are imposing on :has() (and which for the record I agree with) this is not true.

Perhaps we should special-case @supports selector(..) to not use forgiving parsing? Otherwise the only way to potentially detect this is with script (by reading back the serialization of :has() and see if the relevant selectors have been dropped).

cc @byung-woo @anttijk