Text area height is relative instead of fixed

[nwhittaker]

Check existing issues

• I have checked for existing issues to avoid duplicates

Actual Behavior

The height of the text-area component is, by default, relative to its container.

Expected Behavior

The height of text area component is fixed, by default.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/QWoLyww?editors=1100

Reproduction Steps

1. Visit the reproduction sample and see the height of the text area matches the height of the body element.
2. Resize the height of the preview area to see the height of the text-area changes.
3. Interestingly, the height of the text area becomes fixed after sizing the height of the preview area all the way down to zero, and back up.

Reproduction Version

2.1.0

Relevant Info

Giving the text-area component a block-size of auto addresses the immediate issue. Not sure if that introduces other layout issues, though…

Regression?

No response

Priority impact

p3 - want for upcoming milestone

Impact

The behavior is surprising and unexpected because it represents a departure from how the native textarea element works. As a result, it requires a workaround to address in certain scenarios.

For a more real world example, consider a text-area with validation. Depending on how the label/input/message components are laid out across slots and shadow DOMs, hiding/showing the message can cause the text area to continuously grow:

Screen.Recording.2023-12-19.at.12.31.03.PM.mov

Calcite package

• @esri/calcite-components
• @esri/calcite-components-angular
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Field Apps

[anveshmekala]

hi @nwhittaker , as you mentioned setting width & height to auto resolves the issue.

• Currently, text-area has width & height set to 100% at :host which makes it relative to the container it is rendered. We received feedback regarding the issue related to this approach and are considering to set the width & height to auto and change the display to block. Will update this thread.

• Regarding the second issue where viewport height & width is set to 0, setting the var(--calcite-text-area-min-width): 0 would resolve it.

Curious about the repro case for the issue attached in video. Thank you!

[nwhittaker]

Regarding the second issue where viewport height & width is set to 0, setting the var(--calcite-text-area-min-width): 0 would resolve it.

@anveshmekala, I'm seeing the issue when manually resizing the viewport quickly. Interestingly, I don't see the issue when I resize slowly. Setting --calcite-text-area-min-width or --calcite-text-area-min-height did not seem to make a difference.

Here you'll see the first resize is slow and doesn't lock the textarea's height. The second resize is fast and does lock the textarea into a fixed height:

Screen.Recording.2025-01-22.at.1.35.43.PM.mov

---

Curious about the repro case for the issue attached in video. Thank you!

I don't have an exact repro as I suspect some shadow-dom interplay with custom components was causing the text-area's new height to stick.

However, I do have a simplified repro. showing the height of the text-area changing in response to valid and vs. invalid input. I suspect resolving this behavior would also address the more complicated issue.

Screen.Recording.2025-01-22.at.2.08.38.PM.mov

[nwhittaker]

I figured out a simplified repro. for the ever-increasing height behavior and spun off a new issue to capture it.