SplitButton style

[jbooth88]

Bug explanation

Some button properties in the new materialDesign:SplitButton control are unable to be changed without overriding the ButtonStyle.

For example, altering the font size affects the popup, but the left button (PART_LeftButton) is stuck at 14pt.
I don't know if this is a bug or by design.

Version

5.0

[nicolaihenriksen]

@jbooth88 seems like a bug to me. We should probably forward some additional common, non-inheritable, properties (like FontSize) down to the nested button here.

[Keboo]

So right now the ButtonStyle is what is used to configured the internal buttons. If we do template bindings (which I think might be the right answer), then anything with a template binding can't be set via that style.

I am thinking we might want to just obsolete that property and use template bindings for everything as that is a more common use case. Thoughts?

[nicolaihenriksen]

@Keboo So the SplitButton.ButtonStyle DP, in my mind, is an implementation detail. It is really only public to allow for consumers to copy-paste-modify the style and still have it compile. The same result could have been achieved without a DP, but simply a well-known resource key (this approach is used for the DatePicker; see here), or an attached property.

The DP serves a single purpose: Mapping an MDIX SplitButton style to the corresponding MDIX Button style. E.g.:
MaterialDesignFlatDarkSplitButton -> MaterialDesignFlatDarkButton,
MaterialDesignOutlinedLightSplitButton -> MaterialDesignOutlinedLightButton,
etc.

Thus the DP is used to make the SplitButton have a correct baseline-look, but should still allow for modifications via its properties as any other control. As such, I think it is fair to simply forward the "common properties" through via TemplateBindings just like it is already doing for a number of the properties. "Common properties" probably covers any property that is intended to have a visual (and/or possibly behavioral) effect that is relevant to the SplitButton.

[jbooth88]

I think the root cause if this behavior is how the base button styles have setters such as TextBlock.FontSize and TextBlock.FontWeight. Normally having setters like these are not an issue, because users can override style setters easily. However if a style is used for an element inside a control template, the element uses its style setters (when they exist) instead of inheriting from the parent control (I could be wrong here with my limited xaml knowledge, but I think that's how it works?)

So, (focusing on FontSize only for simplicity), possible solutions that I see are:

1. Set FontSize to {TemplateBinding TextBlock.FontSize} in the PART_LeftButton control, even though we know this will break the ButtonStyle's ability to control the font size. If I understood the previous comments, this is what Nicolai is suggesting?
2. Add new styles specifically for the SplitButton template, instead of leveraging existing button styles (so much work)
3. Remove the FontSize setter in base button styles (like MaterialDesignFlatButton). This has an added benefit for users that wish to apply a custom font size to their entire window, for example.
4. Leave as-is, considering there is a valid work around. In my case, I applied my own ButtonStyle property with setters for the font size and font weights I wanted.