You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.
The readonly attribute is a boolean attribute that controls whether or not the user can edit the form control. When specified, the element is not mutable.
On the surface, this reads like it would work on every type of form control. However, looking at the big table in https://w3c.github.io/html/sec-forms.html#the-input-element for instance (or simply when trying it out in current UAs) it's clear that readonly only controls/has an effect on a subset of input elements. It does not affect <input type="color">, <input type="checkbox">, <input type="radio">, <input type="range">, <input type="file">
Further, readonly has no effect on the mutability of <select> elements - and compared to the <input> definition, which at least shows where readonly has or hasn't got an effect, this doesn't seem to be mentioned at all in https://w3c.github.io/html/sec-forms.html#the-select-element (except for the statement "A select element that is not disabled is mutable." which implicitly means that readonly has no effect on mutability).
It would be nice/good if:
the definition for readonly was reworded so that it does NOT imply that readonly controls the editability of all form controls
a note was added to the readonly section to quite explicitly say which form controls readonly has no effect on
the definition of select stated quite clearly that readonly has no effect on this form control
The text was updated successfully, but these errors were encountered:
see also #837 (open) and #89, #91 and #92 (closed) which cover the same question.
Note that readonly affects any input type not recognised by the user agent, as a result of the design of input … and in some cases also recognised types.
@chaals thanks, reading through those other issues.
the issue i describe here is strictly about having the wording in the spec matching reality better. (incidentally, contrary to what I read in some of those other issues, <input type="range" readonly>does allow the user to change the value in Chrome/Windows). so I'd assume this part doesn't need incubation first?
fundamentally though, I'd love to see readonly act effectively like disabled (but submit its value when form is submitted)
We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.
If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.
In the definition for the
readonly
attribute https://w3c.github.io/html/sec-forms.html#element-attrdef-input-readonly it is statedOn the surface, this reads like it would work on every type of form control. However, looking at the big table in https://w3c.github.io/html/sec-forms.html#the-input-element for instance (or simply when trying it out in current UAs) it's clear that
readonly
only controls/has an effect on a subset ofinput
elements. It does not affect<input type="color">
,<input type="checkbox">
,<input type="radio">
,<input type="range">
,<input type="file">
Further,
readonly
has no effect on the mutability of<select>
elements - and compared to the<input>
definition, which at least shows wherereadonly
has or hasn't got an effect, this doesn't seem to be mentioned at all in https://w3c.github.io/html/sec-forms.html#the-select-element (except for the statement "A select element that is not disabled is mutable." which implicitly means thatreadonly
has no effect on mutability).It would be nice/good if:
readonly
was reworded so that it does NOT imply thatreadonly
controls the editability of all form controlsreadonly
section to quite explicitly say which form controlsreadonly
has no effect onselect
stated quite clearly thatreadonly
has no effect on this form controlThe text was updated successfully, but these errors were encountered: