[docs] Fix API table design

[oliviertassinari]

Current behavior

The new design of the Base UI API reference:

https://base-ui.com/react/components/toast#provider

seems to deliver low usability in practice. I landed here trying to use a bit the product.

As far as I'm aware, here are the possible user journeys to use the API reference, sorted by importance/frequency:

1. "I don't know the prop to use, but I want to see if an option to do what I want already exists."
   For example:

• Let's say I'm using Notistack and I want to migrate to the new Toast component. If I'm using Material Design, I can't use stacking: https://m3.material.io/components/snackbar/guidelines.

So I searched for "maximum" to find something similar to https://notistack.com/features/basic#maximum-snackbars. No results.

It's not available in Google nor in Algolia search. Still, the content exists:

• Or let's say I want to implement an "auto close" behavior, same pain.

So I don't see how this solves the design constraint that the table should solve.

2. "I see a component that use a prop, I don't know what the prop does, I follow the link from the IDE".
   For example, I'm in:

(I think it's missing a link to the API reference like MUI Base has, but that's a detail). I'm opening the docs page, now I need to move my cursor all the way to the info tooltip to see what's important.

It feels much slower compared to before.

3. "I don't know the props available, I'm curious to learn what's possible to do"

I have to hover over each info tooltip. I don't see how this is an optimal design solution. It feels much slower compared to before.

4. ? I'm not aware of other use cases.

Expected behavior

Right now, it feels like we have something that is 1. looks great 2. usable. I would expect the opposite priority. So: 1. it has to be usable, 2. it has to look great.

For the solution, we had a couple of attempts in the past (something like 3, 4). The best that I could see to date is https://mui.com/base-ui/react-snackbar/components-api/. I imagine we can still do better, but this felt so frustrating:

Unless this serves a specific purpose that I failed to see, it looks like we need to move away from it.

hidden="until-found" could solve 1. but 2 and 3 still feel frequent enough that it doesn't seem of much help.

Base UI version

v1.0.0-alpha.8

Context

#696 is maybe a bit related for this repo. There are others in http://github.com/mui/material-ui and http://github.com/mui/mui-x about this otherwise.