- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Oct 2020 23:33:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations] TAG feedback: interaction with prefers reduced motion`. <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> Rossen_: aboxhall_ was part of the larger TAG review and has captured thoughts. aboxhall_ if you want to summerize outstanding issues with this it would be great<br> <dael> aboxhall_: I don't have a solution. Problem is we're looking at the scroll animations proposal and it seemed to me that maybe we can do better in this case then requiring authors to take a specific action to support perfers-reduced-motion given that most of the use cases for scroll animations seem like they fall into bucket of things that will trigger vistibular disorders and potentially problematic<br> <dael> aboxhall_: IN the issue the last comment I left tried to get into that. I linked to blog post on WK which listed those potential triggers. paralax and zoom use cases are explicitly called out. Plane shifting in the blog post is implied as scroll triggered<br> <Rossen_> q?<br> <dael> aboxhall_: Seemed strong overlap between use cases and triggers. Seems unsatisfying to leave it to authors to not harm users in this case<br> <florian> q+<br> <dael> smfr: Are there other cases where UA overrides author spec animations when p-r-m is in effect<br> <dael> aboxhall_: Don't believe so, but doesn't mean we shouldn't<br> <dael> aboxhall_: In issue florian drew parallels with forced-colors where UA overrides author's colors. There are escape hatches to let author react.<br> <florian> [It's a different Florian (or I'm having gaps in my memory]<br> <dael> aboxhall_: In that case florian said we could use similar approach. My heistation with that is I don't think users will get an extra switch any time soon. If someone checks the p-r-m switch...it's not for us to say if it's just your opinion or because animations will trigger migraines.<br> <dael> aboxhall_: Given only one switch how can we react to that switch?<br> <fantasai> [Didn't you post https://github.com/w3c/csswg-drafts/issues/5321#issuecomment-659185761 ? ]<br> <Rossen_> q<br> <dael> aboxhall_: Potentially do we add...I don't know enough about technologies to speculate the way forward<br> <astearns> ack florian<br> <dael> florian: I'm hearing what you're saying<br> <dael> florian: Wondering if you turn them off entirely you'd have problem with state where animation in early and end are different. Instead of turning off it can be step wise with one step from start to end so initial and final is right but you don't get the movement<br> <dael> florian: If one initial and final state is enough or we need a way to declare multiple midpoints I don't know<br> <dael> florian: Something like this allowing a snapping change instead of moving change might work<br> <dael> aboxhall_: Fantastic idea to begin experiments with<br> <Rossen_> q?<br> <dael> Rossen_: Just to make sure when we talk about animations here it's css only or web animations?<br> <dael> aboxhall_: scroll-linked animations<br> <dael> aboxhall_: Just because it seemed like the use cases for that had such a strong overlap with the potentially triggering animations<br> <dael> aboxhall_: Worth exploring how to more deeply embed that preference into animation APIs<br> <dael> aboxhall_: To start scroll-linked animations and florian suggestion<br> <dael> florian: The overlap is there but not all scroll animation are pure decoration. Maybe comics or long form articles. If it doesn't move you don't understand what it's telling you. Being able to reach end maybe with multi step is needed<br> <dael> Nicole: On mobile animations are meaningful to find drawers and nav. Shame to lose semantic animations that provide that meaning<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to talk about !important rules<br> <dael> fantasai: Meantion we have 2 levels of author rules. Normal and !important. If this is controllable with css property it's possible we could auto override and we could only do that for non-important rules. If an author things it's important they can flag. Only helps to extent it's expressable in css declarations but we can distinguish between things that exist and nice to have<br> <dael> aboxhall_: That's good, yeah<br> <fantasai> s/things/thinks/<br> <fantasai> s/exist and/needs to exist and those/<br> <dael> astearns: Hearing a lot of interest in solving this problem of scroll animation when p-r-m preference. I don't hear a full idea of what we should be doing<br> <dael> florian: Not fully, but I propose when this preference is on, the easing function of the animation is transformed to step-wise and have an open issue if it's a single step between start and end or if there's a control about how many steps and where<br> <dael> astearns: Seems start to end step is easy to spec<br> <jcraig> q+ to mentioned animations triggered by user animations versus animation that start at unexpected times<br> <dael> fantasai: Scrolling, there's the time during active scroll and when you have stopped scrolling. When you scroll halfway through what happens? Might not want jsut start and end b/c in middl eyou have to pick. Might suspend animation, find interpolation point when scrolling stops, and show that<br> <dael> fantasai: Similar to how we snap after you let go of scroll controls. We step-wise animation to that interpolated position after the scroll but not during<br> <astearns> ack jcraig<br> <Zakim> jcraig, you wanted to mentioned animations triggered by user animations versus animation that start at unexpected times<br> <dael> florian: Interesting<br> <dael> jcraig: We did a ton of research years ago when shipped p-r-m.<br> <dael> jcraig: On android and iOS you can flip to scroll. We found a number of users with the trigger sensitivity would page at a time. Scroll and release but stop the finger for the after effect.<br> <dael> jcraig: Another result is the difference between anmations that happen base don user trigger vs those that follow unexpectidly. We found a number of users if they're doing page in and out prefer to keep that. Made that separate in iOS. User can anticipate there will be motion and it doesn't bother as strongly as when not expected<br> <dael> jcraig: A lot of contextual. Reason we didn't do it automatically is the contextual understanding<br> <aboxhall_> Anecdote: a friend of mine with a TBI said a lot of her therapy was around "strategically shutting her eyes" in cases like James was just talking about<br> <dael> jcraig: Open to explore ideas to allow authros to mark up animation as essential. Haven't found place to shut of animations which is why it's in prefers rather than force<br> <dael> florian: This is probabaly a topic where won't finalize without experiment. Both mine and fantasai suggestions are interesting. Probably need demos to see if people react well to that<br> <dael> astearns: Can or should this be applied automatically or is this author advice we give?<br> <dael> fantasai: Definitely give author advice. Maybe additional controls. But definitely if you don't need a scroll animation when p-r-m is on don't do it<br> <dael> astearns: Anything else to discuss or leave to experimentation?<br> <dael> florian: Experiments and further thought is necessary but is anyone signing up to do them?<br> <dael> florian: Just b/c TAG raised the issue doesn't mean we expect TAG to experiment<br> <jcraig> s/Haven't found place to shut of animations/Haven't found an appropriate way to shut off animations automatically (without risking breaking understandability and context)/<br> <dael> Rossen_: Certainly not<br> <dael> astearns: Lacking volunteers maybe the issue hangs until someone has time to experiment?<br> <dael> astearns: Only forcing function is if and when scroll animations needs those issues to close for progress<br> <jcraig> q+<br> <astearns> ack jcraig<br> <dael> florian: We've have MS, Google, and Apple TAG people discuss. Maybe they can find internal resources?<br> <dael> jcraig: One more thing from initial p-r-m discussion is we left it open to expand later. May be extreme but I'll mention it. Text is left at reduce but expandable so could be specific triggers we avoid<br> <florian> s/We've have MS, Google, and Apple TAG people discuss. Maybe they can find internal resources?/We've have TAG people from MS, Google, and from Apple discuss it today, and the same companies have editors on this spec. Maybe they can find internal resources?<br> <dael> jcraig: Original proposal was p-r-m: no parallax and get it very specific. aboxhall_ linked to original issue<br> <dael> jcraig: It could be reduce which is vague or more specific values if necessary.<br> <dael> jcraig: I'll try and dig up old issue<br> <dael> astearns: Can you open separate issue since that's about MQ and I'd like to keep this scoped to web animations<br> <dael> jcraig: Sure. Appropraite to mention in the issue<br> <dael> astearns: Sure<br> <dael> jcraig: I think we decided didn't need it until there's a use case and this might be the use case<br> <dael> astearns: Okay, fine to just mention. If we do want to add values to the MQ I'd prefer to break it out so we don't have a giant issue<br> <jcraig> s/p-r-m: no parallax/p-r-m: no-parallax/<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-705247209 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 October 2020 23:33:47 UTC