Repository navigation
ValidatedInputControl: email fields should not show validation errors while typing #79515
Description
What problem does this address?
Validated email fields can currently show “Please include an @ in the email address” while the user is still typing an incomplete email address.
For example:
- Focus a required email field.
- Blur it while empty.
- See “Please fill out this field.”
- Focus it again and start typing.
- See “Please include an @ in the email address” until you've typed an @ character.
This feels noisy because partial email addresses are expected to be invalid while being typed, for example firstname.surname would display the error while typing every character.
This is a known UX issue with premature validation. Relevant guidance:
- Nielsen Norman Group: avoid validating before input is complete: https://www.nngroup.com/articles/errors-forms-design-guidelines/
- Baymard: avoid premature inline validation: https://baymard.com/blog/inline-form-validation
- GOV.UK: avoid validating before the user has finished entering information: https://design-system.service.gov.uk/patterns/validation/
What is your proposed solution?
Email fields should clear or hide the existing validation message while the user is editing, then re-check when the field blurs.
One possible implementation is to add a validation timing option, such as revalidateOn, to ControlWithError, surface it through ValidatedInputControl and DataViews controls, and default email fields to blur-based revalidation.
Testing
This can be reproduced in Storybook with ValidatedInputControl:
- Run
npm run storybook:dev. - Open
Components / Selection & Input / Validated Form Controls / ValidatedInputControl. - Set the
typecontrol toemail. - Make sure
requiredis enabled. - Focus the empty field, then blur it.
- Focus it again and start typing an email address.
Activity
mirka commentedon Jun 25, 2026
This follows the standard validation behavior we agreed on, where:
We shouldn't have special behaviors just for email validation, so there needs to be a decision on whether we want to change the standard behavior for the general case.
ciampo commentedon Jun 25, 2026
I can see how validating only on blur can be a UX improvement (as supported by the links in the original issue description), especially for input types such as email, URLs, and pattern-based fields.
On the other hand, there are fields where intermediate invalid states are expected and useful (required fields clearing, password rules, async availability checks, or character limits).
What about supporting both styles of validation, with different defaults depending on the field type (as proposed above), but with the ability to toggle it if needed via a prop?
also cc @WordPress/gutenberg-design
jasmussen commentedon Jul 13, 2026
No strong opinions on whether we do it onblur or on every change. I use a semi-dumbphone which is slow and cumbersome so I imagine onblur only would work better there, but I think the key for ensuring that works well is to ensure there are no layout shifts. If things jump around as you are typing, that feels like mostly a no-go to me.
That's also why the main feedback I'd have looking purely at the visuals—thank you for contributing and providing them!—is that we should be as concise as possible. But I don't know if there's a bulletproof way to avoid layout shifts, especially on tiny phones that gets jumpy quick.
mirka commentedon Jul 15, 2026
I think we may first want to try addressing the general case where fields are marked as touched even though they're not really touched from the perspective of the user. This happens on the second input field in this demo:
CleanShot.2026-07-15.at.19-31-24.mp4
This the probably the majority case where this UX issue is perceived, so it would be good to try addressing this globally before escalating to per-field customization.
ciampo commentedon Jul 15, 2026
Right: if a field blurs without having ever received value changes, we should not mark it as touched.