Style TinyMCE modals to match WordPress admin styling

[melchoyce]

There are a couple instances of TinyMCE modals which don't visually match the rest of the admin:

Let's restyle them to match.

[azaozz]

Non-minified compiled stylesheet

[melchoyce]

Is the best way to restyle these modals to overwrite the default TinyMCE styles, or to remove the default TinyMCE styles and let them inherit styles/classes and from core?

[iseulde]

What kind of styles do you have in mind for them? I'll have to do the same thing for the front-end.

[melchoyce]

Replying to avryl:

What kind of styles do you have in mind for them? I'll have to do the same thing for the front-end.

That's a good question.

We have, as far as I can tell (there might be more), three entirely different modal styles:

• Thickbox modal: ​https://cloudup.com/cmxHcYMWrlP
• Theme browser modal: ​https://cloudup.com/cARAliUS1VL
• Media modal: ​https://cloudup.com/cGekmEyuopE

In this instance, I had the theme browser in mind as a general modal style as I think it'll be easy to design tabs into. That said, the media modal styles already have tabs we could use: ​https://cloudup.com/cmy9QpXCwrx.

This could be a good opportunity to establish one consistent core style we could use for all modals. What are your thoughts?

[iseulde]

+ 1 for having one design to rule them all. :)

[iseulde]

I do like the media modal most, but it needs to be better designed for small screens. When you have a lot of menu items in the sidebar, it will cover too much on top, and the tabs are also a bit weird.

[melchoyce]

Replying to avryl:

I do like the media modal most, but it needs to be better designed for small screens. When you have a lot of menu items in the sidebar, it will cover too much on top, and the tabs are also a bit weird.

Agreed — though in the case of the TinyMCE modals, we'd drop the sidebar entirely.

[iseulde]

Sure, but it'd be good to make something reusable! :)
And you'll probably want smaller modals for that as well?

[melchoyce]

Replying to avryl:

Sure, but it'd be good to make something reusable! :)
And you'll probably want smaller modals for that as well?

True. And yeah, we'd want to scale down the size of each modal to something more proportionate to that modal's particular content.

[nacin]

Replying to avryl:

Sure, but it'd be good to make something reusable! :)

The media modal is very flexible. The sidebar isn't required, and in fact media sometimes doesn't use it, depending on the task.

[iseulde]

Replying to nacin:

Replying to avryl:

Sure, but it'd be good to make something reusable! :)

The media modal is very flexible. The sidebar isn't required, and in fact media sometimes doesn't use it, depending on the task.

Yes, of course, I know! I just meant that we should reuse one modal design for everything, and adjust it to the needs. E.g. the current sidebar works great on small screens if there are only four items in it, but it breaks with more. Reuse it for smaller modals etc. It could be even more flexible.

[paulwilde]

Been following the discussions and thought I'd throw together a quick mockup of what the plugin installer modal could look like given WordPress were to have a single consistent modal UI as suggested. Apologises that it's unrelated to TinyMCE and therefore could sit in its own ticket. Just wanted to get some ideas flowing and to add some context to the discussion. :)

[iseulde]

Looks very nice!

[melchoyce]

That looks awesome — it works great with the plugin content!

[azaozz]

Replying to melchoyce:

Is the best way to restyle these modals to overwrite the default TinyMCE styles, or to remove the default TinyMCE styles and let them inherit styles/classes and from core?

Currently the default is used for the toolbar buttons and partially overridden in editor.css. Thinking we can do the same for the modals.

[nacin]

It's worth noting that the plugin information tab used to look like the plugin directory page on WP.org, by design. (It was practically a mirror image). Over time, WP.org started to look more modern. This would in effect cause the dashboard to again leapfrog WP.org. I don't think that's a problem, but I did want to point it out.

Could we sneak in banner images? Does that work with the constraints? Just curious. :-)

[azaozz]

Don't see a reason why banner images wouldn't work, especially if the modal is a bit wider to reduce scrolling.

[helen]

How about reviews too, then? :) #22599

[helen]

Media attach dialog

[helen]

Remembered another modal - the attach unattached media one. Screenshot uploaded above.

[melchoyce]

Attached two modal mockups above.

Still to-do: the text formatting (paragraph, header, etc.) dropdown, the color dropdown, and the media attachment modal helen posted above.

[iseulde]

First attempt:

