docs(react-infobutton): Adding component's spec

[sopranopillow]

This PR adds the spec for InfoButton. Note: this is still a WIP and will be updated after a design review of the component.

Preview

Related Issue(s)

Fixes #25061

[fabricteam]

📊 Bundle size report

Unchanged fixtures

Package & Exports	Size (minified/GZIP)
react-infobutton InfoButton	7.742 kB 3.265 kB

_{🤖 This report was generated against ea1842baec1d31d0936665bdffedf5803049eb46}

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit a36ef96:

Sandbox	Source
@fluentui/react 8 starter	Configuration
@fluentui/react-components 9 starter	Configuration

[size-auditor]

Asset size changes

Size Auditor did not detect a change in bundle size for any component!

Baseline commit: ea1842baec1d31d0936665bdffedf5803049eb46 (build)

[kolaps33]

Hello :)
there was no similar component in v0 or in 'v8' but one version exists in the TMP repository(in MS Teams code)

Implementation accessibility details are following:

• icon is focusable
• icon has role=img
• with tooltip is icon connected via "aria-describedby" approach
• icon has label "More information"
• tooltip is displayed when icon receive focus
  https://domoreexp.visualstudio.com/Teamspace/_git/teams-modular-packages/pullrequest/477885

This approach was approved by accessibility PM for MS Teams(Brett Humphrey).

If there is a button used, then generally screen reader users would expect there is some action available on the button.

I believe we should be aligned together with v9 and MS Teams component.

[layershifter]

@sopranopillow I was thinking about this spec and here is a proposal from my side...

Make InfoButton a button

In the spec currently button is a slot at InfoButton component. It looks a bit strange as even our form components have a concept our primary slot and behave differently. The only components that are custom are hosts (Menu, Popover, Tooltip, etc.) and triggers (MenuTrigger, etc.). However, both hosts and triggers don't render DOM elements.

So, what is a proposed change? In terms of render template:

  <Popover>
    <PopoverTrigger>
      <slots.root {...slotProps.root} />
    </PopoverTrigger>
    <PopoverContent />
  </Popover>

Instead of Popover being a root - the proposal is to have a button as a root (this solves this concern #25251 (comment)).

This change allows following:

• Use Tooltips and other components:

    <Tooltip content="A tooltip">
       <InfoButton>
         A button
       </InfoButton>
     </Tooltip>

• Use props directly (I mean className, style, ref and etc.)

    <InfoButton className='foo' ref={buttonRef} />
    // over
   <InfoButton className='foo' ref={buttonRef} /> // 💥 does not work
   <InfoButton button={{ className: 'foo', ref: buttonRef }} /> // 😕 works, but not consistent with other components

• We can pass children to a component that makes usages intuitive

  <InfoButton>Content goes here</InfoButton>

What to do with Popover then?

It's a good question for that proposal 👆

We don't need to configure PopoverTrigger, but we need to provide an access to Popover and PopoverSurface. I was thinking about popover & popoverSurface slots:

<InfoButton popover={{ open, positioning }} popoverSurface={{ children: 'Content' }}>
   A button
</InfoButton>

• where popover is an object with slots and cannot have shorthand form and children
• where popoverSurface is a regular slot

Another option is combine that with a current proposal and keep Popover props directly on InfoButton:

<InfoButton open, positioning={{ /* ... */ }} popoverSurface={{ children: 'Content' }}>
   A button
</InfoButton>

---

From my POV it fits more into v9 API design, WDYT?

[sopranopillow]

@sopranopillow I was thinking about this spec and here is a proposal from my side...

Make InfoButton a button

In the spec currently button is a slot at InfoButton component. It looks a bit strange as even our form components have a concept our primary slot and behave differently. The only components that are custom are hosts (Menu, Popover, Tooltip, etc.) and triggers (MenuTrigger, etc.). However, both hosts and triggers don't render DOM elements.

...

From my POV it fits more into v9 API design, WDYT?

@layershifter Love it! I think this is a great candidate for a recipe on how to create a PopupButton (name not set) the Fluent v9 way!

[spmonahan]

This image shows the popover in the "above-start" position. Will InfoButton support positioning of the popover?

[sopranopillow]

Yes, that will be done through the root as it takes the popover props as well. The updated types now have the Popover props.

[behowell]

Do we then also need to use aria-describedby or aria-labeledby on the button itself?

[sopranopillow]

This isn't set yet, once we iron it out, I'll update the spec.