#26952 closed task (blessed) (fixed)
Style TinyMCE modals to match WordPress admin styling
Reported by: | melchoyce | Owned by: | helen |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | 3.9 |
Component: | TinyMCE | Keywords: | has-patch commit dev-reviewed |
Focuses: | ui | Cc: |
Attachments (36)
Change History (138)
This ticket was mentioned in IRC in #wordpress-ui by melchoyce. View the logs.
11 years ago
This ticket was mentioned in IRC in #wordpress-dev by melchoyce. View the logs.
11 years ago
#4
follow-up:
↓ 17
@
11 years ago
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?
#5
follow-up:
↓ 6
@
11 years ago
What kind of styles do you have in mind for them? I'll have to do the same thing for the front-end.
#6
in reply to:
↑ 5
@
11 years ago
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?
#8
follow-up:
↓ 9
@
11 years ago
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.
#9
in reply to:
↑ 8
@
11 years ago
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.
#10
follow-ups:
↓ 11
↓ 12
@
11 years ago
Sure, but it'd be good to make something reusable! :)
And you'll probably want smaller modals for that as well?
#11
in reply to:
↑ 10
@
11 years ago
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.
#12
in reply to:
↑ 10
;
follow-up:
↓ 13
@
11 years ago
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.
#13
in reply to:
↑ 12
@
11 years ago
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.
#14
@
11 years ago
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. :)
#17
in reply to:
↑ 4
@
11 years ago
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.
#18
@
11 years ago
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. :-)
#19
@
11 years ago
Don't see a reason why banner images wouldn't work, especially if the modal is a bit wider to reduce scrolling.
#21
@
11 years ago
Remembered another modal - the attach unattached media one. Screenshot uploaded above.
This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.
11 years ago
#23
@
11 years ago
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.
#24
@
11 years ago
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 TinyyMCE plugins.
- Test on the front-end (wp_editor).
#25
@
11 years ago
@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 ids and styling it might affect other elements in other modals.
#27
@
11 years ago
@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...
#28
@
11 years ago
Looks like I didn't overwrite the font properly. I've also re-added the colours for the close button.
#30
follow-up:
↓ 31
@
11 years ago
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.
#31
in reply to:
↑ 30
;
follow-up:
↓ 32
@
11 years ago
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.
#32
in reply to:
↑ 31
@
11 years ago
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!
#35
@
11 years ago
Whoops, I was just improving the patch. There's also a jshint error for an unused variable btw. Sorry, should test before uploading patches.
This ticket was mentioned in IRC in #wordpress-ui by avryl. View the logs.
11 years ago
#38
@
11 years ago
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.
This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.
11 years ago
#41
@
11 years ago
Restyled jQuery UI dialog. When the link modal is done, this will no longer be used in core, but may be used by plugins.
#44
@
11 years ago
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.
#46
@
11 years ago
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.
#48
@
11 years ago
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.
#49
@
11 years ago
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.
#50
@
11 years ago
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.
#51
@
11 years ago
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?
#53
follow-up:
↓ 55
@
11 years ago
[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.
#54
@
11 years ago
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.
#55
in reply to:
↑ 53
@
11 years ago
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.
This ticket was mentioned in IRC in #wordpress-ui by avryl. View the logs.
11 years ago
#57
@
11 years ago
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).
#59
@
11 years ago
Also reduced the modal title font size and height a bit in [27495]. In 26952.10.patch: bring back wpLink's Cancel button.
#60
@
11 years ago
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.
#65
@
11 years ago
The old wpLink modal triggered a 'wpdialogbeforeOpen' event before opening. Can we get something similar with the new modal?
This ticket was mentioned in IRC in #wordpress-dev by azaozz. View the logs.
11 years ago
#67
@
11 years ago
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).
#68
@
11 years ago
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.
This ticket was mentioned in IRC in #wordpress-ui by avryl. View the logs.
11 years ago
#71
@
11 years ago
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.
#72
@
11 years ago
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.
#74
@
11 years ago
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.
#75
@
11 years ago
Ah, melchoyce and I decided to use a bigger header since the size of the modal is significantly bigger. I'll take a look.
#76
@
11 years ago
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).
#77
follow-up:
↓ 78
@
11 years ago
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? :)
#78
in reply to:
↑ 77
@
11 years ago
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 :)
#79
@
11 years ago
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.
#80
@
11 years ago
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.
#81
@
11 years ago
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.
#82
@
11 years ago
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.
This ticket was mentioned in IRC in #wordpress-ui by paulwilde. View the logs.
11 years ago
#87
follow-up:
↓ 88
@
11 years ago
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.
#88
in reply to:
↑ 87
@
11 years ago
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)?
#89
@
11 years ago
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.
This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.
11 years ago
#92
@
11 years ago
- Owner set to helen
- Resolution set to fixed
- Status changed from new to closed
In 27765:
This ticket was mentioned in IRC in #wordpress-dev by ipstenu. View the logs.
11 years ago
#97
@
11 years ago
- Keywords has-patch commit added
- Resolution fixed deleted
- Status changed from closed to reopened
26952.17.patch does the same as [27932] but for the importer details Thickbox, see before.importer.png and after.importer.png.
Non-minified compiled stylesheet