• Removes text-shadow from dashicons.
• Removes weird border radius from Quicklinks toolbar.
• Fixes arrow border and replaces arrow with dashicon.
• Inherit colours and font (i.e. Open Sans).
• Makes tooltip shadows lighter and font a bit bigger (11px ->12px).
• Also adds some margin between the tooltip and buttons.
• Restyles Charmap and Help modals.
• Added cursor: pointer; to Charmap table cells.
• Removed the close button from the Help modal, because the button will be too big when enqueuing button styles (iframe is small and triggers responsive styles) and I think it's cleaner like this anyway.
• Restyles the format button (but I'm not sure if it's good enough). I think it'd be good if buttons with an arrow all have the same style though.
• Flips the arrow when the menu is open.
• Restyles the format and colour menus.

TODO

• I'd be easier if the Help modal wasn't an iframe. Maybe remove it? Not sure if it's possible.
• Style TinyMCE buttons (e.g. in the plain text modal). It's probably easiest to add button[type="button"]to buttons.css, though TinyMCE wraps it in a div and styles that. Not sure which solution is best and doesn't add too much CSS.
• Test other TinyMCE plugins.
• Test on the front-end (wp_editor).

[iseulde]

@melchoyce I'm not sure if it's possible to style the Charmap sidebar like in your mock up since TinyMCE doesn't provide any id's and styling it might affect other elements in other modals.

[azaozz]

In 27190:

TinyMCE: style the modals to match WordPress admin (first-run). Fix couple of IE problems in tiny_mce_popup.js. Props avryl, see #26952, see #24067

[iseulde]

@azaozz Okay, so is it better not to mimic the media modal style entirely for TinyMCE modals? I agree it's a bit hacky with the iframe...

[iseulde]

Looks like I didn't overwrite the font properly. I've also re-added the colours for the close button.

[azaozz]

In [27193]

TinyMCE: revert style for the blocks drop-down in the toolbar, limit the styles imported for the same drop-down, make the menu highlight color grey. Part props avryl, see #26952

[alleynoah]

In changeset [27190], the use of !important in the modal's z-index styling (for example, https://core.trac.wordpress.org/browser/trunk/src/wp-includes/css/editor.css#L24) to override TinyMCE's use of inline z-index styling causes problems -- if there are additional modal elements, they appear behind the overridden modal and mask. This breaks some elements of the TinyMCE4 table plugin for example (I'll attach a screenshot below). I know it mirrors the media modal styles, but is it necessary to override the z-index this way? On my instance if I simply disabled those overrides I didn't notice any issues, but there certainly may be cases that I'm not thinking of.

I'll also attach a patch that solves the problem for me in the opposite direction (just by adding a similar override to the menu element). My concern about the "more overrides" direction is just that it could potentially mean adding overrides for every special case where TinyMCE already has the handling built, and might make using TinyMCE4 plugins more complex.

[alleynoah]

dropdown menu hidden behind the modal

[alleynoah]

add z-index override to modal dropdowns also

[azaozz]

Replying to alleynoah:

...is it necessary to override the z-index this way?

Yes, unfortunately. Otherwise the modals are "under" the DFW. Thinking the best way to handle this would be to review/audit all z-index values in our css. A lot of them are needlessly high. This has caused problems several times before and the "solution" was to bump them even higher.

[alleynoah]

Replying to azaozz:

Yes, unfortunately. Otherwise the modals are "under" the DFW. Thinking the best way to handle this would be to review/audit all z-index values in our css. A lot of them are needlessly high. This has caused problems several times before and the "solution" was to bump them even higher.

Ah, that makes sense to me, thanks!

[iseulde]

26952.3.patch​ restyles the modal for attaching media to posts.
Before.

[azaozz]

In 27401:

Restyles the modal for attaching media to posts, props avryl, see #26952

[iseulde]

Whoops, I was just improving the patch. There's also a jshint error for an unused variable btw. Sorry, should test before uploading patches.

[azaozz]

In [27403]:

Restyles the modal for attaching media to posts, take II (also some autoprefixer and imagemin). Props avryl, see #26952.

[iseulde]

26952.6.patch​ restyles the link modal in the editor. Instead of jQuery UI it's just CSS, and it also removes the redundant jQuery UI stylesheet. I did the toggling of the existent content search a bit differently. It becomes visible when you focus on the search field and hides again if you focus on one of the other fields. Let me know what you think.

[SergeyBiryukov]

#27310 was marked as a duplicate.

[iseulde]

Restyled jQuery UI dialog. When the link modal is done, this will no longer be used in core, but may be used by plugins.

[azaozz]

In 27460:

Set minimum z-index for the TinyMCE modals and adjust the z-index in DFW, see #26952

[azaozz]

In 27461:

Adjust .find-box-inside responsive style, props avryl, see #26952

[iseulde]

Voilà, last patch restyles the jQuery UI dialog (that plugins may use) and restyles the wplink modal with the current behaviour in mind (+ animation and responsive width/height).
Didn't test in IE, so it'd be great if someone could do that.

[iseulde]

Next: ThickBox. :)

