New Built-in Customizer Control Types

[celloexpressions]

Devs shouldn't need to create custom customizer controls for commonly-used inputs such as textarea, number inputs, etc. Additionally, we should (and easily can) support all of the html5 input types via fallback handling for unknown types. This makes it even easier to build options into the customizer and shifts the need for custom controls to more advanced uses.

This ticket is for discussion and potential inclusion of control input types that could be added to the base WP_Customize_Control. Anything added here would be used with something like:

$wp_customize->add_control( $setting_id, array(
	'type' => 'textarea',
	...
);

The base WP_Customize_Control currently supports the following types:

• text
• checkbox
• radio
• select
• dropdown-pages

Adding a fallback type handler gives us full support for input types such as email, url, hidden, date & time formats, etc. This is accomplished by passing the control type to the type attribute of the input element and otherwise treating it as a text input. We could also add some JS to provide a more consistent experience across browsers and for browsers that don't support things like date & time input types, but I'd consider that a future enhancement (as those are implicitly, not explicitly supported). If we were to do that, passing a color type, for example, would result in the behavior similar to WP_Customize_Color_Control (although in that case it requires a standalone control). I would recommend adding some CSS to handle a few easily-supportable types (mostly for input widths).

If we add a few more properties to the WP_Customize_Control class (min, max, step), we could also fully support number and range input types. This would be similar to how the choices parameter is specific to the radio and select input types.

Finally, there are a few other field types that are commonly used. This might be a good time to add a couple of types such as textarea that can be implemented in the base WP_Customize_Control.

[celloexpressions]

Add default handling to support additional input types that don't require special handling (email, url, etc.).

[celloexpressions]

28477.default.diff​ is the fallback handling part; this is the first step of several things we could do here.

[celloexpressions]

Add core customizer control support for textarea, number, and range, and fallback/implicit support for other input types.

[celloexpressions]

Test plugin that creates a bunch of controls with different types.

[celloexpressions]

Test plugin output with 28477.diff applied, in Chrome 35 (left) and Firefox 29 (right).

[celloexpressions]

28477.diff​ does pretty much everything I suggested in the ticket description. I'm not sure that we should do all of it (particularly the number & range parts), but it's all worth considering.

The attached screenshot and test plugin demonstrate the purpose of the fallback type handler. This allows us to implicitly support all sorts of input types that devs can use with minimal effort. If, for example, someone needs a time or date field and only needs to support Chrome, they can do so quite easily and rely on the browser's support for that input type. Any of these input types is treated as a text input by browsers if the type is unrecognized.

Currently, most developers would just create a text control for a url field, but with this proposal they could just as easily use url, taking advantage of potential improvements that the browser might implement for that specific input type (contextual on-screen keyboards, for example).

[westonruter]

@celloexpressions I really like this.

For feedback, what if instead of a $numerical property, it instead implemented an array of input attrbutes (e.g.$input_attrs), and then all provided attributes would get serialized and inserted into the <input> element. This would make it easy to add support for pattern and other attributes.

Additionally, should not there also be some default server-side validation for controls with these input attributes provided? I suppose it would actually be the domain of the associated customize setting, but it would be nice if there was a low-priority filter that would get added automatically to enforce the HTML5 validity constraints.

[celloexpressions]

Add core textarea type, support for arbitrary types and attributes.

[celloexpressions]

Replying to westonruter:

For feedback, what if instead of a $numerical property, it instead implemented an array of input attrbutes (e.g.$input_attrs), and then all provided attributes would get serialized and inserted into the <input> element. This would make it easy to add support for pattern and other attributes.

Great idea! 28477.2.diff​ adds the textarea type and generic handling for arbitrary types and input attributes. I put in a whitelist of allowed attributes, not sure if that's needed. I'd rather not do that for input types, as that might imply explicit support for those (in terms of styling, supporting JS, etc.).

In terms of validation, I don't think we can do anything here since that's up to the setting (other than maybe making additional functions available).

Usage (not that you would ever use all of these attrs together):

$wp_customize->add_control( $setting_id, array(
	'label'     => $label,
	'section'   => $section_id,
	'type'      => $type,
	'input_attrs' => array(
		'min' => 0,
		'max' => 10,
		'step' => 2,
		'class' => 'test-class test',
		'style' => 'width: 50%;',
		'placeholder' => __( 'Placeholder' ),
		'pattern' => '[a-zA-Z0-9]+',
	),
) );

[westonruter]

In case it is helpful, I applied your patches to the Git repo clone and opened a PR for code review, collaboration, and any additional commits: ​https://github.com/x-team/wordpress-develop/pull/14

[celloexpressions]

Remove explicit text type output, don't use a whitelist of allowed attributes.

[celloexpressions]

Per chat with nacin, we don't need to validate input attributes against a whitelist, and the existing text type output can be removed, as the fallback type handling results in the same output when type = text.

Only outstanding issue here is whether (or to what extent) core should style different possible input types. Applying our standard input styling for all inputs may be the best solution here, but we could probably land the php side of this now.

This will conflict with #27981; I'll just update the other patch once the first one lands.

[celloexpressions]

Refresh with descriptions.

[celloexpressions]

28477.4.diff​ refreshes to account for [28927].

[celloexpressions]

Restore textarea type that fell out of .4.diff.

[celloexpressions]

Revised demo/test plugin with input_attrs(), several input types, and the new description field.

[ocean90]

In 28930:

Customizer: Support textarea and commonly-used input types as control type in WP_Customize_Control.
Add input_attrs property to support custom input attributes.

(Demo plugin attached to ticket.)

props celloexpressions.
fixes #28477.

[ocean90]

Replying to celloexpressions:

Only outstanding issue here is whether (or to what extent) core should style different possible input types.

That should go to another ticket.

[iseulde]

Replying to ocean90:

That should go to another ticket.

#28262

[westonruter]

In 41387:

Customize: Use input event instead of keyup or propertychange events when listening for changes in wp.customize.Element instances.

Ensures that a control's Element is updated in response to pasting into the field. Also fixes issue where inputs using "new" HTML5 types (like url and number) were not updating in the preview during keystrokes. The use of input was previously blocked due to needing to support IE9, but this is no longer a concern since IE<11 is no longer supported.

See #38845, #28477.
Fixes #35832.