@bmartinezcalvo On the open question of 'clearable' element: I would not advise a clearable icon to Textarea. It's an element in all used in single line inputs and there specifically to my knowledge in nearly all cases only in search input fields.
As it's not common, it would be more confusing to users and it would open up issues like extra padding on the right over the full vertical length leading to imbalanced layout.

How do we feel about including a character count, either a pure count (e.g. 52), a limit (e.g. 100), or a dynamic status (e.g. 52/100)? I see this in one of the Growth team's use cases, and think it would be a helpful feature to include.

That seems like a necessity to me, see VE's edit summary dialog

Probably not for the MVP though…?!

I agree that it doesn't need to be included for MVP. It might be a fun subsequent task to work on for our intern, though, if we get to it.

In T284272#8598321, @AnneT wrote:

How do we feel about including a character count, either a pure count (e.g. 52), a limit (e.g. 100), or a dynamic status (e.g. 52/100)? I see this in one of the Growth team's use cases, and think it would be a helpful feature to include.

@AnneT I would move the character counter to the helper text section in order to avoid the character counter being mixed with the text area content when the text is long.

Characters counter in the helper text section	Characters counter within the text area

@bmartinezcalvo Exactly, the extra padding on within the text area is ending up imbalanced and looses valuable space for user input. It also aligns with the VE edit summary dialog.

@bmartinezcalvo makes sense!

Question about the helper text: is this specific to the Textarea component, or will it be a standard part of most form elements? I'm trying to figure out if that would go in the Textarea component itself, or in a generic Field component that contains a Label, form element, inline validation message, and helper text

Looks good to me @bmartinezcalvo.

Regarding the counter I agree with having it outside the field in the helper text section and right aligned.

In the documentation should we provide guidelines for how tall the input should be as default, and for how it should be adapted in designs? It is usually good practice to make the height of a textarea proportional to the amount of text you expect users to enter – so they have a rough idea of what is expected of them.

In T284272#8598578, @AnneT wrote:

Question about the helper text: is this specific to the Textarea component, or will it be a standard part of most form elements? I'm trying to figure out if that would go in the Textarea component itself, or in a generic Field component that contains a Label, form element, inline validation message, and helper text

@AnneT helper text is a text that provides the user about relevant info to include in the field. It's an element that should be added in Textarea but also in some other form items such as TextInput. So I would create Helper text if possible as a separate component. At the moment I think we are using InlineMessage for feedback messages below the Inputs, but I think helper text it's a different element.

So yes, I think any form item should include:

• Label
• Field (Textarea, TextInput, etc.)
• Helper text (if needed) to provide important info to add in the field (e.g. "use just numeric characters") and that could have also a character counter on the right for the text area.
• Inline message (if needed) to provide feedback to the user (e.g. the error message)

In T284272#8600785, @KieranMcCann wrote:

Looks good to me @bmartinezcalvo.

Regarding the counter I agree with having it outside the field in the helper text section and right aligned.

In the documentation should we provide guidelines for how tall the input should be as default, and for how it should be adapted in designs? It is usually good practice to make the height of a textarea proportional to the amount of text you expect users to enter – so they have a rough idea of what is expected of them.

@KieranMcCann I've detected the following sizes use cases that will be included in the final spec sheet:

• Min size: we could use 64px or 128px. I lean towards 64px as min-size since the user will sometimes not need to add more than 2 text lines. But let me know your thoughts.
• Apart from the min sizes, we could improve the following props:
  • Grab: when grabbing, the user could resize the component's width and height.
  • Scroll: a scroll could appear when the text area height is fixed.
  • Autosize: text area could grow with the length of the text automatically.

The HTML <textarea> component has an attribute called row that is the number of visible lines of text, determining the height of the element. I'd recommend we allow users to bind the row attribute to the CdxTextarea component, which will then apply it to the <textarea> element within.

For the 3 other props you mentioned (grab, scroll, and autosize), I think we will just need a single prop: autosize. If set to false, the grabber will be present, and scroll will appear if the text is longer than the visible window. If autosize is set to true, the grabber will not be present, and scroll will not appear because the element will keep growing as more text is added.

This is how the OOUI MultilineTextInputWidget works.

We'll also want to think about the horizontal width...<textarea> also has an attribute for columns to set the initial width, but we might want to default to 100% width, right?

Agreed on using row. A min-height (and if so the smaller one of 64px) could still be useful to more clearly visually differentiate to a single-line TextInput.
columns on the other hand often seems like black magic (what is a column's width?). I'd refer to full-size context-specific.

Looks good to me @bmartinezcalvo

@RHo let us also know your feedback on the design spec before sending the task to Ready for Development.

Sorry I'm late, but per @AnneT and @Volker_E's earlier comments, could we add character count as a follow up task to MVP? There was some old explorations that recall being made when multilingual captions were being worked on for the Structured Data on Commons project which accounted for difference use-cases that would be useful to include:

• Minimum character limit - this is in use on Growth's Add image task as well as Commons captions
  
• Max character limit - this could be expressed as incrementing to a total char count, or else countdown to being over, and possibly even highlighting extra characters like twitter does
  
• Word count min/max limits - this might be out of scope for char count follow up but in the case of captions, min. word count is what would have been preferred for more languages.

In T284272#8637150, @RHo wrote:

Sorry I'm late, but per @AnneT and @Volker_E's earlier comments, could we add character count as a follow up task to MVP?

@RHo I guess characters count will be implemented as part of Field component in T309239.

In T284272#8637896, @bmartinezcalvo wrote:

In T284272#8637150, @RHo wrote:

Sorry I'm late, but per @AnneT and @Volker_E's earlier comments, could we add character count as a follow up task to MVP?

@RHo I guess characters count will be implemented as part of Field component in T309239.

Thanks! Re-posting to the right task.

The TextArea design spec expects the grabber /resize tool to have 4x padding.

I haven't been able to find a simple solution to adding the padding to the grabber. One solution is creating a custom grabber tool that we can target and apply the styles needed. We'd also have to ensure the custom grabber is properly aligned when textarea height grows.

@bmartinezcalvo and I agreed on removing this from the design spec since it was a low priority.

I'm open to discussion with the team.

+1 to this decision, it would be hard/impossible to get a custom grabber consistent across browsers, so using the browser-provided one seems like the safer route

In T284272#8910548, @lwatson wrote:

The TextArea design spec expects the grabber /resize tool to have 4x padding.

I haven't been able to find a simple solution to adding the padding to the grabber. One solution is creating a custom grabber tool that we can target and apply the styles needed. We'd also have to ensure the custom grabber is properly aligned when textarea height grows.

@bmartinezcalvo and I agreed on removing this from the design spec since it was a low priority.

I'm open to discussion with the team.

@lwatson updated the Figma exploration file and the Figma library with this decision.