-
Notifications
You must be signed in to change notification settings - Fork 18
i/5597: Set balloon toolbar's max-width #536
Conversation
…th and make it groupable
…hen toolbar should be shown
…enFull option to the toolbar view constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some changes are necessary to put things right.
Also, as I commented in the twin PR, we need to update ToolbarView
grouping on maxWidth
change.
|
||
setData( model, '<paragraph>b[ar]</paragraph>' ); | ||
|
||
expect( document.body.contains( viewElement ) ).to.be.true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do it via utils/dom/global
. Besides, why do we need this assertion in the first place? Shouldn't this test fail anyway if the editable was detached from DOM?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should I use utils/dom/global
only here? Any other test uses /*global document... */
.
And I check the assertion here just because I like to know exactly where test breaks and why if so ¯_(ツ)_/¯
If you really think that's redundant, I'll remove it ;-)
…y work in certain scenarios
- Remove radundant helper for setting max-width - Add condintion checking if editable element is in the DOM already - Minor fix in the constructor code
- Fix test descriptions - Use global from utils and new Rect instance to get a proper width that contains padding
|
||
// In the balloon editor toolbar's max-width should be set to the 2/3 of the editable's width. | ||
// It's a safe value, because at the moment we don't re-calculate it when position of the selection changes. | ||
this.toolbarView.maxWidth = toPx( new Rect( editableElement ).width * 0.66 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked this ratio and I came to the conclusion that it's unsafe for very small editables, e.g.:
Unfortunately, this case is totally valid, people may enable the editor on very narrow fields.
So here's what I propose:
- instead 2/3, let's go with .9. This should still be safe and it will look better in cases like this where there's plenty of space left
- Let's have a sane min-width for the
BalloonToolbar
in CSS (so at least the heading dropdown is visible + maybe 2 or 3 buttons). As a custom CSS property so developers can override it if they want to.min-width
should overrulemax-width
set by us in JS and this should work out great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we use the viewport width instead of editable width?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about the viewport thing, because in some situations, someone can have the editor's width set to, for example: 60% of the viewport and then we want to make sure, that toolbar will not expand over the editor, covering some important stuff next to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @panr. The UI of the editor should be restricted to the editable whenever possible. This is "our territory" in the application and we should not expand beyond that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could extend default BalloonPanelView
positions and add intermediate ones and then enable them in the BalloonToolbar
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, I added "middle-" states.
… the balloon toolbar
Just added it. I set a default min-width of the balloon toolbar to |
Sorry, I messed up with history merging fast forward |
…hTo for better positioning flexibility of the UI.
…tch editable width by using a mock resize observer.
…ew docs and manual tests
@ckeditor/qa-team Can you guys take a look at this PR constellation? Changes potentially affect all floating balloons in the editor. |
We've checked it and everything looks good 👍 |
Suggested merge commit message (convention)
Feature: The
BalloonToolbar
plugin should group items when its width is close to related editable's. Closes ckeditor/ckeditor5#5597. Closes ckeditor/ckeditor5#5501.BREAKING CHANGE: The
BalloonToolbar
plugin groups overflowing items now by default. This can be disabled via the editor configuration by settingconfig.balloonToolbar.shouldNotGroupWhenFull = true
.BalloonPanelView.defaultPositions
has been extended with additional positions. Please refer to the documentation to learn more.Requires: