W3C home > Mailing lists > Public > public-html@w3.org > July 2011

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 27 Jul 2011 13:18:49 +0000
To: public-html@w3.org
Message-ID: <bug-13390-2495@http.www.w3.org/Bugs/Public/>
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 on the CC list for the bug.
Received on Wednesday, 27 July 2011 13:18:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:37 GMT