Please Fill Out This Field
A lot of what makes a web application is its forms– the inputs you can interact with and submit. Good forms are validated: you can only put valid information into them.
An example would be your username on a website like Twitter. Much of your experience on Twitter is premised on your username– your page's URL, how others mention you, etc. Twitter would be useless without every single user always having a username, and so any form with such a field is always validated for the presence of that field.
How should web forms be validated? In the Single-Page-JavaScript (SPA's) applications that dominate the web of late, the standard answer is to write or import more JavaScript to handle those validations. What I'm using instead on my current project is a little bit punk: the native HTML attributes that ship with every browser.
Consider the required attribute. According to the HTML specification: "The required attribute is a boolean attribute. When specified, the element is required." But what does that practically mean? Each browser decides. Chrome puts a tooltip over empty text inputs that says "Please fill out this field."
Yes, it's a little ugly! I don't have easy control over what it says or how it looks, as I might with a library solution. So, why choose this approach? I have a couple of reasons. Native HTML attributes work now and will work in the future, they're investing in the kind of technological world I want to live in, and they're perfectly boring.
Native HTML attributes like required work today, and have for a long time. The last major desktop browser that didn't support required was Internet Explorer circa 2011. Globally, 96% of internet users today are using a browser that supports required. Those that aren't, probably can't run a modern JavaScript SPA anyway, making it a moot point.
Attributes like required will surely work in the future, as well. Sometimes I like to think of technological investment as a series of bets. If I had one dollar to invest in tech growth toward the future maintenance of my forms, would I choose:
- A popular OSS forms library I'm using right now?
- A paid component library my team has access to?
- A custom solution I wrote?
- Enterprise browsers like Chrome?
I'll choose #4 almost every time. Chrome, Firefox, and Safari are backed by gigantic enterprises, working toward a public global standard, with every reason in the world to implement required flawlessly for as long as they remain in business.
Using required is investing in the technological world I want to live in– voting with my wallet. I want form requirements to be easy. How easy? Typing the word "required." So I'm investing in that future by using required.
Native HTML attributes like required are boring, in the best way. Dan McKinley wrote about boring technology in his essay Choose Boring Technology. Native HTML validations are boring. They don't look amazing. They don't showcase my style or add a touch of branding to every pixel on the screen. They outsource some of the experience I provide. That's boring, and often I think that's okay.
Are there downsides to this approach? Certainly; again, it's outsourcing a little of your application's experience. To that objection, I'd argue: so do all of the form libraries I've seen, as they are used. Such libraries choose default messages and ship with CSS– how else could they look so cool?– and only the brave engineer will override the defaults. It's also harder to do very complex validations, such as showing a message when a list of sub-forms is incomplete. Many forms on the web never get that complex, but once you're there, it might be time for something fancier.
There's a reason Heroku's login page uses native HTML attributes. They work, they've been working, and they'll continue to work more reliably than anything fancier. I like to think somebody on their team thought "This is good enough for now" and never looked back as they built Heroku. We'd be well-advised to consider their path.