[azaozz]

26952.7.patch works better. Still not sure about scrolling the whole "body" hiding the top part and then auto-scrolling to the top on clicking a search result in the bottom part. The old behavior is a better UX imho. Clicking on a search result fills the fields at the top, logically they should always be visible.

Also we lost the "Cancel" link and containing the "tabbing" inside the modal (will add that back). The "X" is not a "tab stop" either.

Was also looking at the search field. Currently it triggers AJAX request on typing 3 chars and on every character after.

• 3 characters should be ok for most languages, but not for gliphs. The user may want to search on the first or second gliph.
• Typing a 10 characters search string triggers 8 concurrent AJAX connections (8 POST requests, 8 DB connections, etc.). Seems pretty wasteful.

Thinking it would be better to have a Submit button for searching. Don't remember if there was one at first, but there is definitely space for it.

Not so sure about the changed "looks" too. Patched it looks like the left side of the above image, was thinking it should be more like the right one. We would change the structural CSS, the header, and tweak the colors in the modal's "body". Not sure it needs anything else.

The "header" and "footer" feel very large too, especially when the modal is folded. I realize we are trying to follow the media modal styling but it covers nearly the whole screen and the footer there has another purpose (shows thumbnails). In all the rest of the modals the footer only holds the "submit" button.

[azaozz]

In 27485:

Adjust the height of the header and footer in the Find Posts modal on the Media Library screen, see #26952

[azaozz]

26952.8.patch uses parts of 26952.7.patch but attempts to keep the look the same/similar to the current modal. It also auto-shows the internal links part on screens < 768px wide or < 440px high. Still needs some cleanup and tabbing fixes.

[iseulde]

Still not sure about scrolling the whole "body" hiding the top part and then auto-scrolling to the top on clicking a search result in the bottom part. The old behavior is a better UX imho. Clicking on a search result fills the fields at the top, logically they should always be visible.

I thought it would be better to allow more space for the list depending on your screen size. But yes, it'd be better if the input fields are visible after selecting a post. Scrolling to the top would be annoying, so it looks like the old scroll behaviour is better.

Also we lost the "Cancel" link […]

I think we should get rid of it. No other modal has it.

Not so sure about the changed "looks" too. Patched it looks like the left side of the above image, was thinking it should be more like the right one. We would change the structural CSS, the header, and tweak the colors in the modal's "body". Not sure it needs anything else.
The "header" and "footer" feel very large too, especially when the modal is folded. I realize we are trying to follow the media modal styling but it covers nearly the whole screen and the footer there has another purpose (shows thumbnails). In all the rest of the modals the footer only holds the "submit" button.

I agree that the headers look a bit big (was trying to copy it from the media modal). So let’s resize them to about 40px? I’d keep the colour of the header though, and remove the visual distinction of the footer.

[iseulde]

Last patch just adds some space between the query results and the footer, removes the border from the last list item and removes the 11px font-size of the checkbox label. Not sure why that was 11px.

[iseulde]

I also noticed that the link modal and TinyMCE modals are the only modals that currently don't close when you click on the backdrop. Not difficult to add to the link modal, maybe be worth asking Spocke to add this to the TinyMCE modals?

[azaozz]

In 27494:

wpLink: stop using UI dialog, restyle the modal, add better responsive behaviour.
Fix UI dialog styling to match the rest of the admin styling.
Props avryl, see #26952

[nacin]

[27494] results in a super-tall modal when the post list is expanded. When collapsed, it's shoved up to the top of the page, rather than being vertically centered. Neither of these are ideal. It should be relatively short and centered on the page.

Why the move away from jQuery UI dialog? It worked fine, and it also enabled you to actually move the dialog around, which was helpful if you wanted to glance at your post again while inserting a link. (I happen to do this a lot.)

Generally speaking, we should shrink the size of the titles in these modals. The media modal is fine to have a large title because it takes up the entire screen. But special characters, about, shortcuts, and links don't; it overpowers the screen.

[nacin]

I would like a cancel link back. The link dialog went through like 50 rounds of UI iteration and a boatload of user tests, every aspect of it was very carefully designed.

[iseulde]

Why the move away from jQuery UI dialog?

