Files
webstudio/docs/university/core-components/checkbox.md
Oleg Isonen 99371187dc docs: Move product documentation into Builder (#5987)
## Summary

- move the complete GitBook documentation tree and assets into Builder
under `/docs`
- generate the exhaustive MCP page from the local CLI source in the same
change
- publish GitBook from a release-gated `docs` branch containing the
exact successfully released revision
- run MCP documentation tests, typechecking, and stale-output checks
with the existing generated-docs check
- remove links to the Community Discussions repository

## Technical choices

- Import the current documentation as a linear snapshot so the branch
satisfies Builder's required-linear-history protection.
- Keep the Markdown wrapper separate from the TypeScript generator at
`scripts/docs/mcp-page.md`.
- Generate through `packages/cli/local.js` so CLI guidance and its
documentation are reviewed together.
- Let `check:generated-docs` reject CLI changes that leave the committed
MCP page stale.
- After both GitHub release creation and package publication succeed,
fast-forward the read-only `docs` branch to the immutable release tag
commit. A divergent update fails instead of publishing a different
revision.
- Configure GitBook to publish `/docs` from the `docs` branch, not
directly from `main`.
- Exclude `/docs` from the repository-wide `oxfmt` scan so imported
GitBook Markdown retains its established formatting; generator tests and
stale-output checks still validate the MCP page.
- Exclude `transcripts/` and GitHub Discussions from the migration.

## Todo

- [x] Import documentation, navigation, includes, and assets under
`/docs`.
- [x] Generate the MCP page from the local CLI source.
- [x] Move MCP generation and validation into Builder.
- [x] Require MCP documentation updates alongside CLI changes.
- [x] Publish released revisions through a read-only `docs` branch.
- [x] Remove Community repository links from Builder and the migrated
docs.
- [x] Preserve and verify a final Community Git bundle locally.
- [ ] Merge this pull request.
- [ ] Let the next successful release create or advance the `docs`
branch.
- [ ] Repoint GitBook Git Sync to `webstudio-is/webstudio`, branch
`docs`, root directory `/docs`.
- [ ] Verify `docs.webstudio.is`, navigation, assets, anchors, and the
MCP page in production.
- [ ] Delete `webstudio-is/webstudio-community`.

## Verification

- `pnpm check:generated-docs`
- `pnpm lint`
- `pnpm oxfmt --check`
- `git diff --check origin/main...HEAD`
- generator regression test demonstrated failing when the GitBook
wrapper behavior was removed, then passing after restoration
- no fixture inputs or outputs are affected

## Known limitation

All documentation merged after the previous release waits for the next
successful release before GitBook publishes it. This deliberately keeps
the public MCP reference aligned with an installable CLI revision.

Ref #5986
2026-08-03 17:55:50 +02:00

4.4 KiB

description
description
Add checkbox inputs to forms in Webstudio.

Checkbox

See MDN: <input type="checkbox">

The Checkbox component creates an HTML checkbox input for boolean selections.

Overview

Checkboxes allow users to select one or more options from a set, or toggle a single option on/off.

Properties

Property Type Description
name string Form field name
value string Value submitted when checked
checked boolean Whether the checkbox is checked
required boolean Whether selection is required
disabled boolean Whether input is disabled
id string Unique identifier
class string CSS class names

Basic Usage

Single Checkbox

For a single yes/no option:

Label (display: flex, align-items: center, gap: 8px)
├── Checkbox (name: newsletter, value: yes)
└── "Subscribe to newsletter"

Checkbox Group

For multiple selections:

Box
├── Label
│   ├── Checkbox (name: interests, value: design)
│   └── "Design"
├── Label
│   ├── Checkbox (name: interests, value: development)
│   └── "Development"
└── Label
    ├── Checkbox (name: interests, value: marketing)
    └── "Marketing"

When submitted, all checked values are sent with the same name.

Styling Checkboxes

Native Styling

Browser checkboxes can be styled with:

  • accent-color: Change the checked color
  • width/height: Adjust size
  • cursor: pointer: Show clickable cursor

Custom Checkbox

For fully custom checkboxes, consider using the Radix Checkbox component, which provides complete styling control while maintaining accessibility.

Form Submission

Single Checkbox

If checked, sends: name=value If unchecked, nothing is sent

Multiple Checkboxes (same name)

Sends all checked values: interests=design&interests=development

Validation

Required Checkbox

For required checkboxes (like terms acceptance):

Label
├── Checkbox (name: terms, required: true)
└── "I agree to the terms and conditions"

The form won't submit until the checkbox is checked.

Accessibility

  1. Always use labels: Associate every checkbox with a label
  2. Group related checkboxes: Use fieldset and legend for groups
  3. Provide clear labels: Make options self-explanatory
  4. Keyboard support: Ensure checkboxes work with Space key

Grouping with Fieldset

Box (role: group)
├── Text (role: legend) → "Notification Preferences"
├── Label
│   ├── Checkbox (name: notify, value: email)
│   └── "Email notifications"
└── Label
    ├── Checkbox (name: notify, value: sms)
    └── "SMS notifications"

States

Style different checkbox states:

State Description
Unchecked Default empty state
Checked Selected state
Disabled Cannot be interacted with
Focus Keyboard focus visible
Indeterminate Partial selection (JavaScript only)

Best Practices

  1. Use for multiple selections: Use checkboxes when users can select multiple options
  2. Label clickable: Make entire label area clickable
  3. Vertical alignment: Stack checkboxes vertically for easier scanning
  4. Reasonable defaults: Pre-check options when appropriate
  5. Clear labeling: Use positive phrasing (what happens when checked)

When to Use

Use Checkbox Use Radio Use Toggle
Multiple selections Single selection from many On/off setting
Optional agreements Required choice Immediate effect
Filter options Exclusive options Settings