-
Notifications
You must be signed in to change notification settings - Fork 66
Description
See https://core.trac.wordpress.org/ticket/42078
In order to be fully accessible, the hue-only control used, for example, in Twenty Seventeen would need to display the underlying input field as an alternative input source. A native input field is the only guarantee the hue control can be used by everyone, with any device and ability. Worth noting the full color picker already allows to manually update the value form the input field and see the color palette and slider updating on the fly.
However, in the hue control moving the slider updates the value in the input field, but the other way around doesn't work. For example, manually changing the input value from 250 to 240 passes an hex color to _setOption () because of color.toString() so what gets passed is actually #224400 and nothing happens.
I've played a bit with the Iris version used in core, and passing the hue value with some adjustments seems to work. However, I'm really not an expert and I'm sure there are better ways to do it.
Issues I've identified so far:
- when the type ie
hue, then_addInputListeners()should pass a hue value (number from 0 to 359) or the value should be converted to something Iris can use to update the slider later on - not sure if the regex in
_addInputListeners()should be adjusted color.jsmay return an error when changing the input to a value under 100 because the current error checking expects a hex string with at list 3 chars- performance: since the input field used in core is of type
number, it's possible to keep the Up or Down arrow keys pressed to change its value. Keeping the key pressed continuously triggers thechangeevent so lots of code is continuously running. Even on a modern macbook pro this makes the CPU go over 100% after a few seconds. The simplest solution I can think of is to debounce also thechangecallback.