I keep forgetting how broken checkboxes are in HTML.

Fuck checkboxes.

@AlexDeLarge

Considering these three:

<input type="checkbox" checked>

<input type="checkbox">

<input type="checkbox" disabled>

I'd expect a true, a false and a null in my POST data.

Or a 1, a 0 and an absent value.

But I get an "on" string, and two absent values.

Maybe in 2038 it will be fixed.

Until then, we have to deal with JS plugins uglier than Merkel's anus, which try to hide various warty forests of html nodes, just to make a pretty toggle.

@bittersweet lol.

Don't forget the styling!
Or do, actually. It's a pain and barely works.

Don't forget the 0.5 state, interdeminate, which is also lacking.

Using multilevel arrays, is a lifechanger though.
name="dataset[group-id][feature-id]"

Note however that an unchecked checkbox doesn't mean 'off' since the field may not have been answered / interacted with.

Unchecked == null (hence why it's not even sent in the request)

I guess this is why radio buttons exist.

@DeadInside I'd consider all fields in a form as deliberate once you press submit, except those with a disabled attribute. Disabled is the null state.

It's a pain when you have one form, with extra options added for certain users (i.e. employee can edit the name and description of a product, admin can toggle a "published" checkbox)

With current "unset" values both on "unchecked" and "disabled", it's annoying to differentiate "uncheck boolean as admin" from "ignore boolean as user".

@bittersweet I'd argue that
Disabled == unanswerable
Unchecked == unanswered
Checked == agreed
in some forms we have to know that they have actually read and answered the field. We can't assume that not checking a box is equivalent to disagreeing with the statement.

Unchecked "Don't punch me in the face" does not mean the user is happy for you to slap them around a bit.

@DeadInside

But checkboxes are not for vague multiple options, they're boolean.

Checked = 1
Unchecked = 0
Disabled = null, pretend it doesn't exist in the form.

Otherwise i'd use a radio, or select... that would be a "please pick from this menu of punching options".

@bittersweet I disagree that they're boolean. I'd suggest they're true and null. There's an argument for null evaluating to false but in terms of user intent we cannot accept that unanswered is the same as answering false.

@DeadInside It's weird, as a user I've always experienced them as a hard yes/no. But I can kind of see your point.

@bittersweet I guess it all comes down to context. As you say, a checkbox in an admin (eg "enable funk mode") is a boolean but there's no meaningful value in the request - it either exists (true) or doesn't (false).
In the context of a customer facing form there's no way to actually answer 'false' - it's just inferred from the lack of 'true'. Do you see the distinction I'm trying to make? Don't use checkboxes if you need to prove they answered false.

@bittersweet it’s funny I was dealing with this tonight too.

The “on” or “null” thing blows my mind.

If you add “value=1” then you get a “1” in your post data rather than “on”.

However you still get “null” if it’s not checked.

@SSDD @DeadInside

So what about

<input type="range" min="0" max="1", step="any">

That way you can have true, false, and a gliding scale of everything between.

Do you want to subscribe to our newsletter? "Meh, I'll fill that checkbox for 33%"

@bittersweet or what about using a radio and spoofing its look into a checkbox by using a mask to overlay the hidden false radio field. 😂

@Divisionbyzero Or a div with an onclick to change it's background color, and an onsumbit to check the state and append post.

Or a tiny square canvas element, send contents as toDataUrl in post, and use image recognition in the backend to check if it resembles a ✔️, a ❌ or was left empty.

@bittersweet Eureka. Genius. 😂

Gaahhhh

@Root actually there are css-only tricks to handle it gracefully 😉

@okstar Yeah because CSS is known for its frustration-free solutions 😂

@okstar of course you can style checkboxes, it's just irritating because not everything works on them.

@AlexDeLarge Oh gross, what is wrong with you people. Why not just smash a few other languages into a template while you're at it!

I should learn React. But because I haven't yet... I must hate it.

@AlexDeLarge I seriously feel divided about this though.

On one hand, Angular/Vue/React are wonderful tools which enable beautiful components in rich websites, but on the other they have spurred on this cancerous growth in frontend development.

Every SPA-like website I use is absolute trash when it comes to efficiency and reliability, whether it's YouTube not loading parts of it's interface, or Asana throwing random reloads in my face, or Github forgetting what the back button is supposed to do, or Google Inbox hanging my browser tab.

But the point is... I do use those websites, because the thick layer of frontend garbage makes them unique and powerful.

I just wonder whether we'll be happy we went down this road in ten years time, when a junior developer is trying to figure out what this "Babel" thing does, and why there are 15 different json files in the project root with weird-ass names like grunt, gulp, yarn, broccoli, gobble and brunch, and why there's TS and CS and JS...

@AlexDeLarge Yup.

Every time I work on frontend stuff I feel like we're not "getting it" yet.

We have just discovered this decade that programming state (two-way) bound to the stuff you see on your screen is very useful.

We keep editing styling through code, defining little bundles of scss-transpiled-to-css-into-classnames, dropping them statically or dynamically into tags, sometimes even through template-language properties and made-up tagnames.

We have this divide between HTML/CSS/JS, a divide which every computer scientist fought for tooth and nail.

Separation of concerns!

Thou shalt not befoul the holy structure of your document with style or function! Thou shalt sprinkle a thousand divs into the DOM and litter them with classes!

But aren't we clearly fighting against some false prophecy here?

So why do we even write our DOM as an XML-like document? Why don't we define a page directly, why isn't the DOM populated from script through a typesafe Tree data constructor?

@bittersweet
Give them values then?