Background

Calls to Composition inside of ImplicitAnimationSet were causing the ColorPicker to fail to show on Wasm in this PR. We're referencing the Animations component for ImplicitAnimationSet, but implicit animations use Composition, which aren't implemented on Uno yet.

Our options were to either:

• Add conditional XAML everywhere ImplicitAnimationSet is used, or
• Update ImplicitAnimationSet to avoid calling Composition APIs when running under Uno until support is added.

Can we combine conditionals with a namespace like that in Uno?

Official Uno docs recommend wrapping it in a container such as a Grid. That requires adjusting the Visual Tree in a lot of different places, both in our codebase and in the codebase of those consuming our packages

We do need a better way of tracking what's not supported in Uno though doing it that way, right? As it's not like we'd have it throw an unsupported exception.

At a high level, our custom MultiTarget system is designed to mitigate this happening on accident by allowing us to isolate code that depends on unsupported APIs (e.g. Composition) into separate libraries (e.g. Media) and disabling Uno-specific MultiTargets so they can't be used without first adding support and checking/addressing the original reason for lack of support.

When we enable Uno for a component that didn't previously support it, we need to be doing a sweep of the component to make sure nothing throws when running under the new platform.

The problem

We didn't originally support the wasm MultiTarget for Animations, but we added *partial* support for running on Uno through the FrameworkLayer abstraction, though this support only extended to AnimationBuilder and CustomAnimation. Other code is still in place that calls to the Composition APIs on Wasm, which will throw out of the box.

Giving the Animations package a quick once-through, I've also noted that:

• CustomAnimation isn't being used by our inbox animations (TranslationAnimation, ScaleAnimation, etc) despite inheriting the same type. They won't default to FrameworkLayer.Xaml on Uno.
• Implicit/Explicit animations and helpers are still using Composition APIs directly without handling what to do when running under the added Uno tfm

The solution

The above isn't an exhaustive list. We should do a full sweep of the Animations package to see what can either:

• Be implemented without using Composition (if needed enough), or
• Be disabled so it doesn't throw when people use it, while we wait for Uno to implement Composition.

Originally posted by @Arlodotexe in #241 (comment)