Re: [csswg-drafts] [css-transitions-2] Put discrete transitions behind new syntax for compatibility (#8857)

The CSS Working Group just discussed `[css-transitions-2] Put discrete transitions behind new syntax for compatibility`, and agreed to the following:

* `RESOLVED: Pick option 2 with name to be bikeshed`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> flackr: When we were trying to ship support for discrete transitions one common case overlloked is common properties that are sometimes discrete and sometimes continuous.<br>
&lt;dael> flackr: This has broken a few sites as shown in issue. Think we need a new syntax to opt in to discrete transitions<br>
&lt;dael> flackr: A bunch of proposals in the issue<br>
&lt;dael> flackr: Two with most support are having a long hand transition property similar to duration and easing that spec per transition if it should start on discrete property changes<br>
&lt;dael> flackr: Other is option 4 from fantasai having a separate property that's a switch for if you do discrete transitions<br>
&lt;dael> fantasai: That prop would have allow/don't allow/all for these properties and it cascades independently.<br>
&lt;dael> fantasai: I'm not saying it's better, but a different approach<br>
&lt;dael> flackr: Two ways of looking. Yours is better for site-wide switch, other is better for property by property.<br>
&lt;dael> flackr: In both you can say you want discrete everywhere. Harder to specify in option 2<br>
&lt;dael> Rossen_: If I'm reading the emoji vote, 6 for #2 and 4 for #1?<br>
&lt;dael> flackr: To be fair, #4 was added later<br>
&lt;dael> Rossen_: Should we be discounting #1? It's a smaller population<br>
&lt;dael> fantasai: I think that option 2 was better than 1. It should come down to 2 vs 4. We could do both<br>
&lt;dael> fantasai: Initial value of the transition mode is an auto value that looks up another property<br>
&lt;dael> flackr: Maybe consider one as a starting point and we could add the other?<br>
&lt;dael> fantasai: One thing that makes it trick is if we think it could be both have to think about how to name them<br>
&lt;dael> Rossen_: Can we live with 2 or 4 only?<br>
&lt;dael> flackr: and fantasai Yeah<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack fantasai<br>
&lt;dael> fantasai: Tricky is what is the pattern of use and what will be easier to use in most cases. You can mostly do most of it with either<br>
&lt;dael> flackr: Either let you global opt in. Option 2 if you don't want all you have to go transition by transition. Option 4 is by property<br>
&lt;dael> fantasai: I think option 2 is better. It's more powerful<br>
&lt;dael> flackr: More configurable. And more consistant with other transition longhards<br>
&lt;dael> fantasai: Agree<br>
&lt;dael> Rossen_: 4 is additive?<br>
&lt;dael> fantasai: Could add if we want to<br>
&lt;dael> Rossen_: Sounds like fantasai you're leaning toward #2?<br>
&lt;dael> fantasai: Yeah<br>
&lt;dael> Rossen_: I think we have a clear winner<br>
&lt;dael> Rossen_: Want to hear from the rest of folks on the call<br>
&lt;dael> smfr: Does this make a non-discrete animating prop animate in discrete way?<br>
&lt;dael> flackr: No<br>
&lt;dael> flackr: Some properties are sometimes discete. Their discrete interpolations star with this<br>
&lt;dael> smfr: Transition list was opacity and display are you forced to supply a value for opacity if you want discrete on display?<br>
&lt;dael> flackr: No downside to discrete on opacity<br>
&lt;dael> smfr: Could be confusing for author<br>
&lt;dael> flackr: It is auto expanding list<br>
&lt;dael> smfr: Could also expect discrete on opacity to split to by 50%<br>
&lt;dael> flackr: That's why I had a bunch of options on names. I proposed animatable<br>
&lt;dael> fantasai: Non-animatable properties are quite exceptional I don't think should name based on that<br>
&lt;dael> flackr: It's what the spec says so suggested that<br>
&lt;dael> fantasai: True, but most people don't read spec. Need to think about best way to suggest this to authors<br>
&lt;dael> flackr: Maybe 'all' is value to include discrete<br>
&lt;dael> fantasai: Thinking transition-discrete: all|none|magic value that says if it's discrete you can animate and if it's not it doesn't animate. That way you can throw it on your site and transition discrete properties<br>
&lt;dael> fantasai: If you're not using the all you can set it on whole site and no effect<br>
&lt;dael> smfr: High level comment, discrete is probably hard for non-native speakers.<br>
&lt;dael> fantasai: Yeah. not sure what else. transition-non-interoperable<br>
&lt;dael> flackr: I think we're good with option 2<br>
&lt;dael> fantasai: Yeah, need to figure out what to call it and values<br>
&lt;dael> Rossen_: Let's take a decision and bikeshed name on the issue<br>
&lt;dael> Rossen_: Objections to pick option 2 with name to be bikeshed<br>
&lt;dael> RESOLVED: Pick option 2 with name to be bikeshed<br>
&lt;dael> fantasai: Do we want a magic value that says transition this property only if it is discrete or interorable. Don't transition if it's a property that has an indiscrete<br>
&lt;dael> flackr: Could be UI default since possibly not breaking<br>
&lt;dael> fantasai: Yeah<br>
&lt;fantasai> s/UI/UA/<br>
&lt;fantasai> s/Yeah/Yeah, could be/<br>
&lt;dael> Rossen_: Do we need to resolve on something?<br>
&lt;dael> fantasai: Question is do we add the value or not<br>
&lt;dael> flackr: And what would we call it?<br>
&lt;dael> fantasai: 'magic' for now. bikeshed later<br>
&lt;dael> flackr: If this was not initial value I'd say it's additive<br>
&lt;dael> fantasai: But it could be initial value<br>
&lt;dael> Rossen_: I think we can work this out on the issue<br>
&lt;dael> Rossen_: And hear more from bramus, tab, brian, and other folks who have been engaged<br>
&lt;dael> flackr: Sounds reasonable<br>
</details>


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


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

Received on Wednesday, 7 June 2023 23:27:55 UTC