Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.


Aaron is a UI engineer from Kansas City. In addition to his full-time role at DEG, he’s the co-creator of, a testing utility for onscreen keyboards, input types and validation patterns, and Yeo+Lab, a scaffolding tool for Pattern Lab. He¹s currently obsessed with front-end performance, workflow tools and build processes. Outside of work and freelance, Aaron is a cliché Kansas City BBQ snob and brews some really bad beer.

Twitter: Follow Aaron Ladage on Twitter

Form Inputs: The Browser Support Issue You Didn’t Know You Had

The lowly form input. It’s been a part of HTML for as long as HTML has had a formal specification; but before HTML5, developers were hamstrung by its limited types and attributes. As the use of smartphones and their on-screen keyboards has flourished, however, inputs have taken on a new and incredibly important role — but they’re also riddled with browser and device inconsistencies. The eight original input types were brilliant in their simplicity. (Well, OK, maybe <input type="image"> hasn’t aged very well.)

Form Inputs: The Browser Support Issue You Didn’t Know You Had

Think about it: by inserting a single element in your markup, you can tell any web browser to render an interaction control, and you can completely modify that interaction – from a text field to a checkbox to a radio button – by simply changing a keyword. Now imagine a world where creating these interactions means also creating custom interaction controls, and you begin to realize how taken for granted inputs really are.


↑ Back to top