Proposal: Adding a Expander Control to the set of WinUI controls.

[ejserna]

Proposal: WinUI Expander Control

A spec has been opened with a PR for this issue. Feel free to continue general discussion in this proposal!

Summary

Throughout Windows, different expander controls are used by Windows Security, Settings, Photos, Paint 3D, the Notification Center, 3D Viewer, Toasts and the UWP Onedrive app. There’s currently no consistent "Windows" way of addressing this common UX pattern. An Expander control is motivated by both its use in many app scenarios and achieving parity with WPF.

Rationale

• There should be a built-in and consistent Fluent way to expand and collapse content.
• Expander scenarios exist across many surfaces that are not aligned in behavior and style, including being Narrator-friendly, keyboard controls, animations, designs, and high contrast changes.

Scope

Capability	Priority
Provide consistent expander behavior across WinUI apps	Must
Expand in size (pushing other content) and collapse based on user interaction with the control	Must
Support controls like Button, ToggleSwitch in the unexpanded and expanded content	Must
Support Expanding in all 4 directions	Should*
Support modifying all content (including the header) in expanded state	Could
Support expanding an InfoBar (open question on implementation)	Could
Include "accordion behavior" logic between Expanders	Won't
Be light dismissible	Won't

*The v1 Expander could be scoped to only expand in the downwards direction, with default down and ExpandDirection added later.

Important Notes

Proposed API

Public enum ExpandDirection 
{ 
Down = 0 
Up = 1 
Left = 2 
Right = 3 
} 

public class Expander : ContentControl 
{ 
Expander(); 

public object Header {get;set;} 
public DataTemplate HeaderTemplate { get;set; } 
public DataTemplate HeaderTemplateSelector {get;set;} 

public static readonly DependencyProperty HeaderProperty; 
public static readonly DependencyProperty HeaderTemplateProperty; 
public static readonly DependencyProperty HeaderTemplateSelectorProperty {get;} 

public bool IsExpanded { get;set} 
public ExpandDirection ExpandDirection { get;set;} 

protected virtual void OnExpanded(); 
protected virtual void OnCollapsed();

public event Expanded; 
public event Collapsed; 

public static readonly DependencyProperty IsExpandedProperty; 
public static readonly DependencyProperty ExpandDirectionProperty; 
} 

Visual States:  
ExpandStates: Expanded/Collapsed 

Accessibility: 
Support Expand/Collapse pattern (IExpandCollapseProvider) 

Expander Controls Elsewhere

• WPF
• Windows Community Toolkit
• Telerik UI
• Xamarin.Forms
• Syncfusion.XForms.Expander
• Avalonia UI

Examples of Expander Scenarios

Open Questions

• In discussion with the WinUI team, it was brought up that a V1 scoped to expand downward would shorten development time and make Expander available for developers sooner (as the scenarios for Expander thus far have all been downward), and a planned V2 could add ExpandDirection soon after. In your apps, are there any scenarios where Expander would need to expand in directions other than downward?

• How should Expander work with InfoBar? Adding expanding functionality to InfoBar? Putting InfoBar as the content of an Expander? The reverse?

[mdtauk]

@mdtauk proposed Including an ExpandTransition and CollapseTransition,

that can use the direction set by the control's property - which could allow the dev to set the transition for each.

Sounds like a smaller scope than using ElementAnimator. Would this give developers complete flexibility in setting the transitions?

Off the top of my head, a resize for the parent panel with easing. Then a slide and fade for the containing object(s) would feel right.

I understand parts of this, but its hard for me to visualize without, well, a visual 😄. Does "resize for the parent panel" mean the header would change in size? Could you elaborate on what you mean by "a slide and fade for the containing object(s)"?

Sorry for the delay, I had to make this little mock-up animation. Ignore the actual animation timings, they are just for illustration. The Pink outline is the Expander Header - and the Green Border is for the Expander Pane/Content etc

[marcelwgn]

I'm not sure that TreeView and hierachical NavigationView have the exact same animation scenario as Expander, what about when Expander will push whatever content (not necessarily text/buttons) nearby and the scenarios when Expanders are 'accordion'-ed with each other and potentially have logic to close/open depending on each others' expansion.

