HTML5 Forms

HTML5 extends the range of form input types providing...

... assuming that the client actually supports the input type. At the time of writing this is a BIG PROBLEM as browser sniffing for compatability is a royal pain and you need to know that your application operates sensibly on ALL clients. Until things improve these devices are to be used with extreme caution, so only when you know what the client is, such as a corporate intranet.

Various types of input allowed in forms:

If we don't declare an input type HTML5 defaults to type text. The required attribute will validate against empty fields. This attribute does not need a value but without one it will not be well formed XML which can have unwelcome consequences. The placeholder attribute can be used to provide a value that is erased on change.

<label for="userName">Please enter your user name </label>
<input name="userName" id="userName" required="required" placeholder="yourUserName"/>

The pattern attribute permits any regular expression validation. This one requires the user ID to be in the form 000123456. The required attribute is included to suppress empty strings, although this could be built into the regular expression.

<label for="userID">Please enter your ID </label>
<input pattern="000[0-9]{6}" name="userID" id="userID" required="required"/>

The input type email will check for a valid email string and save you the trouble of remembering where you left your handy regular expression for emails /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$.. Again the required attribute will validate against empty fields.

<label for="userEmail">What is your email address? </label>
<input type="email" size="30" name="userEmail" id="userEmail" required="required"/>

The input type url will check for a valid URL string and save you the trouble of remembering where you left your handy regular expression for URLs /^(http(?:s)?\:\/\/[a-zA-Z0-9\-]+(?:\.[a-zA-Z0-9\-]+)*\.[a-zA-Z]{2,6}(?:\/?|(?:\/[\w\-]+)*)(?:\/?|\/\w+\.[a-zA-Z]{2,4}(?:\?[\w]+\=[\w\-]+)?)?(?:\&[\w]+\=[\w\-]+)*)$/. OK, so maybe this RegEx is actually a bit of a handfull.

<label for="userEmail">What is your website URL? </label>
<input type="url" size="60" name="userWeb" id="userWeb"/>

The input type number provides some useful validation.

<label for="shoes">How many shoes do you need to take on your holiday?  </label>
<input type="number" name="shoes" id="shoes" value="4" step="2" min="2" max="10"/>

The input type range seems to be the same as type number.

<label for="socks">How many socks do you need to take on your holiday?  </label>
<input type="number" name="socks" id="socks" value="12" step="2" min="2" max="24"/>

By way of contrast, input type tel provides completely useless validation.

<label for="userTel">What is your 'phone number? </label>
<input type="tel" name="userTel" id="userTel"/>

If anyone can explain why input type search exists they win the cigar.

<label for="userSearch">What do you want to look for? </label>
<input type="search" name="userSearch" id="userSearch"/>

An input type color (sic) spawns a colour selector.

<label for="mycolor">What is your favourite colour? </label>
<input type="color" name="mycolor" id="mycolor" value="#33FF99"/>

Calendars are notoriously difficult to write using JavaScript. Not that one would ever write one when they can be sourced from FOC. This widget does not appear to permit assigning a value. The format of the value may vary on different clients, e.g. when in America.

<label for="birthday">When is your birthday? </label>
<input type="date" name="birthday" id="birthday" />

Even a time input widget can be a challenge to write using JavaScript. Again this widget does not appear to permit assigning a value. The format will vary on different clients, e.g. 12 or 24 hour clock.

<label for="appointment">When is your appointment? </label>
<input type="date" name="appointment" id="appointment" placeholder="hrs:mins"/>

Dates and times are notoriously difficult in any software application, usually requiring a timezone to be included to avoid nasty problems.

<label for="departure">When is your flight? </label>
<input type="datetime" name="departure" id="departure" />

If you know the application is timezone independant the simpler local date time may be appropriate.

<label for="meeting">When is the meeting? </label>
<input type="datetime-local" name="meeting" id="meeting" />

Dates and times are notoriously difficult in any software application.

<label for="departure">When is your flight? </label>
<input type="datetime" name="departure" id="departure" />

Datalist extends the option select menu idea. Note how the datalist is separate from the input which has no type but a list attribute. Difficult to resist slapping whover came up with this syntax.

<input list="cheesy" name="peas">
<datalist id="cheesy">
  <option value="Cheddar">
  <option value="Stilton">
  <option value="Wensleydale">
  <option value="Caerphilly">
</datalist>

Button:

Input type submit buttons becomes a <button> element

<button type="button" onclick="alert('fuba')">Eat my shorts!</button>

Significant Conclusions

We already knew that HTML5 was basically a bad idea thrown together by people who really should know better. The sort of people who appear to think that they are too cool for school and that JavaScript is too difficult for web developers, the sort of people who have little understanding of computer science and have never heard of Alan Turing let alone Turing completeness, the sort of people who simply do not understand, let alone appreciate the beauty and the power of simplicity. The more closely we look at HTML5 forms the more we realise that it is a mess, a minefield and should be approached with caution.


 
k.mcmanus@gre.ac.uk 2015
Valid HTML 5!. Valid CSS. WCAG priority 1 approved