Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[2.0 rc.14 / next] Nullish checkbox and radio values submit an empty string on the client

Open
  • Is something wrong?
#4,008 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
28/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
html, javascript, typescript
Domain
frontend, full-stack

Research direction

Start with packages/web/src/client.ts, where the issue identifies setProperty and the spread assignment path that normalize nullish values for inputs. Review the regression reproduction and tests mentioned in the proposed PR; verify checked checkbox and radio inputs submit "on" for nullish values while explicit empty strings and text fields retain their stated behavior. The report notes that Babel and native compiler paths remain a separate scope, so clarify which paths the contribution should cover.

Written by the indexing model from the issue text.

Description

Describe the bug

The client runtime writes value="" when a checkbox or radio receives a nullish value. A checked input then submits "" instead of the native default "on". Clearing defaultValue has the same effect because it reflects the value attribute.

This is reproducible on next at 84dada774d35ff79256e24b5e2feadea4b1dec22. Both setProperty and the spread assignment path in packages/web/src/client.ts use value ?? "" for every input type.

Your Example Website or App

The reproduction is included in the steps below.

Steps to Reproduce the Bug or Issue
import { render, spread } from "@solidjs/web";

const form = document.createElement("form");
document.body.appendChild(form);

render(() => {
  const input = document.createElement("input");
  spread(input, {
    type: "checkbox",
    name: "choice",
    checked: true,
    value: undefined
  });
  return input;
}, form);

console.log(new FormData(form).get("choice")); // "", expected "on"

spread is the same runtime path that a JSX spread like <input type="checkbox" checked {...props} /> goes through.

  1. Run the example in a client-rendered page, without hydration.
  2. Inspect the submitted value and the input's value attribute. Both are empty strings.
  3. Replace checkbox with radio, or undefined with null, to see the same result. Removing a previously defined value key from a reactive spread also writes an empty value.
Expected behavior

A nullish value should remove the value attribute so a checked checkbox or radio submits "on". An explicit value="" should still submit an empty string. Text inputs and textareas should keep clearing to "" for nullish values.

The HTML Standard's default/on mode returns "on" when the attribute is absent; assigning the property writes the attribute.

Screenshots or Videos

Not applicable; the difference is visible in FormData.

Platform
  • Solid: @solidjs/web 2.0.0-rc.14, next at the commit above.
  • Local reproduction: macOS 27.0.1, Node 24.21.0, jsdom 25.0.1.
  • Browser: not tested; reproduced in jsdom.
Additional context

The nullish normalization addressed text fields in #2957. This case needs to retain the distinction between an absent attribute and an explicitly empty one.

I'd like to remove the attribute for nullish value and defaultValue on checkbox/radio inputs in the two runtime paths. The type check would run only for a nullish input value. I opened a PR with that patch and regression tests.

The non-hydratable inline paths still need a separate change: Babel's DOM assignment and the native compiler's DOM assignment emit el.value = v ?? "". The proposed runtime patch leaves those packages unchanged. When rendered on the client, <input type="checkbox" name="choice" checked value={v()} /> with a nullish v() would submit "on" in a hydratable build, which calls setProperty, but still submit "" in a non-hydratable build.

The check uses the input's current type. On a new input, assign(input, { defaultValue: null, type: "checkbox" }, true, {}) still creates an empty value attribute; reversing those keys removes it. Radio inputs have the same limitation. Handling that order is outside this patch.

Submit and reset inputs also receive value="" from this normalization. Under the button label rules, an empty attribute produces an empty label instead of the browser's default label. They are outside this checkbox/radio proposal and could be handled separately.

Would you take the runtime change on its own, or prefer to align the inline compiler paths in the same contribution?

Dominant language
TypeScript
Stars
36.1k
Forks
1.1k
Avg merge
10h 44m
Merged PRs (30d)
339

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solidjs/solid

All issues in solidjs/solid

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.