MDS Assistant is an experiment.
Hi, I'm the MDS Assistant and can help you with information from our guidelines and components.

I do not provide code and development guidance. For coding assistance, please check out our experimental MCP server.

Modernizing our dialog components

A journey towards utilising native HTML solutions.
Marcin Sieradzki
Software Engineer
29 November 2024

We’re excited to share some significant improvements to our dialog-based components that have resulted in better performance, maintainability, and developer experience.

At the heart of this refactor is our new mc-dialog component, which leverages the native HTML <dialog> element to provide robust functionality with minimal complexity.

Unifying Dialog Behaviors

One of the most impactful changes we’ve made is the introduction of McDialogBase, a shared foundation class that now powers three key components: mc-dialog, mc-drawer, and mc-modal. This architectural decision brings several advantages:

  • Consistent behaviour patterns across all dialog-type components
  • Centralised bug fixes and improvements
  • Reduced code duplication
  • Simplified maintenance and testing

From Material UI to native HTML

Previously, our mc-modal component was built on forked Material UI code, which brought unnecessary complexity and maintenance overhead. By transitioning to the native <dialog> element, we’ve achieved remarkable improvements in bundle size:

Before:

Modal: 36KB (7.37KB gzipped)

After:

Modal: 5KB (1.33KB gzipped)

Dialog dependency: 14KB (3KB gzipped)

This represents a significant reduction in bundle size:

Raw size reduction: 17KB (47% smaller)

Gzipped size reduction: 3.04KB (41% smaller)

Automatic bug fixes through native implementation

A side benefit of adopting the native <dialog> element was the automatic resolution of several reported bugs in mc-modal. The browser’s built-in dialog functionality handles many edge cases more reliably than our previous custom implementation, particularly around:

  • Focus management
  • Keyboard navigation
  • Screen reader accessibility
  • Stacking context

Simplified focus management

We’ve deprecated several focus-related properties in favor of native browser behavior:

<!-- Before -->
<mc-modal>
  <mc-input focusstartanchor label="Enter file name" name="filename"></mc-input>
  <mc-button slot="primaryAction" appearance="primary" dialogaction="ok">Save your changes</mc-button>
  <mc-button focusendanchor slot="secondaryAction" appearance="neutral" variant="filled" dialogaction="cancel">Cancel</mc-button>
</mc-modal>

<!-- After -->
<mc-modal>
  <mc-input autofocus label="Enter file name" name="filename"></mc-input>
  <mc-button slot="primaryAction" appearance="primary" dialogaction="ok">Save your changes</mc-button>
  <mc-button slot="secondaryAction" appearance="neutral" variant="filled" dialogaction="cancel">Cancel</mc-button>
</mc-modal>

The native <dialog> element provides built-in focus trapping, eliminating the need for custom focus management code. This means:

  • No more focusstartanchor and focusendanchor properties
  • Automatic focus containment within the dialog
  • Native support for autofocus attribute
  • Better screen reader compatibility

Additional benefits

The refactor has brought several other improvements:

  • Better Browser Support: Native dialog implementations are now widely supported across modern browsers
  • Reduced Technical Debt: Removing forked third-party code eliminates the need to maintain and sync with upstream changes
  • Simplified Testing: With more native behavior, we need fewer tests for basic functionality
  • Enhanced Developer Experience: Developers can rely on standard HTML behaviors rather than learning custom APIs
  • Improved Accessibility: Native dialog implementations provide better screen reader support out of the box

For teams using our components, migration is straightforward:

  • Update to the latest version(v2.92.0 at the time of writing)
  • Remove any focusstartanchor and focusendanchor properties
  • Use autofocus if you need to focus on any element inside the modal when the modal is open

Looking forward

This refactor represents a broader shift in our approach to component development, favouring native browser capabilities where possible.

We’re continuing to identify opportunities to simplify our codebase while improving performance and functionality.

By embracing native browser features and maintaining a unified codebase across related components, we’ve created a more maintainable, performant, and developer-friendly solution for all our dialog needs.

As always, we welcome your feedback and look forward to hearing what you think about these changes.