Components Modal: Add Missing Classname to Div Inside components-modal__content After components-modal__header

[Debarghya-Banerjee]

What problem does this address?

• The components-modal__content in the Gutenberg Components Modal is missing a classname for the div immediately following the components-modal__header. This makes it challenging to apply specific styles or target that div for customization, testing, or plugin development.

What is your proposed solution?

• Add a unique and descriptive classname to the div following the components-modal__header inside components-modal__content. This will enable developers to target the div more effectively for styling and functional enhancements while maintaining consistency with other Gutenberg components.

Screenshot

[Mamaduka]

@ciampo, @mirka, do you remember if this classname was intentionally omitted?

[mirka]

Regardless of whether this particular omission was intentional, we're moving towards a direction where internal elements of components will not have stable classnames for consumer style overrides at all. Internal DOM structure is not part of the backward compatibility guarantee, which makes style overrides like this fragile, so we've always been recommending against it.

@Debarghya-Banerjee Is there a specific kind of style customization or targeting you want here that can't be achieved through children? We can take that into account when designing the next iteration of the Modal component, which we plan to make more modular and customizable.

For example, approaches like <Modal><div data-testid="foo" /></Modal> or <Modal><div style={ { maxWidth: 100 } } /></Modal> is sufficient for most cases.

[Debarghya-Banerjee]

Hi @mirka , Thanks for replying, TBH, I was building something using the Modal component and I wanted to target that div, though targeting it ain't a tough job and can be done using children or nth-child, I was considering if we could have a classname similar to that for the header section.

[mirka]

The question is whether there are legitimate use cases where the component's internal div needs to be targeted, instead of a div that the consumer supplies through children.

[t-hamano]

When I was developing some plugins, I thought it would be useful to have a class like .components-modal__body applied to that div.

One use case is when we want the modal body to expand to 100% height and make some of its children scrollable.

Take the core Classic block as an example. This block does not want to use scrolling of the modal content itself because tinyMCE itself is scrollable:

[mirka]

@t-hamano Good example, thanks. We should make sure this kind of layout is more easily achieved in the v2 component.

No strong opinion on whether we should add a classname there to the v1 component. It definitely solves an immediate problem, but also adds more things we need to think about when making changes to the component.

[ciampo]

Agree with @mirka .

Classnames and internal DOM structure are not part of Modal's (or any components) public APIs, and therefore we discourage consumers of the component from relying on that information in general.

Having said that, you're both highlighting a shortcoming of the current component that is not easily addressable (if not by adding "one more prop"), and considering that the component is already heavily used in a hacky way, I don't think it would make a huge difference to add this extra classname 🙈 .

This of course won't change the fact that consumers shouldn't rely on it and it's their responsibility to make sure that their "hack" doesn't break the UI when the library is updated.

[t-hamano]

If the Modal v2 is planned and use cases like this are considered in the v2 component, I don't think it's necessary to add the class name to the Modal v1.

I discovered that this div had a CSS class in the past that was subsequently removed (#50655). Considering this, adding the CSS class again might not be the best idea. Developers who do want to target this div can use the .components-modal__header + div selector.

[Mamaduka]

Thanks, everyone, for the insightful conversation. Based on it, I think we can close the issue and associated PR. While not perfect, it's possible to target the "body" div.

Is there a tracking issue for Modal v2? It would be a good idea to mention this proposal there.

[t-hamano]

Let's close this issue and the associated PR. I was not able to find any issues related to Modal v2, but if anyone knows of any please link them here.

[ciampo]

We had started the conversation in this discussion