- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 23:05:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `No-motion / forced-reduced-motion issue draft`. <details><summary>The full IRC log of that discussion</summary> <fantasai> flackr: I didn't add this to agenda, was already agenda+<br> <fantasai> flackr: where we left off, we thought it would be valuable for the UA to reduce motion on websites<br> <fantasai> flackr: in a way that didn't require developers to do extra work to make it just work<br> <fantasai> flackr: we previously, in december, talked about a global strategy where there would be some meta tag to say whether site had support for animations reduction<br> <fantasai> flackr: decided later to make it a per-animation toggle<br> <plinss> Whoever edits the minutes, fell free to put above comments on the record<br> <fantasai> flackr: only development since has been putting together a straw man proposal of an animation/transition/WA property<br> <fantasai> flackr: to say whether the animation has been written to support reduced motion<br> <fantasai> flackr: UA could use this to implement reduced motion<br> <fantasai> flackr: I was going to put together examples<br> <fantasai> flackr: asking around for thoughts<br> <smfr> q+<br> <TabAtkins> fantasai: the idea is to tag a partiuclar animation as being conformant with reduced-motion or not<br> <TabAtkins> fantasai: then if the author wants to change which animations to do they'd use an MQ?<br> <TabAtkins> flackr: yes<br> <TabAtkins> flackr: don't really like it since in the worse case you're specifying reduced-motion twice<br> <TabAtkins> flackr: But as said earlier today we don't want MQ matching to affect how we process rules<br> <TabAtkins> fantasai: this seems pretty reasoanble to me actually<br> <astearns> ack smfr<br> <TabAtkins> smfr: I want some backgroudn what UAs do when the user turns on reduce-motion<br> <TabAtkins> flackr: to my knowledge, it's currently entirely on the dev to give a reduced motion experience<br> <ntim> q+<br> <TabAtkins> smfr: are you suggesting a world in which UAs suppress all animatios not tagged with this new property?<br> <TabAtkins> flackr: yes, it's still unclear how thsi would work o nthe platform - a different mode, or waht<br> <TabAtkins> smfr: I do think it's a valid concern and important<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: so you're tagging the @keyframes? or what?<br> <TabAtkins> fantasai: is there a way to sipmlify some things and say "this animation gets dropped if you're in reduced-animation"?<br> <TabAtkins> flackr: we could drop animations that haven't been marked as supporting reduced mode<br> <TabAtkins> flackr: but then it would be backwards incompatible break<br> <TabAtkins> flackr: it would break the experience of users who have this option turned on<br> <TabAtkins> fantasai: the opposite, the author saying in the tag that "this animation is optional"<br> <TabAtkins> hober: the author can already do that with an MQ<br> <ntim> q-<br> <TabAtkins> fantasai: They have to do it on each animation property tho.<br> <TabAtkins> hober: Ah so this is sugar<br> <TabAtkins> fantasai: basically<br> <ntim> q+<br> <TabAtkins> flackr: whether this is sugar or not gets into what we do with animations in this mode<br> <nicole> q+<br> <TabAtkins> flackr: view/scroll animations often display infomration so they can't be ignored<br> <TabAtkins> hober: so are you saying that this wouldn't have any effect on scroll-linked?<br> <TabAtkins> flackr: it would change the interpolation behavior, but it wouldn't drop them, yeah<br> <TabAtkins> flackr: but if this is fully opt-in then it might be safe to just drop things<br> <TabAtkins> flackr: But with an opt-in we're not solving the appraoch that authors aren't thinking about it<br> <TabAtkins> myles: i'm confused<br> <TabAtkins> astearns: I think i'm hearing we have two options<br> <TabAtkins> astearns: The first is rob's original idea: people can tag animations that say 'this is okay for reduced motion'.<br> <TabAtkins> astearns: Second is... wait i'm confused<br> <TabAtkins> flackr: Two options are: 1) UA turns off all aniamtions that aren't tagged as supporting.<br> <TabAtkins> flackr: 2) make it easy for authors to declare animations that can be skipped<br> <TabAtkins> myles: So right now websites have all animations. They can use the MQ to turn off specific ones.<br> <smfr> q+<br> <TabAtkins> myles: Sounds like you want the opposite, off by defualt (in reduced-motion mode) and they can turn specific ones back on<br> <TabAtkins> flackr: yes, because most authors aren't thinkinga bout reduced-motion<br> <astearns> ack ntim<br> <TabAtkins> flackr: so the option really isn't doing anything<br> <TabAtkins> ntim: a concern with this appraoch is fingerprinting<br> <TabAtkins> ntim: the JS could detect whether you're in forced reduced motion or not<br> <TabAtkins> hober: Which is 1 bit more than just preferring reduced motion<br> <TabAtkins> flackr: yes, they can detect if you're in prefers-reduced today; if this is a separate mode it would be detectable as well<br> <TabAtkins> nicole: Rob could you show the demo with the 14 different ways we tried to force reduced motion?<br> <astearns> ack nicole<br> <TabAtkins> nicole: the goal is great, we want people who want reduced motion to get it<br> <TabAtkins> nicole: but the reality of doing it in a forced way is just very complicated<br> <flackr> There's a demo at https://flackr.github.io/reduce-motion/demos/phone/ exploring some automated interventions<br> <TabAtkins> nicole: our example was apple homepage, a device slid in fro one side and words from the other and they met in the middle to connect them mentally<br> <myles> q+<br> <TabAtkins> nicole: that's why rob said scroll-driven was hard to turn off, getting them to arrive together is v important<br> <TabAtkins> nicole: i'm someone who gets nauseated with animations, and if I can control the animatio like with scroll it's much easier for me<br> <TabAtkins> nicole: so form a personal angle, scroll-driven is less bad for me than normal animations<br> <TabAtkins> nicole: But I also don't really turn on reduced motion, because a spatial sense is often an important part of navigating<br> <TabAtkins> nicole: Lots of infomration from motion<br> <TabAtkins> nicole: This issue deserves a lot of thought and care<br> <TabAtkins> nicole: maybe no-motion is a hard a11y setting where some breakage is okay and worth it<br> <jensimmons> Same. I don't turn off animation, because I want it much of the time. And for me, when the animation is in reaction to my actions, it doesn't bother me. What is really hard to take are animations that loop over and over and over without any input from me.<br> <TabAtkins> nicole: but hard to picture it's an everyday feature people browse with, considering how much would break<br> <astearns> ack smfr<br> <TabAtkins> flackr: i think of it as similar to disabling JS<br> <TabAtkins> smfr: I'd be concerned that turning off anims isn't web-compatible.<br> <TabAtkins> smfr: like a fill-forward animation that puts something in place<br> <TabAtkins> smfr: so not turn them off, maybe, but snap them to their final state<br> <TabAtkins> flackr: exactly that, yes<br> <TabAtkins> nicole: we tried a lot of options yeah, most were terrible<br> <TabAtkins> smfr: one issue is different users have different issues with animations.<br> <TabAtkins> smfr: so maybe the UA needs to decide what the user wants and the author doesnt need to know<br> <TabAtkins> myles: a lot of animatios are driven by rAF(), too, and we can't turn those off<br> <TabAtkins> myles: so you end up in a situation where some animatios are turned off and some aren't<br> <TabAtkins> nicole: which will drive people to move their animations to JS<br> <TabAtkins> flackr: yes, this convo has been had several times o the TAG issue, i'm trying to find a path forward<br> <TabAtkins> flackr: hope is that we can find a path that doesn't break sites<br> <astearns> ack myles<br> <TabAtkins> (the "tag the animation as okay" thing avoids the "move to rAF()", right?)<br> <TabAtkins> fantasai: I wonder if having multiple ways for authors to get around this, like tag your animation as what kind of animation it is<br> <TabAtkins> fantasai: it won't solve the case of authors that aren't thinking about it, but lets us get some reduced motion without having to go thru all animation properties or rearchitect styles<br> <myles> q+<br> <TabAtkins> fantasai: so tagging your animations and request handling by the UA<br> <TabAtkins> astearns: like tag it with something telling the UA how to adapt it to reduced motion?<br> <TabAtkins> fantasai: yeah, like dro pit entirely, or skip to end, or jump to each discrete keyframe<br> <TabAtkins> fantasai: so like slides can show each keyframe but lose the animation between them<br> <smfr> s/dro pit/drop it/<br> <miriam> +1 fantasai's proposal (as an author)<br> <TabAtkins> fantasai: so if the author can tell us that, the UA can intervene in the way best suited<br> <florian> q?<br> <TabAtkins> fantasai: I think a lot of your experimentation could inform what interventions are useful<br> <TabAtkins> fantasai: the actions that were reasonable sometimes, even if they wern't good for everything<br> <florian> q+<br> <TabAtkins> astearns: And that could be compatible with the UA choosing something, and the author overriding<br> <florian> q-<br> <astearns> ack myles<br> <TabAtkins> myles: i think i'm letting perfect be enemy of good<br> <TabAtkins> myles: fundamental problem is authors don't consider reduced motion<br> <TabAtkins> myles: i'm suspicious that the solution is add mor eknobs<br> <miriam> q+<br> <astearns> ack miriam<br> <TabAtkins> miriam: as an author who often thinks about it but wants better defaults<br> <TabAtkins> miriam: right now i have to build them myself. jump to end isn't simple, i ahve to set it up myself manually<br> <TabAtkins> miriam: a lot of resets include a jump-to-end keyframe set that's added for you; it doesn't always work<br> <hober> q+<br> <TabAtkins> miriam: if there was a qicker way to do it people would use it<br> <TabAtkins> miriam: not everyone, and it doesn't solve everything, but these shortcuts would be really useful<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: +1 to that<br> <TabAtkins> fantasai: If we improve ergonomics it'll get used a lot more<br> <TabAtkins> fantasai: and if you shift responsibility from invoker to provider of keyframes, you can put it into libraries<br> <TabAtkins> fantasai: authors can use a predefined library of animations, with fallback instructions built in, only needs to be done once<br> <TabAtkins> miriam: also if we've done the research and have a good sense of what the solutions are, if i as an author see a list of three good solutions that are semantic to particular situations<br> <TabAtkins> miriam: like skip-to-end is good for content flying in...<br> <TabAtkins> miriam: if I know those are the options i have a better sense of why i would use them<br> <TabAtkins> fantasai: you could also use the same mechanism to indicate something is important, so keep it even if animations are turned off<br> <astearns> ack hober<br> <TabAtkins> hober: in general im' sympathetic to this general appraoch of lettings authors sprinkle declarative animation that UAs can use to improve the UX<br> <TabAtkins> hober: in this case i'm worried about a few things<br> <TabAtkins> hober: tim mentioned 1bit of fingerprinting<br> <TabAtkins> hober: but depending on diversity of impl behavior it woudl easily be several<br> <TabAtkins> hober: if there's a gradation of settings for how muc hanimation you want suppressed<br> <TabAtkins> hober: from authoring perspective, if there's hints that don't do anything obvious, you often run into situations where authors develop cargo-culty behavior<br> <TabAtkins> hober: they just add something they were told is a best practice<br> <astearns> q+<br> <ntim> +1<br> <TabAtkins> hober: so over time the quality of the signal declines, and interventions that were initially good have to be thrown out<br> <TabAtkins> hober: so I'm concerned if we game it out a few steps if we actually make an improvement<br> <astearns> ack fantasai<br> <astearns> ack astearns<br> <TabAtkins> astearns: could we make this not detectable, skip the animation but make it seem to JS that it does run?<br> <TabAtkins> dbaron: no<br> <TabAtkins> astearns: ok<br> <TabAtkins> fantasai: One way to avoid is to provide a "simulate reduced motion" mode where it shows the effects<br> <TabAtkins> fantasai: so from the privacy aspect, maybe a UA would want multiple levels, but we know of 2 right now<br> <miriam> q+<br> <TabAtkins> fantasai: at the very least we could make "reduced" better for authors to hook into<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <TabAtkins> fantasai: if devtools is helping to simulate that mode, then you can epxerience what that user would see and you're less likely to pick a bad hint<br> <nicole> q+<br> <TabAtkins> fantasai: this might not fully solve the problem and we still might want to force things, but i think making it easy to get some type of result would help the situation<br> <TabAtkins> flackr: there's already an option for that in chrome<br> <TabAtkins> flackr: this discussion was helpful. the TAG said they wanted something that devs didn't have to interact with at all, but here it sounds like we want something that lets athors help.<br> <TabAtkins> flackr: So we can still have the MQ, and then also make some properties that let authors help out.<br> <TabAtkins> flackr: like animation-interpolation-mode or something like that. but i dont' want to propose just yet.<br> <fantasai> I would propose "reduced-motion: <keywords>"<br> <astearns> ack miriam<br> <TabAtkins> miriam: I think Tess makes a good point, but I'd say the cargo cult already exists<br> <fantasai> Where keywords is things like "drop" or "skip" or "discrete" or anything else we think up<br> <TabAtkins> miriam: a big chunk of keyframes that do one thing and do it poorly. providing a better tool ameks it more likely people use the right thing<br> <TabAtkins> nicole: generally i like personalization issues. have to be aware that it puts a burden on author testing<br> <TabAtkins> nicole: it gets combinatorial<br> <TabAtkins> nicole: so we need to be thoughtful. i like the idea of skip-to-end, etc<br> <TabAtkins> nicole: just need to be thoughtful about burden we put on devs<br> <fantasai> And where "reduced motion" is something you can declare inside @keyframes<br> <fantasai> or inside a single keyframe<br> <TabAtkins> astearns: think we'll leave the discussion here and keep working on it<br> <TabAtkins> flackr: this is a change in direction, nicely concrete. i can come up with more details around this<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7440#issuecomment-1646324427 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 23:05:10 UTC