That's certainly true, but at the risk of getting off-topic, you'd be... living dangerously, let's say... to trust the form to check your data integrity. So you're likely going to be checking it server side anyway.

Personally, I like to see that included in forms, not for any application logic or dubious security reasons, but for the general level of ill will you'll generate by silently and ruthlessly obliterating the input from valid users. Preventing such behavior strikes me as a goal of both the presentation and business logics anyway.

Thats the trouble with html it's not always just about appearance. You know I'm sure I read somewhere that forms will be extended to include validation using xml schmas can't quite remember.

I do recognise that javascript and html validation usually creeps into templates and thus puts logic and code into them.

You can usually use file includes to extract most of the javascript out though and generate form fields server side using CGI.pm.

I know maxsize annoys me if it truncates my form input so yep you should usually tell the user on client side with javascript.

If you accept input > 25 characters, then you are providing a value which does not mesh with the database constraints... there need to be front end checks to ensure that bad data is never presented to the backend.

Exactly. Apps built with bOP only get constraint violations for non-uniqueness or exists. Other constraint violations indicate a bug in the application.

The form field meta data is used in two ways: client side validation and server side validation. We never trust what the client sends us, but we try to give as much feedback as is reasonable (without resorting to JavaScript). That's what the maxsize argument is about. You know it, so might as well encode the HTML with it.