If readonly is set on <input> with type="radio" or type="checkbox", the controls can still be checked on and off.

Updating owner + qa.

I found a dupe for this one - bug 7258

That's a XUL issue, this is an HTML issue.

According to the w3c specifications, the readonly attribute is applicable to only <input> text and password controls. see -- http://www.w3.org/TR/html4/interact/forms.html#edef-INPUT this attribute does not apply to any other input controls. I consider this bug to be invalid. It behaves the same way in IE

No, the specification does not say readonly only applies to INPUT elements with certain values of type. It merely states "The following elements support the readonly attribute: INPUT and TEXTAREA." The DTD for INPUT does contain these comments: value CDATA #IMPLIED -- Specify for radio buttons and checkboxes -- checked (checked) #IMPLIED -- for radio buttons and check boxes -- disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED -- for text and passwd -- However, stating that 'value' is "for" radio buttons and checkboxes does not mean it does not apply to text and password input fields - as this bugzilla page demonstrates. Conversely, 'readonly' being "for" text and password inputs doesn't necessarily mean it doesn't apply to radio buttons and checkboxes. I see no normative statement in the standard making such a limitation.

*** Bug 117950 has been marked as a duplicate of this bug. ***

This bug has been sitting around for six months, for what looks to be a simple fix.

is the issue here only checkboxes and radiobuttons? The checkbox part can be fixed when the patch on bug 12164 is reviewed/checkin and when bug 112716 is fixed. Making this depend on bug 112716

*** Bug 207194 has been marked as a duplicate of this bug. ***

What's the status of this bug? And are we even sure it is a bug? While I see Robin's point about the HTML 4.01 spec. limiting readonly to text and password, the DOM 2 HTML spec.[1] seems to clear up the HTML spec's ambiguity: HTMLInputElement readOnly of type boolean This control is read-only. Relevant only when type has the value "text" or "password". See the readonly attribute definition in HTML 4.01. IE 6SP1 and Opera 7.11 for Windows seem to have the same behavior is Mozilla 1.4b. [1] http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-88461592

Until you brought that up, I had no reason to think the W3C intended to limit 'readonly' or 'disabled' to only certain types of <input>. It was just that major browsers implement 'disabled' completely and 'readonly' incompletely. But the DOM groups statement gives me pause. OK, sure readonly is irrelevant for submit, reset, hidden, image, and button. But why would they want to limit its applicability to checkbox, radio, and file? I wonder if this isn't an oversight in the DTD comments that got amplified in the DOM spec.

For what it's worth, Opera 5.x does make readonly checkboxes and radio buttons readonly, though Opera 7.x does not have this functionality.

The basic difference between disabled and readonly for text inputs is that you cannot access a disabled input in any way whatsoever. For a readonly input, you cannot change the value, but you can, for example, highlight the value and copy it, then paste it elsewhere.... Since there is no equivalent operation for checkboxes and radio buttons, there is no reason to have readonly do anything in particular to them -- if you mean "disable this", that's what the "disabled" attribute is for. Marking invalid, since what we do fits what the spec specifies and this is implemented interoperably across all major browser engines.

"The basic difference between disabled and readonly for text inputs is that you cannot access a disabled input in any way whatsoever." Actually, the basic difference is that disabled inputs won't be submitted with the form ("Disabled controls cannot be successful" http://www.w3.org/TR/html4/interact/forms.html#adef-disabled). If I present a form to a user, some items may be marked readonly if they don't have permission to change them, yet I want the values to be displayed and submitted when the form is submitted. I second Robin's theory that the DOM spec came from a cut-and-paste from the HTML spec. Can anyone state why readonly is a bad thing? It certainly makes forms simpler if some value can't be changed, but needs to be displayed and submitted.

> If I present a form to a user, some items may be marked readonly if they don't > have permission to change them, yet I want the values to be displayed and > submitted when the form is submitted. The user can always change the DOM on the fly and resubmit the form with those radio buttons changed. So that's not something to rely on anyway.

"The user can always change the DOM on the fly and resubmit the form with those radio buttons changed. So that's not something to rely on anyway." Yes, and they can also create a malformed GET/POST to submit bad data, etc. That's what server-side validation is for. Irregardless of what happens occasionally, supporting readonly for elements that can be submitted makes sense in the 99.99% of cases where the non-error path is taken.

I don't usually use readonly checkboxes for restricting user input, anyway, you shouldn't rely only on HTML/Javascript to restrict user actions. Sometimes, when I need to show a list with enabled/disabled, on/off or true/false items, readonly checkboxes are very usefull because they have the same UI as everything on the browser, and have a very simple implementation: no need for someone to draw on/off/whatever images, just plain html. Even if this bug isn't critical, I think it isn't invalid, because it relates to a very clear part of the HTML specification. WORKSFORME or LATER sound better as resolutions than this INVALID. Please reconsider the reopening this bug.

I also disagree with an INVALID resolution. INVALID's has no grounding in the HTML specification, and its basis in the DOM2 specification is debatable. The use of 'relevant' in the DOM2 statement 'Relevant only when type has the value "text" or "password".' suggests to me that they overlooked checkboxes and radio buttons, where the relevance of readonly is obvious. If a restriction were intended, you would see a strongly worded statement like that of the HTML 4.0 description of 'checked': When the type attribute has the value "radio" or "checkbox", this boolean attribute specifies that the button is on. User agents must ignore this attribute for other control types. In my opinion, this statement should be taken as (mis)informative, not normative. However, I have posted to the W3C's www-dom (http://lists.w3.org/Archives/Public/www-dom/) and www-html (http://lists.w3.org/Archives/Public/www-html/) mailing lists requesting a clarification of this issue.

If the HTML working group clarifies this in a useful manner, please feel free to reopen...

Robin: Was there any further comment from the working groups? (If so, please drop me an e-mail.)

*** Bug 238240 has been marked as a duplicate of this bug. ***

In reply to comment #21: So far, no official response to either of my two queries each on www-html and www-dom. Jukka pointed out the lack of a readonly attribute on <select>, though what that may imply is a moot question. Perhaps the HTML group didn't consider all possible uses of readonly when they added it.

*** Bug 254384 has been marked as a duplicate of this bug. ***

I think this bug should be resolved with the W3C. There is a strong case for readonly on a checkbox. Heck, just the amount of duplicate bugs and confusion clearly shows that it should be implemented for checkboxes. It just makes no sense to just have a checkbox which can only be disabled...even if the UI behavior is the same, the symantic nature of disabled vs. readonly makes sense in the case of a checkbox. jon

*** Bug 259969 has been marked as a duplicate of this bug. ***

(In reply to comment #26) > *** Bug 259969 has been marked as a duplicate of this bug. *** Sorry for not finding the original bug report. I reported this bug since readonly checkboxes are very useful if you want to present the form to the user as it looked when submit was pressed. The HTML 4.01 is very clear saying that readonly should apply to checkboxes and radio buttons: "The following elements support the readonly attribute: INPUT and TEXTAREA." (Yes, we need reaonly select too but that is not part of HTML 4.01). Saying that IE doesn't implement it isn't a good reason for not implementing it. Especially since an earlier bug I reported was disgarded with the argument that "We do not care about IE, we only care about the HTML-specification". That report was about the nice feature of IE of not stopping at form element if tabindex is negative.

See http://whatwg.org/specs/web-forms/current-work/#readonly

(In reply to comment #28) > See http://whatwg.org/specs/web-forms/current-work/#readonly In this Web Forms 2.0 working draft (as of 1 September 2004), section 2.5 (Extensions to existing attributes) begins: > In addition to the new attributes given in this section, some existing > attributes from [HTML4] are clarified and extended below. Hixie links to the part of this section about readonly: > readonly > This attribute applies only to text, password, email, uri, date-related, > time-related, and numeric input types, as well as the textarea element. > Specifically, it does not apply to radio buttons, check boxes, file upload > fields, select elements, or any of the button types; the interface concept of > "readonly" values does not apply to button-like interfaces. (The DOM readonly > attribute ([DOM2HTML]) obviously applies to the same set of types as the HTML > attribute.) This specific clarification from WHATWG is just what I've asked the HTML Group for for a year now. While I could cite counterexamples in software to WHATWG's rationale that the "interface concept" of read-only does not apply to "button-like" interfaces like checkboxes, that'd argue the merits of the spec, not the meaning of the spec. I'm persuaded that INVALID is the correct resolution.

> I'm persuaded that INVALID is the correct resolution. I don't, like many others. It makes sense to mark checkboxes/radio buttons read-only. It makes sense to anyone. So enforcing WebForms standards by making readOnly unapplicable to such controls is just nonsense. For instance, if we use the keyboard against a checkbox we can change its value (i.e. the value that will be submitted with the form). Rather than sticking to the spec to the letter it would have been logical to *extend* the meaning of readonly to checkboxes and radio buttons in the specs. Just because anyone has a common understanding of what a readonly checkbox or radio button is. Setting such controls readonly in other programming languages has the same effect as what we've been explaining here. With no overhead at all. The current state of the specs make it impossible to provide a checkbox (or radio button) which doesn't change but still submit its value. Granted, a workaround could be to display a checkbox (or radio button) that is disabled *and* a hidden control which value is the one of the disabled control. But this is only a workaround. Being just a workaround denotes there is a need behind it.

*** Bug 310392 has been marked as a duplicate of this bug. ***

30> Rather than sticking to the spec to the letter it would have been logical to 30> *extend* the meaning of readonly to checkboxes and radio buttons in the specs. In which case this should've been not a bug report, but an *enhancement* request. Reopening as RFE, adjusting summary and severity and dropping it as a HTML4 compliance blocker.

A radio-element is ALWAYS readonly: you cant edit the value.

Dan_500: you can't edit the value, but you can edit whether this value will be passed to the server-side (successful control) or not, which amounts to the same from a functional perspective. Disabling the control won't cut it, as it automatically makes it unsuccessful. In short, we have no way of preventing a checkbox from being unchecked while still displaying it for informational purposes (think "mandatory option in such and such situation" for instance).

A disabled checkbox is rendered dimmed and not very readable - it is not easy to see is it checked or not. This would not be the case with a readonly one...

Should this bug be marked WONTFIX? This behavior is forbidden in both HTML 4.01 [1] and HTML5 [2]. HTML 4.01 states that the |readonly| attribute of |input| elements is "for text and passwd" whereas HTML5 states that "the following content attributes must not be specified and do not apply to the element: [...] readonly, [...]." [1] http://www.w3.org/TR/html401/index/attributes.html#h-3 [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#checkbox-state (2010 April 16 Working Draft)

Indeed, @readonly has to be ignored for checkboxes and radios (per HTML5 specifications). This bug is not valid.