88512 - (readonly) allow html radio buttons and checkboxes to be set read-only

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, enhancement)

Description

[Robin Lionheart]

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

Comment 1

[Oliver Klee]

Updating owner + qa.

Comment 2

[Kyle Lynch]

I found a dupe for this one - bug 7258

Comment 3

[Robin Lionheart]

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

Comment 4

[Madhur Bhatia]

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

Comment 5

[Robin Lionheart]

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.

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 7

[Rick DeBay]

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

Comment 8

[basic]

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

Comment 9

[Gérard Talbot]

Attachment: Self-explanatory testcase

Comment 10

[Matthias Versen [:Matti]]

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

Comment 11

[Tim Altman]

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

Comment 12

[Robin Lionheart]

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.

Comment 13

[Robin Lionheart]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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.

Comment 15

[Rick DeBay]

"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.

Comment 16

[Hixie (not reading bugmail)]

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

Comment 17

[Rick DeBay]

"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.

Comment 18

[Luis Reis]

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.

Comment 19

[Robin Lionheart]

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.

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Hixie (not reading bugmail)]

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

Comment 22

[Bill Mason]

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

Comment 23

[Robin Lionheart]

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.

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[Jon Stevens]

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

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 27

[mattias.waldau]

(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.

Comment 28

[Hixie (not reading bugmail)]

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

Comment 29

[Robin Lionheart]

(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.

Comment 30

[Vince C.]

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

Comment 31

[Daniel O'Connor]

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

Comment 32

[Robin Lionheart]

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.

Comment 33

[dan_500]

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

Comment 34

[Christophe Porteneuve]

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).

Comment 36

[eddy]

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

Comment 37

[Patrick Dark]

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)

Comment 38

[Mounir Lamouri (:mounir)]

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