The existing Modal element could be enhanced to use the native HTML <dialog> element and introduce a new, lightweight Tooltip element built on the Popover API. These changes would improve accessibility, reduce custom JavaScript overhead, eliminate common stacking/focus bugs, and bring Cornerstone even more in line with modern web standards.
Under the hood, render Modals using the native HTML element and the HTMLDialogElement API:
- Open with dialog.showModal() for true modal behavior.
- Close with dialog.close() (and support returnValue where useful).
- Leverage the browser’s built-in features:
- Automatic promotion to the top layer (no more z-index conflicts with fixed/sticky headers or other overlays).
- Native ::backdrop pseudo-element (fully styleable).
- Automatic inert behavior on the rest of the page.
- Built-in focus trapping and focus restoration to the trigger on close.
- Implicit aria-modal=“true”.
- Native Escape key handling (fires the cancel event).
- Proper dialog semantics out of the box.
- Allow the Modal to optionally combine with the Popover API (
<dialog popover>) for hybrid use cases.
Some benefits would be:
- Significantly better accessibility with far less custom code.
- More reliable behavior across browsers and assistive technologies.
- Cleaner, more maintainable codebase long-term.
- Future-proofing as the platform continues to improve dialogs (closedby attribute, better animation support).
- Existing builder UX and controls can remain unchanged. Users won’t notice a difference in the interface, only improved reliability.
New tooltip element, built on the Popover API
Add a new Tooltip element to Cornerstone. Or perhaps it should be a new control group because it’s common to want to trigger a tooltip on part of some piece of text or an existing element such as a button. A dedicated element couldn’t do that.
- Use the native Popover API (popover attribute).
- Apply role=“tooltip”.
- Connect the tooltip to its trigger with aria-describedby (or aria-labelledby for pure icon labels).
- Support both hover and keyboard focus triggers.
- Keep content strictly non-interactive (plain text or very simple markup only). If interactive content is needed, users should use a Modal, Off-Canvas, or Dropdown instead.
- Leverage modern CSS features such as anchor positioning for reliable placement.
Why Popover API (and not <dialog>)
- Tooltips are non-modal, ephemeral, and supplementary.
- The Popover API is purpose-built for exactly this pattern (light-dismiss, top-layer, no focus trapping, no inertness).
- Using
<dialog>would be semantically incorrect and heavier than necessary.
It would complement the existing Modal, Dropdown, and Off-Canvas elements with a true lightweight overlay option that is accessible and standards-based.