Csswg-drafts: [css-conditional-4][selectors-4] How should selector supports test react to partially-implemented selectors?

[AmeliaBR]

In #3207, it was agreed to add a selector() notation to @supports. Draft spec for CSS Conditional Level 4.

This would presumably also apply to the CSS.supports(condition) API.

However, I don't think there was any discussion about how this would interact with "selector profiles" — certain selectors that were expected to be implemented only in DOM methods and not in CSS parsing. In #3925, the WG resolved to drop the idea of selector profiles, but instead to mark :has() (and potentially other selectors with performance concerns) as optional. There was a suggestion that “optional” could mean following the profile pattern of supporting some selectors in querySelector etc. that aren't supported in markup.

So my question: if that is allowed, what should CSS.supports("selector(parent:has(child))") return? The same as @supports selector(parent:has(child))?

[emilio]

I don't think this is particularly urgent to fix since no UAs implement those, but I would probably suggest either:

• Adding another function to the CSS namespace (CSS.supportsSelector?) that directly takes a selector.
• CSS.supports() and @supports supports the same selectors that <style> and <link>.
• CSS.supportsSelector uses the same syntax as accepted in querySelector.

But maybe that's not even an issue since querySelector already throws for invalid selectors, so if it's only supported there it won't throw?

[bkardell]

maybe that's not even an issue since querySelector already throws for invalid selectors, so if it's only supported there it won't throw?

That seems bad, it should be possible to code and know without throwing, don't you think? I think the supports and supportsSelector has the advantage of being easy to explain, it could just not throw as long as the thing parses properly and just return a boolean answer?

[SelenIT]

I believe that "optional" shouldn't mean anything more than "up to the implementer". If somebody who (against all reason) implements this selector for scripting only decides to make this check return true, let it be so. If they prefer to return false for the sake of consistency with CSS, let them do so.

Anyways, I'd wager that this would stay a purely theoretical issue for a very long time because in reality 99% of JS developers would never use this check at all, simply switching from the conditional one-liner with the exotic selector to the unconditional two-liners with common selectors proven to work everywhere (not to mention that direct DOM traversal is much less used at all in modern JS than it was in the jQuery era). This would likely lead to the same "no one implemented → no one uses → no one asks for → no one wants to implement" deadlock that I believe we have actually observed in reality since the :has() proposal exists (given the fact that the only context it has been implemented in was _styling_ rather than scripting!).

Please, don't bring back the concept of "snapshot profile" in any form! Disabling _CSS_ selectors for _styling_ as a solution to the performance problem is virtually equal to not introducing them at all. Let's try to find better solutions to the performance problem first. As a starting point for brainstorming: maybe restricting the scope of :has() with something similar to xPath axes would help?..

[SelenIT]

On reflection, I tend to think that consistency with CSS is better. Because probably the most common use case for this check would be detecting the need for polyfill/alternative to the :has() selector _for styling._