Make the modal height and width determined by the content

[afercia]

The Modal component sizing can be improved a bit. Right now, on bigger screens, the height is always a fixed value of 70%. This is far from ideal when the modal content is very short, as the screenshot on #8561 (comment) clearly illustrates.

As a plugin developer, I would like to be able to manage the modal size according to my needs, with minimal effort. I'd like the height to be determined by the actual modal content, as I have no reasons to want a modal that is taller than the content. With regards to the width, I'd like to set it on the content I pass to the modal and implement my own media queries (if necessary) in my component.

This PR is a POC trying to go in that direction.

• the height is determined by the content
• I haven't touched the width yet, I'd say there should probably be a min-width set and then developers should be able to set the desired with in their components

Screenshot with short content:

Screenshot with long content:

The wrapper with overflow: auto is now the modal frame: it already as an ARIA role and it's properly labelled. There's no need for new roles and labels as done in #9900

While this approach doesn't solve all the issues, it's probably simpler and worth exploring. It also makes developers able to manage the modal sizing. I'd propose to consider to explore how to unify this new approach with the improvements currently proposed in #9900 and #9410.

Note on the header: it uses position: sticky which doesn't work on IE 11. Honestly, I wouldn't be so worried by the header that scrolls in IE 11. As said, this is a POC and any improvements are very welcome. /Cc @jasmussen

Fixes #8561

[jasmussen]

Very cool work. Nicely done!

A few things. The close button is a bit rectangular:

It would be nice if it were square. Given the header box is a flex container, I suspect either padding on the container or margin on the child can address this.

Secondly — I would love us to add some max-height to the box. I like 70%, but I could be convinced of more. 80% looks pretty good:

Here's 90%:

Remember that any max-height you add should be wrapped in @include break-small() {} so it's not applied on mobile.

At this height, the width sort of seems small on big screens. Not for this PR, but would it be possible and/or nice if the width was content aware just like the height is? Something about a min and max-width?

Finally, it's nice to see that this PR solves the issue where the tooltip is showing on initial open. I noticed an issue in this branch, though, which is also an issue in master. If you open the modal, click the modal content, then press tab, you tab outside of the modal and into the content below the scrim:

This is not an issue in #9900:

What do you think the best approach is here?

[afercia]

Thanks, will check the points you've raised. Re: the max-height: there is one, see https://github.com/WordPress/gutenberg/pull/9973/files#diff-3c711058f2b216e67a13e12834045ccfR35 I can certainly adjust the value to 90% but that would be an opinionated value, i.e. a "magic number" 😉 Wouldn't be better to subtract to the full available height soem spacing based on the 8p grid ?

Also, any suggestion about the width?

[jasmussen]

Wouldn't be better to subtract to the full available height soem spacing based on the 8p grid ?

That's a good argument. Using some screen rulers, it would feel balanced if we were able to apply about 56px margin above and below the modal. What do you think?

Width was a spur of the moment inspiration. No need to address in this PR. But I would suggest 640px would be a nice max-width, and 360px a nice min-width.

[afercia]

I noticed an issue in this branch, though, which is also an issue in master. If you open the modal, click the modal content, then press tab, you tab outside of the modal and into the content below the scrim:

Right. I think this happens because the keyboard shortcuts modal has only one focusable element: the X close button at the top. When you click in the middle of the content, technically there's no focused element and withConstrainedTabbing gets confused. Unrelated to this PR though. /Cc @aduth

[aduth]

When you click in the middle of the content, technically there's no focused element and withConstrainedTabbing gets confused.

Technically I think withConstrainedTabbing is not doing anything here, since as focus has left the wrapper element it renders, it's no longer capturing the tab presses.

Whether it should be doing something? I'm not clear what that might be.

• Detect blur and force focus back within?
• Make the wrapper element have tabIndex="-1" so that clicking in the content area still keeps focus within?

[afercia]

Technically I think withConstrainedTabbing is not doing anything here, since as focus has left the wrapper element it renders, it's no longer capturing the tab presses

There's a keydown event on the modal wrapper (withConstrainedTabbing) so even after I click in the middle of the modal, then when pressing Tab the keydown event should fire. This works for example in the Classic Editor > Insert link > advanced options dialog: click after the last button within the modal, then press Tab and the keydown fires.
There's clearly a difference in how keydown works in React > withConstrainedTabbing > Modal.

[afercia]

@jasmussen I've set the 56 pixels, a min-width, and I think I've fixed the button size. Re: the modal width, I'm not sure setting a max-width in the component would be ideal. Then, it would be hard to override for developers: they should be free to implement their own media queries and related (max)widths. I think the best approach would be allowing developers to set media queries and widths in the component they pass as content. This should be documented though. Any feedback welcome.

Re: the 360 pixels min-width, maybe it could be moved to the 480 pixels breakpoint?

[aduth]

There's a keydown event on the modal wrapper (withConstrainedTabbing) so even after I click in the middle of the modal, then when pressing Tab the keydown event should fire.

Maybe I'm not understanding. Here's the steps I'm taking:

