- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Nov 2022 15:45:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `No-motion / forced-reduced-motion issue draft`, and agreed to the following: * `RESOLVED: Adopt the general path forward of allowing more granular animation control, Rob will write proposed explainer for it` <details><summary>The full IRC log of that discussion</summary> <emeyer> flackr: In TAG review, we determined they were going to cause a lot of full-page animations<br> <emeyer> …There’s concern that we have a query for reduced motion, but there’s interest in a UA policy to shut off animation<br> <emeyer> fantasai: We could shut off all animation forms, but people want a way to override that<br> <Rossen_> q?<br> <PaulG> q+<br> <emeyer> …Don’t think we should have it at a page level<br> <emeyer> …If we want the ability to override a forced shutdown of all animations, we need to provide it on a granular level<br> <emeyer> flackr: Would this be per element?<br> <emeyer> fantasai: Per animation<br> <emeyer> flackr: So we’re talking about a new property?<br> <emilio> q+<br> <emeyer> fantasai: We might not want the author to be able to override the UA, but if we do, it shoudl be per animation.<br> <emeyer> …This would mean adding some kind of way to set this for each animation<br> <flackr> q+<br> <Rossen_> ack PaulG<br> <emeyer> PaulG: It sounds like developers in commercial and ad spaces will put !important on all their animations, leading to a back-and-forth war between devs and users. I don’t love the idea of overrides.<br> <Rossen_> ack emilio<br> <emeyer> emilio: For users who do this, what I’ve seen user stylesheets set animation: none<br> <emeyer> …I guess that doesn’t work with web animations, but we could make it work with a user setting to ban web animations<br> <jensimmons> q+<br> <emeyer> …I don’t feel great about a per-animation switch<br> <emeyer> …This seems somewhat similar to forced-colors, perhaps we could use a similar approach here<br> <Rossen_> ack flackr<br> <jensimmons> q-<br> <emeyer> flackr: Even though this opens the door for authors to override, they can already do it in JS, and in a worse way<br> <fantasai> scribe+<br> <TabAtkins> emeyer: If there's a property that allows authors to turn on animation, won't they just override it for every animation?<br> <fantasai> emeyer: If there's a property that lets authors disable per-animation, wouldn't they use a universal selector to override for every element every animation?<br> <PaulG> q+<br> <TabAtkins> q+<br> <emeyer> emeyer: If this is done with a property, won’t authors just override with a universal selector or something?<br> <jensimmons> q+<br> <emeyer> flackr: Won’t they use GSAP or something?<br> <Rossen_> ack PaulG<br> <TabAtkins> More generally, we have similar "let me handle this manually" properties in a few places and trust people to use it responsibly.<br> <emeyer> PaulG: People with serious disorders or epilepsy will disable JS. It would be better for them if they can disable CSS animations.<br> <emeyer> …If they can’t shut off CSS the same way they can JS, they have less control<br> <Rossen_> ack fantasai<br> <emeyer> fantasai: If we do this declarative way, that allows the browser to have different levels of policy. One could be force all animations off, another force off unless overridden. We can allow that explicitly.<br> <emeyer> …There was a suggestion at proposal time to set a level and let users set it in the UA.<br> <emeyer> …If someone wants to behave badly, they can always go to JS. With the CSS approach, authors will have to confront their decision to override accessibility concerns.<br> <emeyer> …It is a little bit different from normal ad wars, I think<br> <emeyer> TabAtkins: We have other properties where we let authors explicitly opt into handling things manually, and trust they’ll be used when necessary and good<br> <fantasai> s/unless overridden/, and a third could be force off and ignore overrides/<br> <emeyer> …As a general rule, our policy seems to be to let people opt out on individual levels when there’s a good reason<br> <Rossen_> ack TabAtkins<br> <Rossen_> ack jensimmons<br> <emeyer> jensimmons: Part of the complexity is people have different needs for levels of motion, and a boolean doesn’t work<br> <fantasai> s/set a level and let users set it in the UA/allow a force-off, but allow authors to override with a switch/<br> <flackr> q+<br> <emeyer> …A lot of people want or need to turn off extreme or fast animation; a designer might do that stuff because they think that’s cool<br> <flackr> q-<br> <emeyer> …users who don’t want extreme animation might want small animations<br> <PaulG> https://www.w3.org/TR/adapt-content/ provides levels of importance in animation<br> <emeyer> …I’m for something that will let authors deal with this kind of nuance<br> <emeyer> …If we can also have a switch for users who need no motion at all, that would be an ideal way to go<br> <Rossen_> q?<br> <emeyer> flackr: From what I hear, there’s general support for this idea, which is good. Let’s put together a more concrete proposal and bring it back to the WG<br> <jensimmons> We should design CSS to work the way we want, to provide the result we want, and not rely on a dependency on JS. CSS itself should be well defined as a language, and we don't want to require Authors to use JS to handle animation motion properly.<br> <emeyer> fantasai: I think this should be a standalone for now, but this will have to integrate into animation, scroll-animations, web animations, transitions, [a couple more the scribe missed]<br> <flackr> q+<br> <emeyer> flackr: We have a bit of flexibility because these are delcarative to split apart whether the anio9mation is motion-inducing or not. Is there an appetite to distinguish those from opacity and so forth?<br> <Rossen_> ack flackr<br> <emeyer> PaulG: If you look at the adapt-content document, they talk about levels of distraction. The more descriptive we can get, the better.<br> <emeyer> s/anio9mation/animation/<br> <emeyer> RESOLVED: Adopt the general path forward of allowing more granular animation control, Rob will write proposed explainer for it<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-1332369451 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 November 2022 15:45:05 UTC