Simplified markup for input, textarea, and select

[liamdebeasi]

Definitions

Impacted Components: ion-input, ion-textarea, and ion-select.
Form Control/Form Component: A single impacted component such as ion-input.

Summary

We would like to make the following changes to the impacted components:

1. Move the label inside of the form component so that the label and control are contained within a single component.
2. Move form-specific features currently on ion-item onto the appropriate form components.
3. Remove form control interactions and behaviors that exist in the ion-item code.

Motivation

Form components in Ionic are impacted by multiple issues:

1. Screen readers announce form controls twice. Axe also warns of "nested form interactive" errors:
   bug: axe DevTools reports several items as "not announced by screen reader"  #23511
   bug: Checkbox touch target issue when there is a link in the text - A11y issue  #23289
   bug: adding aria labels to host and input element inside shadow root causes issues with nvda #23213
   bug: AXE: Elements must use only allowed ARIA attributes for ion-select #22715

2. Form components are tightly coupled with ion-item leading to unexpected behaviors:
   bug: Angular ion-item combined with stacked ion-label loses item-label-stacked class once ion-chip is added #24312
   bug: ion-chip is disabled when ion-input is disabled when both are in same ion-item #23331
   bug: Ion-input is broken with 4.7.x #19084
   bug: ion-label inside ion-item aligns wrongly or disappers if custom Angular component is used in this ion-item when stacked or floating position is set #22736
   bug: ion-button inside of an ion-label not clickable in v6 #24215
   bug: delegatesFocus patch for ios causes rendering issues with item sliding in chrome #25273

3. Form component usage is verbose and requires both ion-item and ion-label in order to behavior correctly.

4. It is unclear which features on ion-item apply to which form components.

Features such as the fill and shape properties only apply to ion-input, ion-textarea, and ion-select. However, these properties are set on ion-item implying that they are available on all form components.

Proposed Design

We would like to move all form component APIs from ion-item onto the form components themselves.

1. The affected form components will receive a default slot that can be used to specify the label.
2. A property will be added to each form component to let developers control the position of the label.
3. A property will be added to each form component to let developers control how the label and control are justified within a line.
4. For components that do not need a visible label, developers will be able to set aria-label to ensure the form control remains accessible.
5. Helper text and error text properties will be added to the impacted form components.
6. Properties that control the shape, fill, and whether or not a text counter appears will be added to the impacted form components.
7. CSS Variables will be added to the impacted form components to control the form validation highlight (the green or red line at the bottom of the input when using from validation).

Old Usage:

<ion-item>
  <ion-label>Enter your name</ion-label>
  <ion-input></ion-input>
  <span slot="error">Please enter a name</span>
</ion-item>

<ion-item fill="solid" counter="true">
  <ion-label>Comments</ion-label>
  <ion-textarea maxlength="500"></ion-textarea>
</ion-item>

<ion-item fill="outline">
  <ion-label>Pick a color</ion-label>
  <ion-select>
    <ion-select-option value="red">Red</ion-select-option>
    <ion-select-option value="blue">Blue</ion-select-option>
    <ion-select-option value="green">Green</ion-select-option>
  </ion-select>
  <span slot="helper">Please select your favorite color</span>
</ion-item>

New Usage:

<ion-input label="Enter your name" error="Please enter a name"></ion-input>

<ion-textarea fill="solid" counter="true" maxlength="500" label="Comments"></ion-textarea>

<ion-select label="Pick a color" helper="Please select your favorite color">
  <ion-select-option value="red">Red</ion-select-option>
  <ion-select-option value="blue">Blue</ion-select-option>
  <ion-select-option value="green">Green</ion-select-option>
</ion-select>

Notable Changes:

1. ion-item and ion-label are no longer used.
2. The label and helper have been moved to properties on the form component.
3. Any form features on ion-item such as fill or counter have been moved to the form component.

Benefits

1. There is less boilerplate required to get form components added to Ionic apps.
2. It is clear which properties apply to which form components.
3. Decouples form components from ion-item, allowing the Ionic team to provide for a more predictable user experience.

Drawbacks

1. This is a significant change to how developers have typically used form components.

Why is this RFC separate from the other form control RFCs?

ion-input and ion-textarea do not use the Shadow DOM and we do not have plans to change that. This means that certain features such as Shadow Parts and Slots are not available. As a result, the proposed API deviates slightly from other RFCs such as #25660.

For example, developers provide a label on ion-input using a property instead of using a slot like they would do for ion-radio.

Migration Path and Breaking Changes

This change would ship in Ionic 7.0 at the earliest. We would like to support both the old usage and the new usage for the entire Ionic 7 lifecycle. This will allow developers to migrate their form components at their own pace. It will also reduce the barrier to upgrading to Ionic 7.0.

The following features will be deprecated in Ionic 7.0:

1. The helper and error slots on ion-item.
2. The shape, fill, counter, and counterFormatter properties.
3. The --highlight-color-focused, --highlight-color-invalid, --highlight-color-valid, --highlight-height CSS variables on ion-item.
4. Any form component-specific logic and functionality in ion-item.
   Note: We do not plan to make any breaking changes in Ionic 7.0 as a result of this proposal.

