[CHECKBOX] "unchecked" behavoir

[nuxodin]

I would really like it that when a checkbox is unchecked its value is an empty string.

I don't know about others, but i have to do this hack all the time:

let value = el.value; // other input
if (el.type==='checkbox') { // checkboxes
    value = el.checked ? el.value : '';
}

[nuxodin]

I also use this "hack" to send an "unchecked" checkbox in a form:

<input type='hidden' value='' name='accepted'>
<input type='checkbox' value='1' name='accepted'>

This hack has a rating of 516 at stackoverflow
https://stackoverflow.com/a/1992745/4865307

And it is mentioned at MDN:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input/checkbox

I think if we have the possibilities to redesign the checkbox, we should improve it to this behavior.

<checkbox value="1" name=accepted checked> <!-- checkbox.value === '1' -->
<checkbox value="1" name=accepted> <!-- checkbox.value === ''  -->

Conceivable would also be a future expansion with an attribute like "falsy".

<checkbox value="on" falsy="off" name=accepted>

[gregwhitworth]

@nuxodin thank you so much for filing this. This is the exact same issue that we just discussed in #311 - @domenic actually hits on the confusion of the current checkbox in this comment.

Likewise this issue you raised was brought up to the TAG here. Ultimately the group seems to be in agreement that there need to be better cohesion in how the initial states relate to that of the IDL values themselves.

As far as your proposals are concerned they need to follow the proposal for open in <popup> in that we should be clear in what is controlling the initial state vs reflection in the IDL. Effectively the groups seem to be leaning towards making it clear in the name that you're setting the initial state & value rather than that content attribute reflecting the value. @domenic do you want to add any additional thoughts here?

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[nuxodin]

My final solution would be:

<checkbox on=yes off=no name=accepted>

checkbox.value // no
checkbox.checked = true;
checkbox.value // yes

Advantages:

• Also unchecked checkboxes sends something (as default an empty string)
• the property "value" no longer incorrectly reflects the attribute "value" (the attribute no longer exists)
• "on" and "off" are short and clear attributes

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[nuxodin]

This suggestion was discussed and it was concluded that traditional check boxes should also be given an off value (as I understand it)
whatwg/html#4180 (comment)

This will probably look something like this:

<input type=checkbox value=yes name=accepted **offvalue=no**>.

Unfortunately this will result in checkbox.value not being able to have the selected value, but always the on-state value, as this needs to remain compatible :(

So we still have to do something like this:

let value = el.value; // other input
if (el.type==='checkbox') { // checkboxes
    // value = el.checked ? el.value : ''; // old
    value = el.checked ? el.value : el.offValue;
}

I would rather there were new checkboxes that had a better API.

[annevk]

I don't think that's necessarily true @nuxodin. With an opt-in attribute we could make el.value take that into account. The value IDL attribute and content attribute are different after all. defaultValue is the one that reflects the value content attribute.

[nuxodin]

Do you mean something like that?

Current behavior

<input type=checkbox value="true" checked> 
// .value == "true"
<input type=checkbox value="true">
// .value == "true" // i think .value should be "" (empty string)

Future

<input type=checkbox value="true" offvalue="false" checked>
// .value == "true"
<input type=checkbox value="true" offvalue="false">
// .value == "false"

[annevk]

Yes, something like that. What would help motivate such a feature would be more evidence that this is a problem web developers frequently run into. Stack Overflow questions might help with that as well as JS libraries that work around the issue.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.