[Bug 13390] Readonly attribute on input.{color|range|checkbox|radio}

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13390

--- Comment #1 from Elizabeth Grace Frank-Backman <egfrankbackman@gmail.com> 2011-07-27 13:20:18 UTC ---
(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)

-- 
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:20:20 UTC