Add distinct visual for `ToggleButton` Indeterminate state when `IsThreeState=true`
Describe the bug
ToggleButton with IsThreeState=true (text icon only) => same aspect for unckecked and inderterminate
Aspect should be different.
Reproduction
I've created a Three State ToggleButton, with only one text icon
<ToggleButton x:Name="autoFitToggleButton" Width="30" Height="30" Padding="0" IsThreeState="True"> <ui:FontIcon FontSize="20" Icon="{x:Static ui:SegoeFluentIcons.FitPage}" /> </ToggleButton>
Here are the different aspects.
Checked
Unchecked
Indeterminate
=> We cannot distinguish indeterminate from unchecked
Suggested Solution
No response
Library Version
Trunk version / 2025.07.07
Operating System
Windows 11
Framework
.NET Framework
Framework Version
4.7
Source of Package
Self-Compiled
Additional Notes
No response
Validations
- [x] Check that there isn't already an issue that reports the same or similar problem.
- [x] Check that this is a bug in the library that should be fixed, not a feature, also this is not about the documentation. (Or please choose the right repo and template.)
- [x] This is one single problem, or a few problems with the same cause. (If you want to report multiple problems, please create one issue for every single problem.)
- [x] You've checked that this problem still exists in the latest version. (Keep in mind that we don't provide any support for old versions.)
- [x] You know that we can't guarantee that we will satisfy your request. This is not really our duty to do everything anyone asks for. Also, you will treat our staff, contributors, and other users with respect and kindness.
- [x] You're sure there's something wrong with the library itself, not how you're using it. (If you are having issues using it and need help, please go to discussion.)
Thanks for filing this. What you're seeing is in fact the stock WPF & WinUI behavior:
Note ToggleButton has the same visual state for the indeterminate and unchecked states. Derived controls, like CheckBox, may define different visual states for each state.
From https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.primitives.togglebutton
If you need a unique third-state appearance for an icon-only toggle, here are some paths you can take:
1. Custom style override
Replace or augment our default ControlTemplate in your app. However, that would require more effort to maintain and could lead to inconsistencies with future updates, more importantly, it would break the Fluent Design System.
2. Use other existing controls
Consider using other existing controls that may better suit your needs, such as a CheckButton or a custom ToggleButton implementation that supports the desired visual states.
3. Adjust your design
People usually do not use ToggleButton for indeterminate states. Instead, consider using a different design pattern that better communicates the intended state to users.
In the screenshot you provided, it looks like you are trying to use an icon-only toggle. Maybe you can consider using a different icon or visual cue to represent the indeterminate state.
4. Framework-wide change
We do not rule out not following Microsoft's rules and designing a separate style for the intermediate state. But since its kinda destructive to the overall design consistency, before we diverge from the default, something to consider is:
- Is it really necessary? Does it really compromise the Fluent Design and UX principles?
- Do we want this distinction to be built in, or leave it opt-in?
- If built-in, what's the minimal, sensible differentiation (e.g. 50% opacity vs. new icon)?
- Should we expose a new API or rely purely on theme resources and templating?
- What are the potential impacts on existing users and scenarios, especially apps that 'rely on this specific weirdness'?
Would love to see any quick mockups or CSS-style resource suggestions you have in mind. Once we agree on the scope and API, draft a PR to add indeterminate-state theming.
Thanks for your answer.
Regarding "4. Framework-wide change", as isThreedState has no effect today, I don't consider handling it as a breaking change but rather as an evolution. There's no reason that people have set this flag whereas it has no effect.
Curious to hear everyone’s thoughts on how the Indeterminate state should be represented in the default style. Right now, it’s visually too close to Unchecked, which makes it hard to tell them apart at a glance.
My suggestion
For the third state, keep the background white (to stay consistent with the unselected look) but add a clear accent‑colored border outline. This would make it stand out without introducing a completely new fill color, and it would remain theme‑friendly.
Questions for you guys
- Would you prefer a purely border‑based cue, or should we also consider a background/foreground change?
- Any accessibility concerns we should keep in mind (contrast, high‑contrast mode, etc.)?
If we can agree on a visual direction, we could then update the default control template so this works framework‑wide without per‑app overrides.
As checked background is blue and unchecked background is white (depending on theme), a possibility would be two have half background blue and half background white (2 triangles, splitted according to diagonal).
As checked background is blue and unchecked background is white (depending on theme), a possibility would be two have half background blue and half background white (2 triangles, splitted according to diagonal).
That would mess up the foreground
I agree, except if text is also displayed in two différent colors, according to background.
Or maybe an intermediary background color. Not really clear though.
I agree, except if text is also displayed in two différent colors, according to background.
Or maybe an intermediary background color. Not really clear though.
I'll stick to the accent outline look for now.