The problem with the jQuery UI dialog is that it's not responsive.
attachment:26952.7.patch​ added an animation just like the old modal. The collapsed modal would be vertically centred and expand smoothly.

Generally speaking, we should shrink the size of the titles in these modals.

Sure, I agree. We should try to find a good balance. melchoyce? :)

I would like a cancel link back. The link dialog went through like 50 rounds of UI iteration and a boatload of user tests, every aspect of it was very carefully designed.

If we leave the cancel button in this dialog, we should add one to the others as well. The UI isn't consistent like this.

[azaozz]

Yeah, perhaps we should have Cancel in all modals. Looking at the TinyMCE modals, all have it. How about we center it vertically with CSS's calc() (excludes IE8).

[azaozz]

In 27495:

wpLink: set max-height to 500px (like before) and vertically center the modal (except in IE8), see #26952

[azaozz]

Also reduced the modal title font size and height a bit in [27495]. In 26952.10.patch: bring back wpLink's Cancel button.

[helen]

We touched on this briefly in IRC the other day, but there are some concerns here about back-compat with people using the .wp-dialog class and anybody who's targeting things in the link modal.

[azaozz]

In 27496:

wpLink: better structural and responsive styles, see #26952

[azaozz]

In 27510:

wpLink: bring back the Cancel link, improve responsive styles, see #26952

[azaozz]

In 27513:

TinyMCE modals: re-enable the Close button in charmap, fix arrows in listboxes, add and position dashicons to the menu (when visible), see #26952

[bradyvercher]

The old wpLink modal triggered a 'wpdialogbeforeOpen' event before opening. Can we get something similar with the new modal?

[iseulde]

Last patch darkens all the overlays, updates all the shadow, all the headings, styles thickbox a bit (heading should be 29px, because it's hardcoded...) and makes the link modal a bit smaller in width.
Stil to do: style the plugin modal (without thickbox).

[iseulde]

In the link modal, the button is not responsive. That's because there's no button class. The input fields also don't really wrap well. See screenshot above.

[azaozz]

In 27532:

Modals: darken all overlays, update all box-shadows and headings, correct thickbox styling, make the link modal narrower and bring back the animation (css transition). Props avryl, see #26952

[iseulde]

Patch above restyles the plugin details modal. It still uses thickbox, and should be redone some other time (maybe with backbone and without frames?). Might be worth creating a separate ticket.
Props paulwilde for initial mockup.

[iseulde]

The 'warning' message is still a bit weird on a white backgrounds, and the tabs don't wrap well on small screens. But this is a bigger issue with tabs in core.

[azaozz]

In 27559:

Restyle the plugin install details modal to match the rest of the admin. Props avryl and paulwilde for initial mockup, see #26952

[azaozz]

Had to change couple of things in 26952.13.patch:

• Moved the scrollbar from the middle of the modal to the right.
• Reduced size of the header and footer to match the rest of the modals.

[iseulde]

Ah, melchoyce and I decided to use a bigger header since the size of the modal is significantly bigger. I'll take a look.

[azaozz]

Yes, was thinking this modal can actually cover the whole screen like the media modal. Then perhaps we could pull the plugin header image in it too (needs WordPress.org API update).

[iseulde]

I would definitely make the heading bigger again. The modal is different because it's bigger, has tabs and looks a lot like the media modal with the side bar.
The line between the heading and the tabs doesn't look right. I think the sidebar also looks better covering the full height, just like the one in the media modal. What do you think, melchoyce?

We could put a lot more things in the modal, not just the image. E.g. the contributors and their avatars, the possibility to rate the plugin without visiting wp.org, reviews, submitting reviews, a 'This works for me' toggle', favourite, submit a support ticket etc. etc. But this is out of scope for this ticket and release. Shall I make a separate ticket? :)

[azaozz]

Replying to avryl:

I would definitely make the heading bigger again. The modal is different because it's bigger, has tabs and looks a lot like the media modal with the side bar.

Looks pretty similar in size to the "Find Posts or Pages" modal on the Media Library screen, and a lot smaller than the media modal. Especially on a (somewhat) standard 1080p desktop monitor. Don't mind either way though.

The line between the heading and the tabs doesn't look right.

Wouldn't that make it inconsistent compared to the other non-fullsize modals?

I think the sidebar also looks better covering the full height, just like the one in the media modal. What do you think, melchoyce?

Perhaps, but having a scrollbar in the middle of the modal and another one on the side just for the "sidebar" on smaller height is worse?

We could put a lot more things in the modal, not just the image. E.g. the contributors and their avatars, the possibility to rate the plugin without visiting wp.org, reviews, submitting reviews, a 'This works for me' toggle', favourite, submit a support ticket etc. etc. But this is out of scope for this ticket and release. Shall I make a separate ticket? :)

Yeah, sounds like a whole new project :)

