Tab key behavior

[Frederico Caldeira Knabben]

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)

[Alfonso Martínez de Lizarrondo]

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.

[Frederico Caldeira Knabben]

#1830 has been marked as DUP.

[Brian Klug]

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?

[Frederico Caldeira Knabben]

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.

[Wojciech Olchawa]

#910 has been marked as DUP

[Wojciech Olchawa]

#891 has been marked as DUP

[Brian Klug]

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? :)

[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 ;

...

[Laurent Mascherpa]

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

[Brian Klug]

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.

[David Weekly]

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.

[Frederico Caldeira Knabben]

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.

[dpbabu]

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.

[Artur Formella]

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

[Frederico Caldeira Knabben]

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.

[Frederico Caldeira Knabben]

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

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

[Frederico Caldeira Knabben]

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

[Garry Yao]

Fixed with [5573] on 3.4.x branch.