HTML5 adds more form field types. There are a number of places where we could potentially use them. The main benefits are improved semantics: Many browsers perform their own validation on these fields already (which will reduce the amount of invalid stuff which ever reaches our own server-side code) and mobile devices in particular already adjust the keyboard.

We would presumably need to check in a variety of browsers/OSes for unexpected side-effects and make sure that if we're using things like input[type=text] in CSS that those places are updated.

Things that come to mind, with the observations I've made so far (desktop browsers refer to versions in OSX):

type="email" could be used for email addresses when signing up and editing your profile.

• validated by Opera 12, Firefox 24 and Chrome 34 (not Safari 5)
• Android devices appear to adjust the keyboard to provide @ by default
• no visible changes to the field

type="url" could be used for URL fields when editing entities, the website field when editing your profile and the URL lookup field on https://beta.musicbrainz.org/search

• validated by Opera 12, Firefox 24 and Chrome 34 (not Safari 5)
• Android devices appear to adjust the keyboard to provide / by default
• no visible to changes to the field

type="number" could be used when adding tracks in the release editor and for the number of yes/no votes in the edit search.

• validated by Chrome 34, various behaviours in other browsers (if I enter a letter instead: Firefox 24 treats it like text, Opera 12 submits a blank value, Safari 5 submits the original value)
• Android devices appear to adjust the keyboard to provide the number layout by default
• Opera 12, Safari 5 and Chrome 34 turn it into a spinbox (making it so you can just click up/down to increase/decrease the number, instead of having to backspace and retype).

type="search" could be used for the search input fields, although I'm not too sure about that one because our searches are actually composed of multiple fields and it could interfere with our autocompletes.

• Safari 5 and Chrome 34 add an "x" button to clear the field
• Opera 12, Safari 5 and Chrome 34 display the field with big ugly rounded corners

type="date" - we have a number of date fields (begin/end dates for entities and relationships, release dates, birthdays when editing your profile, but it would probably conflict with any implementation of MBS-1197.

• Opera 12 shows a select box which opens a date picker. It does not allow typing at all.
• Firefox 24 treats it as type=text with no special behaviour.
• Safari 5 displays a spinbox which is empty by default, pressing down inserts yesterday's date in the form yyyy-mm-dd, pressing up inserts tomorrow's date in the same form. It allows entering any text, allows pasting and does not have a date picker.
• Chrome 34 displays "tt.mm.jjjj" (localised version of "dd/mm/yyyy"), a spinbox and a button to open a date picker. It lets me type numbers but does not allow pasting.

As far as I can tell, there would be no downsides to using "email", "url" and "number" in the places I mentioned. "date" seems like a bad idea because there are widely varying implementations, some of which break basic things like typing and pasting. "search" might work but could potentially cause problems and doesn't appear to offer much in the way of improvements, so I would lean towards not using that.