Bug 88512 (readonly)

allow html radio buttons and checkboxes to be set read-only

RESOLVED INVALID

Status

()

Core
Layout: Form Controls
--
enhancement
RESOLVED INVALID
16 years ago
3 years ago

People

(Reporter: Robin Lionheart, Unassigned)

Tracking

({html4})

Trunk
Future
html4
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [p-opera][HTML4-17.2.1][HTML4-17.12.2], URL)

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

16 years ago
Blocks: 7954, 41368
(Reporter)

Updated

16 years ago
Component: Browser-General → HTML Form Controls

Comment 1

16 years ago
Updating owner + qa.
Assignee: asa → rods
QA Contact: doronr → madhur

Comment 2

16 years ago
I found a dupe for this one - bug 7258
(Reporter)

Comment 3

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

Updated

16 years ago
Summary: readonly radio buttons and checkboxes not read-only → readonly html radio buttons and checkboxes not read-only

Comment 4

16 years ago
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
(Reporter)

Comment 5

16 years ago
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.

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Reporter)

Updated

16 years ago
Keywords: html4
*** Bug 117950 has been marked as a duplicate of this bug. ***

Comment 7

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

Comment 8

16 years ago
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
Depends on: 112716
(Reporter)

Updated

16 years ago
Whiteboard: [p-opera]
Whiteboard: [p-opera] → [p-opera][HTML4-17.2.1][HTML4-17.12.2]

Comment 9

15 years ago
Created attachment 106650 [details]
Self-explanatory testcase
*** Bug 207194 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

14 years ago
Alias: readonly

Comment 11

14 years ago
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
(Reporter)

Comment 12

14 years ago
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.
(Reporter)

Comment 13

14 years ago
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

14 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID

Comment 15

14 years ago
"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.

Comment 17

14 years ago
"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

14 years ago
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.
(Reporter)

Comment 19

14 years ago
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

14 years ago
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.)

Comment 22

14 years ago
*** Bug 238240 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 23

14 years ago
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

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

Comment 25

13 years ago
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. ***

Comment 27

13 years ago
(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
(Reporter)

Comment 29

13 years ago
(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

13 years ago
> 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

12 years ago
*** Bug 310392 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 32

12 years ago
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.
No longer blocks: 7954
Severity: normal → enhancement
Status: RESOLVED → REOPENED
OS: Windows 2000 → All
Resolution: INVALID → ---
Summary: readonly html radio buttons and checkboxes not read-only → allow html radio buttons and checkboxes to be set read-only

Comment 33

10 years ago
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).
Duplicate of this bug: 478154

Comment 36

9 years ago
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...
Assignee: rods → nobody
QA Contact: madhur → layout.form-controls

Comment 37

7 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago7 years ago
Hardware: x86 → All
Resolution: --- → INVALID

Updated

6 years ago
Duplicate of this bug: 715456
You need to log in before you can comment on or make changes to this bug.