d3ad1ysp0rk wrote:But each checkbox is it's own element, they aren't supposed to be grouped, that's the way it was designed. I believe the original intent was single options (aka "Disable BBCode in this post", "Notify me when a reply is posted", etc).
First, let me say that I have not been able to find (in the past 15 minutes) anything that explicity says that a group of checkboxes should all share the same name.
I will, however, point to radio buttons. Obviously, a set must share the same name to achieve the "radio" effect. I think the fact that this effect is bound to the radios'
names (as opposed to, say, a group attribute, or all radios within a fieldset or something) speaks to the idea that individual radios are semantically the same as the others, differing only in the value they promise to post. The only way the checkboxes in my example differ from a set of radios is that I want users to have the ability to select more than one (or none) of the options.
Next, I offer the following brief JS function, designed to implement check all/none functionality.
Code: Select all
function setChecks(oField, bState)
{
i(!oField) return false;
if(!oField.length) oField.checked = bState;
else
for(i = 0; i < oField.length; i++)
oField[i].checked = bState;
return true;
}
Note that, in addition to begging the question of proper checkbox naming (and omitting some important validation for brevity), it allows the calling script to act on a distinct set of checks, without relying on a hokey name/pattern-matching scheme paired with a form.elements loop that could behave oddly on forms with similarly named boxes. Also, without modification, it could be used to clear an existing set of radio buttons. And yes, while the script refers to an individual box using array notation, the
actual HTML names them all the same.
Assuming we can agree on the above point, I object to using PHP array syntax in my naming scheme because, as I said earlier, I want to avoid coding my forms for a specific language. I work in an environment in which any number of server-side scripts could potentially be asked to process the results of a given form. I'm not saying these other languages can't handle aid[] as a fieldname (because I don't know), but I think the best solution is to mark up my forms in a language-ignorant way. If these languages are genuinely suited to the web, they should each be capable of dealing easily with data generated by the same form, assuming the form itself adheres to the relevent standards.
I've been building forms (for another language) for several years now, and have formed some very strong opinions about how a form ought to be designed. That said, if there is a W3C recommendation, or some other
de-facto standard that applies specifically to intelligent form design, I'd be happy to bring my code into line with it. If there is a conversation somewhere dealing specifically with these issues, I'd also be happy to participate. Either way, I'd prefer my HTML practices were not dictated by my choice of processing language, but by HTML standards.
Failing that, I want to be able to do it my way. 8-)