Opened 9 years ago

Closed 7 years ago

#979 closed New Feature (fixed)

Tab key behavior

Reported by: fredck Owned by: garry.yao
Priority: Normal Milestone: CKEditor 3.4
Component: General Version: FCKeditor 2.5.1
Keywords: Confirmed Review+ Cc:

Description

Ideally we should uniformize the tab behavior considering the following variations (ordered by priority):

  • If FCKConfig.TabSpaces > 0, the configured number of spaces should be inserted in the selection, no matter the cursor position.
  • A new setting named BlurOnTab, or something like that, should be created to be able to set the editor to loose the focus when hitting tab, moving to the next field in the form (just like any other form field).
  • And finally the default behavior: no action on the text, and possibly reflecting Firefox's behavior for tables on all browsers: TAB and SHIFT+TAB to navigate between cells, or to add a new row if positioned in the last cell. (#775 and #891)

Attachments (2)

979.patch (4.5 KB) - added by garry.yao 7 years ago.
979_2.patch (4.4 KB) - added by garry.yao 7 years ago.

Download all attachments as: .zip

Change History (28)

comment:1 Changed 9 years ago by alfonsoml

I think that maybe we should have only two behaviors:

  1. Using the tab to navigate like another form control
  2. Using the tab like it behaves in Word.

(a) means that users can go to the next form element easily, and it could be activated just if TabSpaces == 0. This is important for users that rely only on the keyboard.

(b) I think is what most people expect in a word processor, although we can try to adjust it to behave better in a web environment (doing everything perfect will be difficult)

  • Pressing tab in the body with no selection inserts TabSpaces *  
  • If a whole paragraph is selected then increase the indent of that paragraph (also, several paragraphs could be selected at the same time)
  • If some text is selected inside a paragraph, replace it with TabSpaces *  
  • If the selection is inside a table, at the end of a cell, move to the next cell
  • If it was the last cell, insert a new row with the same attributes as the previous one.
  • If it is in the middle of a cell, insert TabSpaces *  
  • If it is at the start of a cell, well, this is the most difficult part to say what's best. It could indent the contents or it can move to the next cell. I would vote for moving to the next cell.
  • If the whole content of a cell is selected, move to the next cell.
  • If we are at the end of the body then do like (a) and focus the next control in the page.

And doing Shift+Tab should do the reverse navigation when moving in cells or getting out of the control, and if a whole paragraph is selected outdent it.

comment:2 Changed 9 years ago by fredck

  • Milestone changed from FCKeditor 2.6 to FCKeditor 2.7

comment:3 Changed 9 years ago by fredck

#1830 has been marked as DUP.

comment:4 Changed 9 years ago by dustball

Correct me if I'm wrong, but in 2.4, the behavior of TAB inside a bulleted list was to indent and start a sublist.

This has been changed - and is quite unexpected from the user's point-of-view. Even if we set TabSpaces to "0", TAB still doesn't indent.

I understand and appreciate the goal for 2.7, but it seems like in the meantime we have downgraded functionality. Am I missing something?

comment:5 Changed 9 years ago by fredck

The list item indentation was a feature proposed by the browser itself. Actually, by Firefox only. In IE you didn't have it.

Also, with Firefox, you were able to apply unlimited indentation to an item, having the buggy <ul><ul><ul> effect.

So, the former behavior was incorrect and not consistent among browsers.

For the 2.5, we have introduced a custom list handling system, aiming to provide the same output with all browsers. Also, the TAB key is now handled by the editor, and the browser has no control of it anymore.

Our intention now is proposing this feature properly, compatible with all browsers.

comment:6 Changed 9 years ago by w.olchawa

#910 has been marked as DUP

comment:7 Changed 9 years ago by w.olchawa

#891 has been marked as DUP

comment:8 follow-ups: Changed 9 years ago by dustball

I believe most users will expect that list items indent when the tab key is pressed. This is how Micrsoft Word works -- and a surprisingly large number of people expect the indent behavior.

Rather then fixing the whole TAB issue alltogether (fixing table behavior), is it possible to just have tab cause an indent? Can we sponsor such a fix? :)

comment:9 in reply to: ↑ 8 Changed 9 years ago by lelebitt

Replying to dustball:

I believe most users will expect that list items indent when the tab key is pressed. This is how Micrsoft Word works -- and a surprisingly large number of people expect the indent behavior.

Rather then fixing the whole TAB issue alltogether (fixing table behavior), is it possible to just have tab cause an indent? Can we sponsor such a fix? :)

Hi at all, We can have a TAB key that work like a word and not like something that add some spaces setting in fckconfig.js on line FCKConfig.TabSpaces = 0 ;

...

comment:10 in reply to: ↑ 8 Changed 9 years ago by lmascherpa

Replying to dustball:

I believe most users will expect that list items indent when the tab key is pressed. This is how Micrsoft Word works -- and a surprisingly large number of people expect the indent behavior.

Rather then fixing the whole TAB issue alltogether (fixing table behavior), is it possible to just have tab cause an indent? Can we sponsor such a fix? :)

I did some hack for this problem. If you want to sponsor, feel free. Here is the trick : in fckconfig.js, add some shortcuts to indent and outdent in the keystrokes like :

