[whatwg] Can we make checkboxes readonly?

On Wed, 6 Apr 2011, Tab Atkins Jr. wrote:
>
> Currently, the spec disallows checkboxes from being made readonly.  Is 
> there some good reason for this?  If not, can we change it? Checkboxes 
> being readonly would be useful for the same reasons that text inputs 
> being readonly is.
> 
> Radio buttons can't be readonly either, but they have the obvious 
> complication of being multiple elements.  We could define behavior for 
> them, of course.  One option is to take the @required route, and say 
> that if one radio button in a group is readonly, they all are.  We could 
> alternately say that a radio button being readonly means that that 
> specific input can't have its checkedness changed - if it's currently 
> unchecked, clicking on it won't check it; if it's currently checked, 
> clicking on a mutable radio button from the same group wouldn't change 
> the checkedness of either input.

What's the use case?

Are there any native platforms that have a concept of a read-only radio 
button or checkbox that isn't disabled?


On Wed, 6 Apr 2011, Jonas Sicking wrote:
> 
> What are the use cases for readonly on <input type=text>? I would 
> imagine the use cases for checkbox isn't very different.

On Wed, 6 Apr 2011, Boris Zbarsky wrote:
>
> The primary one I've seen is to have a non-editable text input that the 
> user can still select-and-copy from.

Yeah. I'm not sure I would add readonly to text input controls if it 
didn't already exist.


On Wed, 6 Apr 2011, Tab Atkins Jr. wrote:
> 
> 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.

That's a use case for submitting disabled check boxes, not for read-only 
checkboxes, IMHO. (The same could be said for disabled text controls.)


On Sun, 1 May 2011, Maciej Stachowiak wrote:
> 
> 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.

I agree with all the above.


On Thu, 7 Apr 2011, Randy wrote:
>
> Simple use case with existing car configurators:
>
> When a car feature / accessory is selected that requires another feat. / 
> access., I don't want customers to uncheck that feature, but still need 
> the submission of the required features.
> 
> Or the Mootools library builder:
>
> Depending modules need to be selected and submitted in order to generate 
> the correct javascript file.
> 
> Yes, you can re-add that logic server-side, but why would you want to 
> add that kind of logic twice.

You should always check the data on the server and not trust the client to 
get it right. The client could be completely untrusted.

But in any case, as Maciej says, you can store the data in a hidden input 
if you're doing things with script anyway. It's a two-line function to 
abstract out the logic of checking/unchecking a checkbox and updating a 
hidden input at the same time.


On Thu, 7 Apr 2011, David McMurray wrote:
> 
> A lot of my work involves tables of data which can be navigated via a 
> highlighted cell much like a spreadsheet. Where some cells may be 
> readonly within the table itself, but perhaps editable through a popup 
> value picker opened by double clicking on the cell for example. In this 
> case the text input or checkbox would need to be readonly but still 
> provide a value through the form on submission. This may not sound 
> appropriate for a checkbox because there are only two options, but 
> consider if you had a Y/N field but if the Y option is chosen you wanted 
> to record some other data in a hidden field because you didn't want it 
> to appear in the table. For example you might have a field indicating 
> whether a client wishes to be contacted via telephone, you might then 
> have a popup value picker appear when clicking on the checkbox with 3 
> options 'No', 'Yes, contact anytime' or 'Yes, only during office hours'. 
> The popup would cause the checkbox to be cleared if the first option is 
> selected, and checked for the other two and a hidden field may be used 
> to store the contact time preference.
> 
> I would like to add that it would also be advantageous if checkboxes 
> could be made readonly and in doing so follow readonly text inputs with 
> regards to responding to and firing events like focus, blur, click etc.
> 
> This has been a source of much frustration when trying to implement a 
> spreadsheet-like table where onfocus, onblur and onclick events are used 
> to highlight or unhighlight a cell, because disabled checkboxes do not 
> respond to nor fire these events. Some consistency here with other input 
> types like textbox would be very much appreciated.

It doesn't sound like a checkbox control if it's not interactive. In 
similar situations, I've just made the table display the data with <span>s 
and characters or graphics for the status (check marks, etc), with the 
data stored in <input type=hidden> controls for submission. I think that's 
probably the better approach here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 2 May 2012 15:57:53 UTC