Let users disable animation in Olivero

+1 this would be really helpful, because oliveros design comes with a lot of animation of critical elements like nav (which is great, but not for all).

It would be good to support users who prefer to turn animations off.

To give a bit more context: Some users experience distraction or nausea from animated content. For example, if scrolling a page causes elements to move other than the essential movement associated with scrolling—as with parallax scrolling, where backgrounds move at a different rate to foregrounds—it can trigger vestibular disorders. Vestibular (inner ear) disorder reactions include dizziness, nausea and headaches. The impact of animation on people with vestibular disorders can be quite severe. Triggered reactions include nausea, migraine headaches, and potentially needing bed rest to recover. src

This should be relatively straightforward to implement, however my understanding was that prefers-reduced-motion was for larger more intrusive animations. According to https://developers.google.com/web/updates/2019/03/prefers-reduced-motion, this is meant for "parallax scrolling, zooming effects, etc."

Olivero's animations help with usability, as they indicate where the element has originated from. For example, the desktop navbar slides out when hitting the nav button -- this indicates its origin to the end user. The dropdown buttons also have a slight 10px slide-down/opacity effect, which also gives an indication.

If we disable this on prefers-reduced-motion, these users would lose this benefit. Note that it's "reduced" motion, not any motion.

The most complete article I can find on the subject is https://webkit.org/blog/7551/responsive-design-for-motion/

The perceptual utility of appropriate, functional motion can increase the understandability and —yes— accessibility of a user interface. There are numerous articles on the benefits of animation to increase user engagement:

• Issara Willenskomer: Creating Usability with Motion: The UX in Motion Manifesto
• Aurora Harley: Animation for Attention and Comprehension
• Val Head: UI Animation and UX: A Not-So-Secret Friendship

Consider each animation in its context. If you determine a specific animation is likely to be a vestibular trigger, consider serving an alternate, simpler animation, or display another visual indicator to convey the intended meaning.

Thoughts?

I can foresee transition: none !important being problematic because it doesn't ever fire the transitionend event.

I've seen examples where you set transition-duration: 0.01s;. This would still obviously still fire the transitionend event.

I'll chime in on the core issue as well.

What is the best place to display the enable/disable button, so that it is always available?

Would it make more sense for the animations to initialize as enabled, or disabled?

Here is a Pull Request for this issue: https://github.com/Lullabot/olivero-poc/pull/26

While testing on Google Chrome, I noticed that the hamburger icon in the sidebar nav still animates. When clicked, it will transform from three horizontal lines, into an "X". Is that animation a concern, or not because of its size?

Thanks for all the helpful resources!

I updated the PR with this snippet, using the tiny duration approach:

@media (prefers-reduced-motion: reduce) {
  *, *:before, *:after {
    animation-duration: 0.001s !important;
    -webkit-animation-duration: 0.001s !important;
    -moz-animation-duration: 0.001s !important;
    -o-animation-duration: 0.001s !important;
    transition-duration: 0.001s !important;
    -webkit-transition-duration: 0.001s !important;
    -moz-transition-duration: 0.001s !important;
    -ms-transition-duration: 0.001s !important;
    -o-transition-duration: 0.001s !important;
  }
}

The hamburger icon uses the same method for animation as the other elements on the page, but it was missed because it was made of :before and :after pseudo elements. Using this selector, I was able to account for that case: `*, *:before, *:after`

Vendor prefixes are based on MDN's documentation for "transition-duration" and "animation-duration".

How would a themer using Olivero as base theme turn animations off? Would this do the job?

@media {
  *, *:before, *:after {
    animation-duration: 0.001s !important;
    -webkit-animation-duration: 0.001s !important;
    -moz-animation-duration: 0.001s !important;
    -o-animation-duration: 0.001s !important;
    transition-duration: 0.001s !important;
    -webkit-transition-duration: 0.001s !important;
    -moz-transition-duration: 0.001s !important;
    -ms-transition-duration: 0.001s !important;
    -o-transition-duration: 0.001s !important;
  }
}

My initial thought on this is that we should do this on an individual ruleset level.

Using !important to set animation/transition durations seems like a big ol' hammer, when that's not required (since we own the styles).

I'm not sure I follow, @mherchel could you expand on that or provide an example?

I think using !important is appropriate here. We want to set strong, global rules that won't be easily overridden.

