fix(item): elements should wrap and label should not collapse when text size increases by brandyscarney · Pull Request #28146 · ionic-team/ionic-framework

brandyscarney · 2023-09-07T21:52:18Z

This will resolve the following internal tickets:

FW-4905: bug: label should not collapse in an item or item divider with a note
FW-5092: bug: label should wrap instead of truncating inside of an item

What is the current behavior?

There are a few problems with how labels inside of items behave. Labels inside of items do not wrap their text, instead they truncate with an ellipsis. The label will continue to show an ellipsis while shrinking if there is wide content next to it, until eventually it completely disappears. This is especially problematic for dynamic type, when the font size can be increased up to 310% on ios. Below are some screenshots of how Ionic behaves when increasing the font size with an ion-label and ion-note in an ion-item. You'll notice that the ion-label (Wi-Fi) completely disappears at 310%.

`100%`	`145%`	`310%`

Here is how the same item looks on native iOS at 310%:

What is the new behavior?

A lot of changes were made in order to support wrapping components inside of an item. Since a lot of the code in ion-label and ion-item is used throughout multiple components, several changes were wrapped into this PR.

Item scss was modified to allow wrapping of its containers. Comments have been added to explain the new additions.
Label scss has been updated to allow wrapping (removing the white-space: nowrap) and allow it to grow.
A legacy class was added to item (.item-legacy) by all of the components that have legacy as a property. This class was targeted in the CSS to undo the wrapping changes for legacy items, otherwise it breaks a lot of tests: 6ec8bf4
a) Tests with legacy inputs were updated to include the legacy attribute. Without it the UI will break for several examples: a8a34ce
The item/test/text test was removed. It was almost exactly a duplicate of item/test/basic: eb79794
The Item inside of Datetime was styled to set the width to auto, undoing where I set the width to min-content elsewhere, in order to prevent it from wrapping all of the time. I also added a comment linking to a JIRA ticket to remove the Item because of the issues it causes by being used: 88106d8
Added some CSS to allow the select to shrink when inside of an item, otherwise it always wraps to the next line even when it can shrink and fit: 6804aea
Adds a test to a11y for Note to ensure that the Label next to a Note doesn't disappear: 1f23ffc
Some tests were updated to remove the ion-text-wrap and/or add ion-text-nowrap to prevent screenshot diffs. For example
Passes the skeleton-text class up to item (as item-skeleton-text) in order to add overflow: hidden to the label for skeleton text wrappers: 077fb08 - this also adds overflow: hidden for legacy labels to keep the ellipsis but the modern items do not need it

Does this introduce a breaking change?

Yes
No

Other information

Screenshots for this branch are separated into the following PR: #28278

Issue number: N/A --------- ## What is the current behavior? The datetime button does not support dynamic type. ## What is the new behavior? Adds support for dynamic type by converting `font-size` to use `rem` units and adding an ellipsis to text when the size is too large. ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information Dynamic type can be enabled with the following CSS: ```css html { --ion-dynamic-type: var(--ion-default-dynamic-font); } ```

Adds support for dynamic type by converting `font-size` to use `rem` units and setting a `max-size` which matches native iOS.

- Adds support for dynamic type by converting `font-size` to use `rem` units. - Updates the button width/height for icon only buttons in `md` to use `rem` units to scale the icon larger - Adds test for scaling the font which checks default buttons, clear buttons (because they use a different `font-size`), buttons with an icon, and a button containing only an icon

Issue number: N/A ---------   ## What is the current behavior?  The chip component does not support dynamic type. ## What is the new behavior?  The chip component supports dynamic type, has a dynamic height, has min and max font sizes in `ios` mode, and has a screenshot test. ### md mode Small md mode: <img width="1368" alt="md-small" src="https://github.com/ionic-team/ionic-framework/assets/14926794/4466c1b6-6d01-4ec8-8de9-0eb71fa45223"> Medium md mode: <img width="1371" alt="md-medium" src="https://github.com/ionic-team/ionic-framework/assets/14926794/c51c324e-a3b7-486b-9f68-84b0e4146570"> Large md mode: <img width="1369" alt="md-large" src="https://github.com/ionic-team/ionic-framework/assets/14926794/166e1229-96b7-4270-9ef2-4c708776691e"> ### ios mode Small ios mode: <img width="1371" alt="ios-small" src="https://github.com/ionic-team/ionic-framework/assets/14926794/de240058-5fe5-4387-8481-d695950853db"> Medium ios mode: <img width="1371" alt="ios-medium" src="https://github.com/ionic-team/ionic-framework/assets/14926794/c63db4be-e813-4917-a525-02ec456849ea"> Large ios mode: <img width="1370" alt="ios-large" src="https://github.com/ionic-team/ionic-framework/assets/14926794/3479f619-82c8-4645-85f7-2725ea43de00"> ## Does this introduce a breaking change? - [ ] Yes - [x] No  ## Other information  This also fixes an existing bug that the contents of a chip could get smooshed if the chip doesn't have enough horizontal space for its contents. ### Before <img width="253" alt="rStll" src="https://github.com/ionic-team/ionic-framework/assets/14926794/9a8f4c30-ceef-4fe1-a600-38b2f01c4e68"> ### After <img width="253" alt="Screenshot 2023-08-02 at 5 00 39 PM" src="https://github.com/ionic-team/ionic-framework/assets/14926794/e82e17c3-91e3-4089-a57b-16c7d7b386fb"> --------- Co-authored-by: ionitron <hi@ionicframework.com> Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>

Adds support for dynamic type by converting `font-size` to use `rem` units and setting a max `font-size` which matches native iOS.

Adds support for dynamic type by converting `font-size` to use `rem` units and setting a min `font-size` which matches native iOS.

Adds support for dynamic type by converting `font-size` to use `rem` units.

Adds support for dynamic type by converting `font-size` to use `rem` units and adds a min and max `font-size` for `ios`.

Issue number: N/A ---------   ## What is the current behavior?  The dynamic type feature branch screenshots are out of sync with the updated state from changes on `main`. ## What is the new behavior?  - Regenerates update screenshot diffs for the dynamic type feature branch with the latest changes from `main` ## Does this introduce a breaking change? - [ ] Yes - [x] No  ## Other information  Co-authored-by: ionitron <hi@ionicframework.com>

chore: sync with main

Adds support for dynamic type by converting `font-size` to use `rem` units. Upgrades the `sass` version to `1.33.0` to support this change.

Adds support for dynamic type by converting `font-size` to use `rem` units and adds a min and max `font-size` for `ios`.

Issue number: N/A ---------   ## What is the current behavior?  ion-textarea does not support dynamic type ## What is the new behavior?  - ion-textarea does support dynamic type ## Does this introduce a breaking change? - [ ] Yes - [x] No  ## Other information  Mostly, dynamic type for textarea was already supported. Only the bottom-content had a static size. All other font sizes were all already relative. Note: Textareas do not currently look correct when they are in an item, because #27989 has not yet merged. Once that PR is merged, the font sizes within textareas will be relative to the item sizes, and both will scale appropriately. If preferred, I can base this PR off branch FW-4432 instead. --------- Co-authored-by: ionitron <hi@ionicframework.com>

Co-authored-by: ionitron <hi@ionicframework.com> Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>

liamdebeasi

One comment, but good to go once that's addressed.

tgangso · 2023-12-07T09:38:15Z

Not sure I agree with this not being a breaking change, had to go and put in ion-text-nowrap in a lot of places in my app. Should be mentioned in the notes.

liamdebeasi · 2023-12-07T14:27:21Z

I've updated the release notes, but I recommend allowing text to wrap by default. The previous behavior was broken from an accessibility perspective, so forcing text to not wrap can degrade the experience for many users. We don't consider this a breaking change because the previous experience was broken for many users.

We got some feedback in #28146 (comment) that it would be helpful to note the new item wrapping behavior in v7.6. I've updated the Github release, and this PR updates the Changelog file.

tgangso · 2023-12-07T17:22:08Z

I've updated the release notes, but I recommend allowing text to wrap by default. The previous behavior was broken from an accessibility perspective, so forcing text to not wrap can degrade the experience for many users. We don't consider this a breaking change because the previous experience was broken for many users.

Specifically in places where I also had an ion-input with the label, a label that was previously displaying fine, was now splitting into multiple lines even when there is plenty of room for the label.

SaroGFX · 2023-12-13T14:46:32Z

I built a lot of custom CSS upon the ion-item for our specific needs, and this minor update was definitely breaking a lot for us 😅 Maybe I shouldn't have used the ion-items in these custom UI's

Added a video to show some of the context where this is not desired. Is there a way to opt-out? I cannot find a way to overwrite because the changes are not exposed.

Screen.Recording.2023-12-13.at.15.59.33.mov

liamdebeasi · 2023-12-13T17:58:11Z

You can set .ion-text-nowrap on elements you do not want to wrap: https://ionicframework.com/docs/api/item#basic-usage

SaroGFX · 2023-12-14T08:55:22Z

You can set .ion-text-nowrap on elements you do not want to wrap: https://ionicframework.com/docs/api/item#basic-usage

This utility does nothing to undo the changes to flex-wrap, flex-grow and shrink properties. It looks like I can't overwrite them either, because these elements seem to be unexposed. Is there any other workaround, besides rebuilding everything without using ion-item or wrapping it in a container?

Although an improvement, it would be great to be able to opt-out from this wrapping behaviour, as there are some scenarios where it's not desired. Maybe a custom property --flex-wrap could be a solution here?

tgangso · 2023-12-14T13:21:10Z

I also had some elements where we used ion-item as a base container for custom elements that I had to rewrite. Still do not agree this is not a breaking change. Found no workaround

liamdebeasi · 2023-12-14T15:46:53Z

Try setting width: 0 on the ion-label inside of the item. One of the primary changes was updating this element to flex: 1 0 auto:

ionic-framework/core/src/components/item/item.scss

Line 451 in 516b844

flex: 1 0 auto;

Previously the flex-basis was 0 which defined the initial minimum size of the container. From there, the flex-grow value was 1 which meant the container could grow beyond 0.

The flex-basis was changed to auto which means the initial container size is now based on the width property, so setting width should allow you to retain the old flex-basis behavior.

Of course, if you get down to smaller widths such as 100px, the elements may still wrap/get truncated. However, I'd argue that not wrapping content at that small of a width makes the content hard to understand since most text will be not readable.

Here's a demo: https://codepen.io/liamdebeasi/pen/mdvZdjg

liamdebeasi · 2024-01-02T21:52:13Z

Hi everyone,

The team is having discussions into revising part of the text wrapping behavior. In particular, we are considering not having the end/start slot content wrap to the next line. In other words, only the text in the default slot would wrap within its own container.

We are having this discussion based on some new information we've found related to how iOS handles wrapping. We're tracking this in #28769.

kyleabens · 2024-01-11T13:19:38Z

Is there anyway we can set the item-legacy class globally on all instances of ion-item and ion-item-divider without having to apply it to each one individually? Maybe add a property to IonicConfig for this so we can say:

IonicModule.forRoot({
      mode: 'md',
      itemLegacy: true
})

