eyt*
Jun 28, 2004

A Look at WebForms 2.0...

At the beginning of this month, WHATWG was created by the Mozilla and Opera organizations, and as discussed at MozillaZine, they are presently working on a few new specifications that aim to extend current functionality, instead of the W3C's pushing for something completely new.

Working with something that is backwards compatible is always better than starting something from scratch, especially since the goals of the aforementioned specifications (as stated here) is to be used on Web Applications, such as Amazon and EBay. While some of the web's users are comfortable with installing new applications, there is a large segment of users that are uncomfortable with this. In a recent discussion with a friend at work, he described to me how he was designing a web site for a friend, and decided to place a white paper in a PDF format, however, his friend quickly objected, stating that with PDF, you have to download some third party tool and it is a hassle. Creating a backwards compatible solution would be idea in light of which, albeit tricky.

The first Call For Comments of the Web Forms 2.0 specification was posted yesterday and it is very interesting. It is like making the current set of types richer, in an attempt to blur the difference between a Rich Text Application and a Web Application, such as Joel On Software's recent article talks about. There is still some work to be done to make this completely blurry, but it is going in a good direction.

For starters, the ability to have use the form attribute within a type allows two or more forms to be interlaced. This is similar to specifying the way that a form is processed via submit buttons instead of the form. The former I think will allow design to be more free, whereas the latter will result in cleaning up pages which ask for the same information for a slightly different function, such as subscribe and unsubscribe pages.

The date and time extensions to input is a welcomed extension. The javascript-based calendars that we have been using are nice, but clunky and do not always work so nicely. The required attribute will also save some javascript, and hopefully improve some of the user interfaces created when there are required fields (already the CSS3 UI extensions are nice). Likewise, the Google trick of focusing that is done via javascript will now be done via the autofocus attribute.

Some of the extensions for numbers, ranges, and patterns are also welcomed extensions, which are currently done via javascript or on the server side. Particularly, implementers could implement it via a spin-control, making the context far richer. There are more areas in what is described that could permit this, such as the ability to upload a number of files and a file filter will allow a Open Dialog box to add multiple files of an accepted file format within a directory, simplifying implementations such as Geocities' File Manager. To complete this integration, we now have the help attribute to list a URL to load for help, potentially implemented like Tooltips.

Even with these stricter input tags, the specification adds some form validation controls; in the event that some of the new attributes are not enough to prevent invalid input, the new validation methods seem to simplify some of the previous javascript that had to be written.

The output area is interesting also, since sites like Online Conversions are presently doing this via an input element, and sites like XE force you to have a button, perhaps because of this issue. The example is done via a span element, however, an output area will make its intention much clearer to HTML maintainers.

The autocomplete attribute is interesting, in that it will disable the client-side feature of storing some fields. I foresee this attribute as being ignored by browsers.

The new data attribute allows you to fill in certain types by using an external data source, such as a remote or local file. Using a remote RDF file, I can see this as being useful in some contexts.

One of the most interesting features proposed is the Repeating Form Controls, of which they have created a demo. I see this as being extremely helpful in creating web-based database entry systems, such as a database query engine or, like the example in the specification, an invoicing application. The controls that are described seem very powerful, and appear powerful enough to do even some non-form related repetition.

And to add to this, we now have the ability to submit forms as XML, which will simplify some of the CGI manipulation that must be done presently. There is also the ability to FTP, e-mail, or even SMS the form data (amongst others).

There was one control that I was expecting to see what I did not see, and that is the control for a combo box. There are many cases in development of applications where a combo box is really useful; it provides both a default answer selection and the flexibility to enter other information.

I see that the future of forms will be easier for the content developer, mainly because there is substantially less javascript, and I see the users getting a more better and more consistent user interface. I look forward to using it, except that I am bit concerned of the migration to the new platform; this will hopefully be smoother now that the Internet Explorer team is recreated. I appreciated their humour (or so I assume) of how User agents can handle authors of invalid HTML ;-).

Filed In

Navigation

eyt*