[css-view-transitions-2] :active-view-transition() specificity

[vmpstr]

In css-view-transitions-2, we're adding :active-view-transition pseudo-class that activates on the html element when a view transition is happening. It also takes some parameters. Some examples are below:

/* matches for any view transition */
html:active-view-transition(*) { ... }

/* matches a view transition that has "foo" as one of the types specified */
html:active-view-transition(foo) { ... }

/* matches a view transition that has any of the following in the types: "foo", "bar", or "baz" */
html:active-view-transition(foo, bar, baz) { ... }

This issue is about what specificity this should have.

My proposal is that specificity of :active-view-transition(*) is pseudo-class-like (a.k.a. B) and :active-view-transition with any other parameter(s) is twice pseudo-class-like.

The justification here is that specifying a parameter seems more specific, but increasing the number of parameters doesn't change specificity since it's a disjunction of types.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] :active-view-transition() specificity, and agreed to the following:

• RESOLVED: :a-v-t(*) has specificity of 1 class, :a-v-t(list) has specificity of 2 classes

The full IRC log of that discussion

<TabAtkins> vmpstr: With v-t types we have a way to specify a type in startViewTransition()
<TabAtkins> vmpstr: It enables :active-vie-wtransition() on the root
<TabAtkins> vmpstr: Either takes an * or a list of comma-separated types
<TabAtkins> vmpstr: * matches any type, including none, if there's a VT running
<TabAtkins> vmpstr: list of names uses OR semantics
<TabAtkins> vmpstr: So, specificity of pseudoclass
<Rossen_> q?
<TabAtkins> vmpstr: Suggest we have (*) be 1 class specificifity, (list) be 2 class
<khush> +1
<TabAtkins> Doesn't seem unreasonable since the list is class-like, and it's valuable to have *some* specificity from the * one
<YehonatanDaniv> q+
<TabAtkins> miriam: I find it somewhat confusing but I think it works
<Rossen_> ack YehonatanDaniv
<TabAtkins> YehonatanDaniv: I was wondering why not use the same as :is()?
<TabAtkins> YehonatanDaniv: Same as its contents, so * would function as 0
<TabAtkins> vmpstr: The :a-v-t(*) is still more specific than not specifying anything at all, since it only matches when a VT is active
<TabAtkins> vmpstr: So that's why I'm propossing 1 and 2, rather than 0 and 1
<TabAtkins> (Agreed.)
<TabAtkins> fantasai: I think this makes sense. If we end up with more complex logical within :a-v-t() we probably want to expand the rule
<miriam> q+
<Rossen_> ack fantasai
<TabAtkins> fantasai: Like if you later can say "a view-transition with both foo and bar" it shoudl have 3 class specificity
<TabAtkins> vmpstr: agreed
<Rossen_> ack miriam
<bramus> q+
<TabAtkins> miriam: I wonder if a general way of stating that rule is that it's "is-like" + the pseudoclass
<emilio> q+
<TabAtkins> TabAtkins: It's not really a selector - the class names aren't class selectors, so you'd have to map it anyway. Same complexity as just saying it.
<TabAtkins> fantasai: Probably nto quite true, but as simple as it is now it's fine to be manual
<Rossen_> ack *
<Rossen_> ack bramus
<TabAtkins> bramus: Right now authors could write :avt(foo):avt(bar) to amtch both with a higher specificity
<Rossen_> ack emilio
<TabAtkins> emilio: Isn't this an or rather than an and?
<TabAtkins> TabAtkins: Yes, the discussion was about possible future syntax. Today's syntax is just a flat 1-class specificity
<TabAtkins> emilio: Can we just sort out that future stuff when we add it in the future then?
<TabAtkins> TabAtkins: yes
<TabAtkins> vmpstr: So proposal: :a-v-t() specifity is 1 class if it takes a *, 2 classes if it takes a list.
<TabAtkins> fantasai: CAn it be empty?
<TabAtkins> vmpstr: Not valid syntax
<TabAtkins> fantasai: Should it be valid?
<TabAtkins> vmpstr: That's basically what * does, unsure what benefit it woudl bring
<TabAtkins> fantasai: Just in general if there's a reasonable default behavior we allow omitting.
<TabAtkins> vmpstr: I think that might be a separate issue
<TabAtkins> fantasai: yeah
<TabAtkins> RESOLVED: :a-v-t(*) has specificity of 1 class, :a-v-t(list) has specificity of 2 classes