This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The version of the specs as of 2011-05-25 say that the "readonly" attribute is not allowed on any input type that can store state, i.e. the input types: color,range,checkbox,radio as well as the I would like to recommend that a readonly attribute be allowed on those types for consistency, backwards compatibility and accessibility reasons. HTML 4 and 5 offer both a disabled and a readonly attribute. The HTML4 specs did not limit the use of the attribute to only text/number types as does the HTML5 spec. In practice, disabled vs. readonly have two significances, both of which apply in some measure to these new datatypes for structured values such as colors, ranges, and dates. (a) functionally, disable shuts down the control entirely, preventing all access and submission (the "successfulness" of the control) whereas readonly allows tabbing to, submission and scrolling if some portion of the content is hidden. This allows the user to recover from design faults and accessibility limitations. For example, the designer's CSS made the field too narrow to display the entire value or accessibility software made the font size too large to show the entire value. Such issues can arise on ANY field that potentially displays textual data, not just fields that by design may show only a portion of their data (e.g. textareas or any input type with size/maxlength ). Presumably this is why numbers and dates DO have a readonly attribute? Checkboxes, radio buttons, color values, and ranges can all present data that needs to be stored server side and needs to accompany a submitted form, even when the data in that form is in read only mode (for example, because the user doesn't have enough rights to edit the data). If the only way to turn off editing of certain sensitive values is to disable the field, then one has to create a hidden non-disabled field to store the data that still needs to be submitted from the readonly field. Secondly, we can't assume that color values will always be immune to the same data visibility issues that affect textual data. Although a color can be represented by a color swatch and a color swatch is visible even in a very small field, For example, a color blind person may not be able to read values expressed as color swatches but might have an analytical understanding of color that makes RGB values meaningful. A standards compliant browser ought to be able to display colors in either visual or textual form (perhaps based on user preferences?). Similarly, ranges can have a visual representation, but they can also have a textual representation (5000-10000) which would have the same issues of needed to access the field and cursor through it to see the entire value if the display area for the value is too small. (b) visually disable usually grays out or "fuzzes" a field whereas readonly simply shades it to indicate that the value can't be edited. This helps users know the difference between information they need to pay attention to (even if they can't change it) and information that they can ignore as irrelevant. Although the semantic distinction between "can't edit right now" vs. "not applicable" isn't in the specification it is common out in the wild and making it possible to apply have the browser apply it simplifies user interface implementation. Sources: http://www.w3.org/TR/html4/interact/forms.html#adef-readonly http://www.w3.org/TR/html5/number-state.html (see sections on color state, etc that state readonly is prohibited on color,range,checkbox,radio)
(In reply to comment #0) > The version of the specs as of 2011-05-25 say that the "readonly" attribute is > not allowed on any input type that can store state, i.e. the input types: > color,range,checkbox,radio as well as the Correction to the above paragraph! The version of the specs as of 2011-05-25 say that the "readonly" attribute is not allowed on color,range,checkbox,radio. > > I would like to recommend that a readonly attribute be allowed on those types > for consistency, backwards compatibility and accessibility reasons. > > HTML 4 and 5 offer both a disabled and a readonly attribute. The HTML4 > specs did not limit the use of the attribute to only text/number types > as does the HTML5 spec. > > In practice, disabled vs. readonly have two significances, both of which > apply in some measure to these new datatypes for structured values such > as colors, ranges, and dates. > > (a) functionally, disable shuts down the control entirely, preventing > all access and submission (the "successfulness" of the control) whereas > readonly allows tabbing to, submission and scrolling if some portion > of the content is hidden. > > This allows the user to recover from design faults and accessibility > limitations. For example, the designer's CSS made the field too narrow to > display the entire value or accessibility software made the font size > too large to show the entire value. Such issues can arise on ANY field > that potentially displays textual data, not just fields that by design > may show only a portion of their data (e.g. textareas or any input type > with size/maxlength ). Presumably this is why numbers and dates DO > have a readonly attribute? > > Checkboxes, radio buttons, color values, and ranges can all present > data that needs to be stored server side and needs to accompany a submitted > form, even when the data in that form is in read only mode (for example, > because the user doesn't have enough rights to edit the data). If the > only way to turn off editing of certain sensitive values is to disable > the field, then one has to create a hidden non-disabled field to > store the data that still needs to be submitted from the readonly field. > > Secondly, we can't assume that color values will always be immune to > the same data visibility issues that affect textual data. Although a > color can be represented by a color swatch and a color swatch is visible > even in a very small field, For example, a color blind person may not > be able to read values expressed as color swatches but might have an > analytical understanding of color that makes RGB values meaningful. A > standards compliant browser ought to be able to display colors in > either visual or textual form (perhaps based on user preferences?). > > Similarly, ranges can have a visual representation, but they can > also have a textual representation (5000-10000) which would have the same > issues of needed to access the field and cursor through it to see > the entire value if the display area for the value is too small. > > > (b) visually disable usually grays out or "fuzzes" a field whereas > readonly simply shades it to indicate that the value can't be edited. > This helps users know the difference between information they need to > pay attention to (even if they can't change it) and information that > they can ignore as irrelevant. Although the semantic distinction > between "can't edit right now" vs. "not applicable" isn't in > the specification it is common out in the wild and making it possible > to apply have the browser apply it simplifies user interface > implementation. > > Sources: > http://www.w3.org/TR/html4/interact/forms.html#adef-readonly > http://www.w3.org/TR/html5/number-state.html (see sections on color state, etc > that state readonly is prohibited on color,range,checkbox,radio)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: > The HTML4 > specs did not limit the use of the attribute to only text/number types The HTML4 spec isn't particularly relevant here. Implementations have historically limited the readonly attribute in this way. They do this because there's no UI concept that corresponds to a "readonly" radio button, checkbox, button, etc. It's a concept that only applies to text fields. > (a) functionally, disable shuts down the control entirely, preventing > all access and submission (the "successfulness" of the control) whereas > readonly allows tabbing to, submission and scrolling if some portion > of the content is hidden. Right. It makes no sense to scroll a radio button, range control, color control, etc. Only text fields can be scrolled. There's no point tabbing to a control that is in no way interactive. It is bad UI to have a "not disabled but non-interactive" control. Thus, we disallow it on all the controls where that would be the result, on the basis that it will discourage authors from making that mistake. The submission thing is a historical artifact. If you need to submit a value but don't want the use to change it, use type=hidden. > Secondly, we can't assume that color values will always be immune to > the same data visibility issues that affect textual data. If it ever changes, we can change the spec. > Similarly, ranges can have a visual representation, but they can > also have a textual representation (5000-10000) which would have the same > issues of needed to access the field and cursor through it to see > the entire value if the display area for the value is too small. Ranges by definition do not have a textual representation — they do not represent a specific number. That's what type=number is for. > (b) visually disable usually grays out or "fuzzes" a field whereas > readonly simply shades it to indicate that the value can't be edited. > This helps users know the difference between information they need to > pay attention to (even if they can't change it) and information that > they can ignore as irrelevant. Although the semantic distinction > between "can't edit right now" vs. "not applicable" isn't in > the specification it is common out in the wild and making it possible > to apply have the browser apply it simplifies user interface > implementation. There isn't a concept of "readonly" for controls other than text fields in UI widget toolkits.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15428 related
I think Hixie's answer here is wrong. There are reasonable use cases for not allowing interaction with a control, but making it clear to users that it is currently not interactive - e.g. things that will be submitted in a form, but can't be changed (perhaps except if you did something else first). There are common ways of indicating this visually, but making the control disabled and removing it upsets the expectation of the screen reader user, who may not realise that it can later become interactive. People *are* making readonly controls other than text things, and we should not force them to use horrible messy hacks to do so because that leads them to get accessibility wrong… It should be possible to apply readonly to other stuff.
A little testing has shown that Some browsers make some of these readonly, so a little more testing is probably in order. http://chaals.github.io/testcases/readonlyNonAlphaNumericFormControls.html Moved to Issues 89, 91 and 92 in HTML: https://github.com/w3c/html/issues/92 https://github.com/w3c/html/issues/91 https://github.com/w3c/html/issues/89