- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Sep 2021 00:00:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations] TAG feedback: interaction with prefers reduced motion`, and agreed to the following: * `RESOLVED: We are going to start specifying a no motion at all mode that makes motion inducing animations discrete between keyframes where keyframes are sufficiently separated in time` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [scroll-animations] TAG feedback: interaction with prefers reduced motion<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5321<br> <dael> flackr: Feedback from TAG was that this could be very disconcerting for people with vistibular disorders so want to be able to disable<br> <dael> flackr: 2 separate issues here<br> <dael> flackr: One is idea of adding more granular prefers-reduced-motion values. There are examples of effects devs can fallback to that the dev doesn't believe introduces issues.<br> <dael> flackr: Also you could still run the animations that are necessary. give the dev freedom to run some animations<br> <dael> flackr: Other area is if we had model to force animations to be disabled, how would we? I'd like it to be all animations, not just scroll.<br> <dael> flackr: We need a model to preserve a11y of content. Many examples where scroll linked goes into view and out as you scroll past. First and last isn't sufficient so propose get nearest keyframe so you get all the points in the animation but without smooth motion<br> <dael> astearns: Take the 2 points in order?<br> <dael> flackr: Sure<br> <dael> astearns: First is adding more granular values to prefers-reduced. Purpose is allow devs to gradually add animations?<br> <dael> flackr: Precident is it's dev makes best effort to reduce. Prop to address serious concerns by having another level dev can't override<br> <dino> q+ but only if my microphone works<br> <dino> q+<br> <dael> TabAtkins: What is the set of additional prefers reduced motion values? See a few different in post by jcraig<br> <dael> flackr: Simpliest is just one that is no-motion<br> <dael> flackr: There are intermediates we could consider but detecting which are parallax or scale seems like could be conplicated. In order to meet need of disabling animations I think it would be nice to have a disabled setting<br> <dael> TabAtkins: Stronger than current reduce value?<br> <dael> flackr: Yes<br> <dael> TabAtkins: Okay, seems fine.<br> <Morgan> q+<br> <dino> i'm confused. `prefers-reduced-motion` is a media query, not a browser setting. it doesn't impact what the browser does.<br> <dino> yeah - i give up.<br> <dael> astearns: Question confuses me. I thought it was a browser setting<br> <dael> flackr: Setting reflects the OSs environment.<br> <dael> flackr: Some browser UI responds to preference as well<br> <dael> TabAtkins: I see issue dino is confused. 2 part thing. MQ for more granular helps. Completely separate is the browser intervention to disable or reduce animations.<br> <dael> flackr: Correct<br> <dino> ok.<br> <dael> flackr: Strictest prefers-reduced-motion could be used by authors for when they know browser intevention is taking place<br> <astearns> ack dino<br> <astearns> ack Morgan<br> <dael> Morgan: Wanted to chime in to say we've been getting increasing number of bugs on FF saying we don't step in enough. Entertaining idea of browser doing more might be a good thing<br> <dael> flackr: I think it's unclear yet when we'd choose between versions of reduced. Might be browser setting. This would give us more flexibility<br> <dino> +1 on more granular results in the media-query somehow. But -1 on blocking scroll animations. We can't tell if the scroll animation would cause the issue. That's up to the developer.<br> <astearns> ack dbaron<br> <dael> dbaron_mobile: I wanted to...the TAG discussions quoted were a year ago when I was on TAG so I thought I could give more context<br> <dael> dbaron_mobile: I think one of the big questions that came up in TAG discussion is that the way these mqs work is depend on author to do everything. If author doesn't query for prefers-reduced-motion you don't get anything different<br> <dael> dbaron_mobile: Deep question is doesn't that seem wrong and shouldn't browser automatically reduce to do right thing for user? and once it does that how should MQ works since they're designed around the author does the thing.<br> <dael> dbaron_mobile: If browser does the thing what should the MQs look like so they author can say I know what I'm doing in this case<br> <dael> astearns: MQ would let author know toolkit is reduced. Things they cannot do any they may know a fallback<br> <dael> flackr: Similar to no script<br> <dael> TabAtkins: Problem of communicating forced vs do as much as you can is difficult, but in this case golden. If forced is we're turning off your animations and tell the author then the author removing animations is compat. Browser and author actions would match. We can have a harser value and not worry and let interventions happen<br> <dael> astearns: I was responding to one thing dbaron_mobile mentioned. I don't know if you were finished, though.<br> <dael> dbaron_mobile: I think I was finished. To respond to TabAtkins I think one of the question is if there's a need for intermediate thing where default is to disable but author can say "yeah I know what I'm doing and I want to do this". We have something liket hat for color but it has to be custom for each thing<br> <dael> TabAtkins: yeah, for color there are some things that can't be communicated with system colors. I suspect that's not same with animations. We probably can leave that case to the side and do ar easonable job<br> <astearns> ack fantasai<br> <dholbert> q+<br> <dael> fantasai: One thing I was thinking but haven't thought through- what if the UA disables animations by injecting rules between normal and important. Overrides most but author could important the animation if they're really needed<br> <dael> flackr: Interesting idea.<br> <dael> flackr: Could be something we add later<br> <dael> astearns: Talking about that way of implementing? Or ther granular basis all together?<br> <dael> flackr: We could even if we force disable we could later add a way to reenable either in strong disable or as a third way<br> <astearns> ack dholbert<br> <dael> dholbert: Thinking about what user exposed config or UI for this. A little worried about complexity to communicate. Sounds like do not track header vs adding an ad blocked but appied to animations. Weak is send a single and strong is interventions.<br> <dael> dholbert: I think we need to take that into consideration when thinking about how many values. How do we communicate to user and make it understandable<br> <dael> astearns: yeah, a little concerned on browser UI<br> <dael> astearns: From what I understand no UA impl turn it all off<br> <dael> flackr: Correct<br> <dael> astearns: So MQ for detecting is kind of cart before horse. Once a browser impl we could do MQ to let authors respond to the harser value<br> <dael> flackr: Perhaps relates to next part on how browser would strongly disable. If required for scroll-linked animations we need strong disbale<br> <dael> astearns: Shall we switch to the how?<br> <dael> flackr: sgtm<br> <dael> flackr: My prop is when browser wanted to completely disable animations it would change animation type to discrete that flips at 50% between keyframes. All animations would animate between keyframes but no motion between. Gets you access to intermediate positions<br> <dael> flackr: Gets you intermediate scroll positions or other animations where required for site<br> <dael> TabAtkins: Basically all animation timing is discrete. Seems okay to me<br> <dael> astearns: Straightforward. A bit worried about people with animations that have tons of keyframes to get weird motion. if keyframes are close enough in time it would still have a jerky thing<br> <dael> TabAtkins: Could be detected. Animations that aren't machine generated are small number. machine generated we could take every nth or ever 1sec keyframe<br> <dael> flackr: Yeah, i would propose something like that<br> <dael> astearns: Other comments?<br> <heycam> q+<br> <dael> astearns: Anyone with a different idea of how to impl harsh mode?<br> <astearns> ack heycam<br> <dael> heycam: There was example at end of issue that had scroll linked animations effecting color. Color animations don't fall into same category of effects that cause problems. Should we have a way to allow or distinguish between non-movement animations?<br> <dael> heycam: If we have the intervention we wouldn't want to cut off those<br> <dael> flackr: Yes, we could define property set that is capable of introducing motion and only change interp type of those properties<br> <dael> flackr: Since you would be changing it for all motion properties it shouldn't create inconcsitencies in the animation b/c could have dependent motion properties<br> <dael> heycam: May be possible to select the set of properties, but may need thinking<br> <dael> astearns: May be simplier to find the properties that would not create motion<br> <dael> dholbert: Animated a variable as line height and rgb, would that be inconsistent? Only clamp in one case<br> <dael> flackr: You would<br> <dael> TabAtkins: Variables would be clamp by default because you don't know where they're used<br> <dael> astearns: Makes sense. Also thinking about custom properties defined in JS and we would turn those off b/c don't know what used for<br> <dael> astearns: Hearing a fair bit of interest in getting this worked out. Looking for resolution to proceed on working on this?<br> <dael> flackr: Yes, wanted a path forwrd. If this is promising direction. I noticed you mentioned scoll linked animations.<br> <dael> astearns: I've heard agreement it's for all animations. Any disagreement on all?<br> <dael> astearns: Prop: We are going to start specifying a no motion at all mode that makes motion inducing animations discrete between keyframes where keyframes are sufficiently separated in time<br> <dael> astearns: Obj?<br> <dael> RESOLVED: We are going to start specifying a no motion at all mode that makes motion inducing animations discrete between keyframes where keyframes are sufficiently separated in time<br> <dael> astearns: Also want resolution on adding a MQ for this?<br> <dael> astearns: or wait on that until further along?<br> <dael> flackr: I think it's not blocking but would be nice for devs to be able to respond. Could be deferred.<br> <dael> astearns: Let's defer. We will have better use cases for MQ once this new mode is mapped out<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5321#issuecomment-910924409 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 September 2021 00:00:22 UTC