The question is, should Expander enforce animations though? TreeView and Hierarchical NavigationView definitely would benefit from having a built in expander control that takes care of the expanding/collapsing and would allow us to be able to have a more unified experience in that area. For example, TreeView does not animate anything while hierarchical NavigationView animates the rotating of the chevron.

Is ElementAnimator overkill for Expander animations given that it's intended for panel/collection animations?

It might be, one of the controls that actively support ElementAnimator (at least in preview) is ItemsRepeater which deals with large panels rendering dozens of items. Expander on the other hand does not have such a complex scenario but rather one single item to show/hide.

---

A different thing I noticed is that there wouldn't be a way to customize where the chevron would be placed (left/right or top/bottom). Maybe this would be useful to have as a customization point? NavigationView places the chevron on the right while TreeView places it on the left. Same goes for existing expanders in the system, some areas of the settings app place it on the left while Notifications for example, place them on the right.

[Felix-Dev]

A different thing I noticed is that there wouldn't be a way to customize where the chevron would be placed (left/right or top/bottom). Maybe this would be useful to have as a customization point? NavigationView places the chevron on the right while TreeView places it on the left. Same goes for existing expanders in the system, some areas of the settings app place it on the left while Notifications for example, place them on the right.

We could introduce something like an ExpandGlyphPlacementMode with values like TopLeft, TopRight, BottomCentered (and possibly more (Left, Right, ...)) and an additional ExpandGlyphPlacementOffset property developers could use to modify the base position (set by placement mode) if required.

In addition to that, as @mdtauk already noticed, APIs to customize the expand/collapse glyphs (some controls use >, others use v for their expand glyph) and to control the visibility of the glyph.

[marcelwgn]

We could introduce something like an ExpandGlyphPlacementMode with values like TopLeft, TopRight, BottomCentered (and possibly more (Left, Right, ...)) and an additional ExpandGlyphPlacementOffset property developers could use to modify the base position (set by placement mode) if required.

I am not sure if TopLeft, TopRight ... is the right choice here. Maybe something like "Start" and "End" might be better suited here? In horizontal layouts, Start would be on the left (right in RTL languages), in vertical opening mode, this would be top. "End" could be defined accordingly then. The issue I see with TopLeft ... is that it introduces a lot of complexity (see TeachingTip) for little benefit. TopLeft and TopRight would be the same if the ExpanderControl opens to the right. I think having something like bottom centered is going to look a bit awkward in a lot of spaces and take up a lot of space.

In addition to that, as @ mdtauk (splitting up mention to not spam his inbox) already noticed, APIs to customize the expand/collapse glyphs (some controls use >, others use v for their expand glyph) and to control the visibility of the glyph.

The question is, how to achieve this. If we want to animate the icon similiarly to what hierarchical NavigationView does, we won't be able to allow an API for swapping out the expanded and collapsed glyph which could be used to switch to v or > for collapsed. Maybe we could have an API indicating the collapsed glyph direction?

[robloo]

The ideas for animations seem pretty good. It needs to be possible to turn them on/off just like List View, et al. The header and glyph also need to switch sides for RTL languages automatically. However, all the glyph customization seems to be overengineering the problem. It is impossible to create a style that will work for all cases identified that have custom implementations. Instead, just like CheckBox and other controls, the default design should be the best we can do but the default style should be simple enough to re-template. I dont know why everyone is so adverse to re-templating controls it very much is the solution and is actually a great strength of look less controls. Adding more properties is also increasing that maintenance burden I hear so much about.

Edit: defining resources for a few things to improve lightweight styling might be a reasonable option as well.

[Felix-Dev]

I am not sure if TopLeft, TopRight ... is the right choice here. Maybe something like "Start" and "End" might be better suited here? In horizontal layouts, Start would be on the left (right in RTL languages), in vertical opening mode, this would be top. "End" could be defined accordingly then. The issue I see with TopLeft ... is that it introduces a lot of complexity (see TeachingTip) for little benefit.

