[css-selectors] What should the specificity of functional :invalid() and :user-invalid()

[lukewarlow]

In #1525 we resolved to add a new functional version of :invalid and :user-invalid() which will allow authors to style based on different validity states of form controls.

This issue is to discuss if these needs extra specificity compared to the non-functional counterpart.

[romainmenke]

I think this is closer to :nth-child(even), :dir(rtl) or :lang(en) where the arguments to the functional selector aren't elements and it makes sense to me to be consistent to those.

Especially :first-child vs. :nth-child(...) is a good comparison I think.

I agree with Tab that we can rely on source order and don't need increased specifity.

[bramus]

I think this is closer to :nth-child(even), :dir(rtl) or :lang(en) where the arguments to the functional selector aren't elements and it makes sense to me to be consistent to those.

I think it’s more close to ::view-transition-group(), where ::view-transition-group(name) is more specific than ::view-transition-group(*) as the former targets the one specific group whereas the latter targets any group.

Similarly I think that :user-invalid(argument) is more specific than :user-invalid (which could be seen as :user-invalid(*) BTW).

Additionally: :nth-child(even), :lang(en), :dir(rtl), :first-child always need an argument or no argument at all. So you can’t compare an argument-less version to a version that does have an argument (e.g. you can’t compare :nth-child against :nth-child(3n) because the former does not exist)

[SebastianZ]

I think it’s more close to ::view-transition-group(), where ::view-transition-group(name) is more specific than ::view-transition-group(*) as the former targets the one specific group whereas the latter targets any group.

When using this argument, you should also define how the specificity is influenced. For view transition groups it's logical, the specificity is either equivalent to a type selector (for named groups) or 0 (for *). So the argument basically reflects the specificity of a simple selector.

Though this scheme can't be applied to :user-invalid vs. :user-invalid(argument), as the former already has a specificity of a pseudo-class.
And adding to a different specificity value seems somewhat unlogical to me. This concern was also raised by @LeaVerou's on the call.

So, while :invalid(argument) and :user-invalid(argument) are logically more specific than :invalid and :user-invalid, I agree with @tabatkins, @romainmenke and others to keep the specificity the same and let this be handled via source order. This is also easily explainable to authors, which will probably place :user-invalid before any :user-invalid(argument), anyway.

Sebastian