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.

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

Make it possible to activate the horizontal fake widget caret using a mouse #7433

Closed
oleq opened this issue Jun 15, 2020 · 5 comments
Closed
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:widget resolution:expired This issue was closed due to lack of feedback. squad:core Issue to be handled by the Core team. status:stale type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@oleq
Copy link
Member

oleq commented Jun 15, 2020

Since #6693 we display a fake caret when a user navigates using the keyboard. We're making it look like a browser feature so clicking in this area

Screenshot 2020-06-15 at 15 13 10

could result in

image

like when the keyboard arrows are used. Users might expect it to work this way and this is one of the things that would make the "fake-caret illusion" even more real.

@oleq oleq added domain:ui/ux This issue reports a problem related to UI or UX. squad:magic type:improvement This issue reports a possible enhancement of an existing feature. package:widget labels Jun 15, 2020
@mlewand mlewand added this to the nice-to-have milestone Jun 29, 2020
@AnnaTomanek AnnaTomanek added squad:core Issue to be handled by the Core team. and removed squad:magic labels Mar 1, 2021
@magda-chrzescian
Copy link
Contributor

We definitely should support the mouse clicking here. Not everyone uses the keyboard for navigation and there are some cases where we suggest that it is possible to set a caret with a click, but it doesn't happen. For example, it is impossible to put the caret inside the table cell if there is a widget element inside.

I am aware that the handlers before and after the widget covers this, but it is not very comfortable to be forced to click on some small element just to set a caret in the place where it seems to be allowed.

The same problem occurs when we try to set the selection between two widgets.


The solution seems to be pretty simple if the widget takes up all the space inside the cell - we can activate the horizontal caret before/after the widget.

Alternatively, we could just get rid of the figure margins inside the table (for the first/last child only) - there would be no suggestion that the caret can be just set before/after the widget.


But it gets more complex if it seems to be possible to write next to the widget - the horizontal caret will be misleading since the text will actually appear in a completely different place.

From the user's point of view, in this case, the new paragraph should be added after the widget, but I'm not sure if we are able to tell the difference between the previous case and this one. I believe that the only thing that differs them both is the imageStyle attribute (currently possible to be applied only on the images), which doesn't give us any direct or reliable information about the widget/text behavior - it can be completely custom imageStyle set by the developer or one of the default styles with custom CSS rules. So, we would need to know, where the new paragraph WOULD appear to decide if it should appear at all.

Alternatively, I think that a horizontal caret is still a better way to go, than clicking the button.

@magda-chrzescian
Copy link
Contributor

⬆️ The problem escalates a bit for the inline images because they don't have the buttons for inserting a new paragraph. To write in the cell with only the inline image inside, the user has to select the image and then press the arrow button to activate the caret.

@oleq
Copy link
Member Author

oleq commented Mar 23, 2021

Maybe let's not mix these up. The original (block) issue is way more relevant in my opinion. The latter (inline in table) can be handled as a follow-up.

@pomek pomek removed this from the nice-to-have milestone Feb 21, 2022
@CKEditorBot
Copy link
Collaborator

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 still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

@CKEditorBot
Copy link
Collaborator

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).

@CKEditorBot CKEditorBot added the resolution:expired This issue was closed due to lack of feedback. label Nov 13, 2023
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:widget resolution:expired This issue was closed due to lack of feedback. squad:core Issue to be handled by the Core team. status:stale type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

No branches or pull requests

6 participants