You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds the text field migration plan — the Phase 1 (Preparation) planning output for the 1st-gen sp-textfield → 2nd-gen swc-text-field migration under Epic SWC-2325 (parent Epic SWC-2323).
This is a documentation-only change. It introduces one new planning document plus a single index entry:
The plan captures the full 1st-gen API surface, the recommended 2nd-gen API decisions, architecture (core vs SWC split), a phase-by-phase migration checklist, and the open questions/blockers that must be resolved before implementation. Headline recommendations: scope narrows to single-line (multiline moves to a separate swc-text-area); labelling and help/error move in-shadow via a shared LabellingController (SWC-2466) with form participation via a FieldAssociationController (SWC-2467); breaking changes include removing quiet, renaming label → accessible-label, and dropping the truncated-value tooltip.
The plan is explicitly provisional and its Blockers section is the review surface — see "Open questions for reviewers" below.
Motivation and context
The text field migration is a large, multi-phase effort with architectural decisions (single-line/multiline split, field-family sharing model, shared labelling/form-association controllers) that must be agreed before any code is written. Landing this plan first gives reviewers a single authoritative document to sign off on scope, breaking changes, and sequencing before Phase 2+ implementation PRs stack on top of it.
Open questions for reviewers
Please engage with the plan's Blockers and open questions section. The genuinely blocking item that gates implementation:
Q7 — field-family sharing model for number-field/color-field/text-area (shared base à la ButtonBase vs. controllers-only à la Tooltip/Popover vs. shared mixin à la progress-bar/meter). The decision hinges on how much the LabellingController renders (Q8) and pulls in Q22 (shared styles).
Effectively decided, needs acknowledgment only:
Q1 — remove the quiet variant. Three independent sources agree on removal (spectrum-css/Spectrum 2, the rendering analysis, and the S2 Figma matrix). The quiet use case (dense/table layouts) likely maps to the new inline variant (Q17). Design to acknowledge the breaking-change/consumer impact.
Design context and newer questions worth a look:
A full S2 state × variant matrix has been received (all four sizes × top/side label × five states × content/error variants). It confirms side-label as first-class at every size (Q2) and that there is no quiet variant; it does not cover readonly (Q3) or an explicit valid/checkmark state (both unconfirmed). Figma is the source of truth; exact token values still need extracting from Figma (Q20).
Q23 — in-field ContextualHelp placement ("in-field" per the plan vs. "next to the label" per React Spectrum); confirm the LabellingController API models description sources as an extensible set.
I have reviewed at the Accessibility Practices for this feature, see: Aria Practices
I have added automated tests to cover my changes. — N/A, documentation-only change (no code)
I have included a well-written changeset if my change needs to be published. — N/A, no published package is affected
I have included updated documentation if my change required it. — this PR is the documentation
Reviewer's checklist
Includes a Github Issue with appropriate flag or Jira ticket number without a link
Includes thoughtfully written changeset if changes suggested include patch, minor, or major features
Automated tests cover all use cases and follow best practices for writing
Validated on all supported browsers
All VRTs are approved before the author can update Golden Hash
Manual review test cases
Plan renders and navigates correctly
Open CONTRIBUTOR-DOCS/03_project-planning/03_components/text-field/migration-plan.md in the PR's Files changed tab
Confirm the generated breadcrumbs and TOC render and the in-page anchors resolve
Expect all headings/anchors to match with no broken internal links
Index entry is wired up
Open CONTRIBUTOR-DOCS/03_project-planning/03_components/README.md
Follow the newly added Text Field link
Expect it to resolve to the new migration plan document
Blockers section is coherent
Read the Blockers and open questions section
Cross-check the blocking item (Q7) and the 2026-08-18 design-context note against the API decisions
Expect every breaking change to map to a resolved decision or an open question
Device review
Did it pass in Desktop? — N/A, documentation-only change
Did it pass in (emulated) Mobile? — N/A, documentation-only change
Did it pass in (emulated) iPad? — N/A, documentation-only change
Accessibility testing checklist
This PR adds a planning markdown document only — there is no component, interactive control, or rendered UI introduced, and no runtime accessibility surface to exercise. (The plan's content specifies the 2nd-gen component's a11y requirements; those are implemented and tested in the Accessibility phase of the migration.)
Keyboard — N/A: no interactive/focusable parts are added by this change. Documentation renders as static prose.
Screen reader — N/A: no component roles, names, or states are introduced; standard markdown heading structure and links only.
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds the text field migration plan — the Phase 1 (Preparation) planning output for the 1st-gen
sp-textfield→ 2nd-genswc-text-fieldmigration under Epic SWC-2325 (parent Epic SWC-2323).This is a documentation-only change. It introduces one new planning document plus a single index entry:
CONTRIBUTOR-DOCS/03_project-planning/03_components/text-field/migration-plan.md(new)CONTRIBUTOR-DOCS/03_project-planning/03_components/README.md(index link)The plan captures the full 1st-gen API surface, the recommended 2nd-gen API decisions, architecture (core vs SWC split), a phase-by-phase migration checklist, and the open questions/blockers that must be resolved before implementation. Headline recommendations: scope narrows to single-line (multiline moves to a separate
swc-text-area); labelling and help/error move in-shadow via a sharedLabellingController(SWC-2466) with form participation via aFieldAssociationController(SWC-2467); breaking changes include removingquiet, renaminglabel→accessible-label, and dropping the truncated-value tooltip.The plan is explicitly provisional and its Blockers section is the review surface — see "Open questions for reviewers" below.
Motivation and context
The text field migration is a large, multi-phase effort with architectural decisions (single-line/multiline split, field-family sharing model, shared labelling/form-association controllers) that must be agreed before any code is written. Landing this plan first gives reviewers a single authoritative document to sign off on scope, breaking changes, and sequencing before Phase 2+ implementation PRs stack on top of it.
Open questions for reviewers
Please engage with the plan's Blockers and open questions section. The genuinely blocking item that gates implementation:
number-field/color-field/text-area(shared base à laButtonBasevs. controllers-only à la Tooltip/Popover vs. shared mixin à la progress-bar/meter). The decision hinges on how much theLabellingControllerrenders (Q8) and pulls in Q22 (shared styles).Effectively decided, needs acknowledgment only:
quietvariant. Three independent sources agree on removal (spectrum-css/Spectrum 2, the rendering analysis, and the S2 Figma matrix). The quiet use case (dense/table layouts) likely maps to the new inline variant (Q17). Design to acknowledge the breaking-change/consumer impact.Design context and newer questions worth a look:
quietvariant; it does not coverreadonly(Q3) or an explicit valid/checkmark state (both unconfirmed). Figma is the source of truth; exact token values still need extracting from Figma (Q20).LabellingControllerAPI models description sources as an extensible set.Related issue(s)
Screenshots (if appropriate)
N/A — markdown documentation only, no visual/UI change.
Author's checklist
Reviewer's checklist
patch,minor, ormajorfeaturesManual review test cases
Plan renders and navigates correctly
CONTRIBUTOR-DOCS/03_project-planning/03_components/text-field/migration-plan.mdin the PR's Files changed tabIndex entry is wired up
CONTRIBUTOR-DOCS/03_project-planning/03_components/README.mdBlockers section is coherent
Device review
Accessibility testing checklist
This PR adds a planning markdown document only — there is no component, interactive control, or rendered UI introduced, and no runtime accessibility surface to exercise. (The plan's content specifies the 2nd-gen component's a11y requirements; those are implemented and tested in the Accessibility phase of the migration.)