Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider showing the "insert new paragraph" buttons regardless of widget location #6825

Closed
Reinmar opened this issue May 14, 2020 · 6 comments · Fixed by #7387
Closed

Consider showing the "insert new paragraph" buttons regardless of widget location #6825

Reinmar opened this issue May 14, 2020 · 6 comments · Fixed by #7387
Assignees
@oleq
Labels
package:widget squad:magic type:improvement This issue reports a possible enhancement of an existing feature.
Milestone
iteration 33 (v20...

Comments

@Reinmar
Copy link
Member

Reinmar commented May 14, 2020

📝 Provide a description of the improvement

I find situations like the one above confusing:

So, there's no button in this case... why? Because this image is anchored before the block quote.

That made me think a bit and I realised that I actually use <kbd>Enter</kbd> to start typing after widgets on many occasions – not only when there's no space after/before that widget.

Assuming that the button will show up only when my mouse pointer is near it, I think that it makes sense to have 2 buttons per every widget in the document. This will actually remove some code and make the editor faster too 😁.

If you'd like to see this improvement implemented, add a 👍 reaction to this post.
@Reinmar Reinmar added type:improvement This issue reports a possible enhancement of an existing feature. squad:magic labels May 14, 2020
@oleq
Copy link
Member

oleq commented May 14, 2020

Maybe let's narrow this a little bit and show them always for floated objects?

@Reinmar
Copy link
Member Author

Reinmar commented May 15, 2020

Maybe let's narrow this a little bit and show them always for floated objects?

That would be one option.

But I reported this issue as the current behavior made me think that, in general:

  • it may still be confusing for people why some buttons are displayed and some not – normal users may not get what the "tight, inaccessible" space that this feature is suppose to help with is,
  • creating a new paragraph before/after any image in the content, regardless of its position is a really common case – e.g. after you drop an image into some document template (like here in GitHub Writer, when we use issue templates) – I want to start typing after the image, but there's a heading below it – the button would be one click solution.

@oleq
Copy link
Member

oleq commented May 15, 2020

I don't say no. I think it's worth checking. 

What I'm worried about, though, it that there will be too many UI elements visible at a time (some of them not absolutely necessary) and that will decrease the content/noise ratio and degrade the UX.

@Reinmar Reinmar added this to the nice-to-have milestone May 18, 2020
@oleq
Copy link
Member

oleq commented May 26, 2020

The PoC of this approach is on-line. RFC.

@Reinmar Reinmar modified the milestones: nice-to-have, iteration 33 May 29, 2020
@oleq oleq self-assigned this Jun 2, 2020
@neongreen
Copy link

neongreen commented Jun 4, 2020 •
edited
Loading

I think the magic block buttons should just always be shown when a table/code block/etc is selected, period. Regardless if it's floating or not.

E.g. in this example technically I don't need a magic block to type after this image:

image

But I just tried it out and I found myself reaching for the magic block button instinctively, after using the magic block button just one time before, and felt a tinge of disappointment it wasn't there.

@oleq
Copy link
Member

oleq commented Jun 5, 2020

Good news then, @neongreen: we're planning on enabling these buttons for all block widgets in all situations in the next release. Stay tuned!

@oleq oleq mentioned this issue Jun 5, 2020
Merged
niegowski added a commit that referenced this issue Jun 10, 2020
@niegowski
Merge pull request #7387 from ckeditor/i/6693
eb8dd9f 
Fix (engine): The model selection post-fixer should not set a new selection if the ranges before and after post-fixing are the same (see #6693).

Tests (image): Aligned image tests to the latest `WidgetTypeAround` plugin API (see #6693).

Other (paragraph): The `InsertParagraphCommand` should split ancestors of the `Position` to find a parent that allows `'paragraph'` (see #6693).

Tests (table): Aligned `Table` plugin tests to the latest `WidgetTypeAround` API. Code refactoring (see #6693).

Feature (theme-lark): Added styles for a "fake caret" brought by the `WidgetTypeAround` plugin (see #6693).

Feature (typing): Created a public `isNonTypingKeystroke()` helper (see #6693).

Feature (utils): Created `isArrowKeyCode()`, `getLocalizedArrowKeyCodeDirection()`, and `isForwardArrowKeyCode()` helpers (see #6693).

Feature (widget): Implemented keyboard support for inserting paragraphs around block widgets using a "fake horizontal caret" (`WidgetTypeAround`). Both "Insert new paragraph" buttons are now always displayed for all block widgets regardless of their location in the document. Closes #6693. Closes #6825. Closes #6694.

Also:

*   code refactoring in the `Widget` plugin,
*   aligned `Widget` tests to the new `WidgetTypeAround` keyboard behavior,
*   moved the `Enter` and `Shift+Enter` support from the `Widget` plugin to the `WidgetTypeAround` plugin.

MINOR BREAKING CHANGE (widget): Removed the `getWidgetTypeAroundPositions()` helper since the "Insert new paragraph" buttons are now visible regardless of the widget location in the document
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@oleq oleq

Labels
package:widget squad:magic type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Milestone
iteration 33 (v20.0.0)
Development

Successfully merging a pull request may close this issue.

#6693: Keyboard support for the widget type around feature ckeditor/ckeditor5
3 participants
@Reinmar @oleq @neongreen