[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.

[fantasai]

Agenda+ to ask if we want to close no-change (can already check by seeing if .querySelector throws) or if we want to add a new API that specifically checks for .querySelector support.

[tabatkins]

Close no change, imo. Using a raised error as a flag isn't elegant, but it works acceptably as long as it's well-specified, so I'm fine with that.

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional-4][selectors-4] How should selector supports test react to partially-implemented selectors?, and agreed to the following:

• RESOLVED: Close no-change

The full IRC log of that discussion

<fantasai> Topic: [css-conditional-4][selectors-4] How should selector supports test react to partially-implemented selectors?
<TabAtkins> github: https://github.com//issues/3936
<TabAtkins> fantasai: So it's about how supports() should work for "partially-implemented" selectors (only implemented in some contexts)
<TabAtkins> fantasai: And if we need a separate supports*() function to differentiate them.
<fantasai> TabAtkins: :has() psueudo-class, was suggested could be implemented just in .querySelector and not in CSS
<fantasai> TabAtkins: Question about whether @supports/.supports() return true fo rsupport in that case
<fantasai> TabAtkins: Conclusion was that only true if supported in CSS
<fantasai> TabAtkins: and can tell if .querySelector supports by whether or not it throws
<fantasai> TabAtkins: So shouldn't need additional work
<TabAtkins> astearns: So anyone interested in keeping the issue open, or okay with closing?
<TabAtkins> astearns: Objections to closing?
<TabAtkins> astearns: I trust if Amelia disagrees we'll hear about it
<TabAtkins> RESOLVED: Close no-change
<fantasai> proposed: .supports/@supports checks for support in CSS, use .querySelector throwing to check for support there, close no change