I’ve just come across these for the first time…
But I can’t think of a reason to use them… ?
Why would I want to disable a form field… the point of having a form is that users fill it in and then submit it…
Does anybody have any examples of how they have used these attributes on a site?
Fields can be disabled depending on conditions in the form. When the user changes a condition the field can be enabled, either via JavaScript or via a round-trip to the server.
For instance, you could have a range of radio buttons for various options, where the last one is ‘other’. Then you could have a text field where the user could enter supplemental information, and this field could be disabled unless the user has selected the ‘other’ button.
Readonly fields are useful for presenting information that shouldn’t be editable by the user, yet should be part of the form submission. For instance, a user ID field.
[ot]
like “I agree to nothing, you owe me your soul”, etc.
Wow, awesome! How come I never think to do stuff like that? : ( [/ot]
You may want to “disable” with ‘disabled’ for a form’s submit button until the user has entered some required data to stop undesirable or irrelevant submissions. Disabled elements are “read-only” elements with the added restrictions that the values are not submitted with the form, the elements cannot receive focus, and the elements are skipped when navigating the document by tabbing.
Setting the ‘readonly’ attribute allows authors to display unmodifiable text in a TEXTAREA. This differs from using standard marked-up text in a document because the value of TEXTAREA is submitted with the form, i.e. ‘readonly’ stops the user modifying the value. You may want to do that with a password text, etc.
I am not familiar with an attribute called ‘enabled’ that is NOT an attribute option in plain HTML 4.01. 
Thanks for the responses.
Actually there isn’t an enabled attribute. In CSS3 this is just for non-disabled fields
I routinely use readonly on textareas where users need to read some terms and conditions (there’s also always another page called terms and conditions where people can punish themselves with reading as well). It’s a sort of imitation of the things you agree to before installing some software etc with “check if you’re read this” or radio buttons “I agree, I disagree”.
one reason maybe would be to force users to pick some defined value rather than staying at the default (of course some other form control would be a better choice then).
It should perhaps be mentioned that this practice only works if JavaScript is enabled and that the submit button should initially be enabled. You could then start by disabling the button with JavaScript and then re-enable it once all required fields are filled in etc. Doing it any other way will cause accessibility issues.
That’s one use for them, although a scrolled <div> or suchlike is equally useful. Unless you actually require that the T&C text be submitted with the form, of course.
Using the readonly attribute to make sure that the contents of a textarea is submitted in an unaltered state is dangerous. It would be very easy to alter the contents of the textarea, and then submit the altered version. At least in some countries, this could technically be considered legally binding if the webstore does not react to the altered contract (i.e. a counter-offer). Therefore, the readonly textarea’s contents should be checked server-side.
Luckily, it doesn’t seem to matter to the company if the textarea is submitted.
And, no scrolling divs I think simply because I’d want to keep it a form control in a form (since the terms&conditions are in the middle of a form… yeah also not so smart but that’s the way it is). Though I don’t remember if readonly was an issue in JAWS, since while I can get focus in there in FF there might have been a browser who didn’t allow the focus?? If so then JAWS wouldn’t be able to read it. Hm…
Yes, I’ve fiddled with “terms and conditions” text-areas and submitted them before on online forms that weren’t read-only putting things stupid; like “I agree to nothing, you owe me your soul”, etc. It’s hard to believe many sites still don’t stop the user editing them, or double-check, etc.
[ot]
Probably because you are more sane. ;)[/ot]
But you can see the problems caused by not thinking it through.
But you can see the problems caused by not thinking it through.
I can see Christian’s point, for when it matters (as far as I know, the only truly legally binding stuff we have when someone signs up for insurance online is the stuff they get on paper in the mail later).
Is there some other possible issue as well?
If the textarea is only submitted, but not stored, I don’t see any other issues. If it’s stored in the database, however, it will have to be sanitized as well, as it could otherwise be used for SQL injections.
Your changing it makes no difference really since the submission page on their site still says the same as it said before your change and that says that by submitting the page you agree to that condition. You clicked the link so you agreed to that condition rather than what you changed it to read. To prove you clicked the link all they need do is to show you had accessed where ever the link goes. What the page said with your modification is irrelevant since that isn’t what their page says you have to agree to. So you’ll probably find that although you said “I agree to nothing, you owe me your soul” that the reverse is what you actually agreed to by clicking the link in the first place.