Issue number: resolves 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. -->
Segments can only be changed by clicking a segment button, or dragging
the indicator
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
The segment/segment buttons can now be linked to segment content within
a segment view component. This content is scrollable/swipeable. Changing
the content will update the segment/indicator and vice-versa.
## 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/docs/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. -->
**Limitations:**
- Segment buttons **cannot** be disabled when connected ton
`ion-segment-content` instances
- The `ion-segment` **cannot** be without a value when linked with an
`ion-segment-view`. If no value is provided, the value will default to
the value of the first `ion-segment-content`
[Preview](https://ionic-framework-jlt8by2io-ionic1.vercel.app/src/components/segment-view/test/basic)
[Preview (disabled
state)](https://ionic-framework-jlt8by2io-ionic1.vercel.app/src/components/segment-view/test/disabled)
---------
Co-authored-by: Brandy Carney <brandyscarney@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 new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed old tokens stored on foundations folder. Now the jsons with
the tokens come from the new dependency:
https://github.com/OutSystems/outsystems-design-tokens.
- The tokens from UX Team completely changed the structure and in some
cases the values. Everything was replaced on the project to use the new
tokens.
- Snapshots updated and differences reviewed with UX Team. A fix was
done on the testing css, to make sure the correct _Inter_ font-family
was actually used. This resulted in some differences on the text for
some componentes, that had snapshots with the native fonts.
- Removed generation of scss file on tokens script, that contained the
:root selector with the custom CSS properties, as they were not used on
the Ionic context.
- Removed generation of html file with tokens preview, as there wasn't a
great value on this (we have storybook on other contexts) and it allowed
to reduce a lot of code and complexity from the tokens script.
- The token command was adapted to use the command available from the
https://github.com/OutSystems/outsystems-design-tokens package, using
the `--config` prop, where we pass the path to our Ionic token script,
where we generate the needed scss variables and utility-classes (by
default the tokens repo tries to be as agnostic as possible, and only
generates the css variables, without the prefix and added details we
need on the Ionic side).
- Removed the token command from the npm run build, as it unnecessarily
added time on that command to run. Besides, it should not be common that
we need to run this command in the future.
- Updated reference to latest version of [Style Dictionary
4.1.3](https://v4.styledictionary.com/version-4/statement/). Version 4
comes with a lot of improvements, but also breaking-changes, so it was
needed to adapt the tokens script. The code on the script is also now
cleaner.
- Changed prefix from ionic to ion. The term ionic was used initially,
to help differentiate from the old ios/md stuff, but I feel with the
current scss architecture, that is no longer needed, and we can use the
same prefix across themes.
This requires to run `npm install ` again.
## 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/docs/CONTRIBUTING.md#footer
for more information.
-->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Issue number: internal
---------
## What is the current behavior?
The segment component does not have styles for the `"ionic"` theme and
uses `"md"` styles.
## What is the new behavior?
- Adds styles for both `<ion-segment>` and `<ion-segment-button>` styles
for the `"ionic"` theme
- Adds screenshot tests for the different icon layouts
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
Issue number: N/A
---------
## What is the current behavior?
Currently, every Sass variable in Ionic has the `!default` flag added to
the end.
From the [Sass variables
documentation](https://sass-lang.com/documentation/variables/):
> Normally when you assign a value to a variable, if that variable
already had a value, its old value is overwritten. But if you’re writing
a Sass library, you might want to allow your users to configure your
library’s variables before you use them to generate CSS.
>
> To make this possible, Sass provides the `!default` flag. This assigns
a value to a variable only if that variable isn’t defined or its value
is [null](https://sass-lang.com/documentation/values/null). Otherwise,
the existing value will be used.
In past versions of Ionic Framework, developers wrote Sass variables to
rebuild Ionic Framework using their own values. In the latest versions
of Ionic Framework, this is not possible.
## What is the new behavior?
Removes the `!default` flag from all Sass variables.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
-------
Co-authored-by: brandyscarney <brandyscarney@users.noreply.github.com>
Issue number: None
---------
<!-- 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 new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
This PR follows the architectural changes defined on the _SCSS
Architecture Design Doc_. Due to some of the developments done in the
meantime, not everything that was defined on that document was followed
and some sections were simplified.
Overall, there were two guidelines that supported the work on this PR:
- Have no impact on the current scss partials & CSS architecture for the
`md/iOS` themes.
- Make everything related to the new `Ionic` Theme separated.
Based on these, here're the changes made:
**On Themes folder (private):**
- Renamed current internal scss partials on src/themes, related to
md/iOS, to `native.*.scss` and move them to a new folder, called
`native`. Updated imports on all framework.
- Removed the ionic prefix from the name of the mixins and function
partials on src/themes. Updated imports on all framework.
- Created new folder, named ionic, inside src/themes. This holds the
`ionic.globals.scss`, with all the mixins and functions forwarded, to be
used on other scopes.
- Replaced on already created Ionic theme files, the usage of tokens and
mixins with @use, to instead _@use
"../../themes/ionic/ionic.globals.scss" as globals;_. This ensures an
equal approach is followed everywhere and also makes it easier to change
the files imported or paths, in the future, as its all in the same
global file.
- Updated the foundations `readMe` file, with the new process for using
globals.

**On css folder (public):**
- Created new folder, named `ionic`, inside src/css. This holds all the
files related exclusively to Ionic Theme, following the same structure
as exists now for md/iOS, with a core, a bundle, utils, etc. Some files
were a bit duplicated, to eliminate imports from ios or md theme
partials. The only file common to both Themes is the `normalize.scss`.
- No folder structure or renamings were done on the existing output, to
prevent breaking-changes for developers already making imports from this
folder.
- Updated typography and link partials to use globals instead of tokens.
- Changed `font-size` styles on typography to be on `body`, instead of
`html`, to enable correct support of accessibility features on browsers
and devices, related to `font-size`.

**Other changes related to global styles new architecture:**
- Updated margin & padding utility-classed generated by token, to
include css variables and padding/margin mixins.
- Updated link test to use new global Ionic bundle, correct
utility-class on ion-content and updated snapshots. The font-size
changed to 16, as its now the default on the body.
- Updated typography snapshots.
- Updated prettier format on all scss files. Later on we should make
sure this is equal for all team members.
## 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/docs/CONTRIBUTING.md#footer
for more information.
-->
---------
Co-authored-by: Sean Perkins <sean@ionic.io>
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>
⚠️ This is a combination of previously approved PRs with the
exception of
fe9dca513c.
This change was made as a result of
https://github.com/ionic-team/ionic-framework-design-documents/pull/248.
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. -->
Users do not have a way of increasing the contrast in Ionic apps. This
is valuable for people with low vision as increasing the contrast
between foreground and background content helps improve readability.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds a high contrast light and high contrast dark theme. As with our
other themes, developers can choose between system, class, and always
stylesheets.
While we aim to improve contrast for text and UI components, this
feature prioritizes text in the event that both text and UI component
cannot be improved without one negatively impacting the other.
## 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.7-dev.11706894781.1cd59fde`
Testing instructions:
1. Open `src/themes/test/css-variables`. Activate the high contrast
light and dark themes to verify that contrast does increase.
2. Use the dev build to integrate the theme into a test app (conference
app, starter app, etc).
I'd recommend using these imports:
```css
@import "@ionic/angular/css/themes/high-contrast.system.css";
@import "@ionic/angular/css/themes/high-contrast-dark.system.css";
```
Note: Make sure this is imported **after** `core.scss`
---------
Co-authored-by: Shawn Taylor <shawn@ionic.io>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@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. -->
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
Issue number: resolves#27221
---------
## What is the current behavior?
The value property of the segment component in Ionic Framework currently
only accepts string values.
## What is the new behavior?
This pull request updates the "value" property of the segment component
to accept a union of string and number types. This allows for more
versatile data input in the segment component, particularly for users
who work with numerical data.
## Does this introduce a breaking change?
- [ ] Yes
- [X] No
## Other information
N/A
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
## Pull request checklist
Please check if your PR fulfills the following requirements:
- [ ] Tests for the changes have been added (for bug fixes / features)
- [ ] Docs have been reviewed and added / updated if needed (for bug
fixes / features)
- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See the [contributing
guide](https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation)
for details.
- [x] Build (`npm run build`) was run locally and any changes were
pushed
- [x] Lint (`npm run lint`) has passed locally and any fixes were made
for failures
## Pull request type
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type, submit multiple
pull requests if needed. -->
Please check the type of change your PR introduces:
- [x] Bugfix
- [ ] Feature
- [ ] Code style update (formatting, renaming)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] Documentation content changes
- [ ] Other (please describe):
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
In v7, asynchronously assigning a value to `ion-segment` and
`ion-segment-button` can cause the `ion-segment` to render without an
active value (segment button does not show as checked).
<!-- Issues are required for both bug fixes and features. -->
Issue URL: resolves#26830
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `ion-segment-button` checked state is synced with the parent
`ion-segment`, when the component finishes the initial render.
## 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.0-dev.11678736268.18a0beb1` ✅
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- 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. -->
Segment buttons are only disabled when the segment's `disabled` property
changes. This means that segment buttons added to the segment async
don't have their `disabled` state inited correctly.
<!-- Issues are required for both bug fixes and features. -->
Issue URL: Resolves
https://github.com/ionic-team/ionic-framework/issues/25396
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Segment buttons now check if their parent segment is `disabled` when
added to the DOM.
## 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>
The Ionic Framework team would like to re-evaluate our approach to improving customization options when building mobile applications. We are looking at other solutions that a) make customizing an app UI easier and b) are applicable to a broader set of developers.