- From: <bugzilla@jessica.w3.org>
- Date: Fri, 23 Sep 2011 23:11:06 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13390
Ian 'Hixie' Hickson <ian@hixie.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |ian@hixie.ch
Resolution| |WONTFIX
--- Comment #2 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-09-23 23:11:04 UTC ---
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.
--
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 Friday, 23 September 2011 23:11:07 UTC