@chingucoding The NavigationView uses a vertical opening mode (since a NavigationViewItem expands vertically), right? How would I then be able to set the glyph either on the left or the right side of the header? I'm reading your comment as "start" would be top, "end" probably bottom of the header then. But I'm not seeing a way to specify if the glyph can be placed in the top left corner or the top-right corner. I shouldn't have to use an API like ExpandGlyphPlacementOffset for something we are seeing that commonly.

I think having something like bottom centered is going to look a bit awkward in a lot of spaces and take up a lot of space.

I am sure I have seen examples of that on the web, in apps, etc...which is why I came up with that idea. Though it would best if examples could be posted here to see if that is something worth supporting directly or whether we would leave that up to re-templating.

However, all the glyph customization seems to be overengineering the problem. It is impossible to create a style that will work for all cases identified that have custom implementations. Instead, just like CheckBox and other controls, the default design should be the best we can do but the default style should be simple enough to re-template. I dont know why everyone is so adverse to re-templating controls it very much is the solution and is actually a great strength of look less controls.

@robloo I'm not adverse to re-templating but looking at the examples posted so far, some developers use ">" for the expansion glyoh and others use "v" for the expansion glyph when expanding vertically. Same as for the position of the glyph. The Expander control should make it very easy for developers to set the glyph according to their wishes. Re-templating always comes with trade-offs, mainly that you won't automatically benefit from future changes being made to the control template in WinUI. Instead, that burden will be now on the developers to maintain their customized template.

We should identify common customization scenarios and strive to make them as accessible as possible by the Expander control.

Take, for example, this case of customized glyphs (found on the Fluent UI website):

Glyph symbol customization will necessarily mean any in-built glyph animation has to be considered carefully. Also interestingly to know: What would be more desired by customers - the ability to easily customize the glyphs according to their liking or having an in-built animation for the glyph (like seen in the NavigationView). I personally think the former would be more important to have but I don't have any hard data to back that up.

Another Expander control is the Telerik Expander control which exposes some of the customization APIs we have been discussing here (like the ability to change the position of the glyoh or the glyph symbol) which we could also use for some inspiration.

[mdtauk]

ExpandedGlyph CollapsedGlyph Which the developer could override as they see fit

GlyphPlacement.Start .End .Above .Below Maybe?

Maybe also use content alignment to handle the header filling the width, or have the Glyph and text bunched up together

For the Notification Centre there is a clear all on the same line as the expander, so how would this be handled? Some kind of way to separate the expanding panel from the expanding header?

[marcelwgn]

@chingucoding The NavigationView uses a vertical opening mode (since a NavigationViewItem expands vertically), right? How would I then be able to set the glyph either on the left or the right side of the header? I'm reading your comment as "start" would be top, "end" probably bottom of the header then. But I'm not seeing a way to specify if the glyph can be placed in the top left corner or the top-right corner. I shouldn't have to use an API like ExpandGlyphPlacementOffset for something we are seeing that commonly.

That was poorly worded on my end With "horizontal opening mode", I meant that the horizontal dimension is fixed, so the content is presented in a horizontal fashion. Same for vertical mode. Also what is the top left and bottom left corner? I would assume the icon to be centered, most of the time the header shouldn't/doesn't even take up to much space in the expanding region and top left and bottom left would end up being almost the same.

So to clarify, if the expander expands in vertical direction, start is left (right in RTL) and end is right (left in RTL); in horizontal expansion, start is top and end is bottom. Similar to CSS flex-start and flex-end.

Visual Studio uses a centered icon, however the expand button region stretches the whole control:

Closed:

Expanded:

GlyphPlacement.Start .End .Above .Below Maybe?

That sounds like a very cool idea! How would above and below look like? Similar to what Visual Studio does?

ExpandedGlyph CollapsedGlyph Which the developer could override as they see fit

This would be a way to do this, however this wouldn't allow us to animate the icon (e.g. rotating). However I think it makes more sense to prioritize the possibility to switch out the icon entirely than to have an animation here.

Maybe also use content alignment to handle the header filling the width, or have the Glyph and text bunched up together

100%

