From: tedd on
At 11:42 AM -0500 9/11/10, Tamara Temple wrote:
>The debate on client-side vs. server-side form validation is
>ongoing. Client-side is more responsive, and attempts to keep bad
>data from ever reaching your application, but relies on javascript
>being enabled. Since this is something easily turned off by users,
>one can't always rely on it to do form validation. So server-side
>validation is needed as well to allow your full application to
>gracefully degrade in the absence of working javascript on the
>client's side. Coding defensively helps!

It's not a debate.

You can provide progressive enhancement to your form to help your
users *IF* you want.

You should *always* validate all the information coming from the outside world.

The question of *if* you want to do both is your choice without any
debate. Those are only choices that you can elect to follow or not.



From: tedd on
At 1:09 PM -0400 9/11/10, Jason Pruim wrote:
>Hey tedd,
>Thanks for the response but for this particular project I'm avoiding
>using anything but standard HTML since it will be used almost
>exclusively by people using screen readers and other assistive
>technology so I'm going a little old school with it to make sure it
>all works for everyone else first.

That goes without saying.

Regardless of *if* your users use screen readers, or not, progressive
enhancement should be followed.



From: Tamara Temple on

On Sep 11, 2010, at 12:14 PM, Jason Pruim wrote:
> On Sep 11, 2010, at 12:39 PM, Tamara Temple wrote:
>> Rather than repeating all that code, I suggest the following:
> [snip]
> That's actually what I'm trying to get away from. I was hoping to do
> it all in HEREDOC syntax. I've always thought it made it cleaner.
> But that is a personal opinion :)

Well, from a maintainability aspect, the way i showed makes more sense
because if there are changes to be made (such as adding another
option), you only have to make one change, not n changes.