33

If i have an input like <input type="text"> and i want to trigger a native error on the input, can you do that? Like (faux code) ele.triggerError('Error Message');

It would then look like:

error
(source: tylergaw.com)

But with a custom message and for it's own validation function. Needed for AJAX validations for example.

Community
  • 1
  • 1
Oscar Godson
  • 31,662
  • 41
  • 121
  • 201
  • Can you work with JQuery, JQuery Validation will do it for you – Emmanuel N Dec 21 '11 at 23:12
  • I want to trigger native errors. I can write a custom error no problem, but i want them all to match the browser and use HTML5 – Oscar Godson Dec 21 '11 at 23:19
  • Depending on HTML5 features is somewhat limiting since support is patchy and inconsistent across browsers. HTML5 isn't (and likely never will be) a standard, nor does it stand still since it's a "living specification". It's a combination of standards (i.e. [W3C standards](http://www.w3.org/standards/)), legacy behaviour (i.e. [DOM 0](http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/glossary.html#dt-DOM-Level-0)), current behaviour and proposed future features, but doesn't identify which is which. So anything using HTML5 should use feature detection with fallback to basic browser behaviour. – RobG Dec 22 '11 at 00:09
  • Yes. Ill have a polyfill for setCustomValidity and checkValidity which will basically do a normal "mark as red" on the input if invalid in, lets say, IE. I'd obviously never let the browser submit a form if it just didnt support HTML5 – Oscar Godson Dec 22 '11 at 00:13

2 Answers2

39

The only way to trigger the native error is to submit the form. Although you can set a custom message with setCustomValidity (as described in my answer here) and you can trigger the invalid event with checkValidity, this only provides hooks for you to create your own validation UI. Here's a simple example you can play around with to verify.

Note that if you submit the form with the submit() method that will bypass the validation API. But if you trigger the click event of the submit button that will work in Firefox and Opera, but not Chrome. I'd avoid doing it right now.

Community
  • 1
  • 1
robertc
  • 74,533
  • 18
  • 193
  • 177
  • Hmm, i modified the error message you have and it's not showing in FF or Chrome. I did "`blanksssss`" and it still just shows `blank`. – Oscar Godson Dec 21 '11 at 23:49
  • Nevermind... ugh, JSFiddle. I forget JSFiddle doesn't autoupdate like JSBin. I think this is working... Ill play with it some more! thanks a lot – Oscar Godson Dec 21 '11 at 23:52
  • @OscarGodson Remember you can check the [`ValidityState` object](http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#validitystate) to work out *why* the field is invalid. – robertc Dec 21 '11 at 23:56
  • Im going to play with it now. Seems like those are readonly so I can't trigger those error messages with ValidityState. those would only happen if i used, for example `max`, `min`, `required`, etc HTML attributes, right? – Oscar Godson Dec 22 '11 at 00:07
  • @OscarGodson The `e.target.validity` object has the simple `valid` property but also all those other properties (`valueMissing`, `typeMismatch` etc.) so you can work out what triggered the error. In the example all the errors are assumed to be `valueMissing`, hence the error message, but you can check each one. – robertc Dec 22 '11 at 00:27
  • 1
    I wonder when would the UAz let us handle the error balloon via JS? Its a basic requirement to submit the form via Ajax while keeping the default error handling model and having ability to alter the default invalid UI behavior (`-moz-ui-invalid {box-shadow:color-of-my-choice;//other customizations}`, `::-webkit-validation-bubble` and its derivatives). Our *next-generation* *pervasive* HTML5 must include these features to keep UI consistent in cross-browser/cross-platform. – vulcan raven Jul 08 '12 at 21:47
  • 3
    @JasonWilliams Why on earth would it need to look consistent cross-browser, how many of your site's users other than yourself are visiting in multiple browsers? It's more important that this stuff looks consistent cross-site than it does cross-browser or cross-platform. – robertc Jul 08 '12 at 22:26
  • 3
    @robertc, honestly you don't know? First of all having the same on-error UI state with Ajax that we have without Ajax (standard form submission) would be nice. Secondly, more customization options and leaving UI decisions on webmaster's discretion would make more sense. Like we can customize the submit button, why shouldn't we be able customize the error bubble? For sake of an argument, why did stackoverflow's designer choose to style `Add Comment` button to look same on all browser given every browser has its own **default style** for a button? – vulcan raven Jul 08 '12 at 23:48
  • @JasonWilliams Honestly I don't know. Pointing out to me that designers do it is not the same as making an argument that they *should* do it. Why shouldn't buttons have the same **default style** on every website I visit? Why would I care that the design of a button on one particular website looks identical in another browser which I'm not using, but different to every other button out there? The whole benefit of having a consistent UI for form errors is lost if the UI for form errors is not consistent. – robertc Jul 09 '12 at 02:14
  • @robertc We can use `:invalid` selector to style invalid fields in all HTML5 browsers. Additionally Firefox provides `-moz-ui-invalid` to override the default UI behavior. Also with `-webkit-validation-bubble` you style the bubble but Chrome has nothing comparable to -moz-ui-invalid and Firefox has nothing similar to style the bubble yet. Now, my point is HTML5 should adapt both selectors as standard and your argument is that there is no need? So Firefox & Chrome may drop these tentative selectors & all browsers may drop :invalid selector too; for sake of keeping UI for form errors consistent? – vulcan raven Jul 09 '12 at 05:28
  • 2
    @JasonWilliams HTML does not have selectors CSS does; but yes, that is my argument. I've no idea what the plans of the browsers are or why you've chosen the comments to my (correct) answer to express your own opinions on the matter. If you want to lobby for browsers or specs to add features then [create a bug](https://bugzilla.mozilla.org/) or [subscribe to the mailing list](http://lists.w3.org/Archives/Public/www-style/). – robertc Jul 09 '12 at 08:27
  • Indeed, you need to trigger the native form submit. However you can trigger this in any of your custom handler if the element is part of the form. Check this answer that does that for an ajax setup: https://stackoverflow.com/a/53922759/301753 – e-motiv Dec 25 '18 at 13:32
22

You can now use the HTMLFormElement.reportValidity() method, at the moment it's implemented in Chrome, Firefox, Opera, and Android browsers, but not supported in Internet Explorer (check caniuse.com to see supported browsers).

Peter Umoren
  • 512
  • 6
  • 11
  • 1
    +1 solved my problem. used `reportValidity()` on a return of `document.forms[0].querySelector(':invalid')` to trigger the UI messages by Chrome. – reiallenramos Nov 23 '18 at 07:16
  • 2
    @reiallenramos or in jQuery sytax $('form').reportValidity(); – Maky Apr 25 '19 at 13:37
  • 1
    It seems to work even at an input element without a form element: `document.getElementById('field2').reportValidity();`. I tested it just in Chromium. – S. Doe May 04 '23 at 18:59