For the Notification Centre there is a clear all on the same line as the expander, so how would this be handled? Some kind of way to separate the expanding panel from the expanding header?

I am concerned that this specific scenario might be too complex to achieve simply with the expander control. The placement of the buttons are quite unique, but more importantly, the header and the expand icon are not on the same line which would be quite hard to do with a standard expander control that puts header and icon next to each other. Here is an example for reference:

[robloo]

I'm not adverse to re-templating but looking at the examples posted so far, some developers use ">" for the expansion glyoh and others use "v" for the expansion glyph when expanding vertically. Same as for the position of the glyph. The Expander control should make it very easy for developers to set the glyph according to their wishes.

@Felix-Dev This is one of those things that should be standardized in the fluent design system. It's important for users to have a consistent look and feel. The only time this should change is if an app must do it to meet their own design language or there is a new use case we didn't think of. In that case -- re-template.

Edit: I missed your Telerik example on first read. Still think we are increasing complexity too much and allowing too many design options that will: (1) not be as easily recognized by users (2) will expose a lot of complexity that hasn't historically been needed. Of course there is a fine line here. We want to expose enough functionality that users don't need to re-template, but we also don't want to expose so much functionality that the design language becomes muddied.

WPF, or any other expander controls I can think of, never exposed a property to control this. It really is very much part of the view and should persist only in XAML. The view model (i.e. DPs of the control in this case) should not know anything about such a styling choice in a clean lookless control.

[Felix-Dev]

WPF, or any other expander controls I can think of, never exposed a property to control this. It really is very much part of the view and should persist only in XAML. The view model (i.e. DPs of the control in this case) should not know anything about such a styling choice in a clean lookless control.

@robloo One possibility to expose glyph customization would be through lightweight-styling. These resources, just as DPs, should be considered part of the public API surface of a control, but they are much closer to the control template (the look of the control). So we could expose resources like a ExpanderExpandGlyph and a ExpanderCollapseGlyph (the NavigationView for example has a NavigationViewItemExpandedGlyph resource).

Exposing glyph symbol customization that way could also be read as a recommendation to supply font elements present in the MDL2 font, thus using Fluent Design approved icons. Looking at the MDL2 font, it seems to feature all of the commonly used expand/collapse glyph icons I have seen in examples around the web (the different chevrons, +/-, +/- in circles,...). While developers could probably still override the FontFamily (supplied by the SymbolThemeFontFamily resource), we would only directly expose the ExpanderExpandGlyph,... resources as public resources for the control, thus developers will potentially first look at the MDL2 font family if they want to customize the icons (since that would be the default font family used by the Expander for the glyphs).

For those interested, there is also at least one other yet unresolved issue about how far we as WinUI want to go to provide easy customization glyph options when only a fixed set of icons will make sense in the given context (NumberBox spin buttons glyph customization): https://github.com/microsoft/microsoft-ui-xaml/issues/2789 I know at least some of you are already aware of that issue, but as I'm seeing some parallels in the discussion over there as over here regarding how to expose (glyph) customization option I felt it worth referencing here. Perhaps the solution found here can also be applied in the NumberBox case for consistency in WinUI.

[robloo]

@Felix-Dev Your recommendation for lightweight styling makes the most sense to me. It's what I meant by "Edit: defining resources for a few things to improve lightweight styling might be a reasonable option as well." a few comments above.

[marcelwgn]

The question is how likely developers are not going to provide a glyph but rather have some form of other icon, e.g. a BitmapIcon or some form of custom FontIcon. If non glyph icons are not really a customization point many developers would use, I think a lightweight styling resource for the glyph (and maybe one for the symbol font) to use is the best thing here, as proposed by @robloo and @Felix-Dev .

[mdtauk]

Re-templating is always an option, if a glyph or custom font is not enough.

• Font Glyphs either with Segoe MDL2 or FluentIcons are the most likely and should probably be the default;

• No glyph at all is also common;

• Then there are paths, SVGs that are less likely but very possible;

• And then PNGs or full bitmaps as a not likely but may be possible option for devs.

Whatever approach is used, should probably focus on the first two scenarios, but always allow re-templating for the third.

---

