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 `[selectors-4] Add pseudo-class to establish before-change style for css-transitions on new elements.`, and agreed to the following:

* ``RESOLVED: specify `@initial` as defined in this issue and open another issue about the duplication problems with entry and exit styles``
* ``RESOLVED: start with `@starting-style` ``

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> flackr: We were looking at using a pseudo-class to establish a before-change style<br>
&lt;emeyer> …We’ve proposed `add-initial` (bikeshedding to come) that defines a block used for before-change styles<br>
&lt;emeyer> …This is implemented, working well, doesn’t have weird edge cases<br>
&lt;emeyer> …Tab nicely summarized all the semantics<br>
&lt;emeyer> TabAtkins: It’s `@initial` used whenever an element doesn’t have a before-change style<br>
&lt;fantasai> s/add-initial/@initial/<br>
&lt;emeyer> …In particular, it answers all the weird questions from doing this as a pseudo<br>
&lt;emeyer> …@rules behave a lot better<br>
&lt;emeyer> …This also works a lot better with nesting<br>
&lt;emeyer> …I’m good with this<br>
&lt;emeyer> astearns: Commetns or questions?<br>
&lt;emeyer> dbaron: Are there cases where y ou want to write both for @initial and for something else?<br>
&lt;emeyer> TabAtkins: Possibly but only incidentally<br>
&lt;emeyer> …Sometimes you’ll want to write so that normal style is the same as initial styles<br>
&lt;emeyer> …But with a different class you’ll want different stuff<br>
&lt;emeyer> …Doing it this way means you can’t easily combine them, you’d have to write the styles twice<br>
&lt;emeyer> dbaron: That’s my concern; I had a colleague who had to repeat styles<br>
&lt;dbaron> s/repeat styles/repeat styles to make the entry and exit transitions match/<br>
&lt;emeyer> flackr: I think that might be the common case if you want something to fade out when it goes away and fade in when coming back<br>
&lt;emeyer> TabAtkins: One sets opacity 0 and another doing the same, yeah<br>
&lt;emeyer> flackr: Haven’t thought this deeply but we could consider… never mind<br>
&lt;emeyer> TabAtkins: Yeah, I couldn’t make that make sense either<br>
&lt;emeyer> astearns: Is this a blocking concern, dbaron?<br>
&lt;emeyer> dbaron: I think it’s something we should pay attention to<br>
&lt;emeyer> …The particular pattern I saw looked pretty ugly, but then the other proposals here also had significant issues<br>
&lt;emeyer> …We could maybe change the rules around this to ameliorate in some way<br>
&lt;tantek> RRSAgent, make logs public<br>
&lt;emeyer> TabAtkins: If we do pursue the mixin idea, we could write styles once in the mixin and call it from both spots<br>
&lt;RRSAgent> I have made the request, tantek<br>
&lt;emeyer> astearns: Any other discussion?<br>
&lt;emeyer> (silence)<br>
&lt;masonf> +1<br>
&lt;emeyer> astearns: Sounds like the proposal is to specify `@initial` as defined in this issue and open another issue about the duplication problems with entry and exit styles<br>
&lt;emeyer> …Objections?<br>
&lt;emeyer> RESOLVED: specify `@initial` as defined in this issue and open another issue about the duplication problems with entry and exit styles<br>
&lt;emeyer> flackr: There‘s also a question on the issue about the actual name<br>
&lt;emeyer> astearns: While this isn’t a keyframe, this is tied to animations<br>
&lt;emeyer> TabAtkins: Transitions, not animations<br>
&lt;emeyer> flackr: If you have an implicit `from` keyframe, it animates from there, not the initial style<br>
&lt;emeyer> TabAtkins: `@initial-style` is fairly reasonable<br>
&lt;emeyer> …It’s a little generic but not so generic it doesn’t mean anything<br>
&lt;emeyer> astearns: Would it be bad to make it longer for clarity?<br>
&lt;masonf> `@initial-state` maybe?<br>
&lt;emeyer> flackr: If we’re exploring long names, `@before-change` is very specific to what this is<br>
&lt;masonf> `before-change` is the same length as `initial-state`<br>
&lt;emeyer> …That’s what we call it in the spec<br>
&lt;emeyer> TabAtkins: Not opposed to that<br>
&lt;emeyer> …It’s weirder to puzzle out what it does, but it’s weirdness speaks to specilaized nature<br>
&lt;emeyer> s/it’s/its/<br>
&lt;emeyer> astearns: I like that<br>
&lt;masonf> s/its/it's<br>
&lt;emeyer> dbaron: One thing that bother me about before-change is that it omits it’s only for when the element appears<br>
&lt;fantasai> “before construction” ?<br>
&lt;emeyer> …Maybe replace `initial` with `start`<br>
&lt;masonf> `@starting-style`?<br>
&lt;fantasai> +1<br>
&lt;emeyer> TabAtkins: Maybe we should take bikeshedding back to issue; we need more percolation<br>
&lt;emeyer> fantasai: I like mason’s proposal<br>
&lt;miriam> +1<br>
&lt;emeyer> …`@starting-style`<br>
&lt;emeyer> astearns: Given we’re coming up with multiple good options, we should take it back to the issue<br>
&lt;emeyer> flackr: My concern is delaying too long over the name<br>
&lt;emeyer> fantasai: I think we shoudl conclude on another call but we could bikeshed in the issue<br>
&lt;emeyer> flackr: Sounds good<br>
&lt;emeyer> s/shoudl/should/<br>
&lt;fantasai> fantasai: And start with `@starting-style`, rather than `@initial`<br>
&lt;flackr> +1<br>
&lt;emeyer> fantasai: I suggest we start with `@starting-style` for now<br>
&lt;emeyer> astearns: Are you asking for a resolution?<br>
&lt;TabAtkins> +1<br>
&lt;emeyer> fantasai: Yes, that we call it that until bikeshedding is concluded<br>
&lt;masonf> +1<br>
&lt;emeyer> astearns: Any objections?<br>
&lt;emeyer> RESOLVED: start with `@starting-style`<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-1515026543 using your GitHub account


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

Received on Wednesday, 19 April 2023 16:23:15 UTC