Better textFormField label placement customization when focused and when value input- vertical floatingLabelAlignment feature.

[SexyBeast007]

Use case

I want some fine tuned, detailed customization for my textFormField. Currently, when the field becomes focused (and permanently when a value is input) the floating label floats up to the border & cuts it. The label sits vertically in the centre of the border and the label cuts the border. While this does look okay for some field configurations, such as some rectangular fields, it looks horrible for others. Specifically mine looks gross. I have a beautiful design from my designer and I want to keep with this.

This is a problem for me and my design, not specifically a problem with the textFormField.

Haven't found a package that does this but, here is some code that does solve this problem. It is a bit of a hack because it requires external state and container wrapping logic to exteriorly handle a textFormFields border outline. This is definitely NOT OPTIMUM and I do NOT want to have to use this solution. The full SO post can be found here.

class TextFieldDesignPage extends StatefulWidget {
  TextFieldDesignPage({Key? key}) : super(key: key);

  @override
  _TextFieldDesignPageState createState() => _TextFieldDesignPageState();
}

class _TextFieldDesignPageState extends State<TextFieldDesignPage> {
  // Use it to change color for border when textFiled in focus
  FocusNode _focusNode = FocusNode();

  // Color for border
  Color _borderColor = Colors.grey;

  @override
  void initState() {
    super.initState();
    // Change color for border if focus was changed
    _focusNode.addListener(() {
      setState(() {
        _borderColor = _focusNode.hasFocus ? Colors.orange : Colors.grey;
      });
    });
  }

  @override
  void dispose() {
    _focusNode.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Container(
          margin: EdgeInsets.all(8),
          decoration: BoxDecoration(
            border: Border.all(color: _borderColor),
            borderRadius: BorderRadius.circular(4),
          ),
          child: TextField(
            focusNode: _focusNode,
            style: TextStyle(color: Colors.grey),
            keyboardType: TextInputType.number,
            decoration: InputDecoration(
              contentPadding: EdgeInsets.zero,
              border: InputBorder.none,
              labelText: "Amount",
              prefixIconConstraints: BoxConstraints(minWidth: 0, minHeight: 0),
              prefixIcon: Padding(
                padding: EdgeInsets.symmetric(vertical: 18, horizontal: 8),
                child: Text("₦", style: TextStyle(fontSize: 16, color: Colors.grey)),
              ),
            ),
          ),
        ),
      ),
    );
  }
}

Please take note that the label "Amount" floats to the TOP of the textFormField but does NOT touch or intercept the top border. This is EXACTLY what I would want and I think could be very useful. While this works, the code is hacky and not streamlined. This would also not work with theme for Outline borders for error, at least without the state that is proposed in the hacky solution.
The hacky solution looks like this, PLEASE NOTE, this is exactly what is desired effect visually and functionally but the code aspect needs working into the very fabric of the textFormField API.
[

Here is the default field behaviour and what I DO NOT WANT, please notice how the label cuts the border and is moved too high. 🤮
[

Proposal

Here is my design example:
<!--

The solution I can see (non code descriptive) is to provide a verticalFloatingAlignment property to customize the height the label floats to when focused or filled out. This would also require the textFormFields content to be slightly lower than normal to allow space for the floating label to share space in an aesthetic fashion.

No package does this that I could find.

Also this is very much the same issue/feature request. It has been closed and looks to be HUGELY misunderstood. The issue has NOT been solved and the feature does NOT exist.

Thank you for taking the time to help with this feature.

[exaby73]

Hello @SexyBeast007. Thank you for filing this request. This issue goes against the Material guidelines for text fields you can find here. Since Flutter follows Material guidelines, this does not seem like a valid request to me. Therefore, I am closing this issue. If you disagree, please comment and we can reopen it. Thank you.

[SexyBeast007]

@exaby73 Can you please tell me specifically what this proposal collides with in Material guidelines?

I searched and couldn't find anything specific. As a matter of fact, my design is very similar to underline text fields in that the label floats up just above the input content. Surely a border around it all doesn't hinder anything that I could find.

[exaby73]

If you see the section on label text, you see 2 types of labels used, one with the filled text field which is similar to yours and one with the outline text field which cuts the top border of the text field.

I am in no way an expert here, so I'll label this issue for further insights from the team. Thank you.

[SexyBeast007]

Just curious how long it might take to have something like this implemented if is accepted?

[fras2560]

There any update on this issue?

I am in a similar boat where design calls for the label to not overlap the border.

[lastmeta]

I have a very similar issue to, but I've solved almost all of it, except one part that is hard coded deep in the flutter framework (which I've put in a pull request to parameterize).

I'll share what I did here, but take a look at my issue: #130030.

So I broke the problem down into 3 different problems.

1. background color and shape, and placement
2. border
3. label placement

My situation is easier because I don't have a (responsive) border to deal with. But my background is curved. So I made the TextField transparent and borderless. Then I wrap it in a Stack with a Container behind that has the correct shape and placement of that shape. Using the contentPadding in the TextField I can control where the text shows up, how far away the error text is, etc, I place it below the shape.

The only thing I don't have control over here distance between the label and the text content. that's why I issued a pull request to parameterize that part. once that's accepted I'll be able to specify floatingLabelGap: 0.0 in the InputDecoration and the label will show where it is in our design.

As you can see this is a piecemeal solution, which is never ideal, but sufficient. This isn't a whole perfect solution, but it solves the issue with minimal addition to (and no alteration of) the flutter framework.

Stack(children: [
  Column(children: [
    SizedBox(height: 4),
    Container(
      height: 64,
      decoration: ShapeDecoration(
        color: Color(0xFFE8EAF6),
        shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(28 * 100)),
      ),
    ),
  ]),
  TextField(
    decoration: InputDecoration(
      border: InputBorder.none,
      alignLabelWithHint: true,
      contentPadding: EdgeInsets.only(left: 20, top: 14, right: 14, bottom: 20),

      /*** might not be necessary to specify, but might be helpful to see: ***/
      filled: false,
      fillColor: Colors.transparent,
      focusColor: Colors.transparent,
      focusedErrorBorder: InputBorder.none,
      errorBorder: InputBorder.none,
      focusedBorder: InputBorder.none,
      enabledBorder: InputBorder.none,
      disabledBorder: InputBorder.none,
      /*** end of might not be necessary to specify ***/

      ...
    ),
    ...
]);

[justinmc]

Does @lastmeta's PR (#130039) solve this issue for anyone experiencing this?

[flutter-triage-bot]

This issue is missing a priority label. Please set a priority label when adding the triaged-design label.

[flutter-triage-bot]

This issue is assigned to @lastmeta but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

[lastmeta]

This issue is assigned to @lastmeta but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

For anyone who is curious, the reason this issue hasn't had activity is I'm too tired to fight for it. It's an (above all else) simple, but also easy, effective, and minimal solution. But person after person pushed back on it. Until finally someone suggested they know of a better (unarticulated and still yet unmaterialized) way to handle the situation altogether. Ok then.

Congrats, the bureaucracy won, my many hours of effort to implement a tiny improvement to the code base, amounting to essentially one line of code was simply no match for the it!

[Vanchel]

For those who might encounter a similar issue, here is my workaround. I created my implementation of InputBorder (similar to OutlineInputBorder or UnderlineInputBorder). The key difference is that it positions the label inside the border, eliminating any gap on the border for the label. Here's the gist.

I hope this solution can be convenient as it doesn't introduce any additional wrappers and can be used quite universally. For example, you can use this InputBorder implementation directly in your theme.

There are relatively few differences from the OutlineInputBorder implementation to be fair, and most of the code is simply copied. The main change is that the isOutline getter returns false (similar to UnderlineInputBorder), as this value determines where the label will be positioned. Keep in mind that this value is taken into account for some other minor parameters, so you would possibly want to check how InputDecorator handles it to ensure that my solution suits your needs. For example, you may want to specify custom contentPadding value. I also modified the logic for drawing the border on the canvas to avoid adding any gap for the label, but there shouldn't be any unexpected issues here, as far as I understand.