You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.js may 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 the change event 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 the change callback.
The text was updated successfully, but these errors were encountered:
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 ofcolor.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:
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_addInputListeners()
should be adjustedcolor.js
may 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 charsnumber
, it's possible to keep the Up or Down arrow keys pressed to change its value. Keeping the key pressed continuously triggers thechange
event 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 thechange
callback.The text was updated successfully, but these errors were encountered: