feat: built-in 'underline' for form control

[Wasenshi123]

Prerequisites

• [X] I have read the Contributing Guidelines.
• [X] I agree to follow the Code of Conduct.
• [X] I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

According to this issue : #27236

I am trying to achieve the original look and behavior with new modern syntax about label and AT.

https://stackblitz.com/edit/3we1ad-kzmne4?file=index.html

As you can see, the underline in original is resembling the underline in real paper form for user to fill in the blank.

(But what I tried to do result in the whole thing got underlined, including the label)

It would be nice to have built-in support functionality about this. for each form control (ion-input, ion-select, ion-textarea)

Describe the Use Case

I am trying to achieve the original look and behavior with new modern syntax about label and AT.

https://stackblitz.com/edit/3we1ad-kzmne4?file=index.html

Describe Preferred Solution

No response

Describe Alternatives

No response

Related Code

https://stackblitz.com/edit/3we1ad-kzmne4?file=index.html

Additional Information

As I mentioned, it should be customizable, especially the length (where you want it to underline, the whole, or exclude label and just the fill in area).

[sean-perkins]

Hello @Wasenshi123 thanks for this feature request.

Can you perhaps take a screenshot from your example of which behavior you are referring to for the underline form control?

In your original desired UI you are using floating labels, but in the modern syntax you are using fixed labels instead. I forked your example to make them consistent: https://stackblitz.com/edit/3we1ad-a1b8sd?file=index.html

Outside of the small visual adjustments between legacy and modern to align with the Material design spec, I don't currently see an issue with the underline between the displays.

[Wasenshi123]

Hello @Wasenshi123 thanks for this feature request.

Can you perhaps take a screenshot from your example of which behavior you are referring to for the underline form control?

In your original desired UI you are using floating labels, but in the modern syntax you are using fixed labels instead. I forked your example to make them consistent: https://stackblitz.com/edit/3we1ad-a1b8sd?file=index.html

Outside of the small visual adjustments between legacy and modern to align with the Material design spec, I don't currently see an issue with the underline between the displays.

I mean to have the ability to set this on the form control

As I demonstrated, I tried to add it manually with css on the new syntax one, but that's not quite the exact feeling because it underline the whole thing. So I think the built-in feature for this would be nice.

[Wasenshi123]

@sean-perkins I see now what is your point.

Please see this screen shot, my desired structure has the behavior to change label placement based on screen size. So at wider screen, the difference is noticeable:

My example is also updated to dynamically change label placement now.

[sean-perkins]

Thank you for the extra detail + screenshots! I understand the differences now 👍

The underline border always being visible could be accomplished if Ionic exposed shadow parts for the native wrapper on each control (or CSS variables for border, since not all controls use shadow dom).

The underline width is a much larger task.

For ion-input, the input highlight would need to be conditionally rendered either at the host level (to fill the entire width) or within the .native-wrapper when only wanting to display the highlight under the control. The .native-wrapper would also need: position: relative to contain the element positioning.

Here is an example concept with manually modifying the DOM and adjusting styling:

ion-select isn't as straight forward. The control does not fill the entire container space. I need to do additional investigation on our decision behind these styles, as I don't see the same thing against: https://material-components.github.io/material-components-web-catalog/#/component/select.

A mock API could look like:

<ion-input label="Name" label-placement="fixed" highlight="control"></ion-input>

It would support two options full and control, defaulting to full.

I'll discuss with the team and see if there are alternatives that I may be missing or any questions around the feature's feasibility.

[sean-perkins]

Thinking through the border aspect specifically, we could do something similar to:

/* user land styles - border is always visible */
ion-input {
  --border-width: 1px;
}

The helper/error text styling could be refactored to something similar to this, when active:

/* input.scss */
:host(.has-helper-text), :host(.has-error-text) {
 --border-width: 1px;
}

Lastly, the .input-wrapper styles could be refactored to make use of the border styles, applying the border on the bottom instead of the helper/error text applying a border top:

/* input.scss */
.input-wrapper {
  border-bottom: var(--border-width) var(--border-style) var(--border-color);
}

This would allow the default implementation to apply the border style/color when the helper/error text is used, but developers could optionally override and apply the border at any time through the --border-width, --border-style and --border-color CSS variables.

I am going to move this request into a labeled feature request.

[Majstr]

I am keep coming to this issue but it is not solving my problem. Since Ionic v7 you removed slot="error" which was option to display error in input. Now you put errorText which looks good at first glance. But when you go deeper you can see that it completely breaks existing logic. So there is no way to use this with list because it makes double line. So all the documentation is, put inputs in a list. But now with this new errorText official statement is don't use it in a list. And explanation is:

If you need to provide more context on a input, consider using an ion-note underneath the ion-list.

So I would have 10 inputs in a list and then at the en of the list I will put wall of text for each input what is wrong with entered data? Or I should make a list for each input separately? It totally breaks validation messages for inputs in a list. Or I am missing something essential.

On top of it all select doesn't even have errorText or helperText. All my forms are broken, probably only solution is to go back to v6. And in v8 nothing was done about this topic.

[howlettga]

Is there any intention to support this? Right now the documentation shows most inputs inside an ion-item element, which breaks the errorText functionality. In my opinion, input validation is a requirement for inputs, so the input has been broken for 2 major releases. The documentation doesn't demonstrate a valid way to add realistic input scenarios.

The only workaround right now seems to be use lines="none" on all ion-item elements or use ion-input elements without any list. In addition, you have to stub in errorText="void" or some other valid string to all inputs that aren't required just to get matching user interface.

Is there any plans to get form functionality working or at least document input usage in a way that reflects real world scenarios?