- From: Sebastian Zartner via GitHub <noreply@w3.org>
- Date: Wed, 18 Mar 2026 22:38:00 +0000
- To: public-css-archive@w3.org
> 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 -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13679#issuecomment-4086013372 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 March 2026 22:38:01 UTC