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

[whatwg] non-checked checkbox posting success?

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Tue, 25 Jul 2006 06:18:51 -0400
Message-ID: <44C5F00B.4090302@earthlink.net>
   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.

   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.

   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.

   (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?)
Received on Tuesday, 25 July 2006 03:18:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:47 UTC