fix(item): only default slot content wraps

[liamdebeasi]

Issue number: resolves #28769

---

What is the current behavior?

As part of #28146, we allowed text wrapping inside of ion-item for accessibility purposes. One of the behaviors we added was to allow start, default, and end slotted containers to wrap to the next line to align with the iOS spec. However, this decision was based on an incorrect assumption.

The following screenshot shows the Settings app on iOS:

default scale	310% scale

At the default scale, the blue icon is in the iOS equivalent of the "start" slot, "Bluetooth" is in the default slot, and "On" is in the "end" slot. We incorrectly assumed the same markup was true when scaling the text up. However, at 310% scale the icon, "Bluetooth" text, and "On" text all become part of the default slot in a single container that wraps. You can tell because the bottom border runs underneath the blue icon at 310% whereas it does not at the default scale. This allows the text to wrap underneath the blue icon. When we originally implemented #28146 we thought that this meant the start, default, and end slot containers should wrap to the next line.

I further validated this behavior by creating an app with Swift UI. I created a list of items where each item has the native equivalent of a checkbox in the start slot and multiple ion-labels in the default slot of the item:

Default Scale	310% Scale

The content within each label wraps within the container, but the containers themselves never wrap to the next line.

Demo code:

import SwiftUI

struct ContentView: View {
    struct Item: Identifiable, Hashable {
        let id = UUID()
    }

    private var items = [
        Item(),
        Item(),
        Item(),
        Item(),
        Item()
    ]

    @State private var multiSelection = Set<UUID>()

    var body: some View {
        NavigationView {
            List(items, selection: $multiSelection) {_ in
                HStack {
                    Text("Column 1 with really long text")
                    Text("Column 2 with really long text")
                    Text("Column 3 with really long text")
                    Text("Column 4 with really long text")
                }
            }
            .toolbar { EditButton() }
        }
        Text("\(multiSelection.count) selections")
    }
}

#Preview {
    ContentView()
}

What is the new behavior?

• This PR removes the ability for the start, default, and end slot containers to wrap to the next line. This behavior aligns with pre-v7.6.0 behaviors. The containers inside of the default slot will not wrap to the next line. However, content within each container (such as text within an ion-label) will continue to wrap to meet the team's accessibility requirements.

Does this introduce a breaking change?

• Yes
• No

Other information

Dev build: 7.6.5-dev.11704916749.1e64a3a7

[liamdebeasi]

This API was only needed to control when the default slot content should stop wrapping within its container and instead have the container wrap to the next line. Since the container no longer wraps to the next line, this API was removed.

Note that this is a private API so it is not a breaking change.

[liamdebeasi]

These screenshot changes are a result of c602b30. This screenshot tries to capture the text wrapping behavior found on native iOS when scaled up to 310%. However, as explained in the PR description, the label and note should really be in the same slot so they can wrap within the container.

[brandyscarney]

How would developers achieve this? We have notes documented as being slotted in items. The slotted notes with long labels are expanding outside of the viewport height at 310% with these changes:

100%	310%

vs. inside of the label at 100% they are not clinging to the sides:

100%	310%

[averyrousseau]

I have the same question; is there a way for developers (or us, for that matter) to detect the current font scale and adjust the markup dynamically?

[liamdebeasi]

So this is an area where we don't have a great solution right now. I'm not aware of how developers can easily have a long note go from the start slot to the default slot when the font size changes apart from putting the content in both slots and selectively hiding one based on the font size using mod() similar to what we do in datetime.

However, I'd argue having both long notes and long labels in the same item isn't something we should encourage.

According to https://ionicframework.com/docs/api/item#metadata, any notes should be short/to the point such as a count or one/two words.

If developers follow that best practice, they'd get something like this:

Default Scale	310% Scale

[liamdebeasi]

One other idea is you could use a ResizeObserver on an element/container and then do something when that fires. I doubt that would be a very performant way of doing it though.

[averyrousseau]

Looks like the issue Brandy mentioned in #28773 (comment) is still present; some of the notes have their heights massively expanded with this change. Is that supposed to happen? 😆

Example: https://github.com/ionic-team/ionic-framework/pull/28773/files#diff-8911775ab4bd2c84af54bd46e1bf1a0d54ed17209271e5e0595de243fbf1240b

[liamdebeasi]

That's why I suggested having the note in ion-label so they can wrap and why I mentioned that the test isn't a great example of best practices. The "Really really long note" text is in the start slot, and the default slot is collapsing to account for the width of the start slot. The text inside of the ion-label is wrapping to the next line, so you essentially have 1 character per line (but the width is so small so you don't see it).

The orange/yellow is the ion-label.

[averyrousseau]

Ahh, I see. In that case, should we update the test to avoid these long notes in the first place? Wouldn't be the first time we've adjusted tests to match best practices, and this one is particularly sticky since it leads to unnecessarily massive screenshots.

[liamdebeasi]

Updated in d9e034c. Mind taking another look?

[averyrousseau]

Muuuch better, thank you!!

[thetaPC]

LGTM, works as discussed

[liamdebeasi]

I need to do some clean up and address feedback, so I'll re-request for review when I'm ready 😄

[liamdebeasi]

This is the same "wiggling" that we saw in #28146 being undone.

[liamdebeasi]

"Range" is part of the default slot, and "End" is part of the end slot. Previously the "end" slot container would wrap to the next line. However, this was removed because it was incorrect. Now both the default and end slots will appear on the same line, and the default slot will shrink.

[liamdebeasi]

This diff is correct. The icons were in start/end slots which now no longer wrap to the next line.

[liamdebeasi]

This diff is correct. The icons were in start/end slots which now no longer wrap to the next line.

[liamdebeasi]

I made a few more changes, so re-requesting review.

[thetaPC]

Still LGTM, re-request me if the code changes due to this thread.