CSSbackgroundcolor,CSScolor,andlayerrecipesintheDesignSystemProvider

Problem:

When using the DesignSystemProvider there exist several disconnects that make the implementation difficult to use:

1. The provider does not apply a CSS
   

   1	background-color

   to the element aligning to the designSystem.backgroundColor property



2. The provider does not apply a CSS
   

   1

   color

   to the element aligning to the designSystem.backgroundColor property



3. The provider's
   

   1	backgroundColor

   property cannot be assigned a recipe.

1 and 2 make the out-of-box experience bad because the color of non-FAST content will be inaccessible and obviously incorrect.

3 is more of an interop problem within the FAST system. The FAST system provides and encourages use of the "layer" recipes to be used as app-region background colors but this implementation of the DesignSystemProvider does not facilitate doing so.

Proposal

1. and 2. - CSS color & background-color

1 and 2 can be remedied rather simply. When the

property of the provider is explicitly set, the provider should attach the following stylesheet:

While generally desired, I can imagine cases where a user may not want this behavior so we would want a mechanism to disable attachment. This could be done with a boolean attribute:

or with a property:

3. - Recipe backgrounds

Another commonly desired cases is to set the value of the

to the product of a recipe. This often crops up in cases where the layer recipes are used -

,

, etc.

We could enable the following:

When assigned a recipe / fn, the provider would evaluate the recipe when setting

and which would in turn assign the

CSS Custom Property to the product of the recipe.

A question arises from the above of which

object the above resolution function should be generated with. There are three viable options:

1. The parent provider's design system
   
   1. The downside to this approach is that a user could not set the
      

      1	baseLayerLuminosity

      and the background color on one provider to achieve a light/dark mode change. In fact, the recipe would not see any

      1	designSystem

      changes on the element with the background change. I think this is a big enough miss that this option should not be selected but it is included for completeness.

   
   


2. The local design system
   
   1. This option would invoke the recipe to resolve the background color with the local design system object. This facilitates cases like light/dark mode switching using a single node, because the recipe would see the designSystem changes applied to the node.
   
   
   2. The only reasonable down-side or disconnect I see to this is that it could create recursive behavior that would likely be undesirable. Because this recipe sets a property on the
      

      1	designSystem

      (

      1	designSystem.backgroundColor

      ), if the recipe uses

      1	designSystem.backgroundColor

      in determining the color product then each invocation will be relying on the previous invocations product - recursive color resolution. This would likely be an unintuitive and undesired behavior.

   
   


3. The hybrid design system
   
   1. To address the issue described by 2.2, we could supply the fn a hybrid design system, where every property besides the property being set is derived from the local designSystem object, and the property being set (
      

      1	backgroundColor

      ) is derived from the parent design system.

   
   
   2. Another solution would be to omit the color from the invocation of the recipe so that it cannot be relied upon.
   
   

该提问来源于开源项目：microsoft/fast