Form validation — mobile

Back to the index

See also the desktop table.

Last updated on 11 April 2017.

CSS form validation

With CSS only

[an error occurred while processing this directive] [an error occurred while processing this directive]
:valid and :invalid
On form fields, fieldsets, and forms.
Really ought to work on labels as well, but it doesn’t. 		Yes Incom­plete Incom­plete Yes Incom­plete Yes Incom­plete Static Incom­plete Yes

These pseudo-classes are re-evaluated with every keystroke.

  • Safari 9: minlength not supported
  • Imcomplete: no minlength, no forms and fieldsets
  • Gchromium 44+: everything supported
  • Static Op Mini
  • Edge no maxlength either
input:before/:after
Should not work but mysteriously does sometimes. 		Yes Yes Yes Yes Yes No No
  • Safari anc Chrome BB support them on radios, checkboxes, and date-related types.
  • AW, UC Dolphin: radios and checkboxes

The validity property

With novalidate

[an error occurred while processing this directive] [an error occurred while processing this directive]
badInput
 Yes No ? Yes ? Yes ? Yes ? Yes No Yes - - No Yes

Two Chromia don’t allow invalid numbers to be typed in.
patternMismatch
 Yes Yes Yes Yes Yes Yes Yes
rangeOverflow
 Yes Yes Yes Yes Yes Yes Yes
rangeUnderflow
 Yes Yes Yes Yes Yes Yes Yes
stepMismatch
 Yes Yes Yes Yes Yes Yes Yes
tooLong
 Yes Yes Yes Yes Yes - Yes No Yes
note on user interaction
tooShort
 No Yes No Yes No No Yes No Yes No - No Yes
  • Safari/iOS does not support minlength so I cannot test this property.
typeMismatch
 Yes Yes Yes Yes Yes Incom­plete Yes
Op mini not email
valid
 Yes Yes Yes Yes Yes Incom­plete Yes
Op mini not email
valueMissing
 Yes Yes Yes Yes Yes Yes Yes

The events

The invalid event is supposed to fire when the user submits the form, or on checkValidity() or reportValidity().

[an error occurred while processing this directive] [an error occurred while processing this directive]
invalid
 No Yes No Yes No Yes No Yes Yes Untest­able Yes

Some browsers don’t support reportValidity(), but those that do all fire the invalid event.
valid
 No No No No No Untest­able No

It stands to reason that if we have an invalid event we should also have a valid event.

Browsers are not impressed by our attempt at reasoning. We counter by not being impressed by browsers.

Methods

[an error occurred while processing this directive] [an error occurred while processing this directive]
checkValidity()
Useless; same information is in validity.valid 		Al­most Al­most Al­most Yes Al­most Buggy Al­most Yes Al­most Al­most Al­most Al­most

Also works on forms, but not on fieldsets.

Almost: not on fieldset (well, always returns true)
  • Chromium 30 WebView always returns true.
reportValidity()
Ought to pop up a native error message 		No Al­most No Al­most No No Yes Al­most No Yes No No No Yes
Almost: not on fieldset (well, always returns true)
setCustomValidity('string')
Sets error message to string and assumes field is invalid 		Yes Yes Yes Buggy Yes Yes Yes Yes

Sets error message to string and assumes field is invalid

Empty string: reset error message and assume field is valid

No string: error. Stupid browsers.

  • Chromium 30 WebView: reportValidity() does not return false after setCustomValidity() has been used. That kind-of defeats the entire purpose.

Native error messages

[an error occurred while processing this directive] [an error occurred while processing this directive]
Basic support
 No Yes No Yes No * Yes No Yes Yes No No Yes
  • LG Chromium 30 does everything right except actually showing the error message.
novalidate
attribute on forms. Suppresses error messages 		No Yes No Yes No Yes No Yes Yes Untest­able Yes

<form novalidate> stops onsubmit native error messages and the associated focus. It does not stop native error messages from appearing with reportValidity().
Outline on invalid fields
 No No No No No No Yes

What I mean here is a permanent outline; not the temporary one that’s caused by the focus.
Appear onsubmit
 No Yes No Yes No Yes No Yes Yes No No Yes
Appear with reportValidity()
 No Yes No Yes No No Yes No Yes No No No Yes

Some browsers don’t support reportValidity().
Message disappears
... when ? 		No onscroll No onscroll No - stdChr Yes stdChr No stdChr 5s No No doesn’t
  • Safari’s error messages disappear onscroll, which is a serious problem. If you hit submit, and an error message appears and the focus moves to the faulty field, the browser automatically scrolls, which causes the error message to disappear.
  • stdchr: Standard Chrome: error message disappears after 5 seconds or if form field scrolls off the screen. And remember that due to the focus the keyboard is folded out, so the screen is far smaller than usual.
Suppress message
by returning false oninvalid 		No Yes No Yes No Yes No Yes Yes No No Yes
Set text in title attribute
pattern only 		No No - Yes No Yes Yes No No Yes
onblur validation
 No Terrible No Terrible No No Terrible No Terrible No No No No 
input.onblur = function () {
	this.reportValidity();
}
  • IE/Edge natively repeat the error message when you focus on a form field. Strictly speaking they don’t need onblur validation.
  • Firefox only shows the error message if you tab down. Tabbing up (i.e. shift+tab) doesn’t show the message.
  • In Safari the error message briefly appears and then disappears. Then the focus is re-set on the field you just attempted to leave.
  • In UC and Chrome the error message doesn’t appear even briefly, and then the focus is re-set.
  • FF: shows errors on any field you focus on. This makes the onblur script unnecessary.
setCustomValidity() changes error message
 No Yes No Yes No - Yes No Yes Yes No No Yes
  • Chromia up to 44 set the new error message and append the title attribute. This is something Chrome desktop does not do.
UC BB dolphin show title

Test pages

Tested browsers

[an error occurred while processing this directive]