-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Description
Resolve the following:
How are existing styled Button variants themed?
Ideally we should be backwards compatible, but it appears there are some issues users run into theming existing variants:
I'm facing some issue with split button. I tried writing styling for "splitButtonContainer" for primary button in "PrimaryButton.styles.ts" for "teams theme for fabric" but it doesn't work. I checked fluent and azure theme, they have written the code for primary split button in DefaultButton.styles.ts.
Fluent theme: - https://github.com/OfficeDev/office-ui-fabric-react/blob/master/packages/fluent-theme/src/fluent/styles/DefaultButton.styles.ts
Azure theme: - https://github.com/OfficeDev/office-ui-fabric-react/blob/master/packages/azure-themes/src/azure/styles/DefaultButton.styles.ts
Primary button css is supposed to be written in PrimaryButton.styles.ts, right? With having default/dark/contrast theme with default/hover/pressed/active state it gets really hard to write css for default and primary styles in one file. Is there any work around for it?
How should new createComponent Button variants be themed?
If a SplitButton
contains both a Button
and a MenuButton
, should it be affected by scopedSettings.SplitButton
, scopedSettings.Button
, and scopedSettings.MenuButton
, or only scopedSettings.SplitButton
?
Is it even possible to theme all of SplitButton
's children through just scopedSettings.SplitButton
or would it require nested styling?
We should be backwards compatible with existing theming. Is it possible given any issues theming existing variants? If not, we need to figure out how we would roll out new Button with potential theming regressions.
Do we need to "erase" the names of nested buttons to make sure they don't get targeted scopedSettings
styling?