FCKConfig.Keystrokes = [
	// _ lma: indent fix
	[ 09 /*TAB*/, 'Indent' ],
	[ SHIFT + 09 /*SHIFT+TAB*/, 'Outdent' ],
	// ^ lma: indent fix

comment:11 Changed 8 years ago by dustball

Hi there! The fix looks neat, but I think that dramatically changes the behavior (for the worse) of tabs when not in lists. Ident is not a suitable replacement for tab in most circumstances.

comment:12 Changed 8 years ago by fredck

  • Milestone set to CKEditor 3.0

comment:13 Changed 8 years ago by dweekly

Any update on where we're at with tabbing in tables in CKEditor 3.0? This functionality is very important to our users. As dustball mentioned, PBwiki would be happy to help sponsor work on this.

comment:14 follow-up: Changed 8 years ago by fredck

  • Milestone changed from CKEditor 3.0 to CKEditor 3.x

We already have full support for blur/focus on TAB, as well as the tab spaces feature in V3. We may think about the other features as soon as we have the first stable release public.

comment:15 in reply to: ↑ 14 Changed 8 years ago by dpbabu

  • Component changed from General to Server : Java
  • Keywords Tab key behaviour added; Discussion removed
  • Milestone CKEditor 3.x deleted
  • Priority changed from Normal to High
  • Version set to FCKeditor 2.5.1

Replying to fredck:

We already have full support for blur/focus on TAB, as well as the tab spaces feature in V3. We may think about the other features as soon as we have the first stable release public.

Hi fredck,

I am using 2.5.1. I have the same issue(on tab key hit, the cursor should jump out of editor to another element). I tried to use patch 2297.patch for ticket #2297. But still problem persists. Please help me still anything to update or modify.

Thanks in Advance, Prasad.

comment:16 Changed 8 years ago by arczi

  • Component changed from Server : Java to General
  • Keywords Tab key behaviour removed
  • Milestone set to CKEditor 3.x
  • Priority changed from High to Normal

I don't think it is connected with Java.

Priority is Normal because it is not a critical issue.

As Fred said we may think about this feature as soon as we have the first stable release public.

More info about our ticket system:

http://dev.fckeditor.net/wiki/TracTickets and http://dev.fckeditor.net/wiki/TicketLifeCycle

comment:17 Changed 7 years ago by arczi

  • Keywords Confirmed added

comment:19 Changed 7 years ago by garry.yao

  • Milestone changed from CKEditor 3.x to CKEditor 3.4

comment:20 Changed 7 years ago by fredck

Ok, let's review the behavior we should have here, and finally work to close this ticket.

Currently, the TAB and SHIFT+TAB key already have two behaviors:

  • If tabSpaces is > 0, the configured number of spaces is added in the selection point.
  • In tabSpaces = 0, the focus goes to the next/previous element in the page, just like a normal text field.

I think the above is enough, to control the focus feature. Now, we need to add additional support on tables. For simplicity and easy to use, let's just provide the features we have with MS Word when inside a cell:

  • TAB: select the contents of the "next" cell. If in the last cell in the table, add a new row to it and focus its first cell.
  • SHIFT+TAB: select the contents of the "previous" cell. Do nothing when in the first cell.

It's to consider though that people may also want to enforce TAB to be used for focus "only". Because of this, we should also consider having a specific setting to enable TAB for it, added by an additional keystroke for the table navigation: ALT+ARROW-RIGHT / ALT+ARROW-LEFT (inverted in RTL contents). For the setting, let's have a generic name, like config.enableTabKeyTools (default true), which can be used in the future if we decide to do other things via TAB.

Changed 7 years ago by garry.yao

comment:21 Changed 7 years ago by garry.yao

  • Keywords Review? added
  • Owner set to garry.yao
  • Status changed from new to assigned

comment:22 Changed 7 years ago by fredck

  • Keywords Review- added; Review? removed
  • The cell contents should be selected when moving through them.
  • The ARROW-LEFT and ARROW-RIGHT should be used, instead of ARROW-UP and ARROW-DOWN. Note that this is a usability feature, not an accessibility need.
  • The CKEDITOR.config.keystrokes settings should be done in the tab plugin file, to isolate them (I know we have other unrelated keys there, but that's another issue).
  • Now a question... should it go into the tab plugin, or maybe it makes more sense to have this into the tabletools plugin? I'm starting to think that tabletools is the right place for it.

comment:23 Changed 7 years ago by garry.yao

The ARROW-LEFT and ARROW-RIGHT should be used, instead of ARROW-UP and ARROW-DOWN.

ARROW-LEFT/RIGHT been used a Foward/Back :/

maybe it makes more sense to have this into the tabletools plugin...

Let's keep this inside 'tab' plugin (grouping by keystroke) rightnow.

Changed 7 years ago by garry.yao

comment:24 Changed 7 years ago by garry.yao

  • Keywords Review? added; Review- removed

comment:25 Changed 7 years ago by fredck

  • Keywords Review+ added; Review? removed

Please have this one committed into the 3.4.x branch.

comment:26 Changed 7 years ago by garry.yao

Fixed with [5573] on 3.4.x branch.

comment:27 Changed 7 years ago by garry.yao

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.
© 2003 – 2016 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy