Dropbuttons

The text format overview, which is what a listing of config entities looks like when it is a form: a handful of rows an administrator named, a weight in each one so the order can be changed, and one Save button under the table for all of them. Every row offers the same operations, so the column is a stack of identical dropbuttons -- the case where one of them opening over the row under it matters most, because the row under it holds a control in the same place. The last row has a single operation and no toggle, which is the other state the widget has and the one a theme forgets: it must still look like the button above it.

The content overview, which is the other kind of listing: a column of check boxes and an action to apply to whatever is ticked, above rows nobody administering the site named. Two things follow for the operations column, and both are here. What a row offers depends on the row -- an unpublished one is published and a published one is not -- so the dropbuttons are no longer identical and a theme cannot rely on them being the same width. And the rows are as long as the titles people wrote, so the widest action in a dropbutton is often not its first one.

A split button: the primary action is the submit button the form would have had anyway, and behind the toggle are the ways of leaving the form that are not it. Two of them, because there are two ways to build one and they do not produce the same markup. The first is a links list beside an ordinary submit button, which is all a dropbutton element can hold. The second is a list of submit buttons, which a links list cannot hold at all -- so the list itself is written out by hand around them and only the wrapper is themed, the way the views UI does it. Both sit in the actions of a form rather than in a table cell, where nothing is a fixed width and the row does not end.

The views edit form is the heaviest user of dropbuttons in core, and it restyles them on top of whatever the theme did -- so a theme that has only checked its dropbuttons in a listing has not checked these. Three of them, in the markup of the display they belong to. The extra actions of the view are the ones with nothing beside them, in the strip above the display. The actions of a display are the hand-built list of submit buttons again, this time in its real setting. The operations of a bucket are the one that is not a button at all: the first action carries an icon and the whole thing is squeezed into the heading of a column, which is the narrowest a dropbutton is ever asked to be.