[docs-infra] Allow to increase the table API content layout width about material-ui

[michelengelen]

Hey @lukasschrammknowit ... Good question. I guess this is probably a historic "problem".
The other options do not have that big of a need for the width, so this just has been overlooked.

@joserodolfofreitas I think we could improve a bit here. Agreed?

[flaviendelangle]

AFAIK we have a fixed content width on the whole doc
For most content it's fine because we build it to be great with this width
But for API tables, it's a shame to see this much white space and at the same time have a UI that would benefit from this space.

[michelengelen]

AFAIK we have a fixed content width on the whole doc For most content it's fine because we build it to be great with this width But for API tables, it's a shame to see this much white space and at the same time have a UI that would benefit from this space.

We could probably adjust the width to accommodate for more realty (when available) of other elements as well ... this would also solve this specific pain point

[oliviertassinari]

Why is the width of tables on the documentation so terribly small?

@lukasschrammknowit what screen do you have? What's your browser zoom level configuration? 100%?

The width is set as max-width: 105ch; which is meant to fit 105 characters on a given line. The idea is to limit the width so that when the eye needs to go to the next line, it's not lost.

[flaviendelangle]

The idea is to limit the width so that when the eye needs to go to the next line, it's not lost.

But would you agree that for a table like the one displayed above, the width feels like an arbitrary limiting favor?

[lukasschrammknowit]

I have different screen sizes (3840x1600, 2560x1400), but this is generally a problem existing on every single screen size existing. Limiting the width is just not useful in general I guess.

[flaviendelangle]

I do think it's useful for regular doc pages.
Here is what it would look like on a 3440*1440 otherwise:

But for tables, the problem is that we limit the width with the same approach a basic line of texts, but we have several columns so each column becomes super small when it contains a lot of text.

We have been exploring several solutions.
One of them is to get rid of those tables and replace them with a different UI:

If comes with some trade-off and the feedback we got highlight that we won't be able to have a UI that fits perfectly all components. For components with props that requires long descriptions and complex TS interfaces, the new UI scales better, but for basic components it is over killed and reduces the readability of the whole.

Just increasing the width of the table can improve the experience for people with big screens, but it's not a perfect solution either because people with small screens will still experiment the same problems.

cc @danilo-leal

[danilo-leal]

The option to increase the table's container width if you're on a big monitor definitely makes sense (it avoids horizontal scroll while allowing you to see all columns at a glance), and it'd be a nice feature to support. We don't intend to get rid of the table layout — it has its place, and for more complex components, with more extensive prop sets, precisely as the Date Pickers, it's more fitted. However, I don't feel like it's a super fast thing to pull off; we'd need to carve out some time to make it right, particularly as we already support different layout types for the API content, which naturally made this whole area a bit trickier to maintain.

I'll transfer this issue to the main repository and add it to the backlog!
More updates whenever we get to prioritize it.