[Dialog] DialogTitle overrides DialogContent className

[jlin5]

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

The DialogTitle className (MuiDialogTitle-root) is overriding the set className to DialogContent.

Expected Behavior 🤔

The DialogTitle className should not override the set className to DialogContent.

Steps to Reproduce 🕹

https://codesandbox.io/s/sparkling-architecture-47w73?file=/src/index.tsx

This is happening after @material-ui/core@5.0.0-alpha.35

To reproduce, change the package dependency in the codepen @material-ui/core to 5.0.0-alpha.36 or higher.

[mnajdova]

The reason is the breaking change introduced by #26323. @eps1lon should we improve the description of the breaking change? I think this is a corner case, but as it already came up as an issue maybe we should mention the bigger specificity that is introduced in the styles.

[eps1lon]

I didn't make that particular change nor do I think it should stay. It makes customization not straight forward. You'd have to ask @oliviertassinari what problem the sibling selector solves and what alternatives he tried.

[oliviertassinari]

The biggest constraint I had was the lack of support for &:first-child that emotion sets on us. We moved to &:first-of-type during the migration from JSS to emotion. But now, with a flat header, we can no longer rely on &:first-of-type either. The DOM structure is

• div (MuiDialog-root)
  • h2 (MuiDialogTitle-root)
  • div (MuiDialogContent-root)

The least worse solution I could find is:
https://github.com/mui-org/material-ui/blob/e8dd87d14f9d64719faaca9c8ff8c97e943262e3/packages/material-ui/src/DialogContent/DialogContent.js#L43

[oliviertassinari]

For the solution, an update of the docs like proposed by @mnajdova sounds great 👍

diff --git a/docs/src/pages/guides/migration-v4/migration-v4.md b/docs/src/pages/guides/migration-v4/migration-v4.md
index b66b55e80d..2d8629a8be 100644
--- a/docs/src/pages/guides/migration-v4/migration-v4.md
+++ b/docs/src/pages/guides/migration-v4/migration-v4.md
@@ -773,6 +773,10 @@ You can use the [`collapse-rename-collapsedheight` codemod](https://github.com/m
      </Typography>
   ```

+  Note that the DialogContent now applies its padding with a specificity of 2.
+  It was changed to work around the lack of [support of `:first-child`](https://github.com/emotion-js/emotion/issues/1178) in emotion.
+  See [#26795](https://github.com/mui-org/material-ui/issues/) for more details.
+
 ### Divider

 - Use border instead of background color. It prevents inconsistent height on scaled screens.

[eps1lon]

Why can't we apply the styles to the DialogContent? A Dialog should always have a heading anyway. Instead, people should add padding if they purposely omit the heading.

[oliviertassinari]

A Dialog should always have a heading anyway

@eps1lon It's written as is it was a fact. Why should a DialogTitle be always rendered? Material Design doesn't seem to support this affirmation.

Anatomy
2. Title (optional)

https://material.io/components/dialogs#usage

Or the first demo of the page.

It seems that they are consistent with the legacy version:

https://material.io/archive/guidelines/components/dialogs.html#dialogs-behavior

Most alerts don't need titles.

---

Instead, people should add padding if they purposely omit the heading.

Actually, we could likely leverage that a dialog title will most often be used to reverse the CSS tradeoff.

[oliviertassinari]

I have tried:

diff --git a/packages/material-ui/src/DialogContent/DialogContent.js b/packages/material-ui/src/DialogContent/DialogContent.js
index 131e5e6980..0ed698d896 100644
--- a/packages/material-ui/src/DialogContent/DialogContent.js
+++ b/packages/material-ui/src/DialogContent/DialogContent.js
@@ -32,7 +32,7 @@ const DialogContentRoot = styled('div', {
   // Add iOS momentum scrolling for iOS < 13.0
   WebkitOverflowScrolling: 'touch',
   overflowY: 'auto',
-  padding: '20px 24px',
+  padding: '0 24px 20px',
   ...(styleProps.dividers
     ? {
         padding: '16px 24px',
@@ -40,8 +40,8 @@ const DialogContentRoot = styled('div', {
         borderBottom: `1px solid ${theme.palette.divider}`,
       }
     : {
-        '.MuiDialogTitle-root + &': {
-          paddingTop: 0,
+        ':not(.MuiDialogTitle-root) + &': {
+          paddingTop: 20,
         },
       }),
 }));

But it's not working.

---

How about we add a new prop like noTitle on the DialogContent component, to flatten the CSS specificity for the most frequent use case (with title)?

[eps1lon]

A dialog having no title is problematic UI. Customization should not be our concern in this case. Otherwise we encourage problematic UIs.

[oliviertassinari]

Looking at WAI-ARIA, they seems to support that a dialog should always be labeled.

The dialog has either:
A value set for the aria-labelledby property that refers to a visible dialog title.
A label specified by aria-label.

https://www.w3.org/TR/wai-aria-practices-1.1/

We could support DialogContent being the aria-label of the dialog, and rendered as a h2, without the DialogTitle. This would help better support the guidelines of Material Design.

A dialog having no title is problematic UI.

@eps1lon This is confusing me. Do you mean from a DOM perspective or a design perspective? The two seems distinct. Also, it seems exposed as an axiom, adding resources to support it would help.
I agree with this affirmation if it concerns the label of the dialog and concerns the DOM aspect, not the design one.

[eps1lon]

Do you mean from a DOM perspective or a design perspective?

I don't know what a "DOM perspective" is. The DOM is just a programming interface.

I'm talking about a design perspective. Just as your documents should have titles. Dialogs are mini-documents that are nested within other documents. Especially for fullscreen dialogs I don't see how a dialog without a title is a good thing.

We could support DialogContent being the aria-label of the dialog, and rendered as a h2, without the DialogTitle.

"Content" is not the heading or title and abusing it as such is just straight up confusing. Consider how you would teach this.

[oliviertassinari]

@eps1lon OK thanks for the clarification, so it's none of the option concepts I was wondering about (DOM, as the a11y tree, and design as the Material Design aspect. Your point is more conceptual, "title" as something that labels the content of the modal, which is close to the a11y that requires a label. I agree.

Here Material Design is saying that the "title" can either be the "DialogTitle" or "DialogContent" (if alone).