bug: `ion-select` with `aria-label` breaks layout of `ion-item`

[lincolnthree]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already report this problem, without success.

Ionic Framework Version

v7.x

Current Behavior

Using ion-select with aria-label breaks the layout of ion-item. See screenshot. The first two items demonstrate standard layout without ion-select, and with ion-select in legacy mode:

The second two items demonstrate what happens if ion-select decides to render itself in modern form mode. Even though aria-label is supposed to be a non-UI changing attribute.

Additionally, this causes extreme layout breaking, and any other elements contained within the ion-item are no longer rendered horizontally. They are completely squeezed out by the ion-select. This causes some very strange height to be calculated depending on whatever the content was, and causes part of the select to be non-interactable:

Screen.Recording.2023-04-18.at.5.50.02.PM.mov

Expected Behavior

Layout should not be broken. Elements should be laid out the same way regardless of modern form syntax. ion-item should be able to accept other siblings besides one single ion-select that takes over the entire thing.

Steps to Reproduce

See repro video and repository:

Code Reproduction URL

https://github.com/lincolnthree/ionic-bugs/tree/issue-27232

Ionic Info

Ionic:

Ionic CLI : 6.20.3 (/Users/lincoln/.nvm/versions/node/v16.14.0/lib/node_modules/@ionic/cli)
Ionic Framework : not installed
@angular-devkit/build-angular : 15.1.6
@angular-devkit/schematics : 15.1.6
@angular/cli : 15.1.6
@ionic/angular-toolkit : 6.1.0

Capacitor:

Capacitor CLI : 4.6.3
@capacitor/android : not installed
@capacitor/core : 4.6.3
@capacitor/ios : not installed

Utility:

cordova-res : not installed globally
native-run (update available: 1.7.2) : 1.7.1

System:

NodeJS : v16.14.0 (/Users/lincoln/.nvm/versions/node/v16.14.0/bin/node)
npm : 8.3.1
OS : macOS

Additional Information

No response

[liamdebeasi]

So I'm a little confused as to what you are trying to do here. Selects are designed to take up the full width of the item, and as per the iOS/MD guidelines you typically shouldn't have additional elements (other than an icon or something similar in the start or end slot).

If you use the label property instead of creating a separate ion-label then the issue is resolved.

[lincolnthree]

Hey Liam,

This gets back to the issue with ion-select where it's not possible to create a "complex label", like this:

I have been trying to find a workaround using the "modern form syntax", since this feature went live in V7. I was able to find a workaround to this limitation by placing the ion-select inside the Item's end slot, with a label in the item's default/child content slot, see referenced issue for code.

Essentially, I opened this issue because it seemed like using ion-select inside ion-item in this way caused some unexpected (to me) layout changes as a legacy/long-time ionic user, and I thought you might want to be aware of them.

[liamdebeasi]

So I think the root issue here is a lack of good documentation surrounding how to use form controls in an item. It's something we haven't done great with in the past. We're working on a "Best Practices" guide for items which will document use cases such as the one you are describing.

Both iOS and Material Design have a (surprising) number of "Dos and Donts" for items. One of them is that selects (along with their label) typically should exist by themselves inside of items. You can see an example of this in the "New Event" modal in the iOS calendar app. The team's hope is that this documentation will clarify how to properly use items in a list.

In your example, the "correct usage" would be to pass the label to the select. Unfortunately, you need custom HTML for this which is the second issue here. This is tracked in #26838 and is something we are actively working on adding support for.

Does that help clarify things?

[lincolnthree]

Your explanation makes sense! I agree that the correct solution for my use case is #26838 - but I think this is still a bug in the layout system. Not sure the layout should break like this. I'll leave that up to you though.