Fw: Techniques to review week of February 13 2006 - from Gez

Sent to the team C list on behalf of Gez.
Thanks,
Sofia
_________________________

Hi Michael,

On 14/02/06, Michael Cooper <michaelc@watchfire.com> wrote:
> One thing that was particularly helpful when we discussed the techniques
> in this week's call was the way Sofia and Andi put suggestions directly
> in the wiki, and responded to each others' suggestions there. It was
> much easier to keep everything in context and make decisions on the
> call, so I'd like to encourage everyone to follow that model if you can.

Apologies for not using the wiki for this response, but I completely
disagree with the proposed technique.

There are essentially three problems with the technique:

1: The markup for the technique is invalid, and the whole technique is
based around using invalid markup when it's just not necessary.
2: The technique doesn't work (it accepts 1o - the letter 'o' instead
of the digit zero, or any other characters at the end).
3: The technique mixes behaviour with the markup.

The technique could be fixed by replacing (intValue != NaN) with
(iField.value.match(/^\d+$/)), but I would like to suggest a new
technique.

The proposed technique is valid, works as expected, and designed to be
flexible so that authors can incorporate it easily into their work.
I've no idea how well it works with AT, as I don't have access to any
AT, but if there are any issues then hopefully it would be easy to
resolve and leave valid. The files are attached, but the technique is
available online [1] to save having to download and set up.

If the script is included on a page that has form elements, each form
element is assigned an onsubmit event handler. The handler iterates
through all form controls looking for validation classes (such as
string, email, number). For each class it finds, it validates the
content of the form control according to the rules of the class. To
use the script, authors just need to add a class to form controls that
need validating.

Optional fields that don't need validating wouldn't require a class.
Optional fields that require validating can have an extra class value
of optional. The only constraint is that the validation class (string,
email, number, or any other that is added), must be specified first if
there is more than one class associated with the form control, which
would be the case when an optional value is specified.

To help clarify how it works, the sample markup [1] has two forms. The
second form has two optional fields; one that requires that an email
address if valid if specified, and another that doesn't have any sort
of validation carried out on it.

There is an issue that the proposed technique uses the traditional
event model, but considering how badly user agents handle the W3C's
event model, I think it's excusable. We could provide links to current
best practice for event registration.

The files are attached. The JavaScript file has an extension of .txt
rather than .js to ensure it gets through strict email clients.

[1] http://juicystudio.com/experiments/form.html

Best regards,

Gez




--
_____________________________
Supplement your vitamins
http://juicystudio.com




--
_____________________________
Supplement your vitamins
http://juicystudio.com