Ckeditor4: Split button UI component

[mlewand]

Are you reporting a feature request or a bug?

Feature request

Provide detailed reproduction steps (if any)

We need a UI component that would allow to group multiple related options in a single button (in that sense it's similar to menu button). Once some option is activated it should change the icon to the active option.

For example think about alignment buttons. You have four buttons, but only one is active at a time. Having 4 buttons consumes a lot of space, instead we could group it into a single button. Important thing is that upon refresh, the active button is displayed.

We did a similar thing on our CKSource XMass hackathon. It's on xhackathon-splitbutton feel free to use it as a base for the project.

An would look like that:

When thinking about that I'm wondering if we really need a new component, or whether we could enhance menubutton in a way that it would conveniently handle this case.

Preview

Users interested in seeing how the feature looks like today can preview it on our Split Button feature branch preview.

[engineering-this]

I see few options how it can work.

'Main button' = [ M ] = button on toolbar

1. Main button (one that is pinned to toolbar):

   • it remains its default behavior, and clicking on 'v' arrow next to it opens list of buttons,
   • clicking anywhere on 'main' button opens list of buttons,

2. list of buttons orientation

   • it is horizontal

   [ M ]
   [ A ][ B ][ C ]
   

   • it is vertical

   [ M ]
   [ A ]
   [ B ]
   [ C ]
   

If its horizontal we could keep [ M ] as opener of list with some .active visuals or change it to regular button whenever list is opened.

What do you think @mlewand

[mlewand]

@engineering-this Please check xhackathon-splitbutton branch solution for a reference.

it remains its default behavior, and clicking on 'v' arrow next to it opens list of buttons,

Clicking "main button" should trigger the "active option" (the one referenced by "main button").

Remember that "main button" is not an option on it's own. It just point's (is a shortcut) to an option in the split button.

So For instance in the example above, if I click justify the "main button" from the issue description, it would trigger justify command (because this is the option referenced currently by the "main button").

Of course clicking the arrow should show a dropdown with related options.

---

Options in the split button should be of course oriented vertically. See the mentioned branch as a reference.

[mlewand]

@engineering-this I have added split button branch to be tracked by our preview system, so that it's available at https://ckeditor4-preview.ckeditor.com/t/1679/ as soon as you do a push to this branch.

Please add a sample, similar to the one exposed by Easy Image (#932) so that anyone interested can have an early preview of the feature.

[engineering-this]

The Split Button preview can be found here please try it and leave your feedback.

Note: Split Button with justify is just example usage.

[mlewand]

Feedback

Before we go into details I'll just name certain parts of split button that I'll be referring to:

Obvious Stuff

• First of all, the dropdown should be aligned the left edge of the button:

Discussion

Other things needs to be discussed, I'll just propose some options:

Should the split button act as a single entity?

The question is whether the button should act as a single entity, so that entire button gets focused/hovered rather than allowing to _face_ and _arrow_ to be focused independently?

I believe we should support both cases:

Separated Button

_Face_ and the _arrow_ should act separately (in terms of hover, focus) when the button does an action upon clicking the face area.

Combined Button

There are cases when there is no special action for clicking _face_ and it should simply open a dropdown.

In that case I see no reason to put _face_ and _arrow_ as two entries in the toolbar focus group. That would lead to unnecessary redundancy, since both are doing exact same thing.

Actually this case is handled currently by the dorpdown button/plugin, so this is the button type to be used for this use case.

[AnnaTomanek]

One thing, UX-wise, that you could perhaps consider.

Split button is a piece of functionality dedicated at developers, cool. But its configuration is way more complicated (and different) than other toolbar configuration methods that we had so far.

Is it compliant with the Toolbar Configurator? If not, how can we make it so? We introduced Toolbar Configurator to answer some serious and real issues that people were complaining about, do we want to make a step back now?

If it is not compliant, and if it required manually tweaking the toolbar definition, can we make it simpler? Defining a separate plugin for each split button, and then importing it under the new button name adds a new level of difficulties to an already complicated process with toolbar groups, buttons and ACF.

Doing it wrong can potentially cause people to start looking for "But what are the names of the buttons that are available in CKEditor? WHERE CAN I FIND A COMPLETE LIST!!!" again, with lots of confusion around "Why does my editor NOT contain this (custom made) button".

Can we think of a way to make the definition better aligned with what we already have? Could a split button be defined similarly to a toolbar group, but using another delimiter etc.?

[mlewand]

Could a split button be defined similarly to a toolbar group, but using another delimiter etc.?

Initially we did not think about doing that using configuration alone, the idea would be that the features expose an optional split button that could be used instead of separate buttons.

However that would be only possible using the API. Integrating it with our toolbar configuration seems to be nice, as it simplifies the plugin usage and allows some ad-hoc configuration by users who can't write integration code. I have separated this feature request to #2091.

Is it compliant with the Toolbar Configurator? If not, how can we make it so?

We won't do it at this point, adding that to the Toolbar Configurator would require major works (it would probably be needed to convert it into a drag'n'drop oriented tool).