- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 17:36:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-transitions-2] Put discrete transitions behind new syntax for compatibility`, and agreed to the following: * `RESOLVED: Add transition-behavior longhand, list valued part of transition shorthand, with normal | allow-discrete values (to start).` <details><summary>The full IRC log of that discussion</summary> <dbaron> flackr: We previously discussed that supporting discrete transitions had compat issues.<br> <dbaron> ... we resolved we need a way to opt in.<br> <dbaron> ... we had the open question of what the properties would be and how to apply them.<br> <dbaron> ... we now have a proposal<br> <jarhar_> vote with list of names here: https://github.com/w3c/csswg-drafts/issues/8857#issuecomment-1591335579<br> <dbaron> ... there's a poll with a decent number of responses<br> <dbaron> ... we add a new property: transition-animation-type: normal | animatable<br> <dbaron> ... normal is the current behavior<br> <dbaron> ... animitable allows transitions on discretely animatable property<br> <dbaron> ... it's another part of the transition shorthand, auto-extends<br> <fremy> q?<br> <fremy> q+<br> <dbaron> jarhar_: As Mason ??? we resolved on a longhand that's connected to the transition shorthand, we just need to choose a name.<br> <astearns> ack fremy<br> <dbaron> fremy: A question: what is the value of the animatable keyword? If you specify display, obivously you want it to be animated...<br> <dbaron> fremy: if I understand correctly, maybe I don't ... if you say 'transition: display 2s' it won't work. If so, why?<br> <dbaron> fremy: If you explicitly say `display` that means you want it?<br> <dbaron> flackr: That's correct. Reason not to default to that behavior is there are some properties like left or width where there are auto values that currently do not create transitions when you change values betwene a specified value and auto.<br> <fremy> looks like the room disconnected, or I did<br> <dbaron> flackr: Making this suddenly start discrete transitions breaks many existing sites.<br> <dbaron> flackr: we're trying to avoid this.<br> <dbaron> flackr: What I'm hearing from your question the animation type should be smarter and for properties that are *only* discrete, being specified in transition-property should make them tranition.<br> <dbaron> fremy: I think it's unfortunate that for `display` you have to add this keyword, but I now understand the need for some other properties.<br> <astearns> ack fantasai<br> <dbaron> fantasai: Sorry for not looking at this earlier... the property name seem mostly fine.<br> <dbaron> ... if you just use the longhand the values may also be fine<br> <dbaron> ... but in the shorthand it's vague what `normal` might be referring to.<br> <dbaron> ... since not that common you'd want to set, maybe make clearer when it's in the shorthand<br> <dbaron> flackr: maybe 'interpolable'... but given that it's the initial value you don't have to specify it.<br> <dbaron> fantasai: I might do interpolable | animatable since then the contrast is clearer. And since you don't have to type it in the normal case it's fine to be long. Makes it clearer what we're switching between.<br> <dbaron> flackr: makes sense<br> <dbaron> flackr: One downside I can see of this if if we want to support transitions to/from 'auto' that are interporable in the future, this would no longer make sense as a way to opt out of that new behavior<br> <dbaron> fantasai: good point<br> <dbaron> fremy: this would also be more descriptive, like 'allow-discrete'<br> <fremy> dbaron: one argument for normal is that we need the backwards compatible behavior across multiple changes<br> <fremy> dbaron: there is probably going to be more than one change we will want to do later<br> <dbaron> chrishtr: predicting, or we know of one?<br> <dbaron> flackr: yes, the behavior of to/from auto, we'd like to use this for a compatibility switch for that behavior in the future as well<br> <TabAtkins> I think "normal" is probably okay. "normal color" sounds weird but there's not really any reason to specify it.<br> <dbaron> flackr: I think in the future 'interopolable' doesn't make sense for that.<br> <TabAtkins> and then I really prefer "discrete" for the other value<br> <dbaron> fantasai: That logic makes sense to me... main concern if there's another longhand where 'normal' is the desirable initial value.<br> <TabAtkins> but I'm gonna hard-veto "interpolable" for spelling complexity reasons<br> <SebastianZ> q+<br> <dbaron> astearns: Maybe one resolution to have a longhand with an initial value of 'normal', and then discuss the other value we're adding today?<br> <astearns> ack SebastianZ<br> <dbaron> SebastianZ: How will we interact with 'auto' when you've been transitionable in the future? Should that be part of 'normal' later, or a new keyword?<br> <TabAtkins> yeah `transition-allow` sounds reasonable i think<br> <TabAtkins> it'll work for the next value we want to add too<br> <dbaron> jarhar_: The idea of ???. Many pages already have transitions of top, so animating between auto and 100px is something we want to not animate by default. We need that to be an opt-in. We could make it happen when you say animatable, or add a third thing.<br> <TabAtkins> so i support `transition-allow: normal | discrete`<br> <dbaron> flackr: We could add the interpolable behavior later if we felt need to distinguish between that behavior and discrete animations.<br> <dbaron> fantasai: We're possibly looking at 4... or 3 (flackr; 3) keyword values.<br> <dbaron> fantasai: Current behavior, incorporating discrete animations, and third is allowing things that are currently discrete and allowing them to be interpolated continuously.<br> <fremy> q+<br> <dbaron> fantasai: Initial value is... the first one.<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to suggest transition-allow<br> <dbaron> fantasai: It would be nice if we picked a set of 3 keywords that are distinguishable, rather than picking 2 and possibly ending up with an awkward situation with the third one that we already know we'd like to add.<br> <dbaron> fantasai: So 'animatable' wouldn't cover animate keywords as continuous.<br> <dbaron> flackr: Right, it covers doing anything you can use in animations which is discrete and continuous.<br> <dbaron> fantasai: I don't like 'transition-animation-type'... would 'transition-allow' be reasonable?<br> <dbaron> fantasai: Does that give us a different perspective on keywords we might want?<br> <dbaron> (3 segments but really 2 segments of name)<br> <fantasai> s/don't like 'transition-animation-type'/don't love 'transition-animation-type' because it's 3 segments but really 2 segments/<br> <dbaron> fremy: I guess since it's not a keyword... I like it being shorter, but feel like it's misleading. If you write 'discrete color' you're not going to get a discrete transition, which feels confusing.<br> <TabAtkins> q+<br> <astearns> ack fremy<br> <dbaron> fremy: In the shorthand, which is what people are going use most of the time, I think people will not get what they expect with 'transition: discrete color'<br> <astearns> ack TabAtkins<br> <fantasai> transition-allow: normal | [ continuous || discrete || interpolate-keywords ]<br> <fantasai> Not exactly but maybe something like that...<br> <dbaron> TabAtkins: Mainly a response to fremy -- allow makes things cleaarer -- we have made adjustments for this context before -- we have made specialized keywords that are allowed in the shorthand only.<br> <dbaron> TabAtkins: shorthand could recognize allow-normal and allow-discrete, turns into normal and discrete in the longhand.<br> <dbaron> fremy: the other one is that it sounds to me that it should be possible to hav e >1 of these things that you allow, e.g., 'allow-discrete' combined with new behavior for auto -- in that case you will have confusing shorthand. In that case it will lose meaning a bit.<br> <astearns> transition-capabilities: normal | [ allow-continuous || allow-discrete || allow-keywords ]<br> <dbaron> fremy: in the shorthand difficult to read, esp. with >1 keyword<br> <dbaron> fremy: could do a function allow() with list of behaviors<br> <dbaron> fremy: or whatever ? is ???<br> <astearns> s/? is ???/Alan is writing<br> <TabAtkins> dbaron: I was gonna suggest something like TAb said<br> <fremy> s/?/asterns/ s/???/is writing on irc/<br> <TabAtkins> dbaron: just make the values allow-discrete, at least, without a distinction between the shorthand/longhand<br> <TabAtkins> dbaron: we can have transition-allow: allow-discrete<br> <chrishtr> I can't hear<br> <TabAtkins> dbaron: it's a bit verbose in the longhand but if eveyrone's using the shorthand it's okay<br> <TabAtkins> dbaron: other thought, the other compat thing we know we want to do maybe isn't allow-*<br> <SebastianZ> q+<br> <TabAtkins> dbaron: I think the thing with animating auto values isn't as much about allowing as about changing what they do<br> <TabAtkins> dbaron: so maybe that one shouldn't be allow-*<br> <flackr> +1 it's about changing the interpolation<br> <TabAtkins> dbaron: so maybe name the property something else, but do still call the value allow-discrete<br> <fantasai> transition-ability seems easier than transition-capability<br> <TabAtkins> dbaron: and maybe another two-word name for the "transition from auto" behavior<br> <TabAtkins> (that sounds good)<br> <TabAtkins> (and yes, transition-ability)<br> <dbaron> SebastianZ: I want to iterate on what dbaron just said: I like the idea of putting allow- in values rather than property. We could have transition-type: allow-??? or allow-all<br> <dbaron> fantasai: Maybe traction on transition-ability<br> <fremy> I think it's a fun pun :D<br> <dbaron> jarhar_: future value could be allow-mixed<br> <SebastianZ> s/transition-type: allow-???/transition-type: allow-*/<br> <dbaron> flackr: I think the point is that it's not about allowing something but about changing interpolation between auto and specified values<br> <dbaron> dbaron: I'd point out that the future thing would also want to do things like numeric interpolation between auto / min-content / fit-content etc., which isn't actually mixed<br> <fantasai> interpolate-keyword-lengths<br> <flackr> or interpolate-used-values ?<br> <TabAtkins> yeah it's final values<br> <fantasai> transition-ability: allow-discrete interpolate-keyword-lengths<br> <dbaron> fremy: A question about that: is it about interpolating keywords or about interpolating the final value -- you may use the keyword within complex expressions. Authors want the property to remember the previous value and interpolate from that... but maybe not relevant to the discussion.<br> <dbaron> astearns: Could we resolve on transition-ability (pun) with values that will work in the shorthand?<br> <fantasai> +1<br> <dbaron> flackr: You don't need to specify the initial value in the shorthand because it's the initial value, so we really only need the value for allow-discrete<br> <fremy> +1<br> <dbaron> astearns: Is allow-discrete the first value we would add to this?<br> <TabAtkins> transition-ability: normal | allow-discrete<br> <dbaron> astearns: my proposed resolution is: ^<br> <fantasai> sgtm<br> <dbaron> dbaron: I'm a little hesitant about transition-ability<br> <dbaron> astearns: It has the transition- because it's a longhand, but I'm not sure I have a better idea.<br> <dbaron> ?: -capability<br> <dbaron> fremy: But people aren't going to type it.<br> <flackr> transition-interpolation<br> <fantasai> dbaron: there were some other suggestions in the issue<br> <dbaron> dbaron: Maybe transition-behavior ?<br> <dbaron> fantasai: transition-interpolation doesn't work for allow-discrete because it doesn't change how you interpolate, changes whether you transition at all<br> <chrishtr> transition-behavior: normal | allow-discrete<br> <dbaron> flackr: That's... fine... though not changing how you interpolate.<br> <dbaron> flackr: I don't think it's necessarily wrong.<br> <dbaron> flackr: Transitions don't currently allow discrete interpolations.<br> <chrishtr> transition-allowed: normal | discrete ?<br> <dbaron> astearns: As a sober adult... I think I agree with dbaron that transition-ability has an issue.<br> <astearns> s/As a/trying to be a/<br> <emilio> `transition-tweaks` or so?<br> <flackr> Maybe transition-trigger or transition-change ?<br> <fantasai> TabAtkins: Just don't pay attention to the pun. It works<br> <dbaron> astearns: for the people who think there's an issue with transition-ability, is there a single alternative that sounds better?<br> <fantasai> fantasai: "transition ability" -> "transition-ability<br> <dbaron> flackr: I put some in the IRC. (^^)<br> <dbaron> fantasai: Some values are about how it transitions, some are about whether it transitions. So has to accommodate both.<br> <fremy> transition-behavior sounds fine, really<br> <dbaron> dbaron: That's why I liked transition-behavior.<br> <dbaron> iank_: Don't we already have... overscroll-behavior.<br> <dbaron> chrishtr: poll between those 2 options?<br> <dbaron> astearns: option 1: transition-ability; option 2: transition-behavior<br> <emilio> 2<br> <miriam> 2<br> <flackr> 2<br> <SebastianZ> 2<br> <astearns> 2<br> <chrishtr> 2<br> <TabAtkins> 2<br> <fantasai> 1 !!!!<br> <jarhar_> 2<br> <dbaron> 2<br> <fremy> 2, weakly<br> <ydaniv> 1<br> <iank_> 2<br> <changseok> 2<br> <dholbert> 2<br> <bts> 1<br> <Rossen_> 2<br> <fantasai> T_T<br> <rachelandrew> 2<br> <bramus> 2<br> <dbaron> astearns: Proposed resolution: add transition-behavior longhand with normal | allow-discrete values to start.<br> <dbaron> flackr: Specifically with list values that match transition list.<br> <dbaron> fantasai: I think ability is a better word than behavior.<br> <chrishtr> resolution as stated sgtm!<br> <ydaniv> +1 to fantasai on that last note<br> <dbaron> fantasai: I still disagree, but not objecting.<br> <dbaron> RESOLVED: Add transition-behavior longhand, list valued part of transition shorthand, with normal | allow-discrete values (to start).<br> <iank_> "mode" also is in other properties<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-1646035541 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 17:36:28 UTC