[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