Then there is the possibility to have a ContentPresenter for the glyph, and allow anything to be put on it. But not sure how that works with the VisualStates for moving from Collapsed to Expanded.

---

As for animating the icon - perhaps the Lottie control could be used here?

---

Another thought, just as you have the RadioButton and RadioButtons as a group of them...

Should a group of Expanders make an Accordion Control? Which would allow for a behaviour where only a single expander can be expanded at a time? https://explore.fast.design/components/fast-accordion

[marcelwgn]

Re-templating is always an option, if a glyph or custom font is not enough.

Font Glyphs either with Segoe MDL2 or FluentIcons are the most likely and should probably be the default;

No glyph at all is also common;

Then there are paths, SVGs that are less likely but very possible;

And then PNGs or full bitmaps as a not likely but may be possible option for devs.

Whatever approach is used, should probably focus on the first two scenarios, but always allow re-templating for the third.

Retemplating will always be an option, however of course that is something that can break over time if there are (major) changes to the control. So having a lightweight resource is probably the best here as switching out glyphs (and icon font) are the most common scenarios.

Then there is the possibility to have a ContentPresenter for the glyph, and allow anything to be put on it. But not sure how that works with the VisualStates for moving from Collapsed to Expanded.

Using a ContentPresenter doesn't make a difference regarding collapsing/expanding, it would be just an element like the others.

As for animating the icon - perhaps the Lottie control could be used here?

The question is what kind of animations you want to have. Simple rotation can (and is) already done without lottie.

Another thought, just as you have the RadioButton and RadioButtons as a group of them...

Should a group of Expanders make an Accordion Control? Which would allow for a behaviour where only a single expander can be expanded at a time?

Maybe that could be separate control? While there are scenarios where they could be exclusive to each other, I think in a lot of cases, it doesn't really matter if multiple are open.

[mdtauk]

Then there is the possibility to have a ContentPresenter for the glyph, and allow anything to be put on it. But not sure how that works with the VisualStates for moving from Collapsed to Expanded.

Using a ContentPresenter doesn't make a difference regarding collapsing/expanding, it would be just an element like the others.

But would it be a ContentPresenter which is used by both states, or one per state that gets swapped out/toggled?

As for animating the icon - perhaps the Lottie control could be used here?

The question is what kind of animations you want to have. Simple rotation can (and is) already done without lottie.

Rotations make sense when the glyph is a directional arrow/chevron - but what if its a light bulb turning on and off for some kind of tip or hint scenario? There is a proposal for a generalised animated icon control using Lottie #2802 - would this situation call for this, even if its default/most common use may be a simple icon rotation?

Another thought, just as you have the RadioButton and RadioButtons as a group of them... Should a group of Expanders make an Accordion Control? Which would allow for a behaviour where only a single expander can be expanded at a time?

Maybe that could be separate control? While there are scenarios where they could be exclusive to each other, I think in a lot of cases, it doesn't really matter if multiple are open.

I mention it only as Fast Design includes an accordion control, and it is essentially the same as a bunch of expanders - only that there is a Multi and Single behaviour API which changes how they work together. With an Expander control made, an Accordion would be a logical next step and should be relatively easy to achieve with an orientation property to override the individual directions.

[marcelwgn]

Then there is the possibility to have a ContentPresenter for the glyph, and allow anything to be put on it. But not sure how that works with the VisualStates for moving from Collapsed to Expanded.

Using a ContentPresenter doesn't make a difference regarding collapsing/expanding, it would be just an element like the others.

But would it be a ContentPresenter which is used by both states, or one per state that gets swapped out/toggled?

Both options make sense. I think switching the content of the ContentPresenter is better than swapping out the ContentPresenter or having two and hiding/showing one.

As for animating the icon - perhaps the Lottie control could be used here?

The question is what kind of animations you want to have. Simple rotation can (and is) already done without lottie.

Rotations make sense when the glyph is a directional arrow/chevron - but what if its a light bulb turning on and off for some kind of tip or hint scenario? There is a proposal for a generalised animated icon control using Lottie #2802 - would this situation call for this, even if its default/most common use may be a simple icon rotation?

A rotation animation would be one way to animate and would be easy to achieve. Having an icon that animates into a different one would be quite different. That would also probably make the API more complicated (how do you support such behavior? 2 animations and 2 icons? or one animation that you stop?)

Another thought, just as you have the RadioButton and RadioButtons as a group of them... Should a group of Expanders make an Accordion Control? Which would allow for a behaviour where only a single expander can be expanded at a time?

Maybe that could be separate control? While there are scenarios where they could be exclusive to each other, I think in a lot of cases, it doesn't really matter if multiple are open.

I mention it only as Fast Design includes an accordion control, and it is essentially the same as a bunch of expanders - only that there is a Multi and Single behaviour API which changes how they work together. With an Expander control made, an Accordion would be a logical next step and should be relatively easy to achieve with an orientation property to override the individual directions.

Right, I see. Yes an accordion control is definitely a good idea after expander control and would probably be every easy to implement!

[mdtauk]

Rotations make sense when the glyph is a directional arrow/chevron - but what if its a light bulb turning on and off for some kind of tip or hint scenario? There is a proposal for a generalised animated icon control using Lottie #2802 - would this situation call for this, even if its default/most common use may be a simple icon rotation?

A rotation animation would be one way to animate and would be easy to achieve. Having an icon that animates into a different one would be quite different. That would also probably make the API more complicated (how do you support such behavior? 2 animations and 2 icons? or one animation that you stop?)

This is a big question, and to be honest, is something for the Animated Icon proposal.

Animating the glyph/icon is fine if it will always be an arrow. But it kind of locks that in, unless you have an easy way to remove or change the animation itself.

Making a rotating Lottie animation keeps the default animation, means a little more work to implement, but is more flexible in allowing changing the icon and animations if needed.

The easiest option is to just have no animation for the glyph. But the more you add in, making it easy to override or change becomes more important.

[Felix-Dev]

Looking through the web I see quite a lof of static icons used for the expand/collapse glyphs in typical Expander UI examples. However, on Windows, we also have potential customers of this control who seem to prefer animations (see for example the NavigationView and toast notifications in the shell). Motion is one of the cornerstones of Fluent Design so it probably makes sense here to keep options open for those customers who want an animated glyph without being required to re-template the control.

Ideally, if different teams at MS would like to use an Expander with an animated glyph (i.e. animated arrow glyph) the control would provide an in-built option so we end up having a consistent experience by default. If each team were to be responsible themself for the animation, we might end up seeing different animation duration, different animation directions (i.e. clockwise or counter-clockwise),...If I recall correctly, the animation of the glyph for notifications in the action center is different to the animation of the glyph in the NavigationView. That should be avoided, if possible.

[mdtauk]

Animations are a delighter, and help make the UI feel smooth. Hard coding in a rotation Storyboard, is the simple way to add an animation, but if that animation is difficult to remove, or change - perhaps using the AnimatedIcon control would be a good way to make a flexible way to enable customisation.

I am not saying one way is better than the other - just bringing it to attention here, as it is animating an icon, and that is the Raison Detra for the new control.

And if it has been acknowledged that the glyphs should be customisable - the rotation animation may not always be appropriate.

[marcelwgn]

What to animate and what not to animate is a very difficult question. As Martin already mentioned, a rotation animation does not always make sense. And animated icons still have a lot of open questions.

I think it might be better to scratch glyph/icon animations for v1 then, especially since it is not very common. One thing to reconsider then is if we remove the existing animation on the hierarchical NavigationView to have a uniform experience. Currently there already is inconsistency between TreeView and h-NavigationView on to animate/not animate the switching of the icon.

[Felix-Dev]

Exactly. I wasn't meaning to discourage any exploration here with my last paragraph but just writing once again that one of the challenges we are facing here is about providing enough customization options outside of "the ultimate one" - re-templating - to satisfy common customer wants, yet still making sure that the control will help bring more consistency to Windows, instead of potentially less.

As we have already seen there might not be a perfect solution here since wanting to provide both icon customizations and animation support (perhaps in addition to built-in animations for consistency) can easily collide with each other.

It could be helpful to get potential customers like the Windows Shell on board here to see how they view animations. 10X will supposedly put some focus on animations and the Windows Shell and in-box Windows apps could be "customers" here. If an animated glyph is considered an important piece in the overall UX the Windows team is striving for with 10X, that could require not "punting" on this challenge for now, but instead feature animation support in V1.

[mdtauk]

I would like to see a consistent approach to animating icons, which right now appears to be the Animated Icon proposal.

I would not remove any animation from the NavigationView, as it is an entirely self contained new paradigm for WinUI - and it seems as though the intention is to add animations to all these similar controls - so maybe once it is ready, the control could be added to the NavigationView

[kat-y]

It sounds like ElementAnimator is too much for animating Expander, and that ExpandTransition and CollapseTransition would suffice.

@mdtauk thank you for making the mock-up animation! I understand what you meant for the expanding and collapsing animations.

I believe that accordion behavior will be achieved through list-level logic (rather than a new Accordion control) with IsExpanded for developers to customize this to different scenarios (Ex: where some Expanders close each other and others can simultaneously be expanded).

@Felix-Dev - I've added the Telerik Expander to the proposal, thanks for sharing it!

It sounds there's a desire for customizability in the following directions:

Glyph appearance: lightweight styling seems to be the preferred route to switch out glyphs and icon font, through having ExpanderExpandGlyph and ExpanderCollapseGlyph. Is this level of customization needed in v1 Expander?

@Felix-Dev While developers could probably still override the FontFamily (supplied by the SymbolThemeFontFamily resource), we would only directly expose the ExpanderExpandGlyph ... thus developers will potentially first look at the MDL2 font family if they want to customize the icons (since that would be the default font family used by the Expander for the glyphs).

Glyph animation: including change to a different glyph upon expansion - which is partially solved with AnimatedIcon #2802. Sounds like this level of customization is not necessary for v1 Expander. @chingucoding stated and I tend to agree:

I think it might be better to scratch glyph/icon animations for v1 then, especially since it is not very common.

Glyph position: Is this level of customization needed in v1 Expander? This is further complicated if v1 includes ExpandDirection and the option to change glyph position. @Felix-Dev described

Something like an ExpandGlyphPlacementMode with values like TopLeft, TopRight, BottomCentered (and possibly more (Left, Right, ...)) and an additional ExpandGlyphPlacementOffset property developers could use to modify the base position (set by placement mode) if required.

Hope I've correctly understood the great discussion from this weekend - let me know if I'm mistaken somewhere! Thank you all so much for your insightful thoughts on this. 😄

[mdtauk]

Glyph Appearance Glyph Position

I think these are the easiest and most important customisations to include in V1.

I would also add a way to hide the Glyph

Glyph Animation State Transitions

These could be given a lower priority if Prioritisation is needed and the core behaviour and functionality is taking too long.

[kat-y]

Thanks for the priority order @mdtauk!

I've added a new open question:

• How should Expander work with InfoBar? Adding expanding functionality to InfoBar? Putting InfoBar as the content of an Expander? The reverse?

[mdtauk]

I would imagine it would replace the content, but I think those designing the information bar should provide a design spec for a collapsible bar, which the expander designers can look at.

It's a conversation to be had

[stmoy]

There's a bunch of great conversation here! On the topic of animations...

It sounds like ElementAnimator is too much for animating Expander, and that ExpandTransition and CollapseTransition would suffice.

Agree that ElementAnimator is too much for animating Expander. It might work if everything was in an ItemsRepeater, but ElementAnimator doesn't work outside of ItemsRepeater yet so we'd need to figure that out.

I like the idea of having an ExpandTransition and CollapseTransition in theory, but we've gotten a ton of feedback that the Transition APIs are good in theory but less good in practice because they are not customizable, they are generally tightly coupled to the controls in which they are used, and I don't think they can be built in WinUI 2.x series since they rely on OS hooks. Since these specific transitions don't exist, I'd prefer to explore other options than adding to our collection of ThemeTransition APIs.

On top of all of that, the general area of "layout animations" where content moves as a result of new UI elements entering/growing/shrinking/leaving the page are not well supported in Xaml as a platform today. Fixing this will also require WinUI 3, but isn't on the immediate roadmap.

For Expander in particular, I think the proper course of action will likely end up being: 1) Hard-code the grow/shrink animation in the Expander code (and consider including an API to turn it off - though I don't personally think one is necessary) 2) Provide guidance to app developers about how to animate content around the Expander so that the content below the Expander slides down rather than "jumps" down

I don't think (2) can be solved generally without "layout animations" but can probably be worked around using RepositionThemeAnimation on the content below the Expander.

[ranjeshj]

@stmoy We could use PopInThemeAnimation for (1) if we wanted to go with the existing ones.

[kat-y]

This proposal has been approved for spec writing.

As part of discussion with the WinUI team, we determined that Expander could be scoped to support ExpandDirection for up/down expansion in V1. This covers the scenarios we've seen for Expander and lays groundwork to potentially add left/right expansion in the future.

Please feel encouraged to continue discussion here, and more detailed discussion will occur on the Spec and the associated PR once it's available. Would especially love to hear your thoughts on this open question:

• How should Expander work with InfoBar? Adding expanding functionality to InfoBar? Putting InfoBar as the content of an Expander? The reverse?

[gabbybilka]

For InfoBar, I think I need to open a separate proposal to dive into what specifically it needs and how it can take advantage of this Expander control. Here's some of my first thoughts:

• An InfoBar needs to customize the header and content/pane of the Expander control. The InfoBar should show a "cut-off" message in the header when collapsed and a full message in the expanded content/pane when opened.
• An InfoBar doesn't have to allow truncation and the option should be there for the developer to choose the current wrapping behavior if needed via a "shouldTruncate" property.
• An InfoBar could/should "become" an Expander if the content no longer fits on a single line and shouldTruncate is set to true. Implementing this and understanding when exactly to add the expanding behavior is where it gets tricky 😊 MessageBar mitigates this via their isMultiline property but further thought needs to go into this area.

I think we can also look into other controls in WinUI currently that may benefit from this Expander behavior.

Some initial comps for truncating InfoBar:

For implementation, my initial thoughts are that an InfoBar should derive from an Expander and not be nested inside Expander's content. Thoughts?

[mdtauk]

I think we can also look into other controls in WinUI currently that may benefit from this Expander behavior.

Some initial comps for truncating InfoBar:

I think the Expander may need to be able to separate the Chevron Button from the Content being expanded.

Notifications do this

It would also allow the InformationBar control to integrate it's Expander.

If you do separate it, does that become a behaviour/property? So if you specify a UI Element or Button to this property, the Expander Header does not display it's Button?

For implementation, my initial thoughts are that an InfoBar should derive from an Expander and not be nested inside Expander's content. Thoughts?

If the Expander can't separate the Content and Header from the Toggle/Disclose Button - then that would require more work for the InformationBar to implement.

The Expander control should be as flexible as possible specifically for integrating into various other Controls going forward, as well as for use in the Windows Shell

[kat-y]

I've added initial info to the Expander spec and opened a PR - please feel free to continue spec discussion there! It's PR 100 on the spec repo 😄

[robloo]

There is a need in some cases to prevent the expander from expanding/collapsing. However, it is very difficult to implement this correctly with the current control even in WPF. In order to support this I propose adding two things:

1. PreviewExpanded/PreviewCollapsed events that allow cancelling the operation
2. A new property IsPinned could be added to pin or lock the expander in the current state until it is unpinned

[mdtauk]

Why is the expander using so much padding top and bottom?

and not closer in line with the ComboBox and DropDownButton controls?

[robloo]

Shouldn't this be closed?

[michael-hawker]

@robloo if it is, a follow-on issue for Left/Right support should be opened which is dependent on #546

[Jay-o-Way]

Is this still an issue ? /needinfo

[SnowyWreath]

Can we get an update on the roadmap for Left and Right ExpanderDirection? Windows Community Toolkit v8.0 was released yesterday, removing its Expander control because it is now part of WinUI. This feels premature, because the toolkit control offers Left/Right expansion.