Proposal: Support ThemeShadow entirely within XAML

Proposal: Support ThemeShadow entirely within XAML

Summary

I know I’ll get some flack for calling this a bug but I consider it one 😃 ThemeResource cannot be used without registering the control with the shadow in code-behind. This is a design bug in the way ThemeShadows are implemented. It breaks MVVM and lookless control principles as a shadow is entirely a styling choice.

Expected behavior

<Grid>
    <Grid.Resources>
        <ThemeShadow x:Name="SharedShadow" />
    </Grid.Resources>

    <Grid x:Name="BackgroundGrid" Background="{ThemeResource ApplicationPageBackgroundThemeBrush}" />

    <Rectangle x:Name="Rectangle1" Height="100" Width="100" Fill="Turquoise" Shadow="{StaticResource SharedShadow}" />

    <Rectangle x:Name="Rectangle2" Height="100" Width="100" Fill="Turquoise" Shadow="{StaticResource SharedShadow}" />
</Grid>

Should produce:

Without having to add the following in code behind (I realize Translation can already be set in XAML).

SharedShadow.Receivers.Add(BackgroundGrid);

Rectangle1.Translation += new Vector3(0, 0, 16);
Rectangle2.Translation += new Vector3(120, 0, 32);

https://docs.microsoft.com/en-us/windows/uwp/design/layout/depth-shadow

Rationale

Slowly MVVM and lookless control principles are getting broken. We need to maintain the ability to style shadows entirely within XAML. This came up when talking about styling a new control that has a a selected color that should have a drop-shadow effect. The shadow receiver would need to become a template part and registered in code-behind with the current ThemeShadow implementation. It doesn’t make sense that an additional template part should be required for this situation. We need the ability to do things like shadows directly and entirely in XAML:

Scope

Capability	Priority
Remove the need to register shadow receivers before use or add ability to register in XAML	Must

[mdtauk]

I never implied either things 😉 I just want to point out that both are a lot of work for limited reward, even if you say that we all need to have lookless controls. In my opinion, ideally, you wouldn’t have to retemplate controls because they are already customizable enough through properties and lightweight styling and only in very specific scenarios a retemplate is needed to get the desired result.

Moving away from Lookless Controls would be a big change (should probably go hand in hand with a wholesale change from Xaml to Xaml Next) - and could be a good thing. But it would not be Xaml in the way it has existed since Avalon and WinXP’s days.

Android and Apple have their own UI paradigms - none as flexible as Xaml for changing control designs - but with Rendering offloaded to GPUs, could there be a call for a new approach - without Xaml trees to parse, but deeper aspects of primitive shapes, shadows, etc?

[robloo]

@michael-hawker Yes, we were definitely getting off track for this issue. Thanks for linking to the relevant one, I didn’t know it already existed and I’ll copy some comments over to it.

I also could have sworn when UWP first released (years ago now) the docs looked very much like WPF for templates. What I remember looks exactly like the WPF docs though so it’s possible I was just confusing the two.