Add new Splitbutton render element to eventually replace Dropbutton

To evaluate splitbuttons from the MR, enable the splitbutton_test module and go to

/splitbuttons

. You must have

$settings['extension_discovery_scan_tests'] = TRUE;

in your settings.php for this test module to be available.

Problem

1. Drupal has adopted Views’ dropbutton in several common places in core. Since its introduction in #1608878: Add CTools dropbutton to core, we've spent lots of time refactoring the existing button: #1799498: Improve dropbutton and others [which?]. This component is now even being used for primary form actions on the new node edit form: #1751606: Move published status checkbox next to "Save". However, the implementation there has made the dropbutton harder to theme by pushing it beyond its initial design. (Specifically, allowing its to consist of buttons instead of links, and by introducing sub-elements using #prefix and #suffix).
2. From a UX standpoint, the existing dropbutton’s behaviour is sub-optimal. Since the sub-items are contained within the button, when the button is opened it often must grow in width to accommodate the width of the sub-items. This change moves the click target out from under the user’s cursor, forcing them to hit a slightly different spot in order to close the menu again. In some cases, such as the one reported in #3168326: Dropbuttons in table cells are potentially unusable if it includes options with long text length., opening the dropbutton can result in a reposition that takes the pointer off the dropbotton, which results in it being closed moments after it was opened. The standard implementation of this design pattern does not suffer from this issue: Twitter Bootstrap, Zurb Foundation, jQuery UI. Drupal is the odd one out here.
3. The open/closed state of the menu isn't conveyed to assistive technology, it is only apparent visually.
4. The current focus style for the more-actions button is weak, and won't pass WCAG 1.4.11 Non-text contrast.

Proposed Resolution

Since we cannot change the current Dropbutton (and Operations) implementation for BC reasons, the way to move on is:

1. Create a new Splitbutton element with the required markup, functionality and (accessibility) features.

   • The new Splitbutton element must allow having buttons as well as links, and it should be able to replace the hard-coded fake Dropbutton in Views UI.
   • It should be easy to add modifier CSS classes (described in #2160481: Componentize the dropbutton CSS).
   • Use aria-haspopup and aria-expanded to define the list and toggle to assistive tech.
   • Should have the proper focus styles, to satisfy WCAG success criteria 1.4.11 Non-text contrast. Using an outline (i.e. shape) change is recommended, rather than changing colour alone.
2. In followusp: Replace core's Dropbutton and Operations usage where appropriate with the new Splitbutton element.
3. In a followup: Deprecate Dropbutton. (?)

User interface changes

Splitbutton is a slightly different experience than dropbutton. Dropbutton has a primary item that is always visible. Although it's a primary item, it's semantically part of the the list that is fully visible when the dropbutton is open.
Seven Dropbutton Seven no longer in core

Claro Dropbutton
Claro is styled so the primary and list items look different although they are part of the same list. This visually resembles what splitbutton will be doing semantically.

Seven Splitbutton Seven no longer in core

Claro Splitbutton
Uses Claro's existing component styles, applied to this new element.

API changes

TBD.

Original Proposed Resolution

• Refactor the implementation in core to allow for buttons as well as links in the element while maintaining theme-ability. This is a good opportunity to implement the splitbutton design. — #2278479: Change the dropbutton theme function to ensure consistent output and accommodate the splitbutton design
• Refactor the markup, CSS and JS to be as simple as possible — #2278473: Simplify Dropbutton markup in line with our CSS standards
• Componentize the primary and regular dropbuttons — #2160481: Componentize the dropbutton CSS
• Convey the behaviour and state to assistive technology, in line with the Menu Button pattern from the WAI-ARIA Authoring Practices.
• Follow the keyboard-control behaviour from the Menu Button pattern in the WAI-ARIA Authoring Practices.
• Improve the focus styles, to satisfy WCAG success criteria 1.4.11 Non-text contrast. Using an outline (i.e. shape) change is recommended, rather than changing colour alone.