[whatwg] non-checked checkbox posting success?
michel.fortin at michelf.com
Tue Jul 25 07:00:25 PDT 2006
Le 25 juil. 2006 à 6:18, Matthew Raymond a écrit :
> What I don't understand about this whole "unchecked value" issue is
> why this is even necessary. The status of a check box is a binary
> If no value is returned, the server can simply assume the unchecked
> value. In fact, the server could initially set a string to the
> value, then replace it with a checked value if one is returned.
> This has
> always been the case, and won't cause any real hardship if we continue
> to only allow a checked value for on to be sent to the server.
In a web application, I have a list of checkbox which looks like that:
<tr><th>Activated </th><th>Element </
<tr><td><input type="checkbox" name="e1"></td><td>Element 1</
<tr><td><input type="checkbox" name="e2"></td><td>Element 2</
<tr><td><input type="checkbox" name="e3"></td><td>Element 3</
<tr><td><input type="checkbox" name="e4"></td><td>Element 4</
Now, each time someone submits the form, every element's "activated"
status is set to the corresponding checkbox value. In an ideal world,
I would simply loop over each element in my database and check if the
corresponding input is defined or not to set the right value.
But things are not that simple: someone else, using a different
browser, could have added a bunch of new elements to the list since
the the above markup was sent. So when the user submits this, if I
simply loop over each element in my database I'll surely deactivate
any newly added element that was not present it that list. Obviously,
only the checkboxes the user can see should be altered.
As of how necessary the new feature is: I suppose it isn't really
since you can always use a hidden field to indicate the presence or
the absence of an element. Adding a hidden input isn't very elegant,
but is backward compatible.
> By contrast, if we allow an unchecked value to be sent to the
> server software developers will have to deal with both nothing being
> sent AND a unchecked value being sent, because they will still have to
> legacy browsers, but then you create a dependency on scripting
> while you
> still have to perform a more complicated form of server-side
> to avoid potential security problems.
Ric's proposal wasn't very backward compatible. Mine, the "value-
unchecked" attribute, preserve the old behaviour, unless you add the
attribute. I suppose the best backward-compatible solution may be to
continue to use a hidden input until HTML4 browsers fades out.
> Remember, if only the checked value is returned, then the server-
> code can test for its mere existence and use the resulting boolean
> to determine whether to use the checked or unchecked string. Once you
> have a value returned for the unchecked state, you have to evaluate
> string to determine the state of the control, rather than simply
> for its existence.
Always having a value returned inform the server there was a checkbox
on the user side when the form was submitted. Adding fields to a form
a prime example of a case where you absolutely need to know the
checkbox was there. But again, I suppose it can be solved with hidden
> (Actually, when you consider that server-side validation needs
> to be
> performed to ensure that improper values are not returned by a check
> box, one has to wonder why you'd even bother with allowing values
> than "on" to be returned. Anyone have a scenario where the actual
> returned is of any use?)
I think this is pretty common, if only because of PHP. If you receive
different inputs with the same name which ends with empty brackets,
PHP will automatically build an array for it. So you could have this:
<input type="checkbox" name="attr" value="bold" checked>
<input type="checkbox" name="attr" value="italic" checked>
<input type="checkbox" name="attr" value="superscript">
<input type="checkbox" name="attr" value="subscript" checked>
and automatically get a PHP array like this one:
$_POST['attr'] = array("bold", "italic", "subscript");
Also, I was wondering if we could add an indeterminate state to
checkboxes, like the datagrid has . In this case, a third state
would be needed... maybe from a "value-indeterminate" attribute?
michel.fortin at michelf.com
More information about the whatwg