Tokenized Input

[origami-z]

Description

only grows when adding more pills (not shrinking down to 1 line when out of focus)

Tasks

### Checklist
- [ ] Density (HD, MD, LD, TD)
- [ ] Mode (Light, Dark)
- [ ] Fill (Primary, Secondary, Tertiary)
- [ ] State (Default, Hover, Selected/Active, Disabled, Read-only, Other)
- [ ] Controlled API
- [ ] UITK accessibility parity (screen reader + keyboard interactions)

### Deliverables
- [ ] Characteristics spec
- [ ] Interactions spec, where necessary
- [ ] In Code & Figma (Component + Guide)
- [ ] Supporting site documentation

### Dependencies
- [ ] #2538
- [ ] #2539

[origami-z]

18 Oct - Removed from release plan due to dependency of Pill

[origami-z]

13 Nov - picking up again, starting from previous design spec

[Fercas123]

• POC review planned for TI on 16/11,
• Ongoing conversations about input adornments will fix some issues with pill inside MLI
• MinWidth change required in pillNext

[origami-z]

17 Nov - POC dev meeting yesterday. Updated some implementation , no blocker, to check whether Multiline is needed or not.

[origami-z]

20 Nov - working on styles & types. Most func done. Aiming for review on Wednesday. No blockers.

[origami-z]

27 Nov - Go through component with designer later today (asking review afterwards), PR mostly ready, adding test ATM, drafting docs.

24 Nov - ready for 1st round of dev review (KO), ETA middle of next week

22 Nov - did some tweak based on feedback, aiming for dev review tomorrow, tests to be written. Moving to amber.

[Fercas123]

Questions looking to be resolved in KO/conversation on 27/11:

• should input have height 100%
• hover on highlighted
• pills gap
• close button height, on pill or TI?
• TI Next, or should we modify types in deprecated usages
• tab navigation currently focuses close buttons in pill.

[Fercas123]

from the conversation:

height to follow content height tab back should not navigate gap: 50 it will be a next component clone input to achieve in line adornments one colour highlights, light like it does in text

[origami-z]

1 Dec - Content review addressed, pending dev and design reviews

[origami-z]

4 Dec - same as above, needing more review

[origami-z]

6 Dec - design & dev review needed

[origami-z]

8 Dec - pending review (code & design qa)

[origami-z]

11 Dec - Review pending

[joshwooding]

18 Dec - Updated the docs, ready for reviews. Confident about getting this across the line. @dplsek to take a look at the design review

[joshwooding]

20 Dec - Had a review session with @bhoppers2008 @dplsek

[joshwooding]

09/01 - Addressed feedback, reading for review. Need to discuss the Pill work #2871. Need to discuss design question.

[Fercas123]

17/01 - merged to Labs, ready for 'Core' review

[joshwooding]

Paused due to accessibility concerns and will be looked into as part of #2875

[mark-tate]

As of Q2, we don't have a use-case for this, it was previously thought we needed this for ComboBox but we decided against creating it as a standalone component and composed the functionality within ComboBox instead.

If you have a use-case that requires a standalone Tokenized Input then let us know. You can create a TokenizedInput (Input + Pill) yourselves but be advised that accessibility support, particulary around keyboard/focus needs some consideration. Potentially a good contribution, once a standalone use-case is clear, talk to us first though, through this issue.

Parking in Q3 for now.

[mark-tate]

Moving to Q4 until a use-case surfaces

[origami-z]

Sourcegraph search reveals at least 189 <TokenizedInput usages .

User reported #3024 as well.