Add boolean input element with "true" and "false" values

[alejsanc]

Currently a way to enter in a form a boolean value that can be true or false is to use a checkbox. If the input is selected the field is sent and if it is not selected it is not sent. If it is sent is true and if it is not sent it is false.

It may be the case that in a form, on some occasion, you do not want to add that parameter. So in the server it is not known if that parameter is not included because it was not in the form or because you want to give it the false value.

Right now what is usually done is to have a checkbox and a hidden input with the same name. The checkbox has true value and the hidden one the false value. When the checkbox is marked the two parameters are sent and it is taken the value of the first, the checkbox, which is true. When the checkbox is not marked only the value of the hidden one is sent, which is false and its value is taken. If checkbox and hidden are not in the form on the server you know the parameter is not included.

<input name="boolean-parameter" type="checkbox" value="true" />
<input name="boolean-parameter" type="hidden" value="false" />

Also in databases the boolean field in addition to true or false can be null. In languages ​​like Java the Boolean type can be null. With the above method we cannot differentiate between absent and null, we would have to use for example radio inputs.

<input name="boolean-parameter" type="radio" value="true" /> True
<input name="boolean-parameter" type="radio" value="false" /> False
<input name="boolean-parameter" type="radio" value="null" /> Null

It would be quite useful to have an input with the appearance of checkbox o radio inputs that had the value true when checked and false when unchecked. It would also be useful that it had some mechanism to give it the null value. In summarize an input that allows differentiating between the true, false, null and absent states.

<input name="boolean-parameter" type="boolean" />

[marcoscaceres]

As with the file one... have you filed this issue over at http://github.com/whatwg/html/issues/ ? I might be wrong, but it feels very much like a HTML issue and not so much something we'd want to incubate.

[marcoscaceres]

Oh, also, boolean reminds me of the new type="switch", which is basically boolean. https://webkit.org/blog/15054/an-html-switch-control/

[markcellus]

Yeah, looks like something this has already been filed: whatwg/html#4180 and whatwg/html#10206.

[yoavweiss]

Given that issues have been filed on HTML, closing this one.. Let's continue the discussion over there.

[alejsanc]

Yeah, looks like something this has already been filed: whatwg/html#4180 and whatwg/html#10206.

In these proposals they talk above all about the visual appearance. My proposal focuses on what the browser sends to the server. Right now an unselected checkbox does not send anything and you cannot distinguish between unselected and absent. If any of those proposals add the possibility of being sent to the server "on" or "off" that seems fine to me. If they work the same as the checkbox and do not send anything when they are off, it will not work.

As I say in my proposal: "In summarize an input that allows differentiating between the true, false, null and absent states."

[alejsanc]

As with the file one... have you filed this issue over at http://github.com/whatwg/html/issues/ ? I might be wrong, but it feels very much like a HTML issue and not so much something we'd want to incubate.

I did it. But they didn't think it was important.

whatwg/html#6431

[markcellus]

OP it sounds like you want to use the same endpoint for two seperate things:

1. To determine if the boolean in the form is false and
2. Determine if there is even a boolean used at all

But normally these would be two different forms that submit to two different URLs, which would be more secure imo.

Even if there was an element for your server to detect 2 above, the request could come from a client other than a browser form (e.g. curl POST) and exclude it.

My guess is that the working group thinks this is a very specialized use case and therefore doesnt justify adding a new element to support it.

[ljharb]

I very much would never do that "normally" - usually what i'd do is have a checkbox preceded by a hidden input with the same name set to the "unchecked" value of the checkbox, to patch over this decades-old browser deficiency.

[markcellus]

Sure, you're welcome to do what you want. But again, whether you have this feature or use an hidden input field, it's still not a reliable way to check form submission on the server. The submission could come from any other client that can exclude the field in the request. Then you're right back in the same situation again where you can't reliably detect whether the request is coming from an HTML form or whether it has the false or non-existent boolean or not.

[ljharb]

Sure, but then I can (and would) reject the request when it lacks the field, because I don't care to support requests from clients whose submissions aren't matching expectations.

[markcellus]

That would essentially limit your requests to those made by a browser. Fair. But I'd be curious of the use case that would mandate such a requirement. Why someone would someone want to block a POST request purely because it's not made by a web browser? If it's to block a bot, bots can use web browsers too.

[ljharb]

any endpoint on a webserver would want that; and they usually get that by default with typical validations.

[markcellus]

Got any example or specific use case you can point to? Seems like that's what the working group was also asking about.

[ljharb]

Unfortunately not; all of the use cases have been “every single web app I’ve worked on in the last 15 years”, all of which are internal to their respective company.

[alejsanc]

Got any example or specific use case you can point to? Seems like that's what the working group was also asking about.

Millions of programmers around the world have done the trick of using a hidden input with the same name.

https://www.google.com/search?client=firefox-b-e&q=html+checkbox+true+false+hidden+input#ip=1

[alejsanc]

OP it sounds like you want to use the same endpoint for two seperate things:

1. To determine if the boolean in the form is false and

2. Determine if there is even a boolean used at all

