Opened 17 years ago

Closed 14 years ago

#979 closed New Feature (fixed)

Tab key behavior

Reported by: Frederico Caldeira Knabben 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 14 years ago.
979_2.patch (4.4 KB) - added by Garry Yao 14 years ago.

Download all attachments as: .zip

Change History (28)

comment:1 Changed 17 years ago by 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.

comment:2 Changed 16 years ago by Frederico Caldeira Knabben

Milestone: FCKeditor 2.6FCKeditor 2.7

comment:3 Changed 16 years ago by Frederico Caldeira Knabben

#1830 has been marked as DUP.

comment:4 Changed 16 years ago by 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?

comment:5 Changed 16 years ago by 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.

comment:6 Changed 16 years ago by Wojciech Olchawa

#910 has been marked as DUP

comment:7 Changed 16 years ago by Wojciech Olchawa

#891 has been marked as DUP

comment:8 Changed 16 years ago by 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? :)

comment:9 in reply to:  8 Changed 16 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 16 years ago by 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

comment:11 Changed 16 years ago by 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.

comment:12 Changed 16 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.0

comment:13 Changed 16 years ago by 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.

comment:14 Changed 15 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.0CKEditor 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 15 years ago by dpbabu

Component: GeneralServer : Java
Keywords: Tab key behaviour added; Discussion removed
Milestone: CKEditor 3.x
Priority: NormalHigh
Version: 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 15 years ago by Artur Formella

Component: Server : JavaGeneral
Keywords: Tab key behaviour removed
Milestone: CKEditor 3.x
Priority: HighNormal

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 15 years ago by Artur Formella

Keywords: Confirmed added

comment:19 Changed 14 years ago by Garry Yao

Milestone: CKEditor 3.xCKEditor 3.4

comment:20 Changed 14 years ago by 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.

Changed 14 years ago by Garry Yao

Attachment: 979.patch added

comment:21 Changed 14 years ago by Garry Yao

Keywords: Review? added
Owner: set to Garry Yao
Status: newassigned

comment:22 Changed 14 years ago by Frederico Caldeira Knabben

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 14 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 14 years ago by Garry Yao

Attachment: 979_2.patch added

comment:24 Changed 14 years ago by Garry Yao

Keywords: Review? added; Review- removed

comment:25 Changed 14 years ago by Frederico Caldeira Knabben

Keywords: Review+ added; Review? removed

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

comment:26 Changed 14 years ago by Garry Yao

Fixed with [5573] on 3.4.x branch.

comment:27 Changed 14 years ago by Garry Yao

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy