Files
webstudio/docs/university/core-components/label.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

3.6 KiB

description
description
Add accessible labels to form inputs in Webstudio.

Label

See MDN: <label>

The Label component creates an HTML <label> element that provides an accessible name for form controls.

Overview

Labels are essential for form accessibility. They tell users what information to enter and allow clicking the label to focus its associated input.

Properties

Property Type Description
for string ID of the associated form control
id string Unique identifier
class string CSS class names

Associating Labels with Inputs

Method 1: Using for Attribute

Match the label's for attribute to the input's id:

Label (for: email)
  └── "Email Address"
Input (id: email, name: email, type: email)

Method 2: Wrapping

Place the form control inside the label:

Label
  ├── "Email Address"
  └── Input (name: email, type: email)

Benefits of Labels

  1. Accessibility: Screen readers announce the label when the input is focused
  2. Usability: Clicking the label focuses the associated input
  3. Touch targets: Increases the clickable area on mobile devices

Styling Labels

Typography

  • Font Weight: Slightly bolder than body text
  • Font Size: Same or slightly smaller than inputs
  • Color: High contrast for readability

Layout

  • Position: Above input (most common) or beside it
  • Spacing: Add margin between label and input
  • Alignment: Align with input edges

Required Field Indicators

Show required fields with visual indicators:

Label (for: email)
  ├── "Email Address"
  └── Span (class: required, color: red)
      └── "*"

Form Layout Patterns

Stacked Labels (Most Common)

Box
├── Label → "Name"
├── Input
├── Label → "Email"
├── Input
└── Button

Inline Labels

Box (display: flex, align-items: center)
├── Label (width: 100px) → "Name"
└── Input (flex: 1)

Floating Labels

Create floating label effect with CSS positioning:

  1. Position label absolutely over input
  2. On input focus/filled, translate label up
  3. Reduce font size when floating

Checkbox and Radio Labels

For checkboxes and radio buttons, wrap or associate labels:

Label (display: flex, align-items: center, gap: 8px)
├── Checkbox (or RadioButton)
└── "Accept terms and conditions"

This makes the entire label clickable.

Best Practices

  1. Always use labels: Every form control needs a label
  2. Be descriptive: Clearly describe expected input
  3. Keep it concise: Short, clear labels work best
  4. Mark required fields: Indicate which fields are required
  5. Don't rely on placeholders: Placeholders disappear, labels don't

Error Messages

Associate error messages with the field:

Label (for: email) → "Email"
Input (id: email)
Text (role: alert) → "Please enter a valid email"

Accessibility Tips

  • Use proper label associations
  • Include required field indicators in label text for screen readers
  • Group related fields with fieldset and legend
  • Ensure sufficient color contrast