W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] Can we make checkboxes readonly?

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 11 Jul 2012 16:51:29 +0000 (UTC)
To: Markus Ernst <derernst@gmx.ch>
Message-ID: <Pine.LNX.4.64.1207111610010.7759@ps20323.dreamhostps.com>
Cc: WHATWG List <whatwg@whatwg.org>
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<ian@hixie.ch>  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 <form> 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.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 11 July 2012 16:52:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:09 GMT