Facing up to IT
Dharmesh Mistry
Subscribe to this blog
About Author
Dharmesh Mistry has supported financial services organisations with technology and management expertise for over 20 years. Dharmesh is CTO of edge IPK focusing on developing and launching an Open Presentation Platform built on a Service Oriented Architecture (SOA).
Contact Author
Email Dharmesh
Twitter Profile
Linked-in ProfileHTML5 Forms richer applications
New forms features with HTML5 will accelerate forms development and create richer experiences.
Published 08:00, 15 May 11
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?
On the whole theough 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
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?
On the whole theough 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
Print
Email
