Issue number: resolves#29393
---------
<!-- 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 Stencil v4.17.1, in Angular apps Stencil's `MockDoc` will be
bundled with the consumer's code resulting in a significant increase to
the main chunk.
|v8.0.0|
|---|
||
|v8.0.1|
|---|
||
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates to v4.17.2 of Stencil, which resolves this regression 🎉
|Dev-build|
|---|
||
## 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. -->
Dev-build: `8.0.2-dev.11714402065.169342dc`
Issue number: resolves#29321
---------
<!-- 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 using a select with `fill="outline"`, `interface="popover"` and a
width that fits the content of the options, the select options are not
visible. The hidden radio is covering the text of the radio text
options.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Select options are visible and no longer covered by the hidden radio
container
## 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. -->
Dev-build: `8.0.2-dev.11714165638.13e7dd5b`
Reproduction (issue): https://stackblitz.com/edit/angular-mndtkr
Reproduction (with dev-build):
https://stackblitz.com/edit/angular-mndtkr-d7wsnp
Reproduction steps:
1. Open the select
2. Observe: The popover displays the options, but the options are not
visible/readable to the user
3. Use the dev-build
4. Open the select
5. Observe: The popover displays the options and they are
visible/readable to the user (5, 10, 15).
Issue number: resolves#29386
---------
<!-- 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 item border does not have sufficient contrast in dark mode making
the border almost invisible.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the `--ion-border-color` in the MD dark palette. Instead,
we're using the [theme
default](dc1172a841/core/src/themes/ionic.theme.default.md.scss (L31)).
## 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. -->
The earliest reference to the offending line Brandy and I could find was
[here](https://github.com/ionic-team/ionic-framework/issues/18713#issuecomment-510644371).
Issue number: resolves
https://github.com/ionic-team/ionic-docs/issues/3588
---------
<!-- 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 documentation around `ionChange` not being emitted when
programmatically changing the property associated to the "value" is
either inconsistent or missing from certain components.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds the documentation to the missing components.
- Makes the documentation consistent across components.
## 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. -->
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: 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. -->
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates to the latest version of Stencil
- Includes a fix for the api.txt diff issue we are experiencing off
`next`
## 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. -->
Issue number: resolves#29358
---------
<!-- 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 the clear button is focused, `focusin` is dispatched and bubbles up
to the `ion-input`. Our [scroll assist utility listens for
`focusin`](2fc81ddc9b/core/src/utils/input-shims/hacks/scroll-assist.ts (L135))
to adjust the scroll position. It also causes the input to be
re-focused. As a result, when swiping to the clear button with a screen
reader, focus will be forcibly moved back to the input. This means that
users cannot swipe away from the input to the right when using a screen
reader.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- To fix this, I decided to have the `focusin` event from the clear
button not bubble (as opposed to add a really specific workaround to the
scroll assist utility).
Adding `stopPropagation` was easy enough, but it turned out that the
scroll assist listeners were all configured to listen during the capture
phase instead of the bubble phase. As a result, `stopPropgation` had no
effect because the scroll assist callback had already fired. To address
this, I updated the listeners to listen during the bubbling phase
instead of the capture phase. Based on my testing the capture phase was
not required for scroll assist to work, so it appears safe to remove.
## 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. -->
Dev build: `8.0.1-dev.11713535425.1a4afba3`
Reviewers: Please test this on a physical iOS device and be sure to test
the scroll assist behavior. There is a test at
http://localhost:3333/src/utils/input-shims/hacks/test you can use.
Issue number: resolves#29374
---------
<!-- 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 using Angular binding syntax, the `debounce` value can be set after
`connectedCallback`, but before `componentDidLoad`. This results in the
internal representation of the `debounce` value to be the default and
the watch callback to never fire.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The callback handler for `debounce` is called on component load,
identical to what we do for the same exact reasons for the input `type`.
- `debounce` will correctly reflect and apply the developers value when
using binding syntax on initial load
## 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. -->
Dev-build: `8.0.1-dev.11713879639.102f51a0`
Forked reproduction with the dev-build is available here:
https://github.com/ionic-team/ionic-framework/issues/29374#issuecomment-2072377087
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. -->
If a dev wants to view a test page in dark mode, they have to manually
add the styles. This can lead to a slowdown. Plus they can't use
Playwright's `goto` to test both light and dark. In order to test dark
mode with Playwright, the dev would need to use `setContent` instead of
`goto`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Dark mode can be added to any page by appending `palette=dark` to the
URL.
- The param will be used to add a link tag with the correct palette
file.
- Playwright will load the correct palette file when a dev uses `goto`
and `{ themes: ['dark'] }`
## 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 recommend using badge to try this out. It already has a `goto` in the
basic tests.
Issue number: N/A
---------
## What is the current behavior?
Dark palette is hardcoded in style tags in tests.
## What is the new behavior?
Updated the following tests:
- **datetime/basic** - added an import for `dark.class.css` which works
with the checkbox to toggle the `ion-palette-dark` class
- does not update the e2e test to include dark palette because this was
not tested previously
- **datetime/color** - added an import for `dark.class.css` which works
with the checkbox to toggle the `ion-palette-dark` class
- updates the e2e test to use the dark palette
- **modal/dark-mode** - added an import for `dark.always.css` which
always applies the dark palette
- does not update the e2e test to include dark palette because this test
needs to be moved but I am not sure where it should go yet
- **toggle/enable-on-off-labels** - added an import for `dark.class.css`
which works with the checkbox to toggle the `ion-palette-dark` class
- updates the e2e test to use the dark palette & splits the color into a
separate screenshot test
Did not update the following tests:
- **item/buttons** - has already been updated to remove the dark palette
- **toggle/legacy/enable-on-off-labels** - test was removed in v8
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
- We could probably remove the checkbox toggles entirely when we add
support for the `palette` query param.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#29219
---------
<!-- 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 got feedback that the current dark theme is a bit jarring when
compared with native. In particular, devs are expecting the contrast to
be white for many of these colors to match native iOS. Currently, text
inside of a primary button is black on dark mode, but devs expect it to
be white. Additionally, the dark mode colors appear to be too washed out
when compared with their light mode counterparts.
The team discussed this and we think we can find a way to make the
colors more in line with what devs expect while still allowing for AA
color contrast levels.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adjusted the secondary and danger colors to be slightly more
vibrant/inline with what developers expect in mobile apps while still
meeting AA color 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
I intentionally did not change the contrast color, and I intentionally
did not significantly change the vibrancy of each color token. I did
some research into how the native platforms handle colors. I'll place
this information here, because there are some subtle differences between
web and native that make a difference.
### Material Design
[Source](https://m2.material.io/design/color/dark-theme.html#ui-application)
Material Design 2 calls for desaturated color tokens as well as flipping
contrast colors. For example, a vibrant purple background with light
text on light mode is a washed purple with dark text on dark mode. The
colors in Ionic <=7 did not follow these patterns. The tokens in Ionic 8
now follows these patterns, so what we have in `main` means we are
aligning closer with native MD than have in the past.
### iOS
[Source](https://developer.apple.com/design/human-interface-guidelines/accessibility#Color-and-effects)
iOS is a bit tricky. On the docs, Apple references the WCAG color
contrast formula (what Ionic follows). However, the table they present
below is slightly different:
| Text Size | Text Weight | Minimum Contrast Ratio |
| - | - | - |
| Up to 17 points | All | 4.5:1 |
| 18 points and larger | All | 3:1 |
| All | Bold | 3:1 |
The last row is the main difference. WCAG states that text that is bold
AND >=14pts (~18.66px) needs to meet a minimum contrast ratio of 3:1.
Apple's guidelines state that any text that is bold (regardless of size)
needs to meet a minimum contrast ratio of 3:1. In other words, **Apple
is using different guidelines to choose colors which is why colored dark
mode buttons on iOS typically use white text**.
However, Apple is inconsistent in implementing its own guidelines.
Consider the following red buttons in the Apple Music app.
| Screenshot | Meets Web guidelines | Meets Apple guidelines | Notes |
| - | - | - | - |
| <img
src="https://github.com/ionic-team/ionic-framework/assets/2721089/6bb0e0b3-c29e-4b96-9ad5-e45e59bf0415"
width="300" /> | ❌ | ❌ | Text is not bold which makes it not meet either
guidelines. |
| <img
src="https://github.com/ionic-team/ionic-framework/assets/2721089/8ce93b45-0b2b-4160-97a4-19852134684c"
width="300" /> | ❌ | ✅ | Text is bold which makes it pass the Apple
guidelines, but it's still too small to also pass the Web guidelines. |
### Ionic
One of the things I tried is adjusting the base color to work well with
white and black backgrounds. It's common to have a blue background with
white text (such as a button) AND to have a blue link on a black
background (such as an `a` element). This approach does not work well
for the shade/tint colors used for hover/focus states. These colors also
need to meet Web guidelines.
Consider the following example:
| Screenshot | Notes | Text/Link passes AA guidelines | Tint passes AA
guidelines |
| - | - | - | - |
| 
| This uses the same primary color found in the light palette | ❌ | ✅ |
| 
| This changes the base color such that the Text/Link passes with a
4.5:1 ratio | ✅ | ❌ |
| 
| This changes the base color such that the Tint passes with a 4:5:1
ratio | ❌ | ✅ |
We also considered adjusting the `a` and `ion-text` colors to use the
tint color. We decided against that because it a) felt a little odd
given that tint is typically used for states (hover, focus, etc) and b)
we were concerned that making this change would impose future
restrictions on how this color palette can evolve.
### Conclusion
While Ionic's colors don't exactly match the iOS colors, the reality is
that we are a web-based tool, so we are going to be evaluated using
web-based tools/standards. As a result, it's recommended that we align
closer with the Web guidelines than Apple's guidelines.
## Testing
Testing:
Developers can look at the colors by opening
http://localhost:3333/src/themes/test/colors
In the video below, the first state is the dark theme in `main`. The
second state is the proposed changes.
| Visual Comparison |
| - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/241fb1b6-212b-4f03-83cd-9558b9a53761"></video>
|
Team members on Windows were having trouble running tests inside of
Docker. Given that headed tests must use WSL, I think it makes sense to
have Windows devs use WSL for any E2E tests run inside of Docker. That
way they aren't switching back and forth between shells.
This PR clarifies the Docker docs that instruct devs on how to use WSL.
Issue number: resolves#24583
---------
<!-- 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. -->
See
https://github.com/ionic-team/ionic-framework/issues/24583#issuecomment-2033478601
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- See https://github.com/ionic-team/ionic-framework/pull/29260 and
https://github.com/ionic-team/ionic-framework/pull/29259. This PR is a
combination of previously reviewed fixes.
## 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. -->
Dev build: `7.8.3-dev.11712695191.1d7ec370`
Start your review here 👉
[docs/README.md](https://github.com/ionic-team/ionic-framework/blob/FW-6107/docs/README.md)
## What is the current behavior?
Documentation files with information on how to contribute, component
implementations, testing, etc. are scattered throughout various folders
in this repository.
## What is the new behavior?
Consolidates the documentation files into a root `docs/` directory for
easier discovery and organization.
`/docs` tree:
```
├── _config.yml
├── component-guide.md
├── CONTRIBUTING.md
├── README.md
├── sass-guidelines.md
├── angular
│ ├── README.md
│ └── testing.md
├── core
│ ├── README.md
│ └── testing
│ ├── README.md
│ ├── api.md
│ ├── best-practices.md
│ ├── preview-changes.md
│ └── usage-instructions.md
├── react
│ ├── README.md
│ └── testing.md
├── react-router
│ ├── README.md
│ └── testing.md
├── vue
│ ├── README.md
│ └── testing.md
└── vue-router
├── README.md
└── testing.md
```
**Migrates the following:**
| Previous Location | New Location |
| ----------------------------------------------------------- |
----------------------------------------- |
| `.github/COMPONENT-GUIDE.md` | `docs/component-guide.md` |
| `.github/CONTRIBUTING.md` | `docs/CONTRIBUTING.md` |
| `core/scripts/README.md` | `docs/core/testing/preview-changes.md` |
| `core/src/utils/test/playwright/docs/api.md` |
`docs/core/testing/api.md` |
| `core/src/utils/test/playwright/docs/best-practices.md` |
`docs/core/testing/best-practices.md` |
| `core/src/utils/test/playwright/docs/README.md` |
`docs/core/testing/README.md` |
| `core/src/utils/test/playwright/docs/usage-instructions.md` |
`docs/core/testing/usage-instructions.md` |
| `packages/angular/test/README.md` | `docs/angular/testing.md` |
| `packages/react-router/test/README.md` |
`docs/react-router/testing.md` |
| `packages/react/test/README.md` | `docs/react/testing.md` |
| `packages/react/test/base/README.md` | `docs/react/testing.md` |
| `packages/vue/test/README.md` | `docs/vue/testing.md` |
**Adds the following:**
| File | Description |
| ----------------------------- |
-----------------------------------------------------------------------
|
| `docs/sass-guidelines.md` | Sass Variable guidelines taken from
`ionic-framework-design-documents` |
| `docs/README.md` | Entry file that should link to all other files |
| `docs/_config.yml` | Config file for use with GitHub pages |
| `docs/core/README.md` | Description of core, links to contributing and
testing |
| `docs/angular/README.md` | Description of angular, links to
contributing and testing |
| `docs/react/README.md` | Description of react, links to contributing
and testing |
| `docs/react-router/README.md` | Description of react-router, links to
contributing and testing |
| `docs/vue/README.md` | Description of vue, links to contributing and
testing |
| `docs/vue-router/README.md` | Description of vue-router, links to
contributing and testing |
| `docs/vue-router/testing.md` | Testing file for vue-router, populated
from vue-router's main README |
**Does not** add any files for `angular-server`. This is because the
README is essentially empty and there is no testing in that directory. I
can add blank files if we want to have something to add to later.
**Does not** migrate the content of the packages' root `README.md`
files. These files are used for their npm package descriptions so we
should not edit them.
## Hosting Documentation
We can (and should) host these files using GitHub Pages. I have
duplicated them in a personal repository to see how this would look:
[docs-consolidation](https://brandyscarney.github.io/docs-consolidation/).
Doing so will require some formatting fixes (see [Sass
Guidelines](https://brandyscarney.github.io/docs-consolidation/sass-guidelines.html#-reusable-values))
so I did not publish them now but we can easily enable GitHub pages by
toggling a setting in this repository.
## Other information
- Verify that no documentation files were missed in the migration
- You can use these commands to search for `*.md` files in a directory:
- `find core/src -type f -name "*.md" -print`
- `find packages/angular -type f -name "*.md" -not -path
"**/node_modules/*" -print`
- I did add some redirect links in some of the existing markdown files
so they might still exist for that reason
- We should probably break up the contributing + component guide
documentation into smaller files, such as including best practices, but
I wanted to get everything in the same place first
- The contributing has sections on each of the packages that we could
move to that package's docs folder:
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#core
---------
Co-authored-by: Maria Hutt <thetaPC@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. -->
Ionic Framework developers make extensive use of multi-line comments in
the Sass files. However these comments are not stripped from the
generated output.
This leads to a significant increase to the file size of CSS and can
have an impact on runtime performance.
For example: https://cdn.jsdelivr.net/npm/@ionic/core/css/core.css has
183 lines of comment blocks before a single line of CSS.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Compresses the generated output from Sass → CSS to strip out
multi-line comment blocks.
- Developers can use [loud
comments](https://sass-lang.com/documentation/syntax/comments/) if they
want to include comments in the generated output.
- In the case of just the core.css file, the file size goes from 20kb to
10kb.
- The entire CSS global styles goes from 758 KB to 606kb.
## 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.8.4-dev.11712251308.1da8aede`
Move the `docs/` directory into the `packages/` directory. This will
enable us to create a top level `docs/` folder for onboarding and
contributing guidelines. It will also be necessary when migrating to
pnpm.
---------
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. -->
When using an outline-style button in a toolbar on `md` dark mode, the
activated style causes the button to become invisible.
Steps to repro in `main`:
1. Update the `css-variables` themes test to use the latest dark theme
styles (at least for v7) by replacing the contents of [this
file](https://github.com/ionic-team/ionic-framework/blob/main/core/src/themes/test/css-variables/css/dark.css)
with the [styles from the
docs](https://ionicframework.com/docs/theming/dark-mode#ionic-dark-theme).
2. Host the project locally and navigate to the test at
`themes/test/css-variables/index.html`.
3. Switch to dark mode within the page. Note that the activated outline
button isn't visible:
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Button styles corrected. The colors were correct for `ios` mode, but
had to be flipped for `md`, so I pulled the relevant styles into the
mode-specific stylesheets.
- CSS variables test has also been updated to use the same dark mode CSS
as in [the
docs](https://ionicframework.com/docs/theming/dark-mode#ionic-dark-theme),
as per the repro steps above. Let me know if you would rather this be
split into a separate PR.
Changes to the toolbar test were split into a separate PR to keep this
one clean and ensure the screenshot changes can be reviewed more
effectively: https://github.com/ionic-team/ionic-framework/pull/29231
## 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.
5. Update the BREAKING.md file with the breaking change.
6. 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#29211
---------
<!-- 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 https://github.com/ionic-team/ionic-framework/pull/28861 I fixed a
bug that caused `.popover-viewport` to have `overflow: hidden`. In
reality, this code should have always applied but due to an incorrect
selector it never did.
As it turns out in
https://github.com/ionic-team/ionic-framework/issues/29211, some
developers were relying on the broken behavior to build their
applications. In particular, developers were using `ion-popover` without
an `ion-content`. The linked change made it so that using popovers
without `ion-content` were not scrollable.
After talking with @mapsandapps we think it makes sense to officially
support this behavior. We support using [modals without
`ion-content`](https://ionicframework.com/docs/api/modal#custom-dialogs),
and we could not think of a reason to not support the same use case for
popover.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- If the `.popover-viewport` element has a child content then
`.popover-viewport `will not be scrollable.
- If the `.popover-viewport` element does not have a child content then
`.popover-viewport` will be scrollable.
I implemented this behavior using progressive enhancement via `:has`.
The [`:has` pseudo-class](https://caniuse.com/?search=%3Ahas) has
cross-browser support. Ionic v7 supports some versions of browsers that
do not have `:has` support. As a result, we fall back to the existing
behavior in this environment. Developers are able to get this behavior
on older browsers by explicitly setting `overflow: auto` on
`.popover-viewport`.
Fortunately, we will be dropping support for several of the older
browsers versions in Ionic v8, so the need to do the manual opt-in
should be less frequent as time goes on.
## 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.8.2-dev.11711383079.118d48a5`
Testing:
1. Open https://codepen.io/liamdebeasi/pen/JjVJrZQ?editors=1100 (this
has a dev build installed)
2. Click each button to open a popover.
3. Verify that each popover can be scrolled.
I could not find a great way to automate this test, but let me know if
anyone has ideas!
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 toolbar `basic` test only checks light theme. Dark theme coverage is
required to test against the bug fixed in
https://github.com/ionic-team/ionic-framework/pull/29216.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Dark theme coverage added. This required converting the test to
`page.setContent` instead of `page.goto`, so I went ahead and split the
captured toolbars into multiple tests, including some cleanup of the
test content. Since this included changes across many different tests,
even ones not strictly related to the bug, this work has been split into
a separate PR.
## 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: 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>