@ellenoise: Thanks for your PR. I'm testing it on my MacBook with the Accessibility > Display > 'Reduce motion' set to on but I'm not seeing a difference. I've tried refreshing the page. Is there something else that I need to do to test this out?

@katannshaw and @andrewmacpherson - Thank you for testing! katannshaw, yes, there is another step to test. Make sure to recompile the theme as you're testing locally. Have you run $ npm start or $ gulp watch inside the project?

I will double-check here, because I know this project is progressing quickly: What version of the POC are you testing against? My code is still in an open Pull Request on Github: https://github.com/Lullabot/olivero-poc/pull/26 This has not been merged to the Proof of Concept site yet, so the version that is up on Netlify will not have it. My PR branch is sorely behind master, so I will work on updating it! :)

Tested the patch in #28 against 9.2.x and it worked. Applied cleanly.

However I wonder if it should include rules for -webkit, -moz, etc. as in the earlier examples.

I have applied patch #28 but I am not able to see any change after applying patch. Please check the GIF.

@hinal05 Did you recompile the CSS and turn off motion in the OS settings? It took me a while to realize that disabling motion is not a browser setting but an OS setting.

Please let's re-test it and in case of bugs - provide more information how did you test and where

I've re-rolled #28 and uploaded here.

Testing Instructions

• Apply patch, clear cache
• Set OS prefers-reduced-motion setting. If you need help finding this, MDN has some good guidance.
• Scroll up and down, open mobile menu to confirm animations are happening at a speed too quick to be perceived as motion

Patch #34 works perfectly. Moving to RTBC

@andy-blum I have applied the patch but i can't see any changes for reference sharing screenshot

@vikashsoni did you change your OS settings to reduce motion? Are you using a browser that supports reduced motion (IE11 does not!). You can test your reduced motion settings with this codepen

@andrewmacpherson/@mherchel Playing with that codepen, however, I think we want to kill animations entirely, and not reduce the time to 1ms - that causes an extreme flashing phenomenon.

My thought is that we need to be more granular with this, as opposed to applying a hammer.

According to the spec, prefers-reduced-motion

Indicates that user has notified the system that they prefer an interface that minimizes the amount of movement or animation, preferably to the point where all non-essential movement is removed.

From my point of view, the "header slide out" animation is essential, as it indicates that the button is grabbing control of the visibility of the header. If a person is new to this theme, and they click the button, they might not even notice what happened.

There are several transitions that could be removed though including

• the "down" function of the submenus at desktop widths
• The "side in" function of the mobile menu

I don't think we should use this to remove color transitions, as (AFAIK) its motion that causes the vestibular difficulties, not color changes.

Took a crack at a more granular approach to removing motion transitions. Patch & interdiff attached.

@vikashsoni the before and after gifs you provided in #36 are the same file with different names, not before/after. The fact that your computer clock changes from 11:38 to 11:39 in both makes that quite clear.

The internet ate my earlier review. Here's another! Thanks for working on this.

No need to push `prefers-reduced-motion` into a variable. This value won’t be changing.

We should allow motion by default. By disabling animations, and then enabling them for browser that support the media query, we exclude IE11.

1. +++ b/core/themes/olivero/css/components/header-navigation.css
   @@ -104,7 +104,13 @@
   +  transition: visibility 0.2s;
   

   The header animation serves a purpose where it informs the user what happened to the header. I believe this is an "essential" animation and should not be removed.

   If we do end up removing it, we should also remove the visibility transition.

