Re: [csswg-drafts] [selectors-4] Add pseudo-class to establish before-change style for css-transitions on new elements. (#8174)

The CSS Working Group just discussed `Pseudo-class before-change style for transitions on new elements`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Pseudo-class before-change style for transitions on new elements<br>
&lt;Rossen_> q?<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/8174<br>
&lt;fantasai> flackr: when coming from display:none have no display style<br>
&lt;fantasai> ... so can't define a from state<br>
&lt;fantasai> ... can define in CSS animation, but less ergonomic<br>
&lt;fantasai> ... so proposing we add an :initial pseudo-class which establishes the initial style<br>
&lt;fantasai> ... the before-change style for CSS transitions<br>
&lt;fantasai> ... in discussion, decided that if we made this a pseudo-element<br>
&lt;chris> rrsagent, here<br>
&lt;RRSAgent> See https://www.w3.org/2023/01/11-css-irc#T17-10-12<br>
&lt;fantasai> ... we could optimize this by preventing e.g. sibling selectors and only require occasional style calculation when it's used<br>
&lt;fantasai> ... so proposal is to have ::initial establish the initial style<br>
&lt;emilio> q+<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack emilio<br>
&lt;fantasai> emilio: This would be a pseudo-element that matches against an element?<br>
&lt;fantasai> emilio: so matches element rules plus magic pseudo-element?<br>
&lt;fantasai> pseudo-element would be applied on top of element rules<br>
&lt;fantasai> emilio: that's pretty different from pseudo-element<br>
&lt;fantasai> emilio: I don't think we have a precedence for this, which is a bit tricky<br>
&lt;fantasai> emilio: I'm also confused when you want it<br>
&lt;fantasai> emilio: this is for coming back from display:none?<br>
&lt;fantasai> emilio: seems implementable, but seems tricky and weird to make it a pseudo-element<br>
&lt;fantasai> emilio: because targetting two element styles on one<br>
&lt;fantasai> emilio: weird wrt cascade<br>
&lt;fantasai> flackr: that's good feedback for pseudo-element approach<br>
&lt;fantasai> flackr: could also take pseudo-class approach, but less easily optimizable?<br>
&lt;fantasai> emilio: in what sense?<br>
&lt;fantasai> flackr: if you have combinator selectors, element showing up in the DOM can cause recalcuation<br>
&lt;fantasai> emilio: but that's the case for all pseudo-element<br>
&lt;fantasai> flackr: this is extra style recalc that doesn't normally exist<br>
&lt;fantasai> emilio: I'm a bit confused, you recalc more if you have :initial along the combinators.... depending how wel you optimize<br>
&lt;fantasai> flackr: I think given :initial is only establishing before-change style and otherwise doesn't apply to the element, not that weird that it conflicts with other styles<br>
&lt;fantasai> flackr: because those other styles can't initiate transitions from display: none<br>
&lt;fantasai> emilio: we have a similar case with pseudo-classes for links<br>
&lt;fantasai> emilio: need to resolve :visited / :unvisitied, need to do unconditionally, but dont' understand why :initial would be slower<br>
&lt;fantasai> flackr: if initial is a pseudo-class, can be used as part of combinator selectors<br>
&lt;fantasai> flackr: so have to resolve all those combinators<br>
&lt;fantasai> flackr: but if pseudo-element, can't be used in those combinators<br>
&lt;fantasai> emilio: for :visited we have special case<br>
&lt;fantasai> emilio: basically :visited on left of sibling is ignored<br>
&lt;fantasai> flackr: ah, we could do that<br>
&lt;fantasai> emilio: the way I think of implementing it is, we have this element ...<br>
&lt;fantasai> emilio: otherwise :initial only matches rightmost compound<br>
&lt;fantasai> flackr: that sounds reasonable to me<br>
&lt;fantasai> emilio: that would be less weird<br>
&lt;futhark> q+<br>
&lt;fantasai> +1 to emilio<br>
&lt;Rossen_> ack futhark<br>
&lt;fantasai> futhark: ignoring the pseudo-class, when resolving selectors, would have already computed style for previous one so would have eixsting computed style<br>
&lt;fantasai> futhark: so :initial wouldn't match on those elements<br>
&lt;fantasai> emilio: Right. :initial can only match in this special case<br>
&lt;fantasai> emilio: "this element is now :initial", now compute<br>
&lt;fantasai> emilio: with :has() have similar dependency...<br>
&lt;fantasai> futhark: Similar if getComputedStyle() in display:none subtree<br>
&lt;fantasai> futhark: You need to ensure you have styles there to do inherit etc.<br>
&lt;fantasai> emilio: not for siblings, but for ancestors<br>
&lt;fantasai> emilio: I'd rather say that it only matches on the rightmost<br>
&lt;flackr> +1<br>
&lt;chrishtr> +1<br>
&lt;fantasai> fantasai: How does this interact with page loading, partly loading?<br>
&lt;fantasai> flackr: applies anytime the element first gets a layout box<br>
&lt;emilio> q+<br>
&lt;fantasai> flackr: this would apply any time you add element to a page<br>
&lt;fantasai> flackr: separate issue for avoiding running things during load<br>
&lt;fantasai> flackr: but this is pre-existing problem for animations, which run on page load<br>
&lt;fantasai> Rossen_: So based on description, this would not fire on display:contents ?<br>
&lt;fantasai> Rossen_: since it doesn't have a box?<br>
&lt;fantasai> flackr: that sounds right<br>
&lt;Zakim> fantasai, you wanted to ask how this interacts with loading<br>
&lt;Rossen_> ack fantasai<br>
&lt;Rossen_> ack emilio<br>
&lt;fantasai> emilio: I think I'd rather special-case it to display:none since that's the actual thing<br>
&lt;PaulG> q+<br>
&lt;futhark> +1 to emilio.<br>
&lt;fantasai> emilio: at least, I don't think display:contents stops animations in the subtree, whereas display:none does<br>
&lt;Rossen_> ack PaulG<br>
&lt;fantasai> PaulG: If we're leaning towards pseudo-element, how would that affect AX tree?<br>
&lt;fantasai> PaulG: if not supposed to be animated at that time, just want to make sure we consider that<br>
&lt;fantasai> flackr: don't think we're leaning towards the pseudo-element approach<br>
&lt;fantasai> flackr: but not intenteded to establish a separate elmeent, just style the real element in the before-change state<br>
&lt;Rossen_> ack fantasai<br>
&lt;fantasai> fantasai: Suggest maybe flackr and emilio  can come back with a revised proposal, and we can move to other issues<br>
&lt;fantasai> flackr: fwiw, AX should be equivalent to animations<br>
&lt;fantasai> Rossen_: ok, let's end here<br>
&lt;fantasai> Rossen_: come back when you're ready, thanks for introducing<br>
</details>


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


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

Received on Wednesday, 11 January 2023 17:22:12 UTC