[ContextMenu] FocusGuard creates <span> elements in table body if used on table rows

[ilovemesomeramen]

Bug report

Current behavior

When a ContextMenu is triggered it created <span> elements in the container where it was defined. This creates an issue when used inside Tables since they are not allowed to be inside the table structure.

Expected behavior

Being able to use the ContextMenu inside tables and table rows

Reproducible example

Link to CodeSandbox

Github Repo

Base UI version

1.0.0-beta.4

Which browser are you using?

Chrome

Which OS are you using?

Linux

Which assistive tech are you using (if applicable)?

None

Additional context

The issue was already briefly discussed here:
https://discord.com/channels/1287292451308048406/1436013951367254137

[eckmLJE]

Here is my (rushed) implementation of the hacky approach to this.

• Wraps each row in the context (context doesn't render an html element, so no breaking the table)
• Renders the menu itself as a sibling of the row in the react component hierarchy (it's portalled so it's not an actual dom sibling)
• Within each <td>, wraps the cell content with a zero padding trigger container -- altogether this results in a continuous click area in the whole row
• Inside of that trigger container is the cell content container with padding

https://codesandbox.io/p/sandbox/morning-lake-m6s24z

The benefit of this approach is you're not violating the table row role or breaking assistive technologies by making the <tr> itself interactive.

Edit: I'm noticing that it does still render spans inside the <tbody> while the menu is open, which appears not to break the table layout, but does temporarily make the table markup invalid. I wonder though if that is acceptable because the focus will be locked into the popup, and by the time the focus there is removed, the table will be returned to its valid state? I'm curious too why those spans are rendered as children of the root and not in the portal

From the discord thread, here is some reading on the issue:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/row_role
https://adrianroselli.com/2023/11/dont-turn-a-table-into-an-aria-grid-just-for-a-clickable-row.html

[mj12albert]

Here is my (rushed) implementation of the hacky approach to this.

Thanks for the sandbox ~ for the focus guard spans, they are also transient in OPs sandbox, I wonder if it has any impact on actual usage

Though even if you don't care about invalid HTML, Next.js will throw:

[eckmLJE]

Well I guess if you're using next, and next relies on valid html, then you care about valid html 😄

You could possibly rework my workaround to wrap the whole <table> with the context menu, and use the click target or its ancestor to get up to the row you need with some data-rowid attribute, and populate the menu with what you need that way.

Although I'm still wondering why the focus guard spans render as children of the provider and not into the portal. I suspect it's a requirement for how returning focus works or something. (I haven't investigated yet.)

[eckmLJE]

Here is a new example that places the context menu outside of the table, so we don't render any invalid html elements inside the table. We read the rowid data- attribute off the event target.

https://codesandbox.io/p/sandbox/morning-lake-m6s24z