2. +++ b/core/themes/olivero/css/components/header-sticky-toggle.pcss.css
   @@ -76,8 +79,11 @@ body.is-always-mobile-nav .sticky-header-toggle {
   +        transition: opacity 0.2s;
   

   I don't want to exclude color changing (including opacity changes) from animating.

Patch #42, fixes the user disable animation issue.
I checked Reduce motion setting, and tested.
Scroll up and down, open menu to confirm animations are happening at a speed too quick to be perceived as motion.

Marking as RTBC +1

Attached after patch screen recording for reference.

Still need to look at this.

Verified and tested above merge request - https://git.drupalcode.org/project/drupal/-/merge_requests/1224.patch
Patch applied successfully and looks good to me.

Testing Steps:
# Goto: Appearance > apply Olivero theme
# Goto: System preference -> Click on Accessibility -> Click on Display and click on reduce motion checkbox. (For Macbook)
# Goto any page on Olivero theme
# Click on the Hamburger menu and close it when the user is doing scrolls at the top and bottom sides.

Expected Results:
# User should not see the animation effect on the Olivero theme.

Actual Results:
# Currently user is able to see animation effect on the Olivero theme.

Please refer attached video for the same
Looks good to me.
Can be a move to RTBC.

Rebased

This is looking great. We need to also disable the transition for the wide search form at https://git.drupalcode.org/project/drupal/-/blob/9.3.x/core/themes/olive...

Back to needs work to address typos: https://www.drupal.org/pift-ci-job/2205059

--- Commands Executed ---
core/scripts/dev/commit-code-check.sh --drupalci
Return Code: 1
--- Output ---
Creating list of files to check by comparing branch to 9.3.x
/var/www/html/core/themes/olivero/css/components/header-search-wide.css:257:52 - Unknown word (transitionend)
/var/www/html/core/themes/olivero/css/components/header-search-wide.css:307:47 - Unknown word (transitionend)
/var/www/html/core/themes/olivero/css/components/header-search-wide.pcss.css:134:53 - Unknown word (transitionend)
/var/www/html/core/themes/olivero/css/components/header-search-wide.pcss.css:178:47 - Unknown word (transitionend)

CSpell: failed

Since HTMLElement: transitionend event looks valid, perhaps it's more correct to add transitionend and related events transitioncancel, transitionrun, and transitionstart to /core/misc/cspell/dictionary.txt?

Ah, my mistake. I do see that transitionend has been added to core/misc/cspell/dictionary.txt in the MR. Does it need to be committed first?

Note that transitioncancel, transitionrun, and transitionstart aren't in any comments so they aren't triggering the error.

I was close to correcting it to "transitioned" :) In the test it says "CSpell: passed", so adding transitionend seems to have taken care of the CSpell error.

But maybe the patch needs a re-roll against 9.4.x? I see a few offset's such as Hunk #1 succeeded at 194 (offset 1 line). when applying the latest patch.

Adding "How to disable animation" info in Issue Summary.

As mentioned in #58 I have rebased the current branch with 9.4.x so @ressa - can you please update target branch of merge request so irrelevant changes will not appear in https://git.drupalcode.org/project/drupal/-/merge_requests/1224#c1076630...

Thanks @yogeshmpawar, but I am not sure how to do that, sorry. I had a look at this page, but couldn't find an answer ... https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa...

Perhaps we need to click the "Create new branch" (target: https://git.drupalcode.org/issue/drupal-3093461/-/branches/new?branch_na...) on this page, to create a fresh 9.4.x branch?

Hi @ressa - As this merge request created by you, you can able to edit this merge request & can able to change the target branch from 9.3.x to 9.4.x

I see what you mean, by looking at an MR created by me, which has an "Edit" button:

But this MR was created by Theresa.Grannum, which you can also see if you check out MR #1224, there is no "Edit" button:

Hey @ressa, so sorry for the confusion. I got confused between the names.
Thanks @theresagrannum for changing the branch to 9.4.x

Code quality checks are failing. Please make sure to run core's linting commands

No problem @yogeshmpawar, and thank you for updating the MR @Theresa.Grannum.

Passing tests!

Thanks for the updates. Back to needs work for some formatting cleanup.

@Kristen Pol - all the feedback you left is on *.css files, which are compiled assets. Running yarn lint:css doesn't yield any errors, and yarn build:css doesn't make any changes, so I don't think these are things that need to be fixed. Moving back to needs review.

I've been trying to "resolve" all those unnecessary css file comments but the GitLab page is jumping around all over the place (maybe due to so many files in the MR). Anyway, sorry for the noise. It's weird that the compiling causes the semicolon removal and weird formatting.

The pcss changes looked okay to me.

Left a review in the MR requesting changes. Thanks for the work on this!

Needs rebase to 9.5.x or 10.1.x

Adding SC 2.3.3 tag.

The Olivero theme was approved for removal in #3590816: [policy, no patch] Deprecate Olivero and move to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3595082: [meta] Tasks to deprecate the Olivero theme and the removal work in #3595085: [meta] Tasks to remove the Olivero theme.