feat: [draft] add split button spec

[brookdozer]

Description

Adds a specification for split button web component

Motivation & context

FAST needs a spec for a split button web component both for parity with Fluent and with other design systems.

ASKs:

• Should the buttons be buttons or merely styled like buttons? (If buttons, then listbox is out)
• Should this take a dependency on popover/flyout or listbox?
• Help with the implementation details: slots, properties, events
  • How to manage the collection of buttons? One list and assume the first is primary? A primary and secondary slots?
  • In the modal version (e.g., reactions) How best to show the chosen action in its "checked" state in the Primary slot?
  • How best can the menu button interact with the popover/flyout/listbox?
  • Should this be just a simple Fluent/Bootstrap-style split button AND a Facebook-style reaction button?

Issue type checklist

• Chore: A change that does not impact distributed packages.
• Bug fix: A change that fixes an issue, link to the issue above.
• New feature: A change that adds functionality.

Is this a breaking change?

• This change causes current functionality to break.

Adding or modifying component(s) in @microsoft/fast-components checklist

• I have added a new component
• I have modified an existing component
• I have updated the definition file
• I have updated the configuration file

Process & policy checklist

• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

[janechu]

Can we take the w3c naming menu-button if this is effectively always going to pop up a list of potential actions? Since this is a w3c spec I am alright with this going into fast-foundation. I'll refrain from further spec comment until the naming is sorted out since GitHub tends to lose track of comments when files get moved around.

[chrisdholt]

Can we take the w3c naming menu-button if this is effectively always going to pop up a list of potential actions? Since this is a w3c spec I am alright with this going into fast-foundation. I'll refrain from further spec comment until the naming is sorted out since GitHub tends to lose track of comments when files get moved around.

Slight nuance here. Split button includes a menu button but is not exclusively a menu button. Split button has essentially two buttons, one being a menu button and one being a standard button.

[janechu]

I think if the menu always has to be included and is a w3c spec, we can make the "standard" button optional, that way we can rename this to menu-button and serve both purposes. This would increase flexibility for the component.

[chrisdholt]

I think if the menu always has to be included and is a w3c spec, we can make the "standard" button optional, that way we can rename this to menu-button and serve both purposes. This would increase flexibility for the component.

I like this idea - thoughts @brookdozer ?

[brookdozer]

I think if the menu always has to be included and is a w3c spec, we can make the "standard" button optional, that way we can rename this to menu-button and serve both purposes. This would increase flexibility for the component.

@chrisdholt and @janechu, I'd be more inclined to create a separate menu-button component and use that inside split-button although the unique requirements of a stateful split-button might make that tricky.

Do folks already use fast-button as a menu button by adding aria-haspopup and aria-controls or do we need a menu-button control?

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[EisenbergEffect]

Just checking in to see if you are ready for another round of reviews @brookdozer or if you are still in process on the current feedback. Thanks!

[litteredwitherrors]

Overall I wonder about the general composition of the component dependencies as well as the conveyance of the properties when composed. Somethings come to mind when using the Github review UI:

Would there ever be a circumstance where we'd have a much more complex pop-over? If so, we should consider how can provide support for this level of complex UI.

[litteredwitherrors]

I think we can frame this to be more declarative and let the "draft" status communicate it being "WIP".

[litteredwitherrors]

I'm not sure if this pattern should inherently include a fly-out. The fly-out could be its own component altogether. If this is a pattern that always includes a fly-out, then perhaps it should be name something else.

[litteredwitherrors]

How is this decided?

[litteredwitherrors]

Naming needs to be considered for this slot.

[litteredwitherrors]

Will the pop-over only ever display buttons?

[brookdozer]

Great question. It seems like it should only ever be buttons in a split button pop-over, but I could be wrong. Maybe a divider?

[litteredwitherrors]

Thanks Brook. A scenario comes to mind when an engineer might want to put something else in the popover. For instance, Github has many "split button" patterns that go from simple content:

To more complex content:

This might be something we want to consider in this component.

[litteredwitherrors]

What do we technically mean by the component being "stateful".

[brookdozer]

A stateful split button is one that stores state, similar to a "like" button. The opposite would be a similar to the email "Send | Send Later" button.

[EisenbergEffect]

This one's very old. @chrisdholt What would you like to do with it?

[chrisdholt]

This one's very old. @chrisdholt What would you like to do with it?

Per @janechu's comments above on "menu button", I think we'll close this and pick it up in coordination with that component, requested in #5469. My initial thought on accomplishing the split button would be slotting a button in the start or end slot.