Further improvements to declutter toolbars

[oleq]

📝 Provide a description of the new feature

Problem

We're implementing more and more features and with each new feature, some new buttons arrive. Toolbars are getting really crowded and we implemented the automatic grouping to address this issue but:

• it does not work in inline/balloon editors because there's no obvious size restriction
• it hides the problem so we can tolerate it but it does not get to the root.

Solution

In the discussion about enabling indent buttons in all builds an idea popped up that we should use split buttons to reduce clutter. Instead of two buttons, we could have one (since people mostly indent and rarely outdent anyway):

We could do the same for:

• undo — because users undo most of the time and redo not that often,
• insert buttons (table, media, image, etc.) — because it's not a thing repeated all the time so one more stop would do no harm but it would save tons of space in the toolbar.
• basic styles — same as above

The new split–button component approach would be opt-in. We'd recommend it in our demos but it would be up to the users whether, for instance, they want all basic styles buttons displayed separately or grouped in a split button. Both would be possible.

---

A followup of #1844 (comment).

@Reinmar @dkonopka @mlewand

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.

[oleq]

FYI: I created an extended PoC.

---

---

[changus]

@oleq is having a two row toolbar out of the question? Or is it already possible, I haven't seen a way to do it in the documentation.

[oleq]

@changus In CKEditor5 we consider multi-row toolbars an anti-pattern and whenever we can we avoid this kind of solution. Multi-row toolbars create a sensation of a "heavy" UI and they consume tons of space on mobile devices where space is limited. Plus they don't work well with full–height item separators, which has been discussed last year.

So no, there's no out–of–the–box solution for multi-line toolbar at this moment like, for instance, a declarative toolbar configuration. And to be honest, there was very little pressure from the community over the last years to implement such a feature so it sort of confirms our initial assumptions were right.

BTW: Can you share your integration story? Why do you specifically need multi-row toolbars in your project?

[pshurygin]

I'm actually struggling now to integrate ckeditor 5 into our app because of this toolbar problem.

We are using the baloon editor and the problem is we need it inside a mobile-size iframe (470px wide) and the toolbar itself is almost twice the width. The problem is that toolbar never wraps nor collapse it's content (like the latest classic editor), but simply overflows the viewport of the iframe, causing horizontal scroll and breaking the layout.

I was trying to implement some css workarounds to make toolbar wrap, but they do not work great because toolbar position calculation does not take into account the possible wrapping, which leads to poor positioning in some cases.

I would appreciate some directions on how can i workaround this, and probably better out-of-the-box support for small screens with balloon editor.

[Reinmar]

@pshurygin Could you check #5597, please? I think that what you need is basically wrapping in the toolbar balloon editor.

[pshurygin]

@Reinmar Yes, this is one possible solution for the problem. I have left a comment in that thread.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).