feat: respect preferred-reduce-motion

[alexzhang1030]

cloese #547.

Now we only align with preferred-reduce-motion to solve the consistency.

[netlify]

✅ Deploy Preview for vue-devtools-docs canceled.

Name	Link
🔨 Latest commit	0c4542b
🔍 Latest deploy log	https://app.netlify.com/sites/vue-devtools-docs/deploys/675fa5b53ea53a0008b33877

[pkg-pr-new]

Open in Stackblitz

@vue/devtools-applet

npm i https://pkg.pr.new/@vue/devtools-applet@744

@vue/devtools-core

npm i https://pkg.pr.new/@vue/devtools-core@744

@vue/devtools

npm i https://pkg.pr.new/@vue/devtools@744

@vue/devtools-api

npm i https://pkg.pr.new/@vue/devtools-api@744

@vue/devtools-kit

npm i https://pkg.pr.new/@vue/devtools-kit@744

vite-plugin-vue-devtools

npm i https://pkg.pr.new/vite-plugin-vue-devtools@744

commit: 0c4542b

[webfansplz]

Would it be better if we provided a toggle button in the Settings page?

[alexzhang1030]

Would it be better if we provided a toggle button in the Settings page?

Kinda complicated.

We have two states to determine the final reduce motion. It's not too hard to implement, but the behavior is counter-perception.

Let's describe a scenario:

• System reduce motion is off
• User manually set "reduce motion" of devtools is true
• Now devtools reduce motion is true now
• System reduce motion is on
• Devtools reduce motion is true, of course.
• System reduce motion is off
• Should we disable devtools reduce motion?
  • We can do nothing because enabling/disabling all brings new issues.