HTML5 Forms richer applications


In the early days of the internet data capture forms weren’t the most exciting area of web. Initially every click meant a pause for pages to refresh. Then as Java-script evolved some client side processing meant fewer click-wait-page-refresh cycles. However the real transformation came about with Ajax (enabled by XMLHttpRequest) and suddenly pages felt much more dynamic and responsive (although in the background our broadband speeds were also improving). This innovation certainly was one of the cornerstones of the web 2.0 era.

Developers have got used to using libraries or writing their own code for client side processing to validate data entry, create rich client behaviour like hiding/showing form sections and incorporating more than the basic set of input controls (such as sliders, accordions, google-suggest lists etc.).

However in the background the WHATWG were creating the next upgrade of forms processing capability into HTML5. The new specification continues to push for better user experiences with more client side processing without plug-ins and libraries, and instead facilitated by the browser following open standards.

A number of new input types have been introduced such: tel, url, email, number, color, datetime, search, range. These not only come within inbuilt validation, but also allow browsers to present additional functionality for example: tel would allow mobile browsers to present an onscreen keyboard specific to number entry, color would allow the browser to present a color picker and a range input could be displayed as a slider.

There are lots of new attributes and some of these will especially make developers lives easier when creating richer forms applications. For example:

  • The placeholder attribute allows sample/help text to be displayed in an edit field (typically text is greyed out) – thus assisting users with the kind of response required in the field without navigating to help.
  • The autofocus attribute can be used to set the field in focus.
  • autocomplete attribute aids security of the form data bu allowing you to control which form data elements may be cached by the browser, and which explicitly cannot be.
  • Masked input field can be created using the pattern attribute allowing rich formatting and validation of data into edit fields e.g. <input type=”text name = “Card number”  pattern =”[0-9]{16}]” for a credit card number field.
  • datalist attribute allows for data entry of specific values only, as specified in the list
  • min/max attributes set validation of values in numeric fields
  • For range fields, the step attribute
  • The required attribute tells the forms the field is mandatory for completion

The specification also introduces client side validation status’s. It is possible to check the forms entire status as to whether all fields are valid or not, or too check the validity of individual fields. The standard defines 8 types of validation status’s:

  • · valueMissing Validates “required” fields
  • · typeMismatch e.g. Entering char’s in number
  • · patternMismatch e.g. Email address format incorrect
  • · tooLong i.e. Value exceeds maxLength
  • · rangeUnderflow i.e. Value exceeds minimum set
  • · rangeOverflow i.e. Value exceeds maximum set
  • · stepMismatch value conforms to min/max/step
  • · customError For business logic validation errors

The standard also allows for developers to define which individual fields should be validated (willValidate), when to execute validation (checkValidity), query/set the local error message (validation Message) and switch off form validation (formNoValidate).

There are many other features in the specification that will also make forms more dynamic and performant whilst making developers tasks much simpler. For many business applications client side forms development just become easier, however to mitigate security issues there will still always be the need for server side checks also. I also wonder what over-zealous marketing departments that like to define customer experiences down to the last pixel will think of the browser taking responsibility for how it will display certain field types?

I believe the enhancements for forms with a drive to client side processing (including my soap box topic of client side session management) all make for a dynamic and richer user experience that will be welcomed by all.

http://www.w3.org/TR/2011/WD-html5-20110113/forms.html#forms

In the early days of the internet data capture forms weren’t the most exciting area of web. Initially every click meant a pause for pages to refresh. Then as Java-script evolved some client side processing meant fewer click-wait-page-refresh cycles. However the real transformation came about with Ajax (enabled by XMLHttpRequest) and suddenly pages felt much more dynamic and responsive (although in the background our broadband speeds were also improving). This innovation certainly was one of the cornerstones of the web 2.0 era.
Developers have got used to using libraries or writing their own code for client side processing to validate data entry, create rich client behaviour like hiding/showing form sections and incorporating more than the basic set of input controls (such as sliders, accordions, google-suggest lists etc.).
However in the background the WHATWG were creating the next upgrade of forms processing capability into HTML5. The new specification continues to push for better user experiences with more client side processing without plug-ins and libraries, and instead facilitated by the browser following open standards.
A number of new input types have been introduced such: tel, url, email, number, color, datetime, search, range. These not only come within inbuilt validation, but also allow browsers to present additional functionality for example: tel would allow mobile browsers to present an onscreen keyboard specific to number entry, color would allow the browser to present a color picker and a range input could be displayed as a slider.
There are lots of new attributes and some of these will especially make developers lives easier when creating richer forms applications. For example:
•    The placeholder attribute allows sample/help text to be displayed in an edit field (typically text is greyed out) – thus assisting users with the kind of response required in the field without navigating to help.
•    The autofocus attribute can be used to set the field in focus.
•    autocomplete attribute aids security of the form data bu allowing you to control which form data elements may be cached by the browser, and which explicitly cannot be.
•    Masked input field can be created using the pattern attribute allowing rich formatting and validation of data into edit fields e.g. <input type=”text name = “Card number”  pattern =”[0-9]{16}]” for a credit card number field.
•    datalist attribute allows for data entry of specific values only, as specified in the list
•    min/max attributes set validation of values in numeric fields
•    For range fields, the step attribute
•    The required attribute tells the forms the field is mandatory for completion
The specification also introduces client side validation status’s. It is possible to check the forms entire status as to whether all fields are valid or not, or too check the validity of individual fields. The standard defines 8 types of validation status’s:
•    valueMissing        Validates “required” fields
•    typeMismatch        e.g. Entering char’s in number
•    patternMismatch        e.g. Email address format incorrect
•    tooLong            i.e. Value exceeds maxLength
•    rangeUnderflow        i.e. Value exceeds minimum set
•    rangeOverflow        i.e. Value exceeds maximum set
•    stepMismatch        value conforms to min/max/step
•    customError        For business logic validation errors
The standard also allows for developers to define which individual fields should be validated (willValidate), when to execute validation (checkValidity), query/set the local error message (validation Message) and switch off form validation (formNoValidate).
There are many other features in the specification that will also make forms more dynamic and performant whilst making developers tasks much simpler. For many business applications client side forms development just become easier, however to mitigate security issues there will still always be the need for server side checks also. I also wonder what over-zealous marketing departments that like to define customer experiences down to the last pixel will think of the browser taking responsibility for how it will display certain field types?
I believe the enhancements for forms with a drive to client side processing (including my soap box topic of client side session management) all make for a dynamic and richer user experience that will be welcomed by all.
http://www.w3.org/TR/2011/WD-html5-20110113/forms.html#forms
Advertisements

2 Responses to “HTML5 Forms richer applications”

  1. https://cicerone.org/ Says:

    Hello! This is my first visit to your blog! We are a team of volunteers and starting a new project in a community in the
    same niche. Your blog provided us useful information to work on.
    You have done a marvellous job!

  2. restaurant pest control Procedure Says:

    Heya are using WordPress for your site platform? I’m new to the blog world but I’m trying to get started and set up my own.

    Do you require any coding expertise to make your own blog?
    Any help would be really appreciated!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: