BREAKING CHANGE:
- The `helper` slot has been removed. Developers should use the `helperText` property on `ion-input` and `ion-textarea`.
- The `error` slot has been removed. Developers should use the `errorText` property on `ion-input` and `ion-textarea`.
- Counter functionality has been removed including the `counter` and `counterFormatter` properties. Developers should use the properties of the same name on `ion-input` and `ion-textarea`.
- The `fill` property has been removed. Developers should use the property of the same name on `ion-input`, `ion-select`, and `ion-textarea`.
- The `shape` property has been removed. Developers should use the property of the same name on `ion-input`, `ion-select`, and `ion-textarea`.
Issue number: resolves#28261
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When moving focus from a focus-trapped overlay to a toast, focus is
moved back to the overlay. This is the correct behavior as focus should
never leave a focus-trapped overlay (unless the overlay is dismissed or
focus is moved to a _new_ top-most overlay). However, the way we return
focus is a bit unexpected because it always returns focus to the last
focusable element in the overlay.
This means that if you were focused on the first focusable element,
presented the toast, and then focused the toast, focus might not be
moved back to that first focusable element. In the case of the linked
issue, this was causing an unexpected scroll so that the last focused
element could be in view.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- This fix adds an exception for `ion-toast` (as it is the only overlay
that is **not** focus trapped) that ensures that focus is moved back to
the last focus element.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.7.1-dev.11707253408.186eea70`
Note: We don't recommend this pattern in general because it would be
impossible for a screen reader user to focus the toast. However, we can
at least improve the experience for developers who continue to implement
this pattern by returning focus in a more predictable manner.
Docs: https://github.com/ionic-team/ionic-docs/pull/3432
Testing:
Reviewers should manually test the following behaviors:
1. Create a modal with 2 buttons. Have one of the buttons present a
toast. Open the toast and verify that you can still Tab to cycle through
the buttons in the modal.
2. Create a modal with 2 buttons. Have one of the buttons present a
toast. Open the toast. Move focus to the toast and verify that you can
still Tab to cycle through the buttons in the modal (once focus is
returned to the modal).
Issue number: internal
---------
## What is the current behavior?
In Ionic Framework v7, we [simplified the select
syntax](https://ionic.io/blog/ionic-7-is-here#simplified-form-control-syntax)
so that it was no longer required to be placed inside of an `ion-item`.
We maintained backwards compatibility by adding a `legacy` property
which allowed it to continue to be styled properly when written in the
following way:
```html
<ion-item>
<ion-label>Label</ion-label>
<ion-select></ion-select>
</ion-item>
```
While this was supported in v7, console warnings were logged to notify
developers that they needed to update this syntax for the best
accessibility experience.
## What is the new behavior?
- Removes the `legacy` property and support for the legacy syntax.
Developers should follow the [migration
guide](https://ionicframework.com/docs/api/select#migrating-from-legacy-select-syntax)
in the select documentation to update their apps. The new syntax
requires a `label` or `aria-label` on `ion-select`:
```html
<ion-item>
<ion-select label="Label"></ion-select>
</ion-item>
```
- Removes the legacy tests under under `select/test/legacy/` and all
related screenshots
- Removes the select usage from `item/test/disabled`,
`item/test/legacy/alignment`, and `item/test/legacy/disabled` and all
related screenshots if the test was removed
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
1. Developers have had console warnings when using the legacy syntax
since the v7 release. The migration guide for the new select syntax is
outlined in the [Select
documentation](https://ionicframework.com/docs/api/select#migrating-from-legacy-select-syntax).
2. This change has been documented in the Breaking Changes document with
a link to the migration guide.
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved
placing an `ion-select` inside of an `ion-item` with an `ion-label`,
have been removed from select. For more information on migrating from
the legacy select syntax, refer to the [Select
documentation](https://ionicframework.com/docs/api/select#migrating-from-legacy-select-syntax).
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: internal
---------
## What is the current behavior?
The old `border-radius` mixin added additional selectors and styles
depending on whether the direction was set to `ltr` or `rtl`.
Old mixin usage:
```scss
.old-border-radius {
@include border-radius(5px, 6px, 7px, 8px)
}
```
generates:
```css
.old-border-radius {
border-top-left-radius: 5px;
border-top-right-radius: 6px;
border-bottom-right-radius: 7px;
border-bottom-left-radius: 8px;
}
:host-context([dir=rtl]) .old-border-radius {
border-top-left-radius: 6px;
border-top-right-radius: 5px;
border-bottom-right-radius: 8px;
border-bottom-left-radius: 7px;
}
[dir=rtl] .old-border-radius {
border-top-left-radius: 6px;
border-top-right-radius: 5px;
border-bottom-right-radius: 8px;
border-bottom-left-radius: 7px;
}
@supports selector(:dir(rtl)) {
.old-border-radius:dir(rtl) {
border-top-left-radius: 6px;
border-top-right-radius: 5px;
border-bottom-right-radius: 8px;
border-bottom-left-radius: 7px;
}
}
```
## What is the new behavior?
The new `border-radius` mixin uses the [logical
properties](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values/Margins_borders_padding)
which handles switching based on the
[writing-mode](https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode),
[direction](https://developer.mozilla.org/en-US/docs/Web/CSS/direction),
and
[text-orientation](https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation):
| Before | After |
| -----------------------------| ----------------------------|
| `border-top-left-radius` | `border-start-start-radius` |
| `border-bottom-left-radius` | `border-end-start-radius` |
| `border-top-right-radius` | `border-start-end-radius` |
| `border-bottom-right-radius` | `border-end-end-radius` |
New mixin usage:
```scss
.new-border-radius {
@include border-radius(5px, 6px, 7px, 8px)
}
```
```css
.new-border-radius {
border-start-start-radius: 5px;
border-start-end-radius: 6px;
border-end-end-radius: 7px;
border-end-start-radius: 8px;
}
```
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
The `select` styles have been updated to use the mixin instead of
hardcoding `border-radius`.
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Several tests were still using the legacy form syntax.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrated tests in `core`, `angular`, and `vue` to use the modern form
syntax (`react` did not have form controls).
I opted not to migrate `item/test/highlight` and `item/test/counter`
because those tests are going to be removed in the future once the
deprecate item APIs are removed.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Issue number: resolves#28818
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Select has logic in place to prevent the overlay from opening when
clicking the slotted content. As part of this, we need to deal with the
`<label>` element dispatching another click that then bubbles up and
causes the overlay to open when clicking the slotted content. We
currently deal with this by calling `preventDefault` which prevents this
extra event from being dispatched only when clicking the slotted
content.
We also call `stopPropagation`. This code is not necessary, and in most
cases should not have any adverse effects on developer applications.
However, this does impact React applications due to how React handles
events. When a developer places `onClick` on a slotted element, a native
"click" listener is not immediately applied to that element. Instead,
React adds a native "click" listener to the root element of an
application. When that listener's callback fires, React will dispatch a
synthetic click event on the slotted element. Since we are calling
`stopPropagation`, the click event never bubbles up to this root node's
listener. As a result, the synthetic event is never dispatched on the
slotted element, and the developed `onClick` callback never fires.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Select no longer prevents events from bubbling. The existing
`event.preventDefault` is sufficient to prevent the label from
dispatching another click (thereby causing the select overlay to open)
when clicking the slotted content.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.6.5-dev.11705430252.1023daf3`
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The team would like to ensure that Ionic Framework components that use
an Ionic color (primary, secondary, etc) on top of a contrast color pass
minimum contrast ratios as defined in the WCAG.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Introduces a revised set of Ionic colors that pass AA color contrast
guidelines when with the appropriate contrast.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandy@ionic.io>
Co-authored-by: Sean Perkins <sean@ionic.io>
Co-authored-by: Shawn Taylor <shawn@ionic.io>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Buttons slotted in the start/end slots of input, textarea, or select
have a lot of excess padding that can cause them to look misaligned from
other pieces such as the control's label, especially when using
`fill="clear"`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Padding removed, and a border radius added so that non-clear buttons as
well as the focus state on clear buttons still look okay. Existing
screenshot tests have also been updated to include buttons (non-clear
ones so you can see the border radius in the screenshots).
Let me know if you think this should go on a feature branch instead. I
chose `main` because the current experience looks somewhat broken and we
just did a minor release recently, but this could be considered a
notable enough behavior change.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
We currently apply a workaround to `ion-select` so it can wrap correctly
inside of `ion-item`:
357b8b2beb/core/src/components/select/select.scss (L99-L103)
However, this causes issues when a parent element has `display: flex`
because the `ion-select` width becomes 0.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- In order to get the desired behavior, we need the `ion-select` (and
other elements in the default slot) to either truncate or wrap within
its own container and then have the entire container (i.e. the entire
`ion-select`) wrap to the next line once the container is too small.
To achieve this, I needed to set a min-width on `.item-inner` to define
the point at which the element should wrap to the next line. I also
changed the flex basis from `auto` to `0` which means the initial main
size of the flex item will be 0px. In reality, this will be
`--inner-min-width` since we also set `min-width:
var(--inner-min-width)`. I used `0` for simplicity but I can change this
to use the CSS variable if that's more clear. Since we also set
`flex-grow: 1` we indicate that the element can grow from that basis
(but it cannot shrink).
I chose `--inner-min-width: 4rem` to minimize the number of diffs. We
can certainly change this, but it may cause some diffs as certain
elements will start wrapping sooner. I also chose to use `rem` because
having a fixed min-width means that fewer characters are going to fit in
the same space as text scales.
I made this a CSS variable but left it undocumented. If developers need
a way of changing this `min-width` they can request it and we can easily
expose this variable. However, I think `4rem` is small enough that this
should be sufficient.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
The visual diffs here are correct. The table below shows the screenshot
group and an explanation for why the changes are correct.
| Path | Example | Details |
| - | - | - |
| `disabled` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-d529716f95f7a7aa82c88588104220775b728af67077f48cd47a8afa04423143)
| The searchbar is able to shrink slightly to fit on the same line as
the checkbox at the bottom. |
| `highlight` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-0b64f24c91393923701d1ced4e330a1c6b926d72ee461b8ab1e135e708be3457)
| We're changing how small the main content can get, so the input is
only wrapping once it gets to `--inner-min-width`. |
| `legacy/fill` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-2ef8dbfa5e69e2b96c3e1ed29ab962f08cf5ba2aaf2af773e40bd143e38a4bef)
| We're changing how small the main content can get, so the input is
only wrapping once it gets to `--inner-min-width`. |
| `slotted-inputs` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-2f173c7303969d6a6c58f30a618cebc3caf918d3761fc83df5642fd48dfabd7b)
| We're changing how small the main content can get, so the range is
only wrapping once it gets to `--inner-min-width`. |
`slotted-inputs` note: I'd argue many of these examples are not best
practices. For example, adding a range in the start slot and the end
slot is a bit unusual. I'm not aware of any native apps that implement
this pattern.
popover note: I [removed the `ion-item` from the `popover/test/async`
test](331fcb859c).
There was a diff because the min-width increased, but IMO that component
should not be used in the popover test since we want to test the
popover, not the item.
--------
Demo:
| `feature-7.6` | `branch` |
| - | - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/693d4947-fa33-460d-bc7f-7b96b6338032"></video>
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/df35ca73-87aa-4e76-9bb7-99f0f2810640"></video>
|
(In this demo I updated the `ion-select` to wrap within its own
container first instead of truncate. We may want to consider doing this
by default, but I think this is out of scope for this task)
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Brandy Carney <brandy@ionic.io>
Issue number: Resolves#26297
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
With the modern form control syntax, it is not possible to add icon
buttons or other decorators to the sides of `ion-input`, `ion-textarea`,
or `ion-select`, as you can with `ion-item`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
`start` and `end` slots added to each component.
This PR is a combination of several others that were already approved.
If needed, it might be easiest to review the PRs individually by looking
at the commit history here.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Docs PR: https://github.com/ionic-team/ionic-docs/pull/3271
Dev build: `7.5.4-dev.11701112913.1ea61220`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
When an item containing a select is used inside of a flex container, the item collapses to `0px` width. Example code:
```html
<div style="display: flex">
<ion-item>
<ion-select aria-label="fruit" placeholder="Select fruit">
<ion-select-option value="apples">Apples</ion-select-option>
<ion-select-option value="oranges">Oranges</ion-select-option>
<ion-select-option value="bananas">Bananas</ion-select-option>
</ion-select>
</ion-item>
</div>
```
This change sets the flex property to `1` on `ion-item` so that it will grow inside of a flex container, resulting in the select being displayed. The `flex` property is ignored when item is inside of a block container.
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Type checking inside of the Stencil unit tests have been disabled for a
long time. This has resulted in a difficult developer experience and
numerous issues (both types and implementation) within our unit tests.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Type checking is now enabled for all Stencil unit tests
- Tests have been updated to resolve type errors and implementation
errors
- Many `as any` casts were introduced, as many legacy tests test invalid
configurations of functions that require it (for example passing
`undefined` to an argument that cannot be `undefined`).
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
To test this PR you can checkout the branch locally. Install
dependencies in the `/core` directory to make sure you are on at least
`@stencil/core@4.7.2`.
Opening either a `.spec.ts` or `.spec.tsx` file, validate that your IDE
detects types and can provide auto completions for jest global types.
If you desire, you can provide an invalid type and try building the
project - you will observe the build will fail due to the invalid type.
aIssue number: resolves#28388
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
We added a `min-height: 56px` to the input, textarea, and select
components for MD mode. However, these were added for the outline/solid
style inputs to align with the Material Design spec:
https://material-components.github.io/material-components-web-catalog/#/component/text-field
They should not apply to regular inputs in an item. The end result is
inconsistently sized items when used with non-control items.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Non-filled and non-stacked/floating label controls are now have a
minimum height of 44px.
There should be **no changes** to the following types of controls:
1. iOS controls (all variants)
2. MD filled controls
3. MD stacked controls
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.2-dev.11697818830.1a33c881`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
This project has several unused Sass variables still in the code base.
The team would like to remove these.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed unused Sass variables
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
The original scope of this ticket was for checkbox only, but many other
components had unused sass variables, so I decided to tackle everything
all at once.
Since these variables are not used anywhere:
1. The build should pass
2. There should be no screenshot diffs
1) Wraps the label text and other content in an item when there is not enough room for everything to fit, instead of truncating the label with an ellipsis. Does not apply to items containing legacy inputs.
2) Passes the legacy property up to item from checkbox, input, radio, range, select, textarea and toggle. Item adds classes for all of these and does not wrap its contents if that class exists. If a developer is using a legacy input without the legacy property on it then they will need to add the legacy property to prevent the wrapping.
3) If a developer does not want the text to wrap for labels in modern items, the `ion-text-nowrap` class can be added to the label.
Issue number: resolves#24638, resolves#18592
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Developers have requested that Ionic Framework support the dynamic type
feature on iOS for accessibility purposes. Ionic applications do not
respond to font scaling on iOS which can create inaccessible
applications particularly for users with low vision. Ionic apps on
Android devices currently support the Android equivalent due to
functionality in the Chromium webview.
Developers have also requested a way of adjusting the fonts in their
Ionic UI components consistently.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic components now use `rem` instead of `px` where appropriate. This
means devs can change the font size on `html` and the text in supported
Ionic components will scale up/down appropriately
- Add support for Dynamic Type on iOS (the iOS version of Dynamic Font
Scaling)
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: Shawn Taylor <shawn@ionic.io>
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Sean Perkins <sean@ionic.io>
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: resolves#28284
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Select focuses the first popover option when no value is provided. This
means that the first option is focused even if it disabled.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Select focuses the first **enabled** popover option when no value is
provided.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: Resolves#27169
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Clicking the padded space within an `ion-item` will not pass the click
event to the slotted `ion-radio`, `ion-checkbox`, `ion-select` or
`ion-toggle`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The padded space at the start of `.item-native` and at the end of
`.item-inner` is clickable to activate a control.
- When the item is clicked, we check if the event is a result of
clicking the control or clicking the item's padded space. If the click
event is on the control, we don't need to do anything and let the
default behavior occur. If the click event is on the padded space, we
manually call the `.click()` method for the interactive element.
- The cursor pointer displays when hovering over the padded space when a
slotted interactive control is present.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Several tests for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The outline select uses `border-left` and `border-right` properties to
handle LTR vs RTL borders. However, our border mixin takes care of this
by using logical border properties.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates the outline select to use the border mixin.
Note 1: There should be no visual changes as a result of this. This is
simpler way of doing what we are already doing.
Note 2: There do exist logical border radius properties (for the other
explicit LTR vs RTL work we do), but Ionic 7 supports browsers that do
not support these properties yet. (I created FW-4661 to track this)
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#17248
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
While the `icon` shadow part allows customization of the existing toggle
icon, developers do not have a way to specify a different icon to use
entirely.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
New props `toggleIcon` and `expandedIcon` added. (Design docs are
[here](https://github.com/ionic-team/ionic-framework-design-documents/blob/main/projects/ionic-framework/components/select/0002-custom-icons.md)
and
[here](https://github.com/ionic-team/ionic-framework-design-documents/blob/main/projects/ionic-framework/components/select/0003-custom-icon-on-open.md)
respectively.)
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Docs PR: https://github.com/ionic-team/ionic-docs/pull/2996
Dev build: `7.0.15-dev.11687278023.161b97d8`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27061
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Input does not accept custom HTML labels
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Input accepts custom HTML labels as an experimental feature. We marked
this as experimental because it makes use of "scoped slots" which is an
emulated version of Web Component slots. As a result, there may be
instances where the slot behavior does not exactly match the native slot
behavior.
Note to reviewers: This is a combination of previously reviewed PRs. The
implementation is complete, so feel free to bikeshed.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Docs PR: https://github.com/ionic-team/ionic-docs/pull/2997
---------
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `ion-header` and `ion-footer` use a base64 encoded image for a box
shadow instead of using the CSS box-shadow property directly. The use of
the background image creates CSP violations. The historic reasoning of
using an image instead of box shadow was to improve scroll performance.
Browsers and devices have improved a lot since that was implemented (5
years ago).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates the usage of `ion-header` and `ion-footer` to use a box
shadow. The value comes from Material's web implementation:
https://material-components.github.io/material-components-web-catalog/#/component/top-app-bar
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Reverts ionic-team/ionic-framework#27570
-------
The team is reconsidering this approach as it causes us to fight against
the browser. Discussions are ongoing internally, so I am going to revert
this patch until we can reach consensus.
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The click event was firing twice.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The click event fires once.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
You can use the test file to see that the event now fires once, and
before this change it fired twice. I couldn't figure out how to write an
automated test for this that fails before the change and passes after
the change. (Perhaps because of how Jest "clicks" elements? Not sure.)
Also, you can use the repro repo in the Jira ticket and update it to
`"@ionic/angular": "7.0.10-dev.11685472954.170be0cc",` and see that the
issue is fixed.
Bumps [@playwright/test](https://github.com/Microsoft/playwright) from
1.33.0 to 1.34.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/Microsoft/playwright/releases"><code>@playwright/test</code>'s
releases</a>.</em></p>
<blockquote>
<h2>v1.34.0</h2>
<h3>Highlights</h3>
<ul>
<li>
<p>UI Mode now shows steps, fixtures and attachments:
<!-- raw HTML omitted --></p>
</li>
<li>
<p>New property <a
href="https://playwright.dev/docs/api/class-testproject#test-project-teardown"><code>testProject.teardown</code></a>
to specify a project that needs to run after this
and all dependent projects have finished. Teardown is useful to cleanup
any resources acquired by this project.</p>
<p>A common pattern would be a <code>setup</code> dependency with a
corresponding <code>teardown</code>:</p>
<pre lang="js"><code>// playwright.config.ts
import { defineConfig } from '@playwright/test';
<p>export default defineConfig({
projects: [
{
name: 'setup',
testMatch: /global.setup.ts/,
teardown: 'teardown',
},
{
name: 'teardown',
testMatch: /global.teardown.ts/,
},
{
name: 'chromium',
use: devices['Desktop Chrome'],
dependencies: ['setup'],
},
{
name: 'firefox',
use: devices['Desktop Firefox'],
dependencies: ['setup'],
},
{
name: 'webkit',
use: devices['Desktop Safari'],
dependencies: ['setup'],
},
],
});
</code></pre></p>
</li>
<li>
<p>New method <a
href="https://playwright.dev/docs/test-assertions#expectconfigure"><code>expect.configure</code></a>
to create pre-configured expect instance with its own defaults such as
<code>timeout</code> and <code>soft</code>.</p>
<pre lang="js"><code>const slowExpect = expect.configure({ timeout:
10000 });
await slowExpect(locator).toHaveText('Submit');
<p>// Always do soft assertions.
const softExpect = expect.configure({ soft: true });
</code></pre></p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4aee014caf"><code>4aee014</code></a>
chore: mark 1.34.0 (<a
href="https://redirect.github.com/Microsoft/playwright/issues/23123">#23123</a>)</li>
<li><a
href="bf25a93617"><code>bf25a93</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23171">#23171</a>):
fix(tracing): when zipping remotely, use correct file na...</li>
<li><a
href="7effaf4f22"><code>7effaf4</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23166">#23166</a>):
chore: fix file view padding</li>
<li><a
href="ef18287266"><code>ef18287</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23165">#23165</a>):
docs: update release notes</li>
<li><a
href="552cba8c05"><code>552cba8</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23148">#23148</a>):
chore: do not annotate actions after failed ones as time...</li>
<li><a
href="cd94a3f01d"><code>cd94a3f</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23144">#23144</a>):
feat(connect): <code>pw:server:channel</code> and <code>pw:socks</code>
debug ...</li>
<li><a
href="3543a741fd"><code>3543a74</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23140">#23140</a>):
docs: add dialog/consoleMessage helper methods for langu...</li>
<li><a
href="7196f82e52"><code>7196f82</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23143">#23143</a>):
test: add attachment tests</li>
<li><a
href="32c247b815"><code>32c247b</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23139">#23139</a>):
chore: opt out of trace attachments</li>
<li><a
href="c551cce74e"><code>c551cce</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/23130">#23130</a>):
feat(chromium): roll to r1064 (<a
href="https://redirect.github.com/Microsoft/playwright/issues/23132">#23132</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/Microsoft/playwright/compare/v1.33.0...v1.34.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27112
---------
## What is the current behavior?
The select does not expose the label or the container for the
value/placeholder as a CSS shadow part in order to style it.
## What is the new behavior?
- Exposed `label` and `container` parts for custom styling
- Added an e2e test to verify the parts are working
- Renamed the existing screenshots for the custom tests to fix a typo
from "custon" to "custom"
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `basic` test for `ion-select` contains a lot of content that is
either duplicated within the test, duplicated by other tests, or simply
not used/needed. Additionally, some select options (notably gender and
hair color) are not inclusive.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Test template cleaned up, and options replaced with less personal ones
as needed. Legacy test HTML was intentionally left alone since we'll be
removing that in the near future anyway, though I did have to tweak a
legacy E2E test since it was visiting the non-legacy page.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#27184
---------
## What is the current behavior?
The modern form controls do not use the same opacity for their labels
when disabled, resulting in inconsistent UI when using two different
types in the same view (select vs checkbox, for example).
## What is the new behavior?
The checkbox, input, radio, range, select, textarea and toggle labels
have been updated on both modes to use the same opacity as each other
when disabled. The checkbox and radio icons have been updated to use a
different opacity than the label for `md` mode.
- Updates `ios` mode so all form controls use the same opacity of `0.3`
- I could not find any guidelines by Apple for what color these should
be, so I decided to just make them the same as what is most commonly
used & match item
- Updates `md` mode so all form control labels use the same opacity of
`0.38`
- I used the [Material Design 3
documentation](https://m2.material.io/components) to get this number as
well as the opacity of the disabled selection controls in the [Material
Design 2 figma design
kit](https://www.figma.com/community/file/778763161265841481). The
Material Design 2 documentation does not mention the opacity, but this
is also the number used by Material Design 1 so it's safe to assume it
is what the disabled form labels should also use for Material Design 2.
- Updates the `md` range so the slotted elements are also included when
setting the opacity on the label
- Updates the range, radio & checkbox tests to make sure there are
screenshots in the different disabled states
- Updates the item/disabled test to include radio & textarea so you can
see all form controls side by side
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
I downloaded screenshots of the item disabled tests and put them side by
side for `main` and this branch in order to see the differences in the
labels. The grey boxes to the left of each item are just a bigger
version of the label color for that item, so it's easier to see when
they aren't the same.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27478
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The modern syntax render function was missing `renderHiddenInput` which
caused modern `ion-select` instances to not participate in form
submission. Legacy syntax is not affected.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Modern syntax calls `renderHiddenInput`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.0.7-dev.11684158250.1920157d`
Issue number: resolves#27129
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Material Design has 16px of margin between the form control and the
label, but we have 8px:
https://m2.material.io/components/selection-controls#usage
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates default margin from 8px to 16px for checkbox, input, radio,
range, select, textarea, and toggle.
Note: This should only apply to labels that are on the same line as the
form control. In other words, they do not apply to stacked/floating
labels.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27116
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
With `ion-input`, `ion-select`, or `ion-textarea` using
`fill="outline"`, applying a large value for the `--border-radius` CSS
prop causes the radius to render differently on the left and right
sides:
This is due to the structure of the outline container, which is used to
render the empty space in the border when a `stacked` or `floating`
label floats upwards. The container has three pieces, which combine to
form a seamless-looking border:
The issue is that the browser will only render a radius that fits within
the element's dimensions, and the piece on the left side (or right on
RTL) is not wide enough.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
While we could fix this issue by making the left-side piece wider (and
there was originally a PR for this at
https://github.com/ionic-team/ionic-framework/pull/27459), it was
decided to not include this fix in Ionic automatically. This is because
the fix does not work for `label-placement="stacked"` or `"floating"`;
the notch spacer (the middle piece of the outline) is pushed to the
side, leading to broken visuals:
We decided that introducing inconsistent behavior across different
values for `label-placement` would be confusing for developers. Even if
we did restructure the outline container to position the notch spacer
correctly, it could easily be made to fall on the curve of the border,
creating awkward visuals.
Instead, developers looking to use a large `--border-radius` with
`fill="outline"` should either increase `--padding-start` to be at least
as high as the `--border-radius` (which will increase the width of the
left outline piece while also moving the floating label in step), or use
`shape="round"` (which will change both the padding and border radius
automatically). This PR documents this workaround in the
`--border-radius` description.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#27201
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Selects with a floating label, no value, and a placeholder should have
the label cover the placeholder when blurred. One focus, the label
should translate to the top of the select, and the placeholder should be
visible.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Floating label now covers the select and hides the placeholder when
the select is blurred, matching the `ion-input` and `ion-textarea`
behaviors.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The team has observed that Playwright's default screenshot diff
threshold of 0.2 is not sensitive enough, and screenshots that should be
getting updated are not getting updated.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates the threshold to 0.1
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
