Fluentui: Label: Fluent theme

[mikewheaton]

Verify that the styles checked in to the experiments package match the latest design, then assign to Ben to double-check.

[mikewheaton]

The toolkit doesn't contain an artboard specifically for Label, but looking around other components I think we're aligned here.

@betrue-final-final, please review and confirm that Gray60/#c8c6c4 is the correct color for disabled text, as it's the disabledBodyText semantic color and will be used automatically by other components.

[Vitalius1]

@mikewheaton I believe we decided to have the disabled text using disabledText slot which gives us the gray90/#a19f9d
@betrue-final-final to confirm.

[mikewheaton]

If we change the semantic slot that a component uses, that could lead to breaking changes when this eventually goes into the general release, right? @phkuo, would you consider changing the semantic slot that a component uses to be a breaking change?

It would be safer to limit ourselves to:

1. Overriding exact colors in a *.styles.ts file: color: NeutralColors.gray60
2. Mapping semantic slots to new colors in the Fluent theme's semantic colors object: disabledBodyText: NeutralColors.gray60

Note that whenever we do the second method, we'd need to audit all of the previously-approved components to be sure that this doesn't break any of them.

[betrue-final-final]

Disabled color is actually gray90, not gray60. This was a correction we made late last week/early this week.

[betrue-final-final]

That change was what I worked on with @jalonghu.

[Vitalius1]

@mikewheaton I don't think that changing the semantic slot a component uses as default styles to a different one for Fluent theme would be a breaking change. After all these are just hex codes for colors. Isn't a theme's purpose is changing those?

[mikewheaton]

My concern is that a developer may have created a custom theme based on how the semantic slots are currently used. So if we change the components to use different semantic slots, those themes will break. I'm not sure how severe of a breaking change we'd consider that but it seems like something to avoid.

[Vitalius1]

I thought that we strongly discourage changing the semantic slots and only do it as an exception. The recommended way is by just providing a palette of your choice to the theme and we do the rest. Hmmm... that's a good point though and we should come out with a pattern now so that we don't go over and over back to the already done components.

[phkuo]

A correction here: you should be using disabledBODYText. The disabledText slot is meant to go on top of the disabledBackground slot, whereas disabledBodyText is meant to go on bodyBackground. The comments on the semantic slots explain this.

I think it's fine that a component changes the semantic slot it uses, it just shouldn't be something that happens often. That's the point of semantic slots, as Mike says, it's that they almost never have to change so that devs have a fixed API to code against. But given that this feature is still relatively young and going through some growing pains, I think it's okay to have some expected churn. Especially for a change as large as Fluent.

Fabric DOES support customizing both palette slots and semantic slots. Yes, we definitely do recommend just providing the palette slots and using the default algorithm that assigns those to semantic slots... however half the reason semantic slots exist is to provide an easy customization surface that lets you target specific elements to customize. It gives an easy way to change the colors of buttons across your entire app without needing to exhaustively individually provide a different theme for every invocation of buttons, or something else equally crazy.

[Vitalius1]

So what would be the correct approach with the fluent effort we are investing now? Should we:

1. Use only fluent variables like FluentColors, FontSizes, Fluent... and later when we have more semantic slots and we switch them to Fluent as default styles we go and replace everything with semantic slots.
2. Use a mix of semanticColors, palette, Fluent...stuff

@phkuo @mikewheaton we need to decide now so we can move on with the fluentization and not constantly revising the already done work.

[mikewheaton]

I'd like to see this first round of changes be as targeted as possible, applying exact colors like gray130 to a component. This will prevent a change in one component from breaking others that have already been reviewed and signed off on. We don't have visual regression testing for the theme so it's difficult to catch this stuff.

Once we have those targeted changes across all of the components, we can go back and identify patterns that will allow us to simplify the theme. For example, updating a semantic color or even updating components to use new or different semantic slots.

[phkuo]

I haven't been following the Fluent work effort, but I assumed that you guys would start by creating a custom theme and testing with that? And then once that is verified working, we could switch over the default colors. Components can be updated from Fabric palette slots to semantic slots independent of the Fluent work, if necessary, right?

[mikewheaton]

@phkuo Yes, exactly. We have the Fluent theme that is opt-in for now and will eventually become the new default theme. And it's fine to continue updating components from palette slots to semantic slots, as the Fluent theme can override those changes if necessary.

[betrue-final-final]

@Vitalius1,
The disabled color is still gray60 and should be gray90.

[marygans]

@betrue-final-final can't seem to find a specific toolkit file that includes Label, let me know if I missed something!

[betrue-final-final]

Label is so not a standalone thing for toolkits. However there is a symbol under textfield. It should be #323130, and the site looks good.