Alternative way to display validation errors (=> below control fields)

[xdev1]

@claviska
Please allow me to talk about one last form feature that I personally really miss in SL:
Showing the validation error messages as red texts below the form controls, instead of the usual HTML5 validation error tooltips

Without any doubts, this way of displaying validation errors is very common.
And it would be great, if alternatively the error messages could be in the app language, and not in the browser language (I mean, out of the box, not by using setCustomValidity or whatever manually ).

See for example how this looks in IBM Carbon Design

To implement something similar to this I userland is really complex, I guess you basically have to wrap all SL form controls in new components (at least if you want things framework agnostic) and then in the end you have a bunch of components that cannot easily be mixed up with SL core form controls etc.

Please find here two test implementations of something like that (these experimental libraries that are used here are a complete mess, it's not important how this is actually implemented, as it is not done the right way - whatever the "right way" might be 😄).

Maybe you have to use Chrome, I've not tested those demos with Safari. Be aware that the demos are unfortunately quite buggy.

Login form demo:
https://codesandbox.io/s/login-bgtebe?file=/src/index.ts

Form dialog (the logic when to show the error message is buggy, this was better done in that "Login form demo"):
https://codesandbox.io/s/dialogs-erd22k?file=/src/index.ts

If I recall correctly, you have mentioned somewhere something about "inline validation" or whatever (but I cannot find the corresponding issue on Github).

Do you have by any chance any opinons, ideas, tips or whatever on that topic? Thank you very much in advance.

[Edit] Here's a little Shoelace demo: https://shoelace-dgqwh3tf6-font-awesome.vercel.app/getting-started/form-controls?id=using-inline-validation-messages

[claviska]

As with many features, Shoelace leans on the platform for form control validation. The recommended approach is the Constraint Validation API, which all form controls support.

I do understand that's it a fairly common practice to put validation messages underneath form controls. I think constraint validation works the way it does to prevent layout shifts and jarring behaviors, such as this dialog suddenly expanding on submit.

That said, if you want to use that pattern, it's probably best to not use constraint validation at all and go with your own solution. You can use the help text slot for error messages and even customize colors if you want. I'd probably add a class like has-error and do it that way.

https://codepen.io/claviska/pen/GRBYMVQ?editors=1010

Even though there are only two fields in that example, you can already see a pattern that could be extracted into a utility for all forms.

At this time, I don't have plans to add additional validation techniques to the library. Whether that stance changes in the future depends entirely on feedback and demand from users.

[xdev1]

@claviska Thanks for your answer and the nice demo. It surely cost you quite some time always preparing these nice little demos for your answers, but they are always a great help and absolute gold - a special thanks for all those demos of yours 👍 ❤️

Just for information for anyone who's interested:
In a real implementation it will turn out that using/manipulating the attributes help-text and class might not be what you want. Please find here basically the same demo as above, with the difference that it uses only attribute data-error:
https://jsfiddle.net/1gs9Lxzc/1/

---

Articles that may be helpful to implement a solution in userland:

• https://www.telerik.com/blogs/building-html5-form-validation-bubble-replacements

[xdev1]

Let's for now ignore the requirement "possibility for error messages in app language instead of browser language".

I think, a good solution should be as noninvasive as possible. I also think it's not even necessary to manipulate any form control attributes (like done in the demos of the two latest comments).
The "trick" is that the SL internal FormControlController must synchronize the attribute data-error with validationMessage on the internal form-control part in the shadow DOM. This way it will not manipulate the outside DOM tree at all, yet the error message can still be accessed via CSS:

/*
  The sl-input selector will finally be replaced with a selector
  for all SL based form controls, of course.
  Only used here for simplicity.
*/
sl-input[data-user-invalid]::part(form-control)::after {
  display: block;
  color: var(--sl-color-danger-700);
  content: attr(data-error);
}

Then we must make sure that FormControlController dispatches a cancable invalid event somewhere in the beginning of method handleFormSubmit if the form is invalid and stop processing if this invalid event has been cancelled (this is the way forms normally work).

Now all you have to do in userland is using the following method and setting the form attribute data-inline-validation (the rest is just CSS styling):

function enhanceFormValidation(form: HTMLFormElement): () => void {
  const handleInvalid = (ev: Event) => {
    if (form.hasAttribute('data-inline-validation')) {
      ev.preventDefault();
    }
  }

  form.addEventListener('invalid', handleInvalid, true);

  return () => form.removeEventListener('invalid', handleInvalid);
}

[claviska]

The FormControlController could easily admit sl-valid and sl-invalid events, perhaps even providing the validation message as a payload in event.detail. However, to do this, you'll need to be using the constraint validation API and I don't think there will be a clean way to suppress the browser's tooltip-style error message.

[xdev1]

Actually it's much easier than that, due to the fact that you've done an amazing job with that ElementInternals "kinda-polyfill".

Three steps:

1. For all Shoelace form controls add the read-only properties validity and validationMessage (we have to do this anyway) => not a lot of work (just return the corresponding values of the internal input or whatever elements)

2. Enhance the ElementInternals "kinda-polyfill" with proper dispatching and handling of form invalid events. This was just an important missing standard feature. We had to add it anyway => not a lot of work (adding some code to FormControlController::handleFormSubmit) but needs Step 1 first.

3. This is the only thing that is specific to that inline validation feature (Step 1 and Step 2 are just standard features): Make sure that CSS part form-control has a property data-error set if the form control value is invalid (containing the value of validationMessage).

   Just somthing like the following added to method setValidity (but this simple implementation needs Step 1 to be implemented first):

   const formControl = host.shadowRoot?.querySelector('[part=form-control]');
   
   if (formControl) {
     if (isValid) {
       formControl.removeAttribute('data-error');
     } else {
       formControl.setAttribute('data-error', this.host.validationMessage);
     }
   }

By the end of the day the only thing we are doing here (besides fixing existing issues) is to make the value of validationMessage available for CSS.

[xdev1]

I don't think there will be a clean way to suppress the browser's tooltip-style error message.

This was working in my demos (at least it seemed to work 😉), and this is exactly the way things are working with native form controls:

 form.addEventListener(
    'invalid',
    (ev: Event) => {
      if (form.hasAttribute('data-inline-validation')) {
        ev.preventDefault(); // this will prevent HTML 5 validation tooltips
      }
    },
    true
  );

[xdev1]

Actually I think it's quite interesting that this feature can be implemented in just six LLOCs in Shoelace core plus a bit of JS/CSS in userland. Basically because these data-user-(in)valid attributes are extremely useful . Three days ago I would not have thought that something like this is possible with only minor changes in Shoelace core.

Nevertheless, I personally would prefer a slightly different solution which would need to add the following line to each of Shoelace currently nine form control components:

<div part="form-control-validation-message" hidden>${this.validationMessage}</div>

added as last child of the following structure:

Plus changing the logic of this a little bit.
This increases CSS styling possibilities a lot (and is a cleaner approach, I guess).

[xdev1]

After #1181 will have been implemented all this "inline valiation" stuff can be implemented completely in userland.
No need for further discussion here from my side (at least at the moment 😉)