1. Click editor "More" menu
2. Click "Keyboard Shortcuts"
3. Open browser devtools Console
4. Enter document.activeElement in console
5. Note it's <button>, the close button, a descendant of withConstrainedElement and thus subject to its event handling
6. Click somewhere within the content (on, say, the "Global shortcuts" text)
7. Enter document.activeElement in console
8. Note it's <body>, not a descendant of withConstrainedElement and thus not subject to its event handling

A tab at this point will emit a keydown, but it'll emit on the body element, thus never bubbling to withConstrainedTabbing's wrapper.

By the looks of it, the classic editor link modal gets around this by adding tabindex="-1", which is an option we can consider as well for our own (on the modal? on withConstrainedFocus wrapper?).

[afercia]

Ahhh yes it's the tabindex, sorry for the confusion. Yep, most of the modals in core have a tabindex -1 or 0. I think we should try -1. Also, modern browsers behavior can be confusing sometimes because, regardless of where the focus landed (e.g. when body becomes the activeElement) they have implemented a sequential focus navigation starting point mechanism to try to restart the tab sequence from the last known "focus location". See for example https://bugs.chromium.org/p/chromium/issues/detail?id=454172 landed in Chrome 50. Firefox always had such mechanism.

[jasmussen]

Any progress on this one? It would be very nice to have this addressed in 4.0.

[afercia]

@jasmussen there are a few points that need feedback:

• tabindex: if desired, I can address it in this PR, just let me know
• modal width: developers should be free to implement their own media queries and related (max)widths. I think the best approach would be allowing developers to set media queries and widths in the component they pass as content. This should be documented though. Any feedback welcome.
• Re: the 360 pixels min-width, maybe it could be moved to the 480 pixels breakpoint?

[jasmussen]

tabindex: if desired, I can address it in this PR, just let me know

If this fixes the issue of being able to tab through the underlying stuff, go for it.

modal width: developers should be free to implement their own media queries and related (max)widths. I think the best approach would be allowing developers to set media queries and widths in the component they pass as content. This should be documented though. Any feedback welcome.

I don't disagree. But I also think this can happen separately. Perhaps we should shelve any width related enhancements for now so we can ship this PR?

Re: the 360 pixels min-width, maybe it could be moved to the 480 pixels breakpoint?

On mobile breakpoints all modals are 100% width and height anyway, right?

No strong opinion here otherwise.

[afercia]

@jasmussen I've adjusted the top and bottom spacing to 56 pixels and added tabindex="-1". I'd agree the width thing can be addressed separately.
The tabindex="-1" doesn't work in Safari, Edge, and IE11. Helps with Chrome and Safari. I'd tend to think that, instead of relying on browsers implementation of focus and tab starting point, we should address this programmatically.

@aduth
now that the the modal wrapper has a tabindex="-1" I think withConstrainedTabbing should be updated to take into account that at some point the event.target can be the wrapper, and in that case set focus on the firstTabbable. Will create an issue.

[jasmussen]

The tabindex="-1" doesn't work in Safari, Edge, and IE11. Helps with Chrome and Safari. I'd tend to think that, instead of relying on browsers implementation of focus and tab starting point, we should address this programmatically.

That is disappointing. Help me understand what makes this approach superior to the method used in #9900 which seems far simpler on the face of it?

[afercia]

@jasmussen if you mean the tabIndex="0" added there, that's mainly to make the scrolling div keyboard accessible. Also, withConstrainedTabbing can be used with many components, also custom components, not only with the modal so I think this edge case should be handled directly in withConstrainedTabbing. I've created #10165

[tofumatt]

I'm unclear about how the tabbing working now. Since #10174 was merged, there aren't any issues tabbing with content inside the modal in Safari/Edge/IE 11 now, correct?

I checked this out locally and it seems to work quite nicely for me.

[tofumatt]

The code here looks good to me and I'm happy with how it works when tested locally.

I'm cool with this given I can get clarification on any tabbing issues that still exist (or if they've been fixed). @afercia @aduth: could one of you clarify:

1. are there still tabbing issues?
2. how can they be reproduced?

---

A comment on the original PR: I'm also fine with IE 11 not scrolling the header.

[jasmussen]

With recent changes, the tooltip shows up on initial open. Was this intentionally removed, or is there a way we can add this back?

[afercia]

are there still tabbing issues?

No, as far as I can tell.

how can they be reproduced?

Reverting #10174 🙂

With recent changes, the tooltip shows up on initial open.

Not sure this PR changes anything in that regard, at least not intentionally. Also, there's a specific issue for that, see #9410

[afercia]

Todo: explore a way to allow developers to easily set the modal width. Historically, this has been a recurring issue in core, especially with the legacy thickbox. As I see it, the best option to empower developers to easily customize the modal width would be making it dependent on the width of the content passed to the modal. This should be clearly documented though.

[tofumatt]

explore a way to allow developers to easily set the modal width

That's a good idea, but worth a separate issue. I'm just rebasing this on top of master as some other changes were made to the modal styles, but after that I think this is good to merge. 👍

[tofumatt]

After rebasing this on top of @jasmussens' recent updates to the modal I'm happy with it and think it's solid. Thanks a bunch for this one, once Travis is green I'll get it merged in for 4.0.