Disabled vs Readonly Form FieldsNovember 8, 2007
I sometimes keep forgetting the important difference between a form field input that has the disabled attribute set and the read only attribute set. From a end-user stand point, both do similar things – prohibit the user form changing values of the form element. Unfortunately, that is where a lot of the similarity ends. From a purely academic stand point, you can read how the W3c explains the two attributes. While the differences may appear minor, it can raise some serious pitfalls when programming.
Implementing the Attributes
Let me preface this comparison with the way in which these attributes should be implemented in a typical XHTML compatible file. HTML syntax allows you to set an attribute without setting a value:
<input type="text" disabled>
But in XHTML, attributes must be have a value:
<input type="text" disabled="disabled" />
As in the example above, the disabled attribute gets the value of “disabled”. The read only attribute gets the value of “readonly”.
myInput.disabled = true; // or false
myInput.readOnly = true; // or false
The Disabled attribute
- Values for disabled form elements are not passed to the processor method. The W3C calls this a successful element.(This works similar to form check boxes that are not checked.)
- Some browsers may override or provide default styling for disabled form elements. (Gray out or emboss text) Internet Explorer 5.5 is particularly nasty about this.
- Disabled form elements do not receive focus.
- Disabled form elements are skipped in tabbing navigation.
The Read Only Attribute
- Not all form elements have a readonly attribute. Most notable, the <SELECT> , <OPTION> , and <BUTTON> elements do not have readonly attributes (although thy both have disabled attributes)
- Browsers provide no default overridden visual feedback that the form element is read only. (This can be a problem… see below.)
- Form elements with the readonly attribute set will get passed to the form processor.
- Read only form elements can receive the focus
- Read only form elements are included in tabbed navigation.
Using the Disabled Attribute
If you really need the form element, and value passed to the processor and need to use the disabled attribute, try using a corresponding sister hidden form element to store the value that will be displayed:
<select name="typeDisplay" disabled="disabled">
<input type="hidden" name="type" value="SCH" />
Styling of disabled form elements can be a problem, as some browsers will simply override your styling. Thankfully most modern browsers (including IE 7) handle this well. However, this with the sometimes tricky hidden form element companion implementation guides me away from using this attribute as much as I would/should otherwise. If only there was a way to mark a disabled form element as successful, I would probably use the attribute more often.
Using the Read Only Attribute
This is the attribute I use more often as the changes I need make in order for them to function well is minimal. About the only thing I do is add a CSS class to the element so that it appears to the user as visually different from normal elements (hopefully implying that is not editable)
<input type="text" readonly="readonly" class="uneditable" />
If you turn the form element’s border from normal to a lighter version, along with accompanying text it works just fine. The fact that users can tab to the element usually has little or no impact on the user.
Unfortunately, because some elements cannot use the readonly attribute (like select boxes) You can’t always use the readonly attribute, and may have to use the disabled attribute.
The winner? The real answer is neither. There are really good reasons the smart people at the W3C implemented two distinct attributes, each with its own different behaviors. The key is to know when and how to use each of them.