They are not two separate things. The same action can be performed with different parameters. Sometimes you may want to include the boolean value and other times you may not. Then you need to distinguish between false and absent. It's something very basic. This is what in programming is called method overloading. It is something basic in any computer system.

action(integer parameter 1,  boolean parameter 2)
action(integer parameter 1)

Should we use two methods?

action(integer parameter 1,  boolean parameter 2)
action_without_boolean(integer parameter 1)

[markcellus]

method overloading. It is something basic in any computer system.

Right, and the spec isnt too keen on overloading APIs.

I can see this convo isnt really productive. So I'm just gonna keep quiet until there's a use case someone has that would justify the feature. I've been building complex websites for quite a while and I cant think of a reason you would need this, which is likely why it was turned down.

[alejsanc]

Even Mozilla's documentation recognizes the problem and explains how to do the hidden input trick.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox

Note: If a checkbox is unchecked when its form is submitted, neither the name nor the value is submitted to the server. There is no HTML-only method of representing a checkbox's unchecked state (e.g. value=unchecked). If you wanted to submit a default value for the checkbox when it is unchecked, you could include JavaScript to create a [<input type="hidden">] within the form with a value indicating an unchecked state.

Microsoft HtmlHelper.CheckBox

Returns an <input> element of type "checkbox" with value "true" and an <input> element of type "hidden" with value "false" for the specified expression.

Adobe Granite UI CheckBox has an "unchecked" attribute

uncheckedValuestring

   The submit value of the field when it is unchecked.

[alejsanc]

Laminas Checkbox

setUseHiddenElement(boolean $useHiddenElement) : void If set to true (which is default), the view helper will generate a hidden element that contains the unchecked value. Therefore, when using custom unchecked value, this option have to be set to true.

Ruby on Rails Form Helpers

According to the HTML specification unchecked checkboxes submit no value. However it is often convenient for a checkbox to always submit a value. The check_box helper fakes this by creating an auxiliary hidden input with the same name. If the checkbox is unchecked only the hidden input is submitted and if it is checked then both are submitted but the value submitted by the checkbox takes precedence.

Everyone does the hidden input trick because the input checkbox doesn't have something as basic as sending true or false.

[alejsanc]

Bootstrap Vue Form Checkbox

By default, <b-form-checkbox> value will be true when checked and false when unchecked. You can customize the checked and unchecked values by specifying the value and unchecked-value properties, respectively.

[alejsanc]

Are more examples needed? It is a basic thing that is included in almost all frameworks and people use it all the time. And those who do not use a framework do their own implementation.

[ljharb]

@markcellus to be more specific, twitter, airbnb, and coinbase all rely on this hack and have this use case, so tbh I'm astonished on a complex website you've never run into it before.

[markcellus]

You're probably astonished because the point I'm making somehow isn't clear.

I'm not saying that people don't do this. I could see why frontend and UI frameworks would need this functionality because frontend apps these days are SPAs. Doing this makes it easy to validate a boolean input on the frontend. There are also cases where the UI may need to manipulate state based on the false or non-existence of a boolean. But these all seem like frontend concerns to me.

What I'm asking is: why would a backend (a server) need to know whether a boolean in a request is either false or not there? What difference would it make to evaluate the difference of a false or undefined boolean value in a request made to a backend service?

FWIW, the apps and services I maintain are MPAs (deliberately not SPAs) and I build backend services totally independent of UI. When building a backend service, I always build them under the assumption to never trust the client. And the UIs I build are extremely barebones. I don't have to maintain complex state on the frontend. So no. I've never had a case where I needed to distinguish whether a boolean/checkbox in a form is false or not there at all. They're both considered false to me and any request with either would get the same response.

[ljharb]

@markcellus every backend needs to know that, because if it's false or true, you need to modify the resource - if it's absent, you MUST NOT modify that field of the resource.

There is a categorical difference between true/false and absent.

[markcellus]

Please stop @ing me. I'm not going to keep going back and forth about this. If you aren't going to answer my questions, there's not much more I can say to you. Good luck with getting this feature added.

[ljharb]

I answered it. A backend always needs to know whether a field should be affirmatively set, or unchanged.

[alejsanc]

I'm not saying that people don't do this. I could see why frontend and UI frameworks would need this functionality because frontend apps these days are SPAs. Doing this makes it easy to validate a boolean input on the frontend. There are also cases where the UI may need to manipulate state based on the false or non-existence of a boolean. But these all seem like frontend concerns to me.

I already explained to you that my proposal has nothing to do with the frontend or the visual aspect. This is only about distinguishing between false and absent on the server because it is very useful in many situations. And I have shown that it is something that many people use.

Just because you don't use it is no reason not to add it to HTML. HTML is for everyone. There are many things in HTML that I do not use and I do not ask that they be removed. if there are many people who use it, it is worth thinking about adding it to HTML.

[alejsanc]

Furthermore, in the frontend there is no problem because it is known whether or not the element exists and whether it is selected or not. There is no problem in knowing if it is false or absent.

The problem is that this knowledge is not sent to the server unless you do the hidden input trick.