[whatwg] Can we make checkboxes readonly?

[Maciej Stachowiak]

On Apr 6, 2011, at 3:46 PM, Tab Atkins Jr. wrote:

> On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
>> On 2011-04-07 00:28, Tab Atkins Jr. wrote:
>>> 
>>> On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt<lachlan.hunt at lachy.id.au>
>>>  wrote:
>>>> 
>>>> What's wrong with using disabled?
>>>> 
>>>> <input type="checkbox" disabled>
>>>> <input type="checkbox" disabled checked>
>>> 
>>> Disabled elements don't participate in form submission.
>> 
>> That's true, but if the controls are readonly, then the user can't change
>> the value and so why does that matter?  Could you clarify the use case for
>> having a readonly checkbox value submitted?
> 
> An app may dynamically set inputs or groups of inputs to readonly
> based on app state.  When you submit, though, it's impossible to tell
> (without hacks) whether a checkbox was checked-but-disabled or just
> unchecked.  Handling the form data is *much* easier if you just get
> all the data, regardless of whether, as a UI convenience, your app
> temporarily set some of the inputs to readonly.

In native app UI, it's highly unusual to have a checkbox that is read-only but not disabled. It would be extremely confusing for a checkbox to have the enabled look but not actually be checkable. Therefore, we should not encourage content authors to build UI that looks like that.

If you want to dynamically turn some inputs read-only but still submit their values, then presumably you are using script and can add hidden inputs to reflect that state. While this is inconvenient, I don't think it is a good idea to create bad UI solely for convenience.

Another possibility is to make read-only checkboxes look and act disabled, with the only difference being whether the value is submitted or not. I have no objection in principle to such a state, but:

- readonly seems like a poor name for this state, since in the case of text controls, readonly actually has different user-visible interaction behavior from disabled, not just different submission rules.
- The fact that older browsers wouldn't support this special state makes it hard to adopt incrementally. disabled with an extra attribute saying "submit anyway" would do a better job of degrading gracefully, but would mean that for a while, authors have to do the hidden input trick as fallback anyway.

Given these things and the relative obscurity of the use case (UIs where disabling and enabling controls follows a complex pattern are rare and typically not good design anyway), I am not sure the feature is worthwhile.

Regards,
Maciej