- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Nov 2023 17:35:28 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: With v-t types we have a way to specify a type in startViewTransition()<br> <TabAtkins> vmpstr: It enables :active-vie-wtransition() on the root<br> <TabAtkins> vmpstr: Either takes an * or a list of comma-separated types<br> <TabAtkins> vmpstr: * matches any type, including none, if there's a VT running<br> <TabAtkins> vmpstr: list of names uses OR semantics<br> <TabAtkins> vmpstr: So, specificity of pseudoclass<br> <Rossen_> q?<br> <TabAtkins> vmpstr: Suggest we have (*) be 1 class specificifity, (list) be 2 class<br> <khush> +1<br> <TabAtkins> Doesn't seem unreasonable since the list is class-like, and it's valuable to have *some* specificity from the * one<br> <YehonatanDaniv> q+<br> <TabAtkins> miriam: I find it somewhat confusing but I think it works<br> <Rossen_> ack YehonatanDaniv<br> <TabAtkins> YehonatanDaniv: I was wondering why not use the same as :is()?<br> <TabAtkins> YehonatanDaniv: Same as its contents, so * would function as 0<br> <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<br> <TabAtkins> vmpstr: So that's why I'm propossing 1 and 2, rather than 0 and 1<br> <TabAtkins> (Agreed.)<br> <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<br> <miriam> q+<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: Like if you later can say "a view-transition with both foo and bar" it shoudl have 3 class specificity<br> <TabAtkins> vmpstr: agreed<br> <Rossen_> ack miriam<br> <bramus> q+<br> <TabAtkins> miriam: I wonder if a general way of stating that rule is that it's "is-like" + the pseudoclass<br> <emilio> q+<br> <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.<br> <TabAtkins> fantasai: Probably nto quite true, but as simple as it is now it's fine to be manual<br> <Rossen_> ack *<br> <Rossen_> ack bramus<br> <TabAtkins> bramus: Right now authors could write :avt(foo):avt(bar) to amtch both with a higher specificity<br> <Rossen_> ack emilio<br> <TabAtkins> emilio: Isn't this an or rather than an and?<br> <TabAtkins> TabAtkins: Yes, the discussion was about possible future syntax. Today's syntax is just a flat 1-class specificity<br> <TabAtkins> emilio: Can we just sort out that future stuff when we add it in the future then?<br> <TabAtkins> TabAtkins: yes<br> <TabAtkins> vmpstr: So proposal: :a-v-t() specifity is 1 class if it takes a *, 2 classes if it takes a list.<br> <TabAtkins> fantasai: CAn it be empty?<br> <TabAtkins> vmpstr: Not valid syntax<br> <TabAtkins> fantasai: Should it be valid?<br> <TabAtkins> vmpstr: That's basically what * does, unsure what benefit it woudl bring<br> <TabAtkins> fantasai: Just in general if there's a reasonable default behavior we allow omitting.<br> <TabAtkins> vmpstr: I think that might be a separate issue<br> <TabAtkins> fantasai: yeah<br> <TabAtkins> RESOLVED: :a-v-t(*) has specificity of 1 class, :a-v-t(list) has specificity of 2 classes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9546#issuecomment-1823205562 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 November 2023 17:35:29 UTC