When offering a text editor in a browser environment, what should the Tab-key do. Natively it will leave the currently selected input and select the next one, but the tab key is also a valid character to indent the inputed text or code. Especially now that website UX becomes more individual to suit the needs of visitors rather than general consistency (e.g. 10 years ago all buttons looked alike, now less so), this seems to be a valid question to raise.
1 Answer
What follows are my thoughts on the matter, but I am posting this question to see whether others agree or disagree.
There seem to be two possible reasons to change native Tab-key behaviour:
- The text editor is the main field on the page
- The editor is meant to enter content which will contain
tab
-characters.
The text editor is the main field on the page
When the text editor is the main field on the page and enter relatively longer texts the user will expect behaviour more alike to a traditional desktop text editor such as Microsoft Word than the native tabbing behaviour. This is especially, although not only, the case if we're talking about WYSIWYG editors (contenteditable=true
). Historically larger text editors where rare in the browser world: no CMSs, full document editors or similar services existed and a form was truly a form, rather than even simple websites being more akin to web applications nowadays.
Investigating a couple of Cases:
- Google Drive: Tab causes custom indent
- Microsoft One Drive: Tab causes custom indent
- StackExchange: Tab leaves field
- CKEditor: Tab leaves the field default, but standard plugin is provided to change behaviour
- Joomla: Tab creates
tab
- iCloud: Tab causes custom indent
- Fork CMS: Tab leaves the field
Behaviour seems to differ, especially in full page text editors Tab often creates a tab
-character or adds the illusion of one using a custom indentation system, however this is far from universal and some sites leave the field when tab is hit.
The editor is meant to enter content which will contain tab
-characters.
The only common scenario I can think of is code, but the UX approach seems to be more general to any content which would contain a lot of tab characters. Sometimes in code editors spaces are added rather than the actual tab
character, although it is good to add such an option, it is bad to make this the default as it goes against both the Tab-key (aptly named 'Tab') and native browser behaviour (leaving the field).
Investigating a couple of cases
- Ace editor: Tab causes a tab
- JSFiddle: Tab causes spaces(4) by default
- Dabblet: Tab causes a tab
- c9.io: Tab causes a tab
- Codepen: Tab causes spaces(2) by default
- StackOverflow: Tab leaves field
- Liveweave: Tab causes spaces(2) by default
Drawbacks of changing default behaviour
It is important to be aware that changing the default native behaviour will mean that you will need to take care of users who do not wish to use a mouse. The question quickly becomes how common these users are and this seems only crucial if users do not spend a lot of time in the editor. Either way, this problem can be easily alleviated by creating custom shortcuts for powerusers, whilst the rest of the normal users can enjoy the advantages of the tab character working rather than having to use the mouse to hit a button in the menu to indent or copy/pasting a tab character (yes, I have done this in the past).