Search A2Z 24

Disabled vs Readonly Form Fields

We 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 he 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 Disable​d 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>
<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.

Example :

While disabled, none of the below will get triggered.

$("[disabled]").click( function(){ console.log("clicked") });
//No Impact
$("[disabled]").hover( function(){ console.log("hovered") });
//No Impact
$("[disabled]").dblclick( function(){ console.log("double clicked") });
//No Impact

While readonly will be triggered.

$("[readonly]").click( function(){ console.log("clicked") });
//log - clicked
$("[readonly]").hover( function(){ console.log("hovered") });
//log - hovered
$("[readonly]").dblclick( function(){ console.log("double clicked") });
//log - double clicked


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 Author

by Admin

Share your thoughts!

Login as a member to access comment posting block !! click-here

Thoughts From Other Users (0)

No Comments

Reveal Modal Goodness

This is a default modal in all its glory, but any of the styles here can easily be changed in the CSS.

This is just a simple modal with the default styles, but any type of content can live in here. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi quis sem vel enim eleifend tristique. Etiam tincidunt faucibus pharetra.