Bootstrap 5 validation: combining live per-field feedback with the .was-validated submit-gated pattern

Answer to the core questions

• Is there a documented or recommended way to enable live validation per field while keeping the submit‑gated behavior for untouched fields? Bootstrap itself only provides the presentational styles. The recommended pattern is to keep the standard submit handler that adds .was‑validated, and to wire native Constraint Validation API listeners (e.g., input and blur) that toggle .is‑invalid on each control as soon as the user interacts with it. This keeps untouched fields neutral until the form is submitted, while still showing live feedback on the fields that have been touched.
• When mixing manually applied .is‑invalid with .was‑validated, which takes visual precedence and can they conflict? The selector for .is‑invalid is a class selector applied directly to the control, so it has higher specificity than the .was‑validated .form-control:invalid rule. Consequently, once .is‑invalid is present, its styles override the pseudo‑class styles. The two mechanisms therefore coexist without visual conflict, provided you avoid duplicating error messages in the markup.
• Does this markup pattern differ between Bootstrap 4 and 5 in a way that affects this approach? The overall markup structure—.form-control followed by an adjacent .invalid-feedback element, and the form receiving .was‑validated on submit—is identical in both versions. Bootstrap 5 removed jQuery and tweaked some internal selectors, but the public API for validation styles remains unchanged, so the same strategy applies to both.

Practical steps for this case

1. Keep the form’s submit handler that adds .was‑validated when form.checkValidity() fails.
2. For each control that has a native constraint (e.g., required, type="email"), add a blur listener that marks the element as “touched” (for example, el.dataset.touched = true). Add an input listener that, if the element is touched, toggles .is‑invalid based on el.checkValidity().
3. Because .is‑invalid overrides .was‑validated, you can safely remove the class when the field becomes valid again.
4. If you use setCustomValidity() for custom rules, remember to clear the message when the value becomes valid; otherwise the native :invalid state will stay true and both mechanisms will keep showing the error.

What we still need to know

If your form uses custom JavaScript‑only validation (no native constraints) or relies heavily on setCustomValidity(), the exact timing of when you apply or clear .is‑invalid may need adjustment. Let us know if that’s the case so the guidance can be refined.