[wp-trac] [WordPress Trac] #40925: Review the usage of the change event on select elements
WordPress Trac
noreply at wordpress.org
Mon Jun 5 12:47:03 UTC 2017
#40925: Review the usage of the change event on select elements
----------------------------+-----------------------------
Reporter: afercia | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Administration | Version:
Severity: normal | Keywords: has-screenshots
Focuses: ui |
----------------------------+-----------------------------
See also #31634
The change event can be problematic when used on select elements because
browsers fire the event in different ways across different platforms. In
this ticket I'll try to clarify what this difference is, why it matters
for keyboard users, and why some actions shouldn't be triggered when a
select option gets selected.
On macOS, when using the keyboard to navigate content and a select element
gets focused, using the arrow keys always opens the select "drop-down":
[[Image(https://cldup.com/rU6roN4wAO.png)]]
This behavior allows users to explore the content of the select, scroll
through the options, and select an option pressing Enter or Spacebar. This
way, the change event fires after an explicit user action.
Instead, on Windows using the arrow keys on a select doesn't automatically
open the "drop-down". To clarify what happens, I've made a short video
using the Archives and Categories widgets as an example:
https://cloudup.com/iuFxQ7CkA7k
Historically, this behavior was typical of all browsers on Windows, except
Firefox. However, a recent change made Firefox behave like all the other
browsers. For more details, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1350700
Since the drop-down doesn't open (it does only when pressing Alt+Down
arrow), it's hard to scroll the list of options without firing the event
at each arrow keys press. Users would need to explore the content of the
select before making a choice, and to do so they use the arrow keys.
However, while exploring the select content, the action associated to the
change event runs. In the case of these widgets, the action triggers a
full page reload.
Actions that have a big impact like a full page reload or a complete
change of context should only be triggered after an intentional choice of
the user, i.e. when pressing a button close to the select. In other cases,
when the action triggers minor changes, using the change event could be
OK. The best option would probably be to evaluate the interaction on a
case by case basis.
There are a few places in WordPress where the change event is used this
way, not pretending to be a complete list, here's some of them:
Media views:
- Filter by type
- Filter by date
Customizer
- Menu > Menu locations
- Static front page > A static page
--
Ticket URL: <https://core.trac.wordpress.org/ticket/40925>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list