This recent change of wrapping ion-label by default does in a way break the UI of my app.

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 | | - | - | | <img width="1170" alt="Frame 4" src="https://github.com/ionic-team/ionic-framework/assets/2721089/462ef153-a060-41c8-9a00-f0aad17839be"> | <img width="1170" alt="Frame 5" src="https://github.com/ionic-team/ionic-framework/assets/2721089/f047f880-7b80-4710-939b-96da075fbbf9"> | 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 | | - | - | | ![IMG_3133](https://github.com/ionic-team/ionic-framework/assets/2721089/8b55bd1d-f7a8-4fec-bda4-d1bb12f50d34) | ![IMG_3134](https://github.com/ionic-team/ionic-framework/assets/2721089/92e8a196-36e4-47d6-a4e5-a0e991c78d0d) | The content within each label wraps within the container, but the containers themselves never wrap to the next line. Demo code: ```swift 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 - [x] No  ## Other information  Dev build: `7.6.5-dev.11704916749.1e64a3a7` --------- Co-authored-by: ionitron <hi@ionicframework.com>

liamdebeasi and others added 30 commits July 6, 2023 15:17

feat: add dynamic type variables (#27745)

937c44d

feat(action-sheet): support dynamic type (#27747)

563fda7

feat(breadcrumb): support dynamic type (#27759)

c7126a4

feat(back-button): support dynamic type (#27750)

fff2114

feat(badge): support dynamic type (#27772)

7713ea6

test(many): add font scaling tests (#27836)

914c6f2

feat(loading): support for dynamic type (#27828)

648d06a

feat(reorder): support dynamic type (#27838)

4ee14c4

feat(card): support dynamic type (#27845)

2737871

fix(datetime-button): buttons wrap instead of truncate (#27872)

a62040f

feat(button): support dynamic type (#27887)

afcc7eb

Adds support for dynamic type by converting `font-size` to use `rem` units and setting a `max-size` which matches native iOS.

refactor: add dynamic type sass functions (#27934)

7b458b6

feat(list-header): support dynamic type (#27938)

b37121d

Adds support for dynamic type by converting `font-size` to use `rem` units and setting a max `font-size` which matches native iOS.

feat(note): support dynamic type (#27946)

ed54502

Adds support for dynamic type by converting `font-size` to use `rem` units and setting a min `font-size` which matches native iOS.

feat(item-divider): support dynamic type (#27947)

251a40a

Adds support for dynamic type by converting `font-size` to use `rem` units.

feat(label): support dynamic type (#27962)

b3948d6

Adds support for dynamic type by converting `font-size` to use `rem` units.

feat(menu-button): support dynamic type (#28008)

5a72eca

Adds support for dynamic type by converting `font-size` to use `rem` units and adds a min and max `font-size` for `ios`.

Merge remote-tracking branch 'origin/main' into sp/FW-4146-sync-2

28f6c4a

Merge pull request #28026 from ionic-team/sp/FW-4146-sync-2

221d778

chore: sync with main

feat(typography): support dynamic type (#28045)

b1cc988

Adds support for dynamic type by converting `font-size` to use `rem` units. Upgrades the `sass` version to `1.33.0` to support this change.

feat(item-option): support dynamic type (#28050)

bcc0343

Adds support for dynamic type by converting `font-size` to use `rem` units and adds a min and max `font-size` for `ios`.

feat(range): support dynamic type (#28006)

b453ef5

feat(searchbar): support dynamic type (#28043)

fc39cd3

feat(toolbar): support dynamic type (#28073)

e4cc457

feat(title): support dynamic type (#27990)

a23c122

Co-authored-by: ionitron <hi@ionicframework.com> Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>

Merge remote-tracking branch 'origin/feature-7.5' into FW-4905

168daf2

brandyscarney changed the base branch from feature-7.5 to feature-7.6 October 12, 2023 16:18

brandyscarney added 4 commits October 12, 2023 13:12

test(alert): fix bad merge

4d51615

fix(checkbox): bad merge

962ca25

refactor(datetime): style the item directly in datetime

88106d8

fix(datetime): width auto should be on label

631030c

brandyscarney requested review from liamdebeasi and sean-perkins October 12, 2023 20:37

liamdebeasi reviewed Oct 13, 2023

View reviewed changes

Comment thread core/src/components/skeleton-text/skeleton-text.tsx

liamdebeasi approved these changes Oct 17, 2023

View reviewed changes

brandyscarney and others added 2 commits October 17, 2023 11:56

docs(skeleton-text): add comment explaining why it emits a style

3485a02

Merge branch 'feature-7.6' into FW-4905

5ab4c4a

brandyscarney mentioned this pull request Oct 17, 2023

fix(label): remove overflow hidden #28289

Closed

chore(): add updated snapshots (#28278)

bc54c66

brandyscarney merged commit 6438e3e into feature-7.6 Oct 17, 2023

brandyscarney deleted the FW-4905 branch October 17, 2023 18:08

liamdebeasi mentioned this pull request Dec 7, 2023

chore: note item behavior in 7.6 notes #28664

Merged

liamdebeasi mentioned this pull request Jan 10, 2024

fix(item): only default slot content wraps #28773

Merged

2 tasks

Navigation Menu

Uh oh!

fix(item): elements should wrap and label should not collapse when text size increases - #28146

fix(item): elements should wrap and label should not collapse when text size increases#28146
brandyscarney merged 80 commits into
feature-7.6from
FW-4905

brandyscarney commented Sep 7, 2023 •

edited

Loading

Uh oh!

Uh oh!

liamdebeasi left a comment

Uh oh!

tgangso commented Dec 7, 2023

Uh oh!

liamdebeasi commented Dec 7, 2023

Uh oh!

tgangso commented Dec 7, 2023

Uh oh!

SaroGFX commented Dec 13, 2023 •

edited

Loading

Uh oh!

liamdebeasi commented Dec 13, 2023

Uh oh!

SaroGFX commented Dec 14, 2023 •

edited

Loading

Uh oh!

tgangso commented Dec 14, 2023 •

edited

Loading

Uh oh!

liamdebeasi commented Dec 14, 2023 •

edited

Loading

Uh oh!

liamdebeasi commented Jan 2, 2024

Uh oh!

kyleabens commented Jan 11, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Uh oh!

Conversation

brandyscarney commented Sep 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is the current behavior?

What is the new behavior?

Does this introduce a breaking change?

Other information

Uh oh!

Uh oh!

liamdebeasi left a comment

Choose a reason for hiding this comment

Uh oh!

tgangso commented Dec 7, 2023

Uh oh!

liamdebeasi commented Dec 7, 2023

Uh oh!

tgangso commented Dec 7, 2023

Uh oh!

SaroGFX commented Dec 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

liamdebeasi commented Dec 13, 2023

Uh oh!

SaroGFX commented Dec 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgangso commented Dec 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

liamdebeasi commented Dec 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

liamdebeasi commented Jan 2, 2024

Uh oh!

kyleabens commented Jan 11, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

brandyscarney commented Sep 7, 2023 •

edited

Loading

SaroGFX commented Dec 13, 2023 •

edited

Loading

SaroGFX commented Dec 14, 2023 •

edited

Loading

tgangso commented Dec 14, 2023 •

edited

Loading

liamdebeasi commented Dec 14, 2023 •

edited

Loading