In this third part of a three-part article we will conclude our study of native form validation in browsers. Part 1 discussed general UI considerations and CSS. Part 2 studied a few HTML properties and the JavaScript API.

In this part we will consider the native error messages and offer general recommendations to come to actually usable native form validation.

As usual in my articles, I’m quite vague about exact browser compatibility patterns because I already collated that information in the inevitable compatibility table. You can find the gory details there.

Kendell Geers

The error messages

So far we have been ignoring the details of…


In this second part of a three-part article we will continue our study of native form validation in browsers. Part 1 discussed general UI considerations and CSS. Part 3 will discuss the native error messages and offer general recommendations to come to actually usable native form validation.

By Ricky Romero

In this part we’re going to take a look at a few HTML features and the JavaScript API.

As usual in my articles, I’m quite vague about exact browser compatibility patterns because I already collated that information in the inevitable compatibility table. You can find the gory details there.

HTML attributes

HTML supports many potentially…


After doing exhaustive research into modern CSS and JavaScript form validation, I present my conclusions in this series of articles. It will discuss native HTML validation messages, the CSS :invalid and :valid pseudo-classes, and the Constraint Validation API that is supposed to make form validation easier but doesn’t really.

A small snapshot showing CSS results from the compatibility table

In this article we will attempt to validate a form in a user-friendly fashion entirely by using existing native HTML, CSS, and JavaScript features, writing a few very light custom scripts to pull some supposedly-easy strings in the Constraint Validation API.

We will fail miserably. We will find that serious design…


Not this kind of viewport (public domain)

All mobile browsers have two viewports. The layout viewport constrains your CSS — width: 100% means 100% of the layout viewport — while the visual viewport describes the area of the page the user is currently seeing. This visualisation of the two viewports might be useful as a reminder.

Today’s article studies what happens when these viewports change size. It also studies the resize event.

Some viewport changes are welcomed, such as the visual viewport resize after an orientation change or a zoom action. Others are esoteric, such as rewriting the meta viewport tag. …


Everyone who’s ever messed around with dates knows that they are terribly user-hostile — not only for software developers, but also for users. True, users will be able to tell you their date of birth or today’s date without trouble, but ask them to fill them out in a web form and they will encounter problems.

Month first, day first, or year first? And what about slashes, dashes, and other separators? …

Peter-Paul Koch

Browsers all the way down. Why is there a browser on this orange?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store