Re: [csswg-drafts] [web-animations-1][css-ui] Animating user-interaction controls (#3153)

The CSS Working Group just discussed `animating ui controls`, and agreed to the following:

* `RESOLVED: Mark user-select as discretely animatable, not non-animatable.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: animating ui controls<br>
&lt;RossenF2F> github:https://github.com/w3c/csswg-drafts/issues/3153<br>
&lt;TabAtkins> fantasai: I thought we resolved this topic last year. I think we should be marking these properties as discretely aniamtable? (nav-up, user-select, etc)<br>
&lt;TabAtkins> fantasai: Stuff in the UI spec.<br>
&lt;TabAtkins> dbaron: I think we've only marked things as non-animatable when there are technical problems, like animation-* or display.<br>
&lt;tantek> is that really the right default?<br>
&lt;tantek> q+<br>
&lt;TabAtkins> fantasai: That's my understanding, so I think we just close this issue?<br>
&lt;TabAtkins> florian: I agree we only make things impossible when it's technically hard, and I don't that the css-ui things are that. I think they should be switched to discrete explicitlyh.<br>
&lt;tantek> q?<br>
&lt;TabAtkins> florian: So if anything in CSS UI is still marked as non-animatable, we should fix that to say "discrete"<br>
&lt;RossenF2F> ack tantek<br>
&lt;TabAtkins> tantek: Something dbaron said  about non-animatable.<br>
&lt;TabAtkins> tantek: I agree that's been our historical default, but I'm wondering if that's acutally desirable.<br>
&lt;TabAtkins> tantek: At minimum, every time we mark something animatable, that implies we need tests for that, that the animation works.<br>
&lt;heycam> q+<br>
&lt;florian> q+<br>
&lt;TabAtkins> tantek: So those are all costs. So is that rule a sufficient default? In this particular case, it feels kinda weird to animate these particular proeprties.<br>
&lt;TabAtkins> tantek: I want to know florian's opinion on this. But my intuition is that there's no use-case for these particular properties.<br>
&lt;emilio> q+<br>
&lt;TabAtkins> dbaron: As far as use-cases, peopel use animations in contexts where they animate some UI in from not being there, then "turn it on".<br>
&lt;TabAtkins> dbaron: I could imagine setting nav-up as part of turning it on. Maybe it could have been there all the time, but it seems plausible to do.<br>
&lt;TabAtkins> tantek: That's the kind of reasoning I'm happy to have on the reasoning.<br>
&lt;TabAtkins> s/the reasoning/the record/<br>
&lt;florian> q?<br>
&lt;TabAtkins> tantek: If you're animating layout, you might need to animate the nav-* props; seems weird but I've seen weirder.<br>
&lt;RossenF2F> ack heycam<br>
&lt;TabAtkins> TabAtkins: And Lea has brought up examples in the past of odd-seeming animations; I think there's probably an example for everything.<br>
&lt;TabAtkins> heycam: I think there's value in having the blanket rule of "animatable unless impossible" vs lots of use-case analysis.<br>
&lt;RossenF2F> ack florian<br>
&lt;TabAtkins> heycam: And if something's not animatable we ahve to write tests for that anyway, so same amoutn of work.<br>
&lt;emilio> q-<br>
&lt;TabAtkins> florian: Agree on testing.<br>
&lt;tantek> q?<br>
&lt;tantek> good point heycam<br>
&lt;TabAtkins> florian: And note it's also about transitions. "animate or not" tells you whether the transition happens at the middle or at the beginning (or end? don't remember). So it has to switch anyway.<br>
&lt;tantek> is there a use-case for user-select animating?<br>
&lt;TabAtkins> florian: display, animation, etc can't be switched at all for technical reasons, but everything else we're just deciding where in the animation it switches, and there's no good reason to ban it from choosing where to switch.<br>
&lt;tantek> (figured I'd just ask in IRC instead of q+ for that)<br>
&lt;tantek> what are we making user-select consistent with?<br>
&lt;TabAtkins> florian: I agree that user-select doesn't appear to ahve a use-case, but for aforestated reasons having an exception here doesn't seem to be useful; we stil have to pick one way or the other.<br>
&lt;heycam> tantek, perhaps for similar reasons as dbaron mentioned about some UI animating in. maybe you want it not to respond to user interaction until the animation is done, or at a certain point<br>
&lt;fantasai> all other properties in CSS that use keyword values<br>
&lt;RossenF2F> q?<br>
&lt;tantek> ok heycam. good enough for now.<br>
&lt;TabAtkins> tantek, more importantly to florian's point, transitioning the property makes it swap at some point regardless, its 'justa bout whether it's possible to choose where it transitions or not.<br>
&lt;TabAtkins> RossenF2F: So close as accepted? Any objections?<br>
&lt;TabAtkins> RESOLVED: Mark user-select as discretely animatable, not non-animatable.<br>
&lt;tantek> TabAtkins: ok that's the consistency I was looking for. thanks.<br>
</details>


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

Received on Thursday, 23 January 2020 12:45:43 UTC