WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 13 months ago

Last modified 12 months ago

#38667 closed task (blessed) (fixed)

Allow tab characters in custom CSS input

Reported by: helen Owned by: westonruter
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)

38667.0.diff (2.4 KB) - added by westonruter 13 months ago.
38667.1.diff (3.7 KB) - added by westonruter 13 months ago.
38667.2.diff (5.1 KB) - added by westonruter 13 months ago.

Download all attachments as: .zip

Change History (18)

This ticket was mentioned in Slack in #accessibility by helen. View the logs.


13 months ago

#2 follow-up: @westonruter
13 months ago

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 textarea could 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 that textarea they 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.

#3 @helen
13 months ago

Seems like we use escape in some other places (or plan to), which works for me.

#4 @afercia
13 months 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 @afercia
13 months 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:

https://cldup.com/EBqqlUt-3p.png

#6 @westonruter
13 months 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 @afercia
13 months 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 @westonruter
13 months 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 placeholder for control to default value for setting.

#9 @afercia
13 months ago

@westonruter thanks, looks good to me. Didn't know about tab-size! Worth considering to add it to the plugin/theme editors (will open a ticket).

#10 @afercia
13 months ago

Firefox needs the prefixed version -moz-tab-size.

#11 @westonruter
13 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 39149:

Customize: Allow tab characters in custom CSS input.

Pressing Esc followed by Tab allows for tabbing to the next element.

Props afercia, coffee2code, westonruter.
See #35395.
Fixes #38667.

#12 @westonruter
13 months ago

@afercia I've opened #38685 for addressing the placeholder issue.

#13 @ocean90
13 months ago

In 39163:

Customize: Autoprefixer for [39149].

See #38667.

#14 @westonruter
12 months ago

In 39557:

Customize: Prevent scrolling custom_css textarea to top when pressing tab.

Props tyxla, sstoqnov for testing, celloexpressions for testing.
See #38667.
Fixes #39134.

#15 @dd32
12 months ago

In 39569:

Customize: Prevent scrolling custom_css textarea to top when pressing tab.

Props tyxla, sstoqnov for testing, celloexpressions for testing.
See #38667.
Merges [39557] to the 4.7 branch.
Fixes #39134.

Note: See TracTickets for help on using tickets.