Allow readonly on checkboxes and radio buttons?

[chaals]

Not sure if it works anywhere. There seems to be a use case for distinguishing between disabled and readonly, although it might be unnecessary complication. As far as I know it does work anywhere (only tested mac browsers though).

testcase

[travisleithead]

[inclusive of Issue #91]

On windows, readonly also doesn't work anywhere except for Chrome on Windows makes input[type=range] non-adjustable.

My interpretation of the spec's position on readonly is that it is intended to apply to textual input scenarios, and input controls that represent physical knobs and switches, etc., are not applicable to readonly. (This appears to be confirmed in the spec's text at Section 4.10.5.3.3.)

Why we probably shouldn't allow readonly on these controls, taking radio buttons as an example: a readonly radio button would presumably remain interactive, allowing users to adjust the ui (toggle different radio buttons), however, these UI changes would of necessity be disconnected from their actual values. This would probably lead to user confusion given that 1) they wouldn't be able to visually inspect the current value, and 2) it may break expectations for what value is actually submitted when used in a form scenario.

[arronei]

Also inclusive of Issue #89

[chaals]

If we allowed this, the readonly should make the controls non-operable, as it does with text inputs, but the user would be able to see that there is a value that is being submitted with the form - whereas if the control is disabled that doesn't happen.

Blink-based browsers make ranges non-interactive if they are readonly on Mac too. And Safari makes colour pickers non-interactive by not supporting them and having a text input instead, which behaves as other text inputs.

Also #89 and #91

[LJWatson]

@travisleithead is right about the current spec interpretation, but I think it is worth considering readonly for checkboxes and radio buttons too - with the proviso (as @chaals noted) that they are inoperational.

The use case that comes to mind is reviewing previous form choices before final submission. The design pattern usually allows changes to be made by following a link to return to the original form. The UX gets a bit confusing when some fields can be interacted with and others not.

[MorganEPatch]

I agree with this suggestion, to allow readonly for checkboxes and radio buttons. @LJWatson provides a great use case: prevent the user from editing a field, for example if they're reviewing a form before submitting it, or in the case of an "if this, then force that" scenario, or if a user doesn't have permission to edit the value (obviously also performing server-side validation of the data as well), and you therefore want the value of the fields to be sent as a part of this form, but don't want the user to change it.

I've been spending most of my day today looking for an easy way to implement this, including digging through BugZilla tickets on why Firefox doesn't support this and W3C documents in the hopes of finding some justification for making this unnecessarily difficult. (In case you're wondering, I ended up using disabled radio buttons alongside hidden input fields with some JQuery to constantly update the hidden fields to hold the values of the radio buttons. This is an incredibly hacky workaround.)

[stevefaulkner]

As this is marked with 'incubate first' closing here, should be raised in WICG.