[wp-trac] [WordPress Trac] #38845: Implement HTML5 input validity constraints in customizer settings

[WordPress Trac]

#38845: Implement HTML5 input validity constraints in customizer settings
-------------------------+------------------
 Reporter:  westonruter  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.8
Component:  Customize    |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------
Description changed by westonruter:

Old description:

> Ever since #28477 controls in the customizer have supported custom HTML5
> input types along with new input attributes passed via the control's
> `input_attrs` param. The support, however, has been lacking because when
> a user supplies something that violates some of the constraints (such as
> `pattern` or `step`) there is nothing that blocks the setting from being
> saved (using setting validation model in #34893). So using the
> `input_attrs` along is in fact somewhat harmful if it is not accompanied
> by the same constraints being applied in the setting's
> `sanitize_callback` or `validate_callback`. The browser's built-in input
> validation error UI also does not show because no form actually gets
> submitted, and there are no calls to the poorly-supported
> `input.reportValidity()` method.
>
> To address these issues, I suggest that the default `validity_callback`
> for `WP_Customize_Setting` could look for any associated controls and
> then check the type of the value against the control's `type` and also
> check the value against the validation constraints defined in the
> control's `input_attrs` param, such as `min`, `max`, `pattern`, `step`,
> `maxlength`, and so on. In this way, a setting's
> `sanitize_callback`/`validate_callback` wouldn't even need to be defined
> since the validation constraints would be defined declaratively and
> checked automatically.
>
> It's not exactly the best pattern, however, for the setting's validation
> constraints to be defined on the control. So there could be a new
> `validation_constraints` param on `WP_Customize_Setting` where the
> validation input attributes could be defined instead of the on the
> control's `input_attrs`. A control could then automatically populate it's
> own `input_attrs` by copying from the setting's `validation_constraints`.
>
> These changes will ensure that setting validation routines will apply and
> error notifications will be displayed when settings fail validation on
> the server with a full refresh, selective refresh, or changeset update.
> In order to get the browser's native validation error reporting to
> appear, the JS control logic can be updated to call
> `input.reportValidity()` if it is available (it's currently only
> implemented in Chrome).
>
> See feature plugin: https://github.com/xwp/wp-customize-input-validity-
> constraints
>
> Lastly, in order for

New description:

 Ever since #28477 controls in the customizer have supported custom HTML5
 input types along with new input attributes passed via the control's
 `input_attrs` param. The support, however, has been lacking because when a
 user supplies something that violates some of the constraints (such as
 `pattern` or `step`) there is nothing that blocks the setting from being
 saved (using setting validation model in #34893). So using the
 `input_attrs` along is in fact somewhat harmful if it is not accompanied
 by the same constraints being applied in the setting's `sanitize_callback`
 or `validate_callback`. The browser's built-in input validation error UI
 also does not show because no form actually gets submitted, and there are
 no calls to the poorly-supported `input.reportValidity()` method.

 To address these issues, I suggest that the default `validity_callback`
 for `WP_Customize_Setting` could look for any associated controls and then
 check the type of the value against the control's `type` and also check
 the value against the validation constraints defined in the control's
 `input_attrs` param, such as `min`, `max`, `pattern`, `step`, `maxlength`,
 and so on. In this way, a setting's
 `sanitize_callback`/`validate_callback` wouldn't even need to be defined
 since the validation constraints would be defined declaratively and
 checked automatically.

 It's not exactly the best pattern, however, for the setting's validation
 constraints to be defined on the control. So there could be a new
 `validation_constraints` param on `WP_Customize_Setting` where the
 validation input attributes could be defined instead of the on the
 control's `input_attrs`. A control could then automatically populate it's
 own `input_attrs` by copying from the setting's `validation_constraints`.

 These changes will ensure that setting validation routines will apply and
 error notifications will be displayed when settings fail validation on the
 server with a full refresh, selective refresh, or changeset update. In
 order to get the browser's native validation error reporting to appear,
 the JS control logic can be updated to call `input.reportValidity()` if it
 is available (it's currently only implemented in Chrome).

 See feature plugin: https://github.com/xwp/wp-customize-input-validity-
 constraints

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38845#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform