#38667 closed task (blessed) (fixed)
Allow tab characters in custom CSS input
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 4.7 | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Customize | Keywords: | has-patch |
| Focuses: | javascript | Cc: |
Description
Considering more IDE-esque features such as syntax highlighting and autocompleting braces was punted from 4.7, but I think including the ability to enter tab characters within the custom CSS input for 4.7 is an important basic usability thing to include. A lot of people are taught to use tab characters right from the start even if they only ever learn basics, and it's pretty infuriating to tab out of the input.
Keyboard nav considerations likely need to be made.
Attachments (3)
Change History (18)
This ticket was mentioned in Slack in #accessibility by helen. View the logs.
8 years ago
#4
@
8 years ago
An option could be what is already implemented for the plugin/theme editors. See #31415 where the solution implemented was to use Escape and then Tab to exit the textarea.
See also what was done for the textarea for user notes on developer.wordpress.org
https://meta.trac.wordpress.org/ticket/626
#5
in reply to:
↑ 2
@
8 years ago
Replying to westonruter:
It's a similar problem to pressing Enter to create a new line in messaging apps, where often it's a preference for whether Enter submits, and/or the user hits Shift+Enter to create a new line. Unfortunately this same “shifty” paradigm won't work for Tab since Shift+Tab means to go to the previous field.
Yep, it wouldn't work so well. Just for reference, adding a screenshot with an example of the Enter-shifty thing:
#6
@
8 years ago
- Keywords has-patch added; needs-patch removed
- Owner set to westonruter
- Status changed from new to accepted
@afercia thanks a lot for referencing that previous code from @coffee2code (and yourself). I incorporated into a patch in 38667.0.diff. Should the “hit Esc to tab out” behavior be added to the help text behind the “?”?
#7
@
8 years ago
@westonruter yep I guess a short text in the Help explaining users they can indent code using the Tab key and use Escape to tab-out would be useful.
Couple things:
- when pressing Escape twice, the section closes (I guess this is the expected behaviour) but then noticed when you reopen the section again, entering tab characters doesn't work any more the first time you use the textarea. Starts working again after you blur the textarea and then focus it again
- I was staring at the comment used in the placeholder and trying to use the keyboard to select/cancel what initially appeared to me being text... was wondering why the arrow keys weren't working at all. Maybe it's just me being a bit slow :) Since it's formatted like an inline comment
/* */it looks like actual code that can be selected. Maybe potentially confusing for users, I'd consider to remove the/* */.
#8
@
8 years ago
@afercia thanks, please give 38667.2.diff a try.
- Adds Esc text to section contextual help.
- Removes IE8-specific code.
- Ensures that hitting Tab enters a Tab character after blurring the first time.
- Moves
placeholderfor control todefaultvalue for setting.
It's a similar problem to pressing Enter to create a new line in messaging apps, where often it's a preference for whether Enter submits, and/or the user hits Shift+Enter to create a new line. Unfortunately this same “shifty” paradigm won't work for Tab since Shift+Tab means to go to the previous field.
The
textareacould have Tab capturing off by default. Then once the user focuses on the field and enters any character (other than Tab) the Tab capturing can be started so that literal Tab characters can be entered. Then if the user wants to get out of thattextareathey could hit Esc to disable Tab capturing to restore normal behavior of tabbing between fields. There would need to be some help text explaining this.