[Docs] Add table layout guidelines

[tkajtoch]

Summary

Resolves #9527

This PR adds table layout guidelines as part of the tables sweep initiative.

API Changes

N/A; Documentation only

Screenshots

Impact Assessment

• [ ]~ 🔴 Breaking changes — What will break? How many usages in Kibana/Cloud UI are impacted?~
• 💅 Visual changes — May impact style overrides; could require visual testing. Explain and estimate impact.
• 🧪 Test impact — May break functional or snapshot tests (e.g., HTML structure, class names, default values).
• 🔧 Hard to integrate — If integration is complex, stage commits in Kibana/Cloud UI branches for cherry-picking and link to them below.

Impact level: 🟢 None

Release Readiness

• Documentation: {link to docs page(s)}
• Figma: {link to Figma or issue}
• Migration guide: {steps or link, for breaking/visual changes or deprecations}
• Adoption plan (new features): {link to issue/doc or outline who will integrate this and where}

QA instructions for reviewer

• Check the new documentation page for correctness and spelling

Checklist before marking Ready for Review

• Filled out all sections above
• QA: Tested light/dark modes, high contrast, mobile, Chrome/Safari/Edge/Firefox, keyboard-only, screen reader
• QA: Tested in CodeSandbox and Kibana
• QA: Tested docs changes
• Tests: Added/updated Jest, Cypress, and VRT
• Changelog: Added changelog entry
• Breaking changes: Added breaking change label (if applicable)

Reviewer checklist

• Approved Impact Assessment — Acceptable to merge given the consumer impact.
• Approved Release Readiness — Docs, Figma, and migration info are sufficient to ship.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 65ed14a
• Documentation website
• Storybook

History

• 💚 Build #3098 succeeded 2648c38

cc @tkajtoch

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 65ed14a

History

• 💚 Build #6146 succeeded 2648c38

cc @tkajtoch

[JasonStoltz]

My overall impression: This is too verbose and text heavy.

A few suggestions:

• Structure this as Dos and Dont's or make it more "rules" based.
• Add examples
• Make text concise -- the intro, for example.

Ex.

Current:

## Layout and scrolling
Enable scrollableInline={true} and tableLayout="auto" to allow horizontal scrolling on overflow to maintain usability across different viewports.

Whenever creating a table, always consider all possible viewport and container sizes, and especially smaller resolutions, even if the application doesn't explicitly support mobile devices. This helps to maintain usability even when push flyouts are open or other container-affecting components are rendered.
...

What is the rule here? Lead with that.
When should we apply this rule, and when should we NOT apply this rule? And if it's a gray area, how do we make that decision?
What does that look like?

Potential option:

## Enable horizontal scrolling

**Always design tables for the narrowest container they may appear in** -- including
states where push flyouts, sidebars, or other elements reduce available width.Enable horizontal scrolling

Set `scrollableInline={true}` and `tableLayout="auto"` so the table scrolls
horizontally on overflow rather than compressing columns into illegibility.

:::tip
Test your table at ~600 px width or with a push flyout open.
If columns become unreadable, horizontal scrolling should take over.
:::

• Can we tie this together with Kibana utils? Something we do this elsewhere:

:::note Kibana engineers

Kibana provides presets which do {xyz}. You can read more here {link to presets}
We enforce these guidelines in Kibana with lint rules, which are here {link to lint rules}

:::

[JasonStoltz]

I had cursor rewrite what you provided. Don't use this exactly, but do use it as an illustration of the feedback I left.