[paulwilde]

Played about with the new Plugin modal design and agree with avryl's points.

I'm a bigger fan of the larger title with no seperator line. The seperator line gives off the impression that the contents of the modal isn't as tightly integrated to WordPress as it could be and that it comes from a third party site rather than WordPress itself. The contents of the modal flow better with no separation.

I'm also a fan of of the sidebar being fixed. When you scroll down you lose a lot of vital at-a-glance information about the plugin with nothing but whitespace replacing it, so you end up losing more than you gain. Adding height media queries could be used to prevent double scrollbars should that be an argument against the sidebar being fixed.

I've also noticed a slight regression caused by the new design. When you try and install a plugin you already have installed you are presented with a clickable action button labelled "Latest Version installed" which upon clicking does nothing. In the previous design you were unable to actually click this button. Adding a 'disabled' class to the link seems to fix it.

[melchoyce]

Just had a chance to preview. I also agree with all of avryl's points.

Wouldn't that make it inconsistent compared to the other non-fullsize modals?

Nope — it makes it consistent with the media modal. The same styling (removing the border) should be applied to the TinyMCE help modal as well. Any modal that contains tabs should not have an extra border between the tabs and the title.

[paulwilde]

I've gone ahead and created a new ticket for further enhancements to the Plugin modal at #27440 as to not entirely derail the ticket with out-of-scope ideas.

[paulwilde]

Added a patch which fixes the disabled button behaviour I mentioned previously, along with making the dimensions of the loading spinner correct on HiDPI displays.

[nacin]

#27072 was marked as a duplicate.

[nacin]

In 27677:

Plugin Installer: Disable 'Latest Version Installed' buttons.

props paulwilde.
see #26952.

[nacin]

In 27678:

Ensure Thickbox loading spinner is properly sized for HiDPI displays.

props paulwilde.
see #26952.

[nacin]

What else is left here? I have the following:

• I agree with melchoyce and avryl on the plugin info modal. Title needs to be bigger and border needs to be gone. This is more like the media modal than the link dialog.

Also, I like moving the scrollbar to the right on the plugin info modal. Could we still stick the "fyi" div to the top, if there's enough room for it to be presented? Like the sticky admin menu. If difficult/annoying to do, then it's not a big deal.

[iseulde]

Replying to nacin:

What else is left here? I have the following:

• I agree with melchoyce and avryl on the plugin info modal. Title needs to be bigger and border needs to be gone. This is more like the media modal than the link dialog.

Also, I like moving the scrollbar to the right on the plugin info modal. Could we still stick the "fyi" div to the top, if there's enough room for it to be presented? Like the sticky admin menu. If difficult/annoying to do, then it's not a big deal.

Cool, I'll make a patch before the meeting. Not sure what you mean for the right sidebar. So leave it as it is now and and stick it on top if it's small enough? Or make it look like in the media modal (full height)?

[iseulde]

Let's also remove that line in the TinyMCE help modal and use the same tabs. I'll submit a patch asap.
Patch for the plugin modal above. Not sure if the sidebar is okay, but the chance that the content is longer than the height is pretty small. On small screens the sidebar is placed on top, and the aren't any screens that have a small height and long width.

[iseulde]

Last patch fixes the tabs in the help modal.

[helen]

In 27765:

Better, more consistent styling for plugin details Thickbox and TinyMCE help.

props avryl. fixes #26952.

[azaozz]

In 27831:

Fix styling for mce-path (at the bottom of the editor), see #26952

[nacin]

In 27833:

Restore the original z-index of the sticky admin menu, as first set in [26442].

The inline comment is now correct again. This z-index was changed in [26701], but those circumstances no longer apply after [27532].

props mordauk.
see #26442, #26952.
fixes #26567.

[ocean90]

In 27932:

Fix styling for plugin update details Thickbox.

see #26952.

[ocean90]

26952.17.patch​ does the same as [27932] but for the importer details Thickbox, see before.importer.png​ and after.importer.png​.

[azaozz]

26952.17.patch looks good. Adds the thickbox CSS overrides to Tools -> Import.

[nacin]

Good to go.

[azaozz]

In 28080:

Add the new modlas styling to the importer details Thickbox on Tools -> Import. Props ocean90, fixes #26952

[iseulde]

#22156 was marked as a duplicate.