[TextField] Long labels break layout

[csantos1113]

The textfield layout is not responsive when there are long labels.

• This is a v1.3.1 issue.
• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

According to Material Design, long labels should be correctly positioned within the available input space:

Current Behavior

• Two or more line labels are overlapping the underline line.

Steps to Reproduce

https://codesandbox.io/s/6xjr79vx3w

import React from 'react';
import TextField from '@material-ui/core/TextField';

class TextFields extends React.Component {
  render() {
    return (
      <form noValidate autoComplete="off">
        <TextField
          id="name"
          label="This is a long label because things"
        />
      </form>
    );
  }
}

export default TextFields;

Context

• All content is usually content managed, which means that the content editors could enter in label that may break the layout.
• If the enter in a label that is longer than the available space, example: "Do you have any association with a government entity?", and the user is loading the page in an iPhone 5, there is no enough space to render the label in only one line.

Your Environment

Tech	Version
Material-UI	v1.3.1
React	v16.4.1
browser	Chrome

[oliviertassinari]

@csantos1113 We can try to solve the issue by inverting the positioning strategy. We should be able to use bottom: 0 over top: 0.
https://github.com/mui-org/material-ui/blob/d2c16fc3e36691cd7dfdd6e4c1ed46147305f4cb/packages/material-ui/src/InputLabel/InputLabel.js#L18
Do you want to work on it?

[kybarg]

@csantos1113 @oliviertassinari
From specs:

Labels should be short in other case use helper text instead

[oliviertassinari]

@kybarg It should, but we have the opportunity to make the implementation more flexible without extra cost. Well, in the case of the outlined text field, it's a dead-end, the text won't stay within the parent background boundaries.

[oliviertassinari]

Alright, we can forget about the bottom positioning strategy. It won't work with multiline text fields

Let's not support this use case for simplicity.

[bmaclean]

@oliviertassinari Just wondering what the resolution to the issue was, and how I should handle multiline labels (specifically as long labels condense on mobile devices). Thanks!

[oliviertassinari]

The resolution is: we don't support it, we don't want to support it. I would encourage you to increase the width of your input, or to reduce the width of your label or to use the helper text under the input.

[ErikParso]

Any workaround on this issue ? My labels are dynamic with diferent lenghts. At least, is there a way to disable wrapping and set text overflow to ellipsis ?

[oliviertassinari]

I would recommend that you implement a hard ellipses logic: if .length > x then cut and add ....

[ErikParso]

Sorry this wont work with respinsive design and various label texts. Ill give it a try if there wont be another solution. If i only could determine if label overflows, i could use helper text sa you recommended instead.

[oliviertassinari]

Yes, you could also use layout measurements.

[ErikParso]

I found a workaround to trim label with ellipsis

.label {
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
    right: 22px; //do not overlap icon
    bottom: 0px; //maximize container height so label wont be cut horizontaly
}

.label-shrinked {
    right: unset; //show complete label if shrinked
}

and in my component

...
<InputLabel
    classes={{
        root: styles.label,
        shrink: styles["label-shrinked"]
    }}
    id="label">

    {this.props.text}
</InputLabel>
...

result looks like this:

[oliviertassinari]

Thanks for sharing.

[zehawki]

The resolution is: we don't support it, we don't want to support it. I would encourage you to increase the width of your input, or to reduce the width of your label or to use the helper text under the input.

Would you all be willing to reconsider the decision on this issue? Irrespective of what the Goog says, the world is full of long questions in forms. The idea of short labels only holds good for limited cases of "username / password / address / credit card" and the like. I can give dozens of examples of long questions in forms, that needs be there, and not all of it can be turned into helper text. Eg surveys / questionnaire are terrible on small screens.

[eps1lon]

Re-opening since we should have a documented, simple workaround for automatically scaling the textfield so that it fits the label.

[oliviertassinari]

@zehawki #12255 (comment) this is outdated, it's how v4 behaves. We changed the solution in v5 with #25012.

What version are you using? What's the visual output that you see? What solution do you envision?

[zehawki]

@oliviertassinari I saw that as well (I looked thru all the issue threads around this issue), and I beg to differ with that solution. Its not good UX. I saw a similar comment from another person: #26248 (comment)

Starting here https://next.material-ui.com/components/text-fields/. This shows me v5.0.0-beta.1. From there to https://codesandbox.io/s/461qq?file=/demo.js&resolutionWidth=320&resolutionHeight=675, and I changed one of the labels, which gives me:

and

As you can see, this is very troublesome.

I'm truly sorry to bring up this issue again, after its gone through so much churn thru the years :-(

---

What version are you using?

I'm on v4.11.

What's the visual output that you see?

What solution do you envision?

[zehawki]

Oh here is a possibly elegant solution - one that is no longer available in v5 due to the (...) change.

When the label is looooooong, one could use a Multiline version of the textlabel. This together with a rows prop (set to say 3 or 4), would make it just perfect. Eg https://codesandbox.io/s/2jtq9

Edit: Nope doesnt work out of the box.

[ErikParso]

Another good workaround for me was to position label using transform-origin bottom property instead of top. Using this approach label will be aligned on bottom also when wraps. Doesn't work with multiline edits :/

or you can try to use calc in shrinked transform transform: translate(14px, calc(-75% + 6px)) scale(0.75);

[Angelk90]

@oliviertassinari : In reference to these two comments.
#26781 (comment)
#26781 (comment)

[ashishBharadwaj]

this is outdated, it's how v4 behaves. We changed the solution in v5 with #25012.

For anyone trying to resolve this is v4..
Adding the following style fixes it...

.MuiInputLabel-root{
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  max-width: 80%;
  height: 100%;
}
.MuiInputLabel-shrink{
  max-width: 109%;
}

[oliviertassinari]

Regarding the next step on this issue, AFAIK, this is not solvable within the Material Design methodology.

However, we are working on second design system, code name Joy. I think that it would be great to evaluate using a similar layout to Bootstrap, with an isolated label and input. Meaning no floating label. This has been a controversial topic, e.g. https://www.smashingmagazine.com/2021/02/material-design-text-fields/. cc @siriwatknp

[eps1lon]

Regarding the next step on this issue, AFAIK, this is not solvable within the Material Design methodology.

It is definitely solvable. The problem is integrating the solution with backwards compatibility.

[oliviertassinari]

It is definitely solvable.

@eps1lon Ah, nice. Could you expand on the solution with the floating label of Material Design? :) Maybe a community member could then take it on in a PR.

[Mireille-Medhat]

Another good workaround for me was to position label using transform-origin bottom property instead of top. Using this approach label will be aligned on bottom also when wraps. Doesn't work with multiline edits :/

or you can try to use calc in shrinked transform transform: translate(14px, calc(-75% + 6px)) scale(0.75);

Hi @ErikParso, do you happen to have a sandbox for this? I am trying to do what you described above and it is not working for me. Thanks.

[garg10may]

transform-origin bottom property instead of top.

Can you please provide a sandbox

[simon-guider]

This issue has been open since 2018 and is still not resolved. Has anyone managed to resolve this issue locally?

[ErikParso]

This issue has been open since 2018 and is still not resolved. Has anyone managed to resolve this issue locally?

I changed it in theme and set label positioning from bottom (changed transformOrigin to bottom left) so text will move upside when it wraps.

	MuiInputLabel: {
		styleOverrides: {
			standard: {
				marginBottom: 0,
				top: 'unset', // label will be positioned from bottom
				bottom: 0, 
				transform: 'translate(0, -16px) scale(1)', // in normal state label is 16px from bottom
				'&.MuiInputLabel-shrink': {
                                            whiteSpace: 'normal', //allow shrinked label to wrap
					maxWidth: 'unset',
					right: '-33%', // add more space for label when it shrinks
					transformOrigin: 'bottom left', // set label positioning from bottom
					transform: 'translate(0, -47px) scale(0.7777)', // when shrinked label is 47px from bottom
				},
			}
		}
	}

Change label position as you want.

Result looks like this

[simon-guider]

@ErikParso thank you for the reply, unfortunately, this method does not seem to work with MUI v5.x

[ErikParso]

@ErikParso thank you for the reply, unfortunately, this method does not seem to work with MUI v5.x

You have to transform label slightly higher and to the right (16px) in your case.
for non shrinked use 'translate(16px, -36px) scale(1)'
for shrinked use 'translate(16px, -67px) scale(0.7777)'
Adjust height as suits you best

[zehawki]

Regarding the next step on this issue, AFAIK, this is not solvable within the Material Design methodology.

As @oliviertassinari mentioned up in this thread, I've also come to believe that its not solvable in MUI because this is how its designed in Google's material design for text fields (aka chic-but-useless). Google itself has been conflicted in form field design. This format was intended for short fields (username / email and the like), and is not meant for long fields. As one can see there are dozens of examples on that page with short fields.

All the methods proposed in this thread either lead to loss of info or legibility and/or cognitive overload - which is basically bad UX, and form fields being really important cannot afford to have poor UX.

One is better served by using a classical format for text fields. We ourselves have adopted this practice and its relieved our customers and end users.

Real examples:

Google material design:

Classical:

---

For non-english characters and perhaps even non-sophisticated audiences, we find it better to use classical format for forms, even for short fields.

Google material design:

Classical:

---

And all our text fields are also classical:

[brsjak]

I've solved this issue by overriding the MUI MuiFormLabel-root class in my global CSS file.
.MuiFormLabel-root { white-space: break-spaces; }

[siriwatknp]

As pointed out by @zehawki, I think long label should not be used with floating label. I think a suggestion on the docs and example of tacking the long label is the solution to this issue.

Anyway, I am closing this because we aim to have a fresh look for Material UI in the near future.

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

Note

@csantos1113 How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.

[oliviertassinari]

I'm reopening because I believe we will need to support the outline input, even in this new design direction. e.g. https://www.twilio.com/login I don't see this going away,