Digital Web Magazine

The web professional's online magazine of choice.

Forms, usability, and the W3C DOM : Comments

By Peter-Paul Koch

May 30, 2003


Marek M

May 26, 2004 12:56 PM

Nonetheless, the advantages of this script outweigh this weakness. Besides, XHTML is, authorities assure us, eXtensible HTML. So let

Ryan Cannon

June 30, 2004 11:09 AM

Wouldn’t a simpler solution be to search through a fieldset or hand-selected group of widgets, reset their values, possibly hide them with CSS and set them disabled? This doesn’t invalidate your XHTML like adding custom attributes and placing widgets outside of a form.

Christian Fecteau

November 12, 2004 3:18 PM

You can detect IE5 on Mac with object detection:

if (!window.showModelessDialog && window.ActiveXObject && document.getElementById)

Jake Burkey

December 23, 2004 7:46 PM

Thank you for the great article. I’ve been authoring forms with conditional presentation of questions for several years, and the XHTML approach seems worth exploring. Regarding the inclusion of hidden fields in the request collection when using DHTML, I’ve used that as an opportunity to write a specific code to the fields indicating that they were not presented to the respondent. Unanswered fields have a different code written to them indicating presentation with nonresponse.


January 10, 2005 12:27 PM

Nice guide, poor comments on it though.
I personally dont give a !@#@# about it not being validated by validators cause I want to use it on a website not on a beaty pagent that has no room for inovating thoughts.


January 12, 2005 9:42 AM

Using tables for the forms isn’t the most accessible option. Extending XHTML by adding custom attributes is not what the X in XHTML standards for. That X is related to XML, and you would use differnet name spaces etc if all browsers supported that properly.

Right on that without JS this should work. It sounds like you need the full form there. Then, with JS/CSS, enhance it to hide/display relevant bits as certain questions get answered. Do that, remove table-based layout and use fieldsets etc (you can hide those too) and it will be more accessible, as well as usable.


March 23, 2005 11:02 AM

This article reflects good forward-thinking for its time. However, right on the heels of mid-2003 came the advent of widespread CSS adoption and general know-how, which leads to a much more elegant, less error-prone (and semantically useful) solution.

We can use the DOM to manipulate the display property (or visibility property, depending on need) of our form objects. (For example, setting the style attribute of an element to “display:none” makes it disappear.)

It is wholly unnecessary to physically add and remove elements simply for the sake of showing and hiding them. Not only is it messier code by several orders of magnitude (and potentially crashing a browser), we have to remember to ALWAYS do server-side validation. Always always. Otherwise, a simple home-brewed script can submit bad data to our web form and suddenly we’re inserting bad data into our database.

Since it is always necessary to validate forms on the server-side, we gain no benefit from actually removing elements from the DOM. We simply need to make them disappear. And altering the style properties is the most elegant and straightforward way to do that. Peter’s own site has great information on how to do this.

Michael Yevdokimov

June 9, 2005 2:42 AM

Hello Peter, hello guyz!

First of all thank you for sharing your article and thoughts. To be honest I have already researched all of this you were writing in this article but came up with different approach. The problem was I had to create the form consisting of around 20 steps. Each step had around 3-5 fields (all form field kinds) to fill and besides that depending on what you select ‘here’ you show something else ‘there’.

The first prototype of this was based on a switch-logic predefined in JS array. So in this prototype the form had to be a valid xhtml, although the pages of our project were built in html 4.01 format.

On some point I gave up with this approach and switched into a little bit more complex but in the same time I think more winning approach. I define the form and it’s logic in server-based XSLT + I apply my form validator which works great for both IE/Mozilla browsers (didn’t test in Opera though).

In form validator I had difficulties basically only when validating the radio-buttons. But for that I decided to put them into [span]. In the same time the fields have relationship with [label] elements. If I need to make some field to be required, I just sent the dir attribute of label into “required”. Only this thing is not really standard-compatible.


[label id=“lblrad” for=“rad”]Radio Group[/label]
[span id=“rad_group”]
[input type=“radio” name=“rad” value=“1” /]
[input type=“radio” name=“rad” value=“2” /]

Anyway. Good luck to us with our thoughts! :)))


August 2, 2005 4:49 PM

How’s it “attribute/tag soup” if they’re custom attributes, meant to work on all browsers by their implementation? Just thought I’d mention that, because it annoys me when people immediately retort in such a way. And if they don’t register with the browser, that’s it, like he said. Nothing happens; the form remains “accessible” in the most part (although I agree with the suggestion to use something other than a table as a container).

Why is it that you go on about XHTML in a lot of your off-site articles as such, though, PPK, but you don’t even use a DTD on; you profess against it? I know you somehow “prefer” to let the browser think it’s “tag soup” even though it’s usually quite semantic (ugh, I’m gonna see what happens with HTML 4.01 Strict, seems like a decent compromise to me for the time being, without going onto the “extensible” stuff… Yada-yada, I know it sounds promising, but what’s wrong with good, semantically sound HTML 4; at least until they get less bloated and experimental with the “newer” Standards? It’s 2005, yeah, but I don’t think I’ll ever use XForms, for instance…), but, well…

Sorry, comments are closed.

Media Temple

via Ad Packs