Blogroll

Meta

Tag: form

Once in a while, the web development community reintroduces old ideas in a new way. Years ago, there was a concept called ECML (E-Commerce Markup Language) that added an HTML attribute to identify values in a FORM that could be auto-filled from a users “virtual wallet”. Sadly, while it was implemented on a variety of websites (mine included), it was not widely supported and disappeared.

The concept has been reintroduced as values in the ‘autocomplete’ attribute in HTML5. Traditionally this attribute was only used to prevent auto-filling of values, now it can identify which values it is related to for pre-fill.

The usual payment, address and demographic fields (and variations of each) are supported.

Okay, so this one’s a little old, and I just found it while looking at some of Microsoft Update’s HTML source, it appears to be relevant for MSIE6 and newer and may be responsible for some interesting styling and behaviour of form components.

A quick search for it turns up lots of discussions about other browers such as Firefox being effected if the value is not defined… as such it’s likely a good idea to define it in your pages to be sure.

An old MSDN entry reads…

When running on Windows XP, Internet Explorer 6 and the content displayed in it sports a look and feel that matches the Windows XP platform. You can opt to have your HTML content not take on the same look as the operating system for elements such as buttons and scroll bars, by adding the following META tag:<meta http-equiv="MSThemeCompatible" content="no" />

Setting this will disable theme support for the document. Some background on this, Windows XP (MSIE6) allows for the use of themes for the operating system to change the general color scheme of many elements.
As such, many HTML components (such as SELECT dropdowns, BUTTONS and INPUT fields ‘MAY’ also be effected if you don’t explicitly prevent it in your code.

There was some support for this in Mozilla Firefox builds for Windows, as such, while I’d normally recommend using a conditional comment, I’m torn in this case.

I was recently looking back at some websites I’d created years ago and realized just how much of a hastle the HTML FORM tag used to be for page layouts. This generally resulted in non-valid markup where the FORM tags themselves were improperly nested in TABLE, TR and TD tags.

Other than the obvious accessibility and semantic markup issues, there are two specific items that must be realized about the layout when working with a FORM.

A Controller servlet may perform either a forward or a redirect operation at the end of processing a request. It is important to understand the difference between these two cases, in particular with respect to browser reloads of web pages.

Forward

a forward is performed internally by the application (servlet).

the browser is completely unaware that it has taken place, so its original URL remains intact

any browser reload of the resulting page will simple repeat the original request, with the original URL

Redirect

a redirect is a two step process, where the web application instructs the browser to fetch a second URL, which differs from the original

a browser reload of the second URL will not repeat the original request, but will rather fetch the second URL

redirect is marginally slower than a forward, since it requires two browser requests, not one

objects placed in the original request scope are not available to the second request.

There are several ways to perform a Redirect, here are a few common ones:

In general, a forward should be used if the operation can be safely repeated upon a browser reload of the resulting web page; otherwise, redirect must be used. Typically, if the operation performs an edit on the datastore, then a redirect, not a forward, is required. This is simply to avoid the possibility of inadvertently duplicating an edit to the database.

More explicitly :

for SELECT operations, use a forward

for INSERT, UPDATE, or DELETE operations, use a redirect

In HTML, a <FORM> tag can either GET or POST its data. In this context, a GET corresponds to a SELECT-then-forward, and a POST corresponds to an edit-then-redirect.

It is strongly recommended that forms for the input of search criteria should use GET, while forms for editing database records should use POST.

SECURITY NOTE: When using GET, be sure to not expose sensitive data in the URL’s.

This is a browser oddity that I’ve had to code around for years. In most modern browsers (currently Mozilla Firefox 2.x and MSIE 7.0), when a FORM contains only one editable INPUT field pressing the Enter or Return key will automatically submit the form, but when there are more than one the form is not submitted. This irregularity in the single field case is responsible for several odd errors, and often results in double-submits of form data to the server.

Here’s a newer solution to the problem, the ‘magic’ is in the javascript events that we’ve added to the FORM object itself, no longer do you have to place event handlers on every INPUT field as has often been done in the past.

NOTE: not completely valid XHTML for ease of documentation and readability.