- From: <bugzilla@jessica.w3.org>
- Date: Wed, 27 Jul 2011 13:18:49 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13390 Summary: Readonly attribute on input.{color|range|checkbox|radio} Product: HTML WG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: HTML5: The Markup Language (editor: Michael(tm) Smith) AssignedTo: mike@w3.org ReportedBy: egfrankbackman@gmail.com QAContact: public-html-bugzilla@w3.org CC: public-html-wg-issue-tracking@w3.org, public-html@w3.org 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) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 27 July 2011 13:18:54 UTC