h1

Disabled vs Readonly Form Fields

November 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”.

It is important to note that these values do not transport directly into the JavaScript DOM. If you were setting disabled or readonly via JavaScript, you would do it like so:

myInput.disabled = true; // or false
myInput.readOnly = true; // or false

Note also that in JavaScript attributes are case sensitive and that the readonly attribute is spelled “readOnly”.

Key Differences

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.

Overcoming Shortcomings

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">
<option value="SCH">Search</option>
<option value="SRT">Sort</option>
</select>

<input type="hidden" name="type" value="SCH" />

Just remember that if you are going to use JavaScript to disable/enable the form element, that you may want to provide additional code to move the current value of the disabled field to the hidden field companion.

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.

Conclusions

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.

About these ads

5 comments

  1. Nice Tip,
    Thanks a lot :)


  2. Another important difference: I have a site where the original coder used .disabled to disable some 1000 textboxes in javascript. This took 24 minutes to run, and naturally the users complained. Plus, as the number of textboxes increased, as it always did, the time delay grew exponentially. Replacing .disabled with .readOnly reduced the time to some 5 seconds regardless of the number of textboxes.


  3. @Larry – Why not use the native HTML attribute to initially disable the 1000 fields from the start (i.e. disabled=”disabled”), then use javascript to enable them when needed?

    Therefore your page HTML should render instantly, and javascript would take no time at all to enable one field at a time rather than disable all fields at once.


  4. This is a great article, thank you. I have a question. When testing this out in both IE and FF, FF easily will search and find whatever is in the text fields boxes, whether it’s readonly or disabled text. However, IE7 and IE8 cannot find anything in text fields when using CTRL-F search. Anyone know why this is, or if there’s a work around?


  5. […] are about limiting actions that can be performed on a system. For example disabling or hiding options in a form that aren’t currently available. I’m sure you’ve encountered a form that requires […]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: