Feature request: official support for form-floating and input-group

[719media]

There are quite a few issues in regards to using form-floating with input-group, and the proper markup for such:
#34275
#34198
#33871
#33741
#33721
#33341

Bootstrap's reply is "not supported at this time". Makes sense. I really wanted to have this work, so went through various ways to make this happen. I think it can be supported fairly easily with just a few rule adjustments. So I'm leaving my findings here in hopes of discussion to support this in the main branch.

From my findings, there are 4 problems with using input-group with form-floating:

1. What is the proper markup? Some people are combining input-group with form-floating in the same element, which causes problems when you have prefixes to the input-group such that the form-control isn't the first element in the group. The benefit to this approach is that it (sort of) fixes some of the border-radius issues. However, IMO the floating issues would be very difficult to solve cleanly. So, form-floating used on a child element of input-group works best here.

2. z-index focus/hover issues. Solved by CSS rule.

3. border-radius issues. Solved by CSS rule.

4. form-control flex-grow issues. Solved by CSS rule.

My findings are most easily seen in the codepen provided below. I may be overlooking some cases, obviously. But, it seems to work for my purposes. Do you have any feedback?

Associated codepen:
https://codepen.io/nefiga/pen/VwbpdVw

Anyway, feel free to close this if these types of requests are driving you nuts, just figured I'd at least provide feedback on what I assembled over a few hours.

[719media]

Doing a little more testing, in some cases the form-floating input would break with a button funny as seen in the codepen above on small width screens (mobile).
I've addressed this fix by using an existing rule in bootstrap and just adding .form-floating to the definition
See
https://codepen.io/nefiga/pen/BaRRQrK

[719media]

Made a PR #34527

The above codepen (only important parts) with the PR:
https://codepen.io/nefiga/pen/dyWRWXK

I ended up using explicit .form-control and .form-select selectors, because otherwise the styling ends up applying to the <label> for example inside of the form-floating element (which isn't even really noticeable, but it would be dirty otherwise). I figured something like this was better:

.form-floating:not(:first-child) > .form-control,
.form-floating:not(:first-child) > .form-select,

Over something like

.form-floating:not(:first-child) > :not(label),

Obviously, if this is acceptable, will still want to add some examples to the docs.

[mdo]

Wow, not sure how I missed following up here. Sorry!

Does this look a little odd to anyone else? Something about it feels a little wrong with the label inside the field with a value and the vertically centered at sign.

[AgentSmith0]

I compared it to bootstraps default floating labels and I see no difference.

[719media]

I can see where it looks a little off center, but I looked at it for so long I'm used to it. I get your point that the @ sign doesn't really make sense as a prefix to the label "Username", but there are other examples that make more sense. For example, using input-group buttons and dropdowns. I also wanted it for alignment purposes with other .form-floating elements.

In addition, googling around, there are various options which become possible with this fix. For example, I see this, which uses a different layout you could achieve by changing some border styles:

I updated this pen real quick for a rough example (last input):
https://codepen.io/nefiga/pen/KKXapZG

In summary:

1. Although the @ sign in your example may not be the optimal use case, other use cases do make more sense, like input-group buttons and dropdowns.
2. Form-floating inputs can be uniformly aligned, regardless of if they are using input-group or not.
3. Other styles that use an input-group becomes more accessible with less custom styling.

[719media]

@mdo @ffoodd
Hey guys this is a feature I could really use, one I think the community seems to want, and think it should be merged. It's been almost a year with a PR I keep updating in the hopes it will get merged, I honestly see no drawback to the merge, it works great, fixes numerous "input group doesn't work with form-floating" issues that seem to get posted every few months and linked to the PR #34527

If you don't want to support it and just want to kill the PR, that's fine, but some response would help me at least know if this has any chance of getting merged so I don't keep pestering if it isn't in alignment with the project direction. Thank you sincerely for your time and effort in maintaining such an awesome repo.

[mdo]

So sorry! Let me try to merge it today, I've seen enough issue requests to justify it :).

[AgentSmith0]

Thank you all very much!