WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 6 months ago

Last modified 4 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 6 months ago.
38667.1.diff (3.7 KB) - added by westonruter 6 months ago.
38667.2.diff (5.1 KB) - added by westonruter 6 months ago.

Download all attachments as: .zip

Change History (18)

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


6 months ago

#2 follow-up: @westonruter
6 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
6 months ago

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

#4 @afercia
6 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
6 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

@westonruter
6 months ago

#6 @westonruter
6 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
6 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 /* */.

@westonruter
6 months ago

@westonruter
6 months ago

#8 @westonruter
6 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
6 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
6 months ago

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

#11 @westonruter
6 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
6 months ago

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

#13 @ocean90
6 months ago

In 39163:

Customize: Autoprefixer for [39149].

See #38667.

#14 @westonruter
4 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
4 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.