The following features will be removed in Ionic 8.0 at the earliest:

1. The helper and error slots on ion-item.
2. The shape, fill, counter, and counterFormatter properties.
3. The --highlight-color-focused, --highlight-color-invalid, --highlight-color-valid, --highlight-height CSS variables on ion-item.
4. Any form component-specific logic and functionality in ion-item.

[rdlabo]

This is an interesting discussion.
My only concern is the expandability of the label. For example, this example uses a span element in the ion-label to tell the user that input is required.

必須 = required

I think you need to consider slots instead of attributes for this kind of extensibility.

[liamdebeasi]

Our main concern here is around adding slots for ion-input and ion-textarea. Adding slots to ion-input and ion-textarea means that these components must use the Shadow DOM. Unfortunately, there is a bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=172567) that breaks autofill (emails, passwords, etc) in Safari when inputs are in the Shadow DOM.

Does the red required text need to be part of the label for your use case? If it does not need to be part of the label you could do something like this:

<div class="required-text">Required</div>
<ion-input label="First Name"></ion-input>

From here, you could use display in CSS to get these on the same line. You can also use the required property to ensure that screen readers indicate that this form component is required for form submission.

Would that work instead?

[rdlabo]

Hi, thanks for reply.

there is a bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=172567) that breaks autofill (emails, passwords, etc) in Safari when inputs are in the Shadow DOM.

Recently, I've come to feel that WebView apps are a battle against Safari😥

you could use display in CSS to get these on the same line.

I don't think this will be a problem. My only concern is whether ion-label[position=floating] can be easily implemented, what do you think?

[rdlabo]

I remember one more possible problem. If you are using icons for labels, you need to provide a way to implement them.

ex)

<ion-item>
  <ion-label><ion-icon name="call-outline"></ion-icon>tel</ion-label>
  <ion-input></ion-textarea>
</ion-item>

[liamdebeasi]

I don't think this will be a problem. My only concern is whether ion-label[position=floating] can be easily implemented, what do you think?

Would targeting the ::after or ::before pseudo elements of <label> inside of <ion-input> work? That would let you display the red rectangle without worrying about implementation details such as floating vs. non-floating labels.

I made a CodePen as an example: https://codepen.io/liamdebeasi/pen/RwMQPLm

The relevant code is in the app-input label::before CSS block.

---

I remember one more possible problem. If you are using icons for labels, you need to provide a way to implement them.

Similar question as in #25661 (reply in thread): Does the icon SVG need to be part of the label, or can it be next to the control? The icon doesn't provide much value to screen readers, yet it would still be announced in the provided example.

[rdlabo]

This seems good. I forgot ::after or ::before . Thanks for solution!

[MaximS]

ion-item is very often consists of three parts: 1 - label, 2 - input itself and 3 - conditionally visible validation error message. Where to place the error message with this new style? Probably it should be part of inputs with an appropriate slot as well?

[liamdebeasi]

Item 5 of "Proposed Design" covers this:

5. Helper text and error text properties will be added to the impacted form components.

We will be adding helper and error properties that will let developers specify validation text.

I also added an example to the Old Usage and New Usage sections to clarify this.

[MaximS]

It's fine. The only problem is that it limits the way the error message is presented. What if the error component includes not only a text but an icon for error/warning/etc or may be a link to a help page or a button with "Fill from ..." / "Set to ..." / "Do you mean ...?" that opens a menu with standard corrections/solutions? Like for example an input for an upper bound of date range that allows to autofix an error when its value is below a lower bound of the range? Or a quanity input for a product in a busket with "The quantity asked is anavailable. Only X items are available. Set to X or delete this product?"

[liamdebeasi]

I think part of the issue here is we were never clear about how the error feature was meant to be used. The feature was only ever intended to be used to describe how to avoid the error not provide any additional interactions, so I can understand the concern around this change. The feature was modeled after the Material Design spec which recommends only using text in these fields: https://material.io/components/text-fields. (Scroll down to the "Error text" section)

For your use case, do elements such as "Only X items are available. Set to X or delete this product?" need to be part of the error text? Or would rendering it below the input also work? Some thing like the follow:

<ion-input></ion-input>
<span *ngIf="!isInStock">
  Only {{ numAvailable }} items are available. 
  <ion-button (click)="removeFromCart()">Remove from Cart</ion-button>
</span>

I used Angular syntax, but the code snippet is applicable to React and Vue as well.

[MaximS]

Yes, MD spec actually clearly state that error is just a text message. So any interaction should really be outside the input field. Thanks.
By the way, the spec suppose that error message should replace the helper text and not be added below:
For text fields that validate their content (such as passwords), replace helper text with error text when applicable. Swapping helper text with error text helps **prevent** new lines of text from being introduced into a layout, thus **bumping content to fit it**.

[deving1995]

I think this sounds great, usage looks a lot nicer. I'm super excited for Ionic 7 now!

[liamdebeasi]

Hi everyone,

Thank you for your feedback on this RFC! We will be moving forward with this proposed change in an upcoming release of Ionic Framework.