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
[EMAIL PROTECTED]
http://www.michelf.com/
