Some notes:

• We'll need to add a design spec to this task
• If this task is implemented by someone outside the Design System Team, we can talk about splitting up the acceptance criteria to make the work more manageable. For example, a Codex volunteer could implement the functionality, but then someone from the Design System Team could add the new demos

Just to confirm, is this a hard blocker to T362583?

@AnneT provided some examples of similar UI:

• In Adiutor, there's a checkbox that shows a text input field when checked. I will note that it's not styled according to our designs (see screenshot)
• In ReportIncident, there's a checkbox that shows a text area when checked.

{F48839978}

Hi @CCiufo-WMF

Yes that's correct, it's not a hard blocker.

If you are happy to, then the contractors can develop a version for now and work to update it with the Codex component when ready?

In the meantime I will work on the design spec with Bárbara's guidance.

In T363416#9749787, @CCiufo-WMF wrote:

Just to confirm, is this a hard blocker to T362583?

@AnneT provided some examples of similar UI:

• In Adiutor, there's a checkbox that shows a text input field when checked. I will note that it's not styled according to our designs (see screenshot)
• In ReportIncident, there's a checkbox that shows a text area when checked.

{F48839978}

In T363416#9752949, @KColeman-WMF wrote:

Hi @CCiufo-WMF

Yes that's correct, it's not a hard blocker.

Perfect, thank you!

If you are happy to, then the contractors can develop a version for now and work to update it with the Codex component when ready?

That sounds good. Let us know if they run into any issues. To confirm: are the contractors also open to upstreaming this to Codex? That might be faster than waiting for us to develop it.

Implementation

We will want to add a few new props to Checkbox and Radio (prop names are open for debate)

• showOther: a boolean prop that, when true, will add a TextInput or TextArea
• otherComponent: a prop that can either be 'text' or 'textarea', defaulting to 'text' (the name of these strings is also up for debate. This could also be a boolean prop like useTextArea or something)
• otherValue: the value of that input, bound with v-model:otherValue

The Checkbox and Radio templates will need to be updated to conditionally show the TextInput or TextArea, and appropriate styles will be added.

The proposed implementation seems a little clunky to me, and also inflexible. If we need to go back and later add support for a Select or Combobox component in the same way, we'd have to do additional work. Also, what if someone wants more custom markup beneath the text area (like a link to docs or a privacy policy)?

For a use case that is potentially very open-ended, I think we are better off handling this as a slot. Maybe we'd call it something like #customValue. This slot could hold arbitrary content inside an element that appears inline with the checkbox/radio button (unlike the #description slot content, which appears beneath). The user could take care of binding the value themselves. We could provide an example of how to set this up similar to our custom dialog examples.