Alpha button

[origami-z]

Follow up from #4188, add button to work with System Status

[mark-tate]

Latte Goal: finish spec

[mark-tate]

Kickoff to be created in Latte

[mark-tate]

@jake-costa we need some a11y help on this

[jake-costa]

@mark-tate working with @dplsek to go over what assistance is required for this. Working to clarify Non-text Contrast 1.4.11.

[dplsek]

I reviewed the design proposal with @bhoppers2008 @joshwooding @jake-costa and they achieve ADA and design requirements.

Got a preliminary 'thumbs up' from @origami-z via email who could not make the call.

Specs for Salt Legacy
Specs for Salt Next

Still need to review this in detail with @pseys and @origami-z to confirm if this is technically feasible, can be wired systematically, and the necessary tokens to do so.

[mark-tate]

Lungo Goal: @pseys & @origami-z to review token requirements

[mark-tate]

Lungo update: reviewed, proposal for implementation by @origami-z

[origami-z]

Thoughts from meeting earlier:

We saw 2 sets of alpha buttons

1. mode agnostic for 500 background
   2.flipped for standard background variants (white/black texts)

1st one is needed for unblocking system status. 2nd one is preferred visual for replacing transparent button within Banner.

As soon as we release the button for system status, the community will ask to use them on other places (e.g. solid background toast, even we don't provide them). So limiting it to be SystemStatusButton won't be a good choice. However, if we don't have time to work on all buttons right now, we can opt for staged approach

1. release SystemStatusButton, constraint for only SystemStatus usage
2. [future] release AlphaButton (or other name), with 2 variants mentioned above, and swap internal implementation of SystemStatusButton to the new button

For alpha button, we need to think about

• Good name for the 2 variants
• Recommendation when used outside of Salt (e.g. BLOM)

Additional question for active state for @bhoppers2008 and @jake-costa, active state are usually transient state when used standalone. What about when the alpha button is used as menu trigger and when menu is open (active state will be kept there). We can't prevent users to pair the new button with overlay or menu for additional workflow.

[pseys]

• release SystemStatusButton, constraint for only SystemStatus usage
• [future] release AlphaButton (or other name), with 2 variants mentioned above, and swap internal implementation of SystemStatusButton to the new button

Does it cause us any complications down the line if we create a systemStatusButton component and then rename it?

[origami-z]

Does it cause us any complications down the line if we create a systemStatusButton component and then rename it?

Rename only works at major breaking change, which would be tied to a specific future event. It's better we plan something not relying on those?

[pseys]

Yes I was thinking it makes more sense that we get the naming right from the start, rather than try to rename it down the road.

[origami-z]

Yes I was thinking it makes more sense that we get the naming right from the start, rather than try to rename it down the road.

Yes, it could work. Do we know a good component name (and potential variant name) we can go to directly? With the complexity of mode agnostic / light+dark + potential different background? I'm not sure whether "AlphaButton" is a safe bet....

[mark-tate]

Macc Goal: How many alpha buttons do we need and how do we name them ?

[origami-z]

Met with Ben, Darrin, Paul and Shey on Friday.

1. Agreed that "mode" shouldn't be in component props/name, given it's option in theme.
2. Not against using appearance to unify Banner and System Status, which could work with other components (e.g. Toast, Tooltip) as Darrin shown. Need to consider additional options, given transparent doesn't apply to Banner.
3. Darrin also shared some potential alpha button usage for any buttons with purpose (e.g. close button of dialog, arrow button of pagination, etc), which could be aligned with semantic icon (Provide a mechanism to swap out built-in component icons to custom icons #3520)
4. If we decide to unite banner, need to make sure we don't lose System status's edge to edge use case (for Pepper)
   Need more thoughts around naming.

[origami-z]

My proposal below, feedback welcome

1. Create a GhostButon, with prop adaptiveAppearance = "solid" | "non-solid", default to "non-solid", to be paired with most default option of "container" type of components
2. Deprecate variant in Banner, replace with appearance = "solid" | "filled" | "bordered", default to "bordered" for backwards compatibility. New filled is introduced to the overall appearance options, to describe design choice of border + light-weight filled background (prior primary/secondary).
3. Deprecate SystemStatus, replace with <Banner appearance="filled">, move relevant use case and guidance to pattern section

See #4280 (comment) above, and more notes below

• Explored options to add "ghost" prop to existing Button component, but it's hard to explain usage guidance when paired with sentiment / appearance options
• Explored options to add "ghost" to Button's appearance prop option, similar to above, can't really explain the relationship with sentiment, and can't work out how to incorporate 2 design choices needed (mode agnostic vs not)
• System status vs Banner: creating a net new component to distinguish some component usage purpose feels against component creation, and could be hard to extend beyond current offering. I'd think System status (use case) is a pattern, together with "edge to edge" advice which could be optional for certain products. Similar to file upload pattern v.s. static list component.

[bhoppers2008]

@origami-z proposal looks good.

1. filled or solid - how did you determine which to use? (Assuming 'filling' inside the border?)
2. Assume full language for appearance is solid, filled, bordered, transparent?
3. Edge-edge - how to support this going forwards? @pseys corner won't be visible as option in new library. Is it prop driven, since JPM Brand is rounded corners?

[origami-z]

1. filled or solid - how did you determine which to use? (Assuming 'filling' inside the border?)
2. Assume full language for appearance is solid, filled, bordered, transparent?

Yes, 4 total options. I'm open to other language as well.
To explain, we could add something to the glossary around the term.

1. there is a hierarchy of "importance" - solid > filled > bordered > transparent
2. define each, e.g. solid - bold background and border color, filled - subtle background + bold border, bordered - no background + border, transparent - no background no border

3. Edge-edge - how to support this going forwards? @pseys corner won't be visible as option in new library. Is it prop driven, since JPM Brand is rounded corners?

Being a pattern, it would be a custom component from BL, which means a small override of corner could be applied there...?

[mark-tate]

Mocca Goal: If we have capacity, add button in code (medium size change) and initial docs
Publish to Labs

[origami-z]

Talked to @Fercas123 about this, with a bit more background information.

The most tricky part would be theme / theme-next wiring, not the component itself. I suggested to look at existing Button set (neutral transparent & caution solid as reference) + System Status (mainly bold foreground) token to scope out potential theme tokens, then can review with @pseys. Initial thoughts:

• characteristics could start with actionable-ghost-*, some palette values could take from existing Button/System Status, use Figma spec as reference. There is a difference in theme current, around caution solid button vs system status foreground color.
• palette layer, likely palette/alpha-next.css could be used, may need extending. Theme current may be more tricky, given neutral palette white/black fade is usually associated with disabled token. This may mean we need to extend more tokens in neutral or make palette/alpha.css (name is easy to change in code)

  • salt-ds/packages/theme/css/palette/alpha-next.css

    Lines 1 to 5 in 7d32518

    	.salt-theme.salt-theme-next[data-mode="light"] {
    	--salt-palette-alpha: var(--salt-color-black-30a);
    	--salt-palette-alpha-strong: var(--salt-color-black-45a);
    	--salt-palette-alpha-weak: var(--salt-color-black-15a);
    	--salt-palette-alpha-weaker: var(--salt-color-black-10a);

  • salt-ds/packages/theme/css/palette/neutral.css

    Lines 1 to 5 in 7d32518

    	.salt-theme[data-mode="light"] {
    	--salt-palette-neutral-primary-background: var(--salt-color-white);
    	--salt-palette-neutral-primary-background-disabled: var(--salt-color-white-fade-background);
    	--salt-palette-neutral-primary-background-readonly: var(--salt-color-white-fade-background-readonly);
    	--salt-palette-neutral-primary-foreground: var(--salt-color-gray-900);

• I also mentioned the potential deprecation of foundations/fade.css which @pseys talked about. I'm not recommending mixing the problems together into this alpha button work. If we can't solve it with existing set up, then we may look into it.

In short, the main goal is to try out whether token connection is possible for both themes.