bug: item start and end slots wrap to next line

[rdlabo]

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

If an element other than ion-label is used in the default slot and the width is long, slot=end will break lines.

ex:

<ion-list>
  <ion-item>
    <ion-text style="background-color: lightgreen">
      A "Hello, World!" program is generally a simple computer program.
    </ion-text>
    <div slot="end" style="background-color: yellow">[slot=end]</div>
  </ion-item>
</ion-list>

This has been occurring since v7.6.0 and does not occur in v7.5.8. In complex apps, ion-grid may be placed under ion-item, and this behavior can be a major problem.

Expected Behavior

Equivalent behavior to v7.5.8.

Steps to Reproduce

1. npm i @ionic/angular@7.5.8 or npm i @ionic/angular@7.6.0

Code Reproduction URL

No response

Ionic Info

Ionic:

Ionic CLI : 7.1.1 (/opt/homebrew/lib/node_modules/@ionic/cli)
Ionic Framework : @ionic/angular 7.6.0
@angular-devkit/build-angular : 17.0.8
@angular-devkit/schematics : 17.0.8
@angular/cli : 17.0.8
@ionic/angular-toolkit : 9.0.0

Capacitor:

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

Utility:

cordova-res : 0.15.4
native-run : 2.0.0

System:

NodeJS : v20.10.0 (/usr/local/bin/node)
npm : 10.2.3
OS : macOS Unknown

Additional Information

No response

[ionitron-bot]

Thanks for the issue! This issue has been labeled as holiday triage. With the winter holidays quickly approaching, much of the Ionic Team will soon be taking time off. During this time, issue triaging and PR review will be delayed until the team begins to return. After this period, we will work to ensure that all new issues are properly triaged and that new PRs are reviewed. In the meantime, please read our Winter Holiday Triage Guide for information on how to ensure that your issue is triaged correctly. Thank you!

[liamdebeasi]

Thanks! I think we need to take a closer look at this behavior. While the text wrapping itself is correct, it looks like the end slot should not be pushed onto the next line when comparing with native iOS. I'll discuss the best course of action with the team.

[corradodellorusso]

This also happens in ios mode, when you have a clickable ion-item with a ion-label with ion-text-nowrap class.

  <ion-item  lines="none" button>
      <ion-icon color="primary" name="reader-outline" size="large" slot="start"></ion-icon>
      <ion-label class="ion-text-nowrap">Some very long text!</ion-label>
  </ion-item>

[lincolnthree]

We use ion-item for inputs, pickers, and other block level elements -- not just for text with buttons on the ends. This change has had ripple effects from our login screen to our main pages and lists.

I'm interested in testing a dev-build that fixes the end-wrapping behavior to see if it makes it possible for us to navigate the changes required to accommodate this new item layout spec. I think that fixing the end slot wrap should take care of most of it.

Also, any suggestions for a global CSS rule to make this work "the way it did before"?

[harry-molyneux]

I've found that this appears to be an issue with the flex property of the <div class="input-wrapper"> element. In previous versions of Ionic, I noticed that this element had flex: 1 1 0%;. If this style is applied, the issue appears to be resolved.

Therefore, I believe that the expected behaviour/fix is that the <div class="input-wrapper"> element within the shadow-root of an <ion-item> should have flex: 1 1 0%; if it contains an <ion-label> with class="ion-text-nowrap" (unless there would be any known side-effects of changing this style).

[lincolnthree]

I've found that this appears to be an issue with the flex property of the <div class="input-wrapper"> element.

Yeah, that's right. They changed this intentionally to support wrapping: ionic-team/ionic-docs#3313 (comment)

I think this should be a breaking / non-backwards compatible UI change, but that's just me. Or at least it should be done outside of the shadow-DOM, or with a CSS "off switch" so we can control how this behavior works globally in our app CSS.