feat(dial)!: migrate to use @adobe/spectrum-tokens

[pfulton]

Description

Migrates the Dial component to use @adobe/spectrum-tokens instead of the legacy "vars" packages.

This component does not have an updated spec file from design, nor does it have new tokens defined for it. This is a "DIY migration".

How and where has this been tested?

• How this was tested:
• Browser(s) and OS(s) this was tested with:

Screenshots

To-do list

• If my change impacts other components, I have tested to make sure they don't break.
• If my change impacts documentation, I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have tested these changes in Windows High Contrast mode.
• I have updated any relevant storybook stories and templates.
• If my change(s) include visual change(s), a designer has reviewed and approved those changes.

• This pull request is ready to merge.

[github-actions]

🚀 Deployed on https://pr-1971--spectrum-css.netlify.app

[jenndiaz]

Couple of small questions and one issue with the custom token not being applied.

[jawinn]

This is looking pretty good.

My only questions are around focus and keyboard focus, which also apply to what is in prod. Right now there is no visible focus when tabbing to the dial. On the docs page, is-keyboardFocused is applied by the JS there, which does not trigger the .is-focused styles (the dark grey visible after click and drag). Rather than using .is-focused, should this be using :focus or :focus-visible? The docs currently are allowing focus on the handle with tabindex='0', which allows those pseudo classes to be activated.

I'm also wondering about disabled showing a hover background color. It does it that way in prod, but it seems odd because it makes it look interactive. And it doesn't seem to match how other components' disabled states behave.

[jawinn]

The updates for disabled and focus look great!

One thing I am noticing is that tab focus disappears for one stop as it appears to go from the handle to the range input itself. I'm not sure if we should put a tabindex="0" on the input without some sort of keyboard control behavior/guidelines associated with it? This might also be a good case for adding :focus-within to the existing focus styles, to at least keep the focus style when the input is focused. To have a single stop in the tab order, ideally we could use :focus-within and not have a tabindex on the handle at all, but I don't know if the browser support is enough to use it by default yet (can-i-use says 94.14% global support).