Re: [whatwg] Can we make checkboxes readonly?
On Wed, 11 Jul 2012, Markus Ernst wrote: > Am 11.07.2012 00:59 schrieb Ian Hickson: > > On Fri, 4 May 2012, Tab Atkins Jr. wrote: > > > On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: > > > > 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.) > > > > > > That's more-or-less what @readonly does - the input becomes > > > "disabled" but still submits. > > > > That's part of what it does, but not the main thing it does. It's > > mainly a UI affordance, which doesn't apply to check boxes. > > Given that there are valid use cases for submitting values of elements > that have a disabled resp. readonly behaviour in the UI: Would it do any > _harm_ to allow @readonly to checkboxes and radio buttons? I assume this > would be easy and possible without breaking existing content. Submitting > disabled elements, OTOH, looks to me like an impossible change, as it > would likely break existing content. Just making readonly="" on checkboxes be a synonym for disabled="" (but with different submission behaviour) would be an abuse of the attribute, IMHO, since readonly="" doesn't mean disabled, it means read-only, which is a concept that only applies to text fields. The only reason we'd want to use readonly="" rather than make up some new feature is if it had good graceful degradation, but it doesn't (it wouldn't be disabled in old UAs). If we want to make it possible to submit disabled controls, we should just provide that feature explicitly, e.g. an attribute on that causes disabled controls to be submitted. But with form submission slowly being replaced by JavaScript-mediated in-place "AJAX" UI, and given that the server typically already has the disabled data since it sent it to the user and the user isn't allowed to change it, and given that servers can't trust the client not to have changed the data so has to check it anyway, and given that it's possible to work around this issue already using type=hidden without much difficulty, I don't really see much of a compelling reason to add this feature at this time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we make checkboxes readonly?
Am 11.07.2012 00:59 schrieb Ian Hickson: On Fri, 4 May 2012, Tab Atkins Jr. wrote: On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: 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.) That's more-or-less what @readonly does - the input becomes "disabled" but still submits. That's part of what it does, but not the main thing it does. It's mainly a UI affordance, which doesn't apply to check boxes. Given that there are valid use cases for submitting values of elements that have a disabled resp. readonly behaviour in the UI: Would it do any _harm_ to allow @readonly to checkboxes and radio buttons? I assume this would be easy and possible without breaking existing content. Submitting disabled elements, OTOH, looks to me like an impossible change, as it would likely break existing content.
Re: [whatwg] Can we make checkboxes readonly?
On Thu, 3 May 2012, Shaun Moss wrote: > > An obvious use case for readonly checkboxes came up a few weeks ago when > I made this page: http://marssociety.org.au/membership > > The checklist at the bottom I could have made more simply/cheaply with > readonly checkboxes. However I had to use images. Those aren't check boxes, so it seems entirely correct that you not use the element for them. It would be like using for the cells in the second column of that table, or for the cells in the first column. On Fri, 4 May 2012, Tab Atkins Jr. wrote: > On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: > > 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.) > > That's more-or-less what @readonly does - the input becomes "disabled" > but still submits. That's part of what it does, but not the main thing it does. It's mainly a UI affordance, which doesn't apply to check boxes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we make checkboxes readonly?
On May 4, 2012, at 9:05 PM, "Tab Atkins Jr." wrote: > On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: >> 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.) > > That's more-or-less what @readonly does - the input becomes "disabled" > but still submits. > > ~TJ Afaik, the issue with disabled is selection. There are some long term issues with selection; between CSS content and vendor prefixes (text-selection), this issue ought to be considered.
Re: [whatwg] Can we make checkboxes readonly?
On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: > 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.) That's more-or-less what @readonly does - the input becomes "disabled" but still submits. ~TJ
Re: [whatwg] Can we make checkboxes readonly?
On Wed, May 2, 2012 at 5:57 PM, Ian Hickson wrote: > On Wed, 6 Apr 2011, Jonas Sicking wrote: > > What are the use cases for readonly on ? I would > > imagine the use cases for checkbox isn't very different. > (year+13mon) It's useful if you want to have an isolated block of text that's easy to copy-and-paste, without the selection spilling into adjacent text; you just double-click the input, or focus it and hit ^A. That isn't relevant for checkboxes and radio buttons, of course. -- Glenn Maynard
Re: [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 ? 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 rea
Re: [whatwg] Can we make checkboxes readonly?
On Apr 6, 2011, at 3:46 PM, Tab Atkins Jr. wrote: > On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt wrote: >> On 2011-04-07 00:28, Tab Atkins Jr. wrote: >>> >>> On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt >>> wrote: What's wrong with using disabled? >>> >>> 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
Re: [whatwg] Can we make checkboxes readonly?
On 6 April 2011 23:39, Lachlan Hunt wrote: > On 2011-04-07 00:28, Tab Atkins Jr. wrote: > >> On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt >> wrote: >> >>> What's wrong with using disabled? >>> >>> >>> >>> >>> >> >> 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? > 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. David McMurray
Re: [whatwg] Can we make checkboxes readonly?
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. My 2 cents Randy -Original Message- From: Lachlan Hunt Sender: whatwg-bounces@lists.whatwg.orgDate: Thu, 07 Apr 2011 00:39:04 To: Tab Atkins Jr. Cc: WHATWG List Subject: Re: [whatwg] Can we make checkboxes readonly? On 2011-04-07 00:28, Tab Atkins Jr. wrote: > On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt wrote: >> What's wrong with using disabled? >> >> >> > > 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? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
Den 2011-04-06 22:45:36 skrev Tab Atkins Jr. : 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. ~TJ These are very good points, which many web developers that has been handling forms probably have torn their hairs about for a long time. Time to do something about it ;) Thank you for bringing it up :) -- Jesper Gustin QA, Linux Devices SDK Opera Software
Re: [whatwg] Can we make checkboxes readonly?
On Thu, Apr 7, 2011 at 3:25 AM, Alexandre Morgaut wrote: >> >>> What are the use cases for readonly on? >> >> The primary one I've seen is to have a non-editable text input that the >> user can still select-and-copy from. > > Well... could be enough for this use case ;-) Well... you wont get effect of cursor movement, which are something wanted by our end user.
Re: [whatwg] Can we make checkboxes readonly?
> >> What are the use cases for readonly on? > > The primary one I've seen is to have a non-editable text input that the > user can still select-and-copy from. Well... could be enough for this use case ;-) Alexandre Morgaut Product Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com
Re: [whatwg] Can we make checkboxes readonly?
On 4/6/11 3:43 PM, Jonas Sicking wrote: What are the use cases for readonly on? The primary one I've seen is to have a non-editable text input that the user can still select-and-copy from. -Boris
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt wrote: > On 2011-04-07 00:28, Tab Atkins Jr. wrote: >> >> On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt >> wrote: >>> >>> What's wrong with using disabled? >>> >>> >>> >> >> 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. ~TJ
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt wrote: > On 2011-04-07 00:28, Tab Atkins Jr. wrote: >> >> On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt >> wrote: >>> >>> What's wrong with using disabled? >>> >>> >>> >> >> 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? What are the use cases for readonly on ? I would imagine the use cases for checkbox isn't very different. / Jonas
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 3:28 PM, Tab Atkins Jr. wrote: > On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt wrote: >> On 2011-04-06 22:45, 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. >> >> What's wrong with using disabled? >> >> >> > > Disabled elements don't participate in form submission. Also, consistency across input types seems like a good thing for authors. / Jonas
Re: [whatwg] Can we make checkboxes readonly?
On 2011-04-07 00:28, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt wrote: What's wrong with using disabled? 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? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt wrote: > On 2011-04-06 22:45, 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. > > What's wrong with using disabled? > > > Disabled elements don't participate in form submission. ~TJ
Re: [whatwg] Can we make checkboxes readonly?
On 2011-04-06 22:45, 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. What's wrong with using disabled? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 1:45 PM, Tab Atkins Jr. wrote: > Checkboxes being readonly would be useful for the same reasons that > text inputs being readonly is. > As someone who spends a lot of time writing native UIs, I agree. It's useful to be able to "dim out" a checkbox that no longer applies when some other, related form control is changed. 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. > Enabling individual radio buttons within a group to be disabled would match Windows' capabilities, at least. It's not clear whether the right behavior might not be to allow clicks on an enabled button to unselect the disabled button, though. See for example someone wanting that with a Windows native control here: http://social.msdn.microsoft.com/Forums/en-IE/vcmfcatl/thread/75fef4b4-a7ab-4e96-ac9b-12cb27085ab9 PK PK
