[whatwg] non-checked checkbox posting success?

[Michel Fortin]

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  
> value.
> If no value is returned, the server can simply assume the unchecked
> value. In fact, the server could initially set a string to the  
> unchecked
> 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:

     <table>
     <tr><th>Activated                        </th><th>Element  </ 
th></tr>
     <tr><td><input type="checkbox" name="e1"></td><td>Element 1</ 
td></tr>
     <tr><td><input type="checkbox" name="e2"></td><td>Element 2</ 
td></tr>
     <tr><td><input type="checkbox" name="e3"></td><td>Element 3</ 
td></tr>
     <tr><td><input type="checkbox" name="e4"></td><td>Element 4</ 
td></tr>
     </table>
     <input type="submit">

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,
> server software developers will have to deal with both nothing being
> sent AND a unchecked value being sent, because they will still have to
> support legacy clients. You might argue that Javascript can handle
> legacy browsers, but then you create a dependency on scripting  
> while you
> still have to perform a more complicated form of server-side  
> validation
> 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- 
> side
> code can test for its mere existence and use the resulting boolean  
> value
> to determine whether to use the checked or unchecked string. Once you
> have a value returned for the unchecked state, you have to evaluate  
> the
> string to determine the state of the control, rather than simply  
> testing
> 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  
inside the browser using JavaScript or HTML5's repeating model may be  
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  
fields too.

>    (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  
> other
> than "on" to be returned. Anyone have a scenario where the actual  
> string
> 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 [1]. In this case, a third state  
would be needed... maybe from a "value-indeterminate" attribute?

  [1]: http://www.whatwg.org/specs/web-apps/current-work/#indeterminate


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/