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

Focusing the table cell with only a widget inside. #9120

Closed
magda-chrzescian opened this issue Feb 26, 2021 · 2 comments
Closed

Focusing the table cell with only a widget inside. #9120

magda-chrzescian opened this issue Feb 26, 2021 · 2 comments
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:table squad:core Issue to be handled by the Core team. type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@magda-chrzescian
Copy link
Contributor

📝 Provide a description of the improvement

It is impossible to put the caret inside the table cell if there is a widget element inside, despite the fact that the cursor suggests that it should be possible.

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.


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

@magda-chrzescian magda-chrzescian added type:improvement This issue reports a possible enhancement of an existing feature. package:table domain:ui/ux This issue reports a problem related to UI or UX. labels Feb 26, 2021
@AnnaTomanek AnnaTomanek added the squad:core Issue to be handled by the Core team. label Feb 26, 2021
@niegowski
Copy link
Contributor

DUP #7433

@oleq
Copy link
Member

oleq commented Feb 26, 2021

Yeah, looks like the same problem but described in a slightly different way. If so, can you please close this issue and move your comments to the original one @magda-chrzescian?

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:table squad:core Issue to be handled by the Core team. type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

No branches or pull requests

4 participants