Can the Balloon editor toolbar be sized based on the viewport instead of editor width?

[benfosterlitmos]

📝 Ask a question

Is there a way to configure the Balloon editor toolbar to set it's width based on the viewport width rather than the editor instance width?

I have an editor in a dialog which is much narrower than the viewport. The toolbar items collapse into a submenu because they don't fit within the width of the editor, however they would fit within the viewport. I was able to change the positionLimiter so the toolbar can flow outside the dialog, but the width is still an issue when there is plenty of space:

[Reinmar]

I agree. We've tried to limit the editor's floating UI to the editor's area, but I have strong doubts whether it actually makes sense. 

What do integrators expect in generak? Unfortunately, I guess the answer is not that simple and that it's highly context-specific.

But it's clear that in case of small editor areas, probably when the ratio between the editor size / viewport size is small, we should us all the available space. Or perhaps extend what we consider "the editor's space" e.g. 2x in every direction, so the floating UI still gravitates towards the editor and does not extend too much outside it, but has more space than today.

cc @oleq @dagdzi

[Witoso]

[Semi-related]: cutoff of dropdowns in the toolbar: #5514

[oleq]

For the record, here's the code responsible for this logic https://github.com/ckeditor/ckeditor5/blob/9954cb525b993da7427225d16242a52379547814/packages/ckeditor5-ui/src/toolbar/balloon/balloontoolbar.ts#L178-L183

and you can hook into this logic and test different approaches, for instance

updateToolbarMaxWidth();

editor.plugins.get( 'BalloonToolbar' ).toolbarView.on( 'change:maxWidth', updateToolbarMaxWidth );

function updateToolbarMaxWidth() {
    editor.plugins.get( 'BalloonToolbar' ).toolbarView.maxWidth = .9 * window.innerWidth  + 'px';
}

The problem is that there's a finite number of balloon tip ("arrow") positions we can use. The BalloonPanelView system has been implemented in such a way that it offers a set of tip positions, and then the positioning logic getOptimalPosition() tries to figure out which position to use so that the balloon remains in the viewport (long story short). There's no reverse logic that prioritizes the fit of the balloon in the viewport and then (fluidly) changes the placement of the tip so that the balloon remains in the context.

This is why, the code snippet that prioritizes viewport width I pasted will fail occasionally:

while it wouldn't be an issue, if the editing root width as used instead (default)

In this way, the current logic is fail-safe although it may not feel perfect in some cases. We could experiment with combined editing root and viewport width but this will consume a considerable amount of time.