Skip to content

Button: Variant Styling #9093

@JasonGore

Description

@JasonGore

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?

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions