Issue number: **ROU-4815**
---------
## What is the new behavior?
- Adds an ionic theme style implementation for `ion-button`.
- Adds a new `rectangular` shape to the button.
- Adds two new button sizes: `xsmall` and `xlarge`.
- Adds a new `focus-ring` CSS shadow part for the ionic theme.
## Does this introduce a breaking change?
- [ ] Yes
- [X] No
## Preview
---------
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandy@ionic.io>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: Sean Perkins <sean@ionic.io>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: João Ferreira <60441552+JoaoFerreira-FrontEnd@users.noreply.github.com>
Co-authored-by: João Ferreira <joao.manuel.ferreira123@gmail.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. -->
When given a password input it is hard to know what users are typing as
the contents of the input are obscured. As a result, it is a common
pattern to have a button that lets users temporarily toggle the
visibility of the password so they can correct any mistakes. Ionic
currently has the infrastructure for developers to implement this on
their own, but this use case is so common that the team thinks it is
worth having this functionality built-in to Ionic.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Introduces the `ion-input-password-toggle` component. This component
is a button that toggles the visibility of the text in the input it is
slotted into.
## 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. -->
⚠️ Give co-author credit to
https://github.com/ionic-team/ionic-framework/pull/29141 on merge.
Docs PR: https://github.com/ionic-team/ionic-docs/pull/3541
Note: We did not do the approach listed in the other PR due to
https://github.com/ionic-team/ionic-framework/pull/29141#discussion_r1523631811.
---------
Co-authored-by: OS-giulianasilva <OS-giulianasilva@users.noreply.github.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. -->
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Adds the base architecture to add a new theme configuration to Ionic
Framework components.
- Components can now specify an additional stylesheet for the `ionic`
theme.
- Developers can specify the `theme` and `mode` independently to control
look and feel of a component.
Test infrastructure has been updated to add support for testing the
theme configuration with Playwright.
- Existing `themes` test configuration has been renamed to `palettes`
This PR is just the initial effort to decouple Ionic's architecture to
separate look and feel and allow our dev team to start introducing the
new component appearance to the UI. There will be additional changes
required to completely add support for the Ionic theme. These changes
are targeted against the `next` branch and are not expected to be used
in a production environment at this time.
## 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: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: internal
---------
## What is the current behavior?
In Ionic Framework v7, we [simplified the form control
syntax](https://ionic.io/blog/ionic-7-is-here#simplified-form-control-syntax),
eliminating the requirement to place form controls inside of an
`ion-item`. We ensured backwards compatibility by introducing a `legacy`
property for the form controls and keeping, but deprecating, the
following CSS variables on item:
```css
--highlight-color-focused
--highlight-color-invalid
--highlight-color-valid
--highlight-height
```
While this was supported in v7, console warnings were logged to notify
developers that they needed to update to the modern syntax if they were
using form controls in an item for the best accessibility experience.
## What is the new behavior?
Removes the `--highlight-color-focused`, `--highlight-color-invalid`,
`--highlight-color-valid`, and `--highlight-height` variables from item.
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
Steps taken to mitigate this breaking change:
1. Developers have had console warnings when using the legacy syntax
since the v7 release and the variables were marked as `deprecated`.
2. The removal of these CSS variables has been documented in the
Breaking Changes document with a link to the migration guides for the
affected form controls.
BREAKING CHANGE:
The following CSS variables have been removed from item:
`--highlight-height`, `--highlight-color-focused`,
`--highlight-color-valid`, and `--highlight-color-invalid`. These
variables were used on the bottom border highlight of an item when the
form control inside of that item was focused. The form control syntax
was [simplified in
v7](https://ionic.io/blog/ionic-7-is-here#simplified-form-control-syntax)
so that inputs, selects, and textareas would no longer be required to be
used inside of an item.
If you have not yet migrated to the modern form control syntax,
migration guides for each of the form controls that added a highlight to
item can be found below:
- [Input migration
documentation](https://ionicframework.com/docs/api/input#migrating-from-legacy-input-syntax)
- [Select migration
documentation](https://ionicframework.com/docs/api/select#migrating-from-legacy-select-syntax)
- [Textarea migration
documentation](https://ionicframework.com/docs/api/textarea#migrating-from-legacy-textarea-syntax)
The highlight variables should then be moved from the item to the form
control:
```diff
- ion-item {
+ ion-input,
+ ion-textarea,
+ ion-select {
--highlight-color-focused: purple;
--highlight-color-valid: blue;
--highlight-color-invalid: orange;
--highlight-height: 6px;
}
```
> [!NOTE]
> The input and textarea components are scoped, which means they will
automatically scope their CSS by appending each of the styles with an
additional class at runtime. Overriding scoped selectors in CSS requires
a [higher
specificity](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)
selector. Targeting the `ion-input` or `ion-textarea` for customization
will not work; therefore we recommend adding a class and customizing it
that way.
---------
Co-authored-by: Sean Perkins <sean@ionic.io>
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. -->
`ion-menu` currently accepts any `string` to the `type` property, even
though only `overlay`, `push` and `reveal` are only supported.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds more explicit types to the `type` property on `ion-menu`
## 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. -->
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. -->
In v7, using the legacy syntax, the height of the highlight on an item
could be adjusted using the `--highlight-height` variable. This variable
was not added to input and therefore would not work using the modern
syntax.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Adds the `--highlight-height` variable to `ion-input`, `ion-textarea`
and `ion-select` so that developers can customize this height in `md`
mode. Since the highlight element is not added for `ios` mode, this
variable won't do anything for `ios`. Note that this diverges from the
v7 behavior, where setting `--highlight-height` enabled the highlight
for `ios`. A design document outlining this has been proposed here:
https://github.com/ionic-team/ionic-framework-design-documents/pull/252
## 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: Brandy Carney <brandyscarney@users.noreply.github.com>
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#27606
---------
<!-- 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. -->
Certain attributes are not be inherited to the inner searchbar.
Developers need control over these attributes to provide important
context to users for things like language and text direction.
Additionally, being able to control things like autocapitalize,
maxlength, and minlength can help improve the user experience by a)
guiding what should be entered into an input and b) removing
autocapitalize where it's not appropriate.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Added autocapitalize, maxlength, and minlength properties
- lang and dir are global attributes, so adding them as properties will
cause issues. However, developers can still set them as attributes and
they will be inherited to the native `input` element. We also watch them
so any changes to the attributes are also inherited to the native
`input`.
## 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. -->
Note: We expanded the scope of this work to also include input and
textarea, and this work will be handled separately. However, the
original request was only for searchbar so that's why I associated this
PR with the linked issue.
Dev build: `7.7.3-dev.11709159644.114cd8b1`
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 Datetime header, Datetime time button, and Datetime Button have
default date formatting that cannot be set by the developer.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The developer can customize the date and time formatting for the
Datetime header and time button
- The developer can customize the date and time formatting for the
Datetime Button
- A warning will appear in the console if they try to provide a time
zone (the time zone will not get used)
- A warning will be logged if they do not include the date or time
object for formatOptions as needed for the presentation of the Datetime
## 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. -->
These changes have been reviewed in #29009 and #29059. This PR just adds
them to the feature branch now that the separate tickets are complete.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved placing an `ion-range` inside of an `ion-item` with an `ion-label`, have been removed from range. For more information on migrating from the legacy range syntax, refer to the [Range documentation](https://ionicframework.com/docs/api/range#migrating-from-legacy-range-syntax).
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved placing an `ion-checkbox` inside of an `ion-item` with an `ion-label`, have been removed from checkbox. For more information on migrating from the legacy checkbox syntax, refer to the [Checkbox documentation](https://ionicframework.com/docs/api/checkbox#migrating-from-legacy-checkbox-syntax).
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved placing an `ion-radio` inside of an `ion-item` with an `ion-label`, have been removed from radio. For more information on migrating from the legacy radio syntax, refer to the [Radio documentation](https://ionicframework.com/docs/api/radio#migrating-from-legacy-radio-syntax).
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved placing an `ion-toggle` inside of an `ion-item` with an `ion-label`, have been removed from toggle. For more information on migrating from the legacy toggle syntax, refer to the [Toggle documentation](https://ionicframework.com/docs/api/toggle#migrating-from-legacy-toggle-syntax).
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?
In Ionic Framework v7, we [simplified the input
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-input></ion-input>
</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/input#migrating-from-legacy-input-syntax)
in the input documentation to update their apps. The new syntax requires
a `label` or `aria-label` on `ion-input`:
```html
<ion-item>
<ion-input label="Label"></ion-input>
</ion-item>
```
- Removes the legacy tests under under `input/test/legacy/` and all
related screenshots
- Removes the input usage from `item/test/a11y`, `item/test/counter`,
`item/test/disabled`, `item/test/highlight`,
`item/test/legacy/alignment`, `item/test/legacy/disabled`,
`item/test/legacy/fill`, and `item/test/legacy/form` 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 input syntax is
outlined in the [Input
documentation](https://ionicframework.com/docs/api/input#migrating-from-legacy-input-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-input` inside of an `ion-item` with an `ion-label`, have
been removed from input. For more information on migrating from the
legacy input syntax, refer to the [Input
documentation](https://ionicframework.com/docs/api/input#migrating-from-legacy-input-syntax).
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: internal
---------
## What is the current behavior?
In Ionic Framework v7, we [simplified the textarea
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-textarea></ion-textarea>
</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/textarea#migrating-from-legacy-textarea-syntax)
in the textarea documentation to update their apps. The new syntax
requires a `label` or `aria-label` on `ion-textarea`:
```html
<ion-item>
<ion-textarea label="Label"></ion-textarea>
</ion-item>
```
- Removes the legacy tests under `textarea/test/legacy/` and all related
screenshots
- Removes the textarea usage in `input/test/legacy/spec`,
`item/test/disabled`, `item/test/legacy/disabled` and
`item/test/legacy/fill`
## 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 textarea syntax is
outlined in the [Textarea
documentation](https://ionicframework.com/docs/api/textarea#migrating-from-legacy-textarea-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-textarea` inside of an `ion-item` with an `ion-label`,
have been removed from textarea. For more information on migrating from
the legacy textarea syntax, refer to the [Textarea
documentation](https://ionicframework.com/docs/api/textarea#migrating-from-legacy-textarea-syntax).
---------
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. -->
The `ion-input` component currently specifies a `size` attribute to
align with the HTML `input` implementation. However, Ionic's custom
appearance for MD and iOS is not compatible and should not be used with
the `size` attribute:
https://github.com/ionic-team/ionic-framework/issues/27945#issuecomment-1669702274.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `size` property has been removed from `ion-input`.
## Does this introduce a breaking change?
- [x] Yes
- [ ] 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.
-->
The `size` attribute has been removed from `ion-input`. As it was not
compatible before, this is likely to have a minimal impact to
developers. If your application is using the `size` attribute, replace
the usage with CSS styling to control the width of the `ion-input`.
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
resolves#28826
BREAKING CHANGE: `getLength` returns `Promise<number>` instead of `<number>`. This method was not previously available in Nav's TypeScript interface, but developers could still access it by casting Nav as `any`. Developers should ensure they `await` their `getLength` call before accessing the returned value.
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. -->
Ionic's progress bar implementation deviates from the appearance of a
progress bar on iOS 17.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Progress bar is updated to have rounded corners (around the
container).
- Increases progress bar height to `4px`
- Solid progress bars (progress bars with a buffer value of `1`) will
have a consistent background appearance.
- Buffer progress bars will continue to have the colored background
appearance as they do in v7.
## Does this introduce a breaking change?
- [x] Yes
- [ ] 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.
-->
### Breaking Changes
- `--buffer-background` has been removed in favor of `--background`.
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Accomplishing rounded caps for the inner progress with Ionic's scale
transformation was not viable. To maintain 60fps animations for the
progress, rounded corners were applied to the container.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@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. -->
Action sheet buttons cannot be disabled. This behavior exists in iOS 17.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Action sheet buttons can be disabled
## 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>
Issue number: resolves#28716
---------
<!-- 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. -->
All components that have per-mode stylesheets can have their mode
adjusted by setting `mode` on the component. We use the `setMode`
function to determine which mode to use on the component:
516b84475e/core/src/global/ionic-global.ts (L75)
While this works on refresher, it is missing the `virtualProp` jsdoc
comment which causes it to not have the appropriate type information. As
a result, when developers try to use a JS binding for `mode`, they will
get compilation errors.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds virtualProp for mode to refresher
## 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. -->
I am considering this a bug fix instead of a feature. In non-TypeScript
environments you can set `mode` on `ion-refresher` and it does change
the mode. What's missing here is the type information associated with
it.
Dev build: `7.6.2-dev.11702914017.1ae72da5`
Issue number: resolves#24905, resolves#26840, resolves#15710
---------
<!-- 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 current picker is only displayed as an overlay which makes it
impossible to use inline with the rest of the application. Additionally,
there are several bugs and missing features. For example, it is
impossible to know when the value of the picker column has changed using
public APIs. This is valuable for updating other columns in response to
that data.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Introduces `ion-picker` as an inline wheel picker component. The
overlay picker is still available using `ion-picker-legacy`.
- The implementation of this component resolves linked bugs. It also
resolves linked features by exposing an `ionChange` event for developers
to listen for.
## 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.8-dev.11702398696.1ab62ea9`
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Shawn Taylor <shawn@ionic.io>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: Part of #28300
---------
<!-- 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 are unable to adjust margin, width, etc. of the radio label
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Radio label has a shadow part.
## 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. -->
As part of this work, I investigated moving `pointer-events: none` up
the DOM tree so developers wouldn't be able to override it with the
shadow part. In my testing, I was unable to see any difference in
behavior with vs without `pointer-events: none`. Therefore, I removed it
entirely.
Issue number: Part of #28300
---------
<!-- 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 are unable to adjust margin, width, etc. of the checkbox
label
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Checkbox label has a shadow part.
## 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. -->
As part of this work, I investigated moving `pointer-events: none` up
the DOM tree so developers wouldn't be able to override it with the
shadow part. In my testing, I was unable to see any difference in
behavior with vs without `pointer-events: none`. Therefore, I removed it
entirely.
Issue number: resolves#21769
---------
<!-- 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. -->
Toast does not support swipe gestures to dismiss.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Added a `swipeGesture` property that allows users to swipe toasts
closed.
Note: This is a combination of previous PRs
https://github.com/ionic-team/ionic-framework/pull/28380 and
https://github.com/ionic-team/ionic-framework/pull/28402⚠️ There is a visual glitch on iOS where dragging and having the toast
animate back to its opened position causes a flicker. This is an iOS 17
regression and is being tracked in
https://github.com/ionic-team/ionic-framework/issues/28467. This bug has
been reported to and confirmed by Apple.
## 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. -->
⚠️ Give co-author credit to author in
https://github.com/ionic-team/ionic-framework/pull/23124
---------
Co-authored-by: evgeniy-skakun <evgeniy-skakun@users.noreply.github.com>
Issue number: resolves#17499
---------
<!-- 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. -->
Currently, there isn't a way to position toasts such that they don't
overlap navigation elements such as headers, footers, and FABs.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Added the new `positionAnchor` property, which specifies an element that
the toast's position should be anchored to.
While the name can be tweaked, we should take care to keep the relation
between it and the `position` property clear. The `position` acts as a
sort of "origin" point, and the toast is moved from there to sit near
the chosen anchor element. This is important because it helps clarify
why the toast sits above the anchor for `position="bottom"` and vice
versa.
I chose not to rename the `position` prop itself to avoid breaking
changes.
Docs PR: https://github.com/ionic-team/ionic-docs/pull/3158
## 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>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#23750
---------
<!-- 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. -->
Datetime does not support h11 and h24 hour formats
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Datetime supports h11 and h24 formats
## 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. -->
Implementation Notes:
1. I broke up the `is24Hour` function into two functions:
- The first function, `is24Hour`, accepts an hour cycle and returns true
if the hourCycle preference uses a 24 hour format
- The second function, getHourCycle, accepts a locale and an optional
hour cycle and returns the computed hour cycle. I found that the hour
cycle is not always set via `hourCycle` (such as when we are using the
system default if it's specified in the `locale` prop using locale
extension tags). This was coupled to is24Hour, but I needed this
functionality elsewhere to add support for this feature, so I decided to
break the functions up.
2. We were using the hour cycle types in several places, so I decided to
create a shared `DatetimeHourCycle` to avoid accidental typos.
Issue number: resolves#25340
---------
- Exposes the following parts for a calendar day: `calendar-day`,
`today`, and `active`
- Combines the `calendar-day-highlight` element with the `calendar-day`
element so developers don't have to know to style two different elements
& we don't have to expose them as separate parts
- Improves height parity of the calendar day across browsers
- Updates the `custom` e2e test to include an example of styling days
using the newly exposed CSS parts
- Adds tests for the focus states of the calendar day
Issue number: resolves#22142
---------
<!-- 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. -->
Textarea always takes up the entire width of a line which prevents the
`cols` property from working correctly.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The textarea respects the `col` property value only when `autoGrow` is
`false`
## 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.3.2-dev.11693402720.1adb3bcf`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
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#26596
---------
<!-- 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. -->
There is no way to customize the month/year toggle button using CSS.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds a Shadow Part to the month/year toggle button.
## 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#25945
---------
<!-- 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. -->
Datetime wheel pickers cannot be styled.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Adds styling APIs in accordance with the Wheel Pickers and Time Picker
sections of [this design
doc](https://github.com/ionic-team/ionic-framework-design-documents/blob/main/projects/ionic-framework/components/datetime/datetime-styling.md).
Shadow parts added:
- `wheel-item`
- `wheel-item active`
- `time-button`
- `time-button active`
CSS properties added:
- `--wheel-highlight-background`
- `--wheel-fade-background-rgb`
## 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.11685554390.10c2ca9b`
Docs PR: https://github.com/ionic-team/ionic-docs/pull/2982
