Re: [csswg-drafts] [css-view-transitions-2] Specificity of view transition pseudos with classes (#9887)

The CSS Working Group just discussed `[css-view-transitions-2] Specificity of view transition pseudos with classes`, and agreed to the following:

* `RESOLVED: for view transition pseudos, have * argument as 0 specificity, and everything else 1 type like specificity`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> vmpstr: We have VT pseudos that take a paramter<br>
&lt;TabAtkins> vmpstr: take name, *, and now classes<br>
&lt;TabAtkins> vmpstr: makes the arg syntax more involved<br>
&lt;TabAtkins> vmpstr: before classes, specificifity of the pseudo was 0 if *, and 1 tag-like specificity if it took a name<br>
&lt;TabAtkins> vmpstr: with classes, should probably change a bit. a few options<br>
&lt;TabAtkins> vmpstr: First option, and front-runner, is have every non-asterisk token count as a tag for specificity. just add them up<br>
&lt;TabAtkins> vmpstr: minor problem here is having a name and a class has the same specificity. only downside.<br>
&lt;TabAtkins> vmpstr: Second option is have the name be ID-like and class be class-like<br>
&lt;TabAtkins> vmpstr: This is also simple, and similar to :has()/:is()<br>
&lt;TabAtkins> vmpstr: counter-argument is :has/is are more structural, this is specifically a VT element<br>
&lt;TabAtkins> vmpstr: Last option is to use the argument just as a tiebreaker<br>
&lt;bramus> q+<br>
&lt;khush> q+<br>
&lt;TabAtkins> vmpstr: so you use the argument solely if selectors entirely tie.<br>
&lt;TabAtkins> vmpstr: a bit more complicated to spec and implement<br>
&lt;TabAtkins> vmpstr: I initially thought the tiebreaker is best, but I'm convinced now it's more complex than necessary. I think option 1 is good enough, where every token is just a tag-like for spec.<br>
&lt;miriam> ack bramus<br>
&lt;TabAtkins> bramus: I'm on board with Vlad - option 3 was my first, but option 1 is easy to comprehend.<br>
&lt;TabAtkins> bramus: I dont' think option 2 is viable since you're changing existing beahvior<br>
&lt;TabAtkins> bramus: often authors today are adding a clause to the root to flip the animation direction<br>
&lt;TabAtkins> bramus: that adds a class-like specificity to make it win<br>
&lt;TabAtkins> bramus: If we change to have the name be ID-like, it could override those. so it's a breaking change<br>
&lt;miriam> ack khush<br>
&lt;TabAtkins> khush: echoing Vlad, if we made an ideal choice we'd add a new specificity term<br>
&lt;fremy> q?<br>
&lt;fremy> q+<br>
&lt;TabAtkins> khush: the pseudo arguments are just what specific pseudo you're selecting, my intuition it's less important than what element is being targeted for the pseudo<br>
&lt;TabAtkins> khush: but it is indeed a lot more complex, and so just doing Option 1 is fine<br>
&lt;TabAtkins> khush: I'm the one that suggested giving the name ID-like spec, but we have already specced different beahvior indeed<br>
&lt;TabAtkins> khush: one nice thing is the another feature for VT types lets you not rely on outside elements to select. hopefully that can reduce the issue with specificity - you'll generally just use the VT type only<br>
&lt;khush> q?<br>
&lt;miriam> ack fremy<br>
&lt;TabAtkins> fremy: Is this even required?<br>
&lt;TabAtkins> fremy: current behavior is just [0,0,0] or [0,0,1]<br>
&lt;TabAtkins> fremy: If you do that you can just order them in your stylesheet as needed<br>
&lt;TabAtkins> fremy: Is there really a use-case for having them implicitly ordered somehow? Just wondering if it's even worth increasing the specificity<br>
&lt;TabAtkins> vmpstr: good question. if you order them correctly in your stylesheet - we still have to say what happens if you specify a class but not a name<br>
&lt;noamr> q+<br>
&lt;TabAtkins> vmpstr: But adding them to get a larger count is optional, sure. If just feels more specific if you add more class names, or class+name, then just adding a name by itself<br>
&lt;TabAtkins> vmpstr: So just adding them up is probably Good Enough and somewhat intuitive<br>
&lt;TabAtkins> fremy: Yeah, just something new to learn. if it's not required, might be okay to just do nothing new<br>
&lt;TabAtkins> vmpstr: So your proposal is just "anything but asterisk is [0,0,1]"<br>
&lt;TabAtkins> noamr: And that doesn't compete with HTML in the selector<br>
&lt;miriam> ack noamr<br>
&lt;TabAtkins> vmpstr: And then your tiebreaker would be declaration order<br>
&lt;TabAtkins> bramus: i'm not sure if having asterisk 0 and anything else be 1...<br>
&lt;TabAtkins> bramus: i can imagine a scenario "all .card animate one way, but one specific card animate another"<br>
&lt;khush> q+<br>
&lt;miriam> ack khush<br>
&lt;TabAtkins> vmpstr: if that specific one is targeted with a name, wouldn't fix things - still would be [0,0,1]<br>
&lt;TabAtkins> khush: yeah intuitively you might write ::vt(special-card) and ::vt(.card), expecting first to win, but that's a harder model to specify<br>
&lt;TabAtkins> khush: So maybe better here indeed to just rely on name ordering<br>
&lt;vmpstr> proposal: for view transition pseudos, have * argument as 0 specificity, and everything else 1 type like specificity<br>
&lt;TabAtkins> miriam: objections?<br>
&lt;TabAtkins> RESOLVED: for view transition pseudos, have * argument as 0 specificity, and everything else 1 type like specificity<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9887#issuecomment-1939286361 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 12 February 2024 18:16:46 UTC