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

Table keyboard navigation - wrapping to next row invalid for row-spanned cells #6668

Closed
niegowski opened this issue Apr 24, 2020 · 6 comments
Labels
package:table resolution:expired This issue was closed due to lack of feedback. status:discussion status:stale type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@niegowski
Copy link
Contributor

πŸ“ Provide a description of the improvement

While in table cell, arrow right should wrap navigation to next row.

βœ”οΈ Expected result

Apr-24-2020 12-56-29

❌ Actual result

Apr-24-2020 12-52-11


If you'd like to see this improvement implemented, add a πŸ‘ reaction to this post.

@niegowski niegowski added type:improvement This issue reports a possible enhancement of an existing feature. package:table labels Apr 24, 2020
@niegowski niegowski self-assigned this Apr 24, 2020
@jodator
Copy link
Contributor

jodator commented Apr 24, 2020

This is what I was talking abut arrow vs TAB handling. Compare with Google Docs behavior:

Arrows

Tab

ps.: In other words we agreed that this is how it will work ;)

@panr
Copy link
Contributor

panr commented Apr 24, 2020

What about this behaviour?
Kapture 2020-04-24 at 13 03 38

78 -> down to the 80 -> back to the 71 -> again in row above / back to the 72

@niegowski
Copy link
Contributor Author

niegowski commented Apr 24, 2020

ps.: In other words we agreed that this is how it will work ;)

It was supposed to behave like this only in last row. I guess we need to discuss UX of this.

@jodator
Copy link
Contributor

jodator commented Apr 24, 2020

What about this behaviour?

Same - compare with Google Docs behavior. It was raised here: ckeditor/ckeditor5-table#304 (comment) and the agreement was that we follow others in handling arrows and tab.

It was supposed to behave like this only in last row. I guess we need to discuss UX of this.

The issue I was rising was exactly about this. And AFAIR the conclusion from F2F on this with @oleq, @niegowski & @jodator (me) was not to change the current behavior and to Β follow GDocs & other implementations.

@jodator jodator added this to the nice-to-have milestone Apr 30, 2020
@niegowski niegowski removed their assignment May 11, 2020
@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 12, 2023
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:table resolution:expired This issue was closed due to lack of feedback. status:discussion 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