[wp-trac] [WordPress Trac] #28477: New Built-in Customizer Control Types

[WordPress Trac]

#28477: New Built-in Customizer Control Types
--------------------------------+-----------------------------
 Reporter:  celloexpressions    |      Owner:
     Type:  enhancement         |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Appearance          |    Version:  3.4
 Severity:  normal              |   Keywords:
  Focuses:  ui, administration  |
--------------------------------+-----------------------------
 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`.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28477>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform