WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 9 months ago

#24308 closed enhancement (fixed)

Twenty Thirteen: Add Editor Styles for Post Formats

Reported by: celloexpressions Owned by: lancewillett
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.6
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

Since the post formats UI is adding/changing the current post format to the tinyMCE iframe body class, we might as well include the post format styling in the editor. This has several advantages, including additional visual distinction between post formats for Twenty Thirteen users. It also makes it clearer what sort of content is expected in the editor, because you can compare directly to where it appears on the site. For example, the editor expects the quote itself, with or without blockquote tags. By making the editor display just like the output, it becomes obvious that the quote itself is expected here, and that quotation marks are provided.

The average first-time user won’t necessarily know that the different post formats are treated with an array of bold colors in Twenty Thirteen; they may not try publishing or previewing the different post formats, but instead just play with the PF admin UI. By reflecting the theme styling in the editor, they immediately know that the different formats feature different colors (and other minor layout changes), and are therefore more likely to start publishing with the different formats right away.

And, of course, by doing this we’re showing the thousands of default-theme-dissectors how easy it is to do separate styling per-format and encouraging them to as well. For me, it really completes the post formats UI. After all, the point of editor-style.css is to make editing a visually similar experience to the end result.

Attachments (9)

add-post-formats-to-editor-styles.diff (2.8 KB) - added by celloexpressions 11 months ago.
24308.1.patch (2.1 KB) - added by celloexpressions 11 months ago.
Colors and typography only, slightly faster transition
24308.2.patch (2.4 KB) - added by obenland 11 months ago.
Adds styles for blockquote cites and adjusts anchor color to what we use in .entry-content.
24308.3.patch (482 bytes) - added by azaozz 11 months ago.
24308.4.patch (3.7 KB) - added by celloexpressions 10 months ago.
Restore Post Format styling in TinyMCE, update audio format layout
24308.5.patch (546 bytes) - added by celloexpressions 10 months ago.
Fix audio and status format max-widths to account for their padding
format-audio-before.png (30.8 KB) - added by azaozz 10 months ago.
24308.6.diff (692 bytes) - added by celloexpressions 9 months ago.
Fix audio:before height and audio/status max-widths
24308.7.diff (1.4 KB) - added by obenland 9 months ago.
Takes a different approach to avoid magic numbers.

Download all attachments as: .zip

Change History (51)

comment:1 celloexpressions11 months ago

  • Keywords has-patch added

For the most part, I just worked from the styles in the PF section of style.css. It turns out that we can do quite a lot in terms of added styling (like with the status format) in addition to just changing the background color, so I retained those styles. Also threw in a transition on everything on the body (where most of the styles are applied); I thought linear looked better than ease in this case. The included styling is designed to work as best as possible with both new and “legacy” content (pre-post-formats-UI), to render as close to the frontend as possible.

Tested and should work with latest Chrome, Firefox, and IE 10.

comment:2 azaozz11 months ago

Bear in mind that styles in editor-style.css may behave unexpectedly and even break contenteditable mode. See #17154 about what Chrome does with font and line-height...

Generally "simple" styling like background-color, etc. are safe, not so sure about :before and :after, etc. This will need good testing in all supported browsers.

comment:3 celloexpressions11 months ago

  • Keywords needs-testing added

Good point. In the testing I've done so far, it's behaved shockingly well. I originally planned to only change colors, but when I forgot to remove some of the quote styling and it worked, I decided to see how well I could get them to work similarly to the front end.

I ran the editor through some fairly harsh formatting and unformatting in IE10 and couldn't hit any bugs. It works in each IE version down to 7, with the fallback simply not displaying the :before styling in 7 and 8 (UI-wise it's not bad with the left margin). I couldn't get it to corrupt the post contents html in any of those. I've also been unable to break it in Chrome 26 or Firefox 20.

I think the best way to see if it works is for a bunch of people who have no idea what they're doing and/or people who know where the bugs tend to show up try it out. If these editor-style.css components bring out more bugs, we could just remove the more obscure styles and cut it down to the colors, but if they work they definitely improve the UI, especially for the quote format. I think the fact that they're almost all on the body element probably helps.

I did notice that gallery placeholders still aren't displaying (in Chrome), but the issue persists with Twenty Twelve as well.

comment:4 lancewillett11 months ago

  • Milestone changed from Awaiting Review to 3.6

comment:5 lancewillett11 months ago

I think we should go with background color and typography only (not the icons).

What's the transition for?

comment:6 celloexpressions11 months ago

The transition is to make it look and feel better; in this case the PF UI uses lots of transitions so not having the transition here makes format switching kind of jarring, especially considering switching from, for example, standard to quote where size, font-style, color and background color all change. I would advocate for putting more transitions in the theme itself, but I think those design decisions were already made. The short reasoning is that the brain doesn't like sudden changes, there's always some sort of a transitioning movement in the physical space, for instance.

I think it works well with just the colors and typography; those are the primary things that people will want to add their own styles to in the editor (ie, adding italics to one part only to find that the whole quote is in italics, or changing a font color to red only to find a red-orange background color on the front end).

The decorative iconography of the status format is entirely unnecessary here, although we probably should maintain the smaller width. I would say that the quote icon is fairly important because it helps visually guide the user through the UI, although mimicking the changes in #24332 would probably change that, so it may not work to do that. I guess my primary goal with the editor styles would be to make previewing the post for formatting concerns unnecessary, but we're getting pretty close anyway. Also, if using :before does work (as it appears to), this would be a good opportunity to show theme devs that you really can do amazing editor styles that complement the PF UI. But I understand the concerns of the potential for it to break.

celloexpressions11 months ago

Colors and typography only, slightly faster transition

comment:7 celloexpressions11 months ago

New patch removes the icons, and updates the quote format. It now pushes users to use blockquote (as there's no other good way to denote the quote in the editor styles), and I think the quote distinction is clear enough without the icon. Transition is also slightly faster, more like the PF UI transitions.

comment:8 mercime11 months ago

  • Cc mercijavier@… added

comment:9 follow-up: obenland11 months ago

First of all, thanks for ruining a surprise, celloexpressions!
We had a patch for that prepared and I asked Lance to wait until the very last possible moment to commit it, so we'd have a fun surprise after launch.

But - like I found out after the initial core commit of Twenty Thirteen, when all the things we knew of that still needed work were pointed out and trac'd within the first day and a half - the WordPress community is just too good to let details like this go unnoticed! :)

The only thing I'm not too excited about in the existing patch is the transition, to be honest. It makes switching between formats seem slow and sluggish to me and it doesn't feel as responsive (in context of triggering the action) as it does without the effect. Also: We don't know for how long the PFUI will use a transition etc, so it would be one more thing to maintain.

obenland11 months ago

Adds styles for blockquote cites and adjusts anchor color to what we use in .entry-content.

comment:10 lancewillett11 months ago

  • Keywords needs-testing removed
  • Type changed from defect (bug) to enhancement

comment:11 lancewillett11 months ago

In 24308:

Twenty Thirteen: first pass to add post format visual styles to visual editor. Props celloexpressions and obenland, see #24308 and #24298.

comment:12 in reply to: ↑ 9 celloexpressions11 months ago

Replying to obenland:

We had a patch for that prepared and I asked Lance to wait until the very last possible moment to commit it, so we'd have a fun surprise after launch.

Haha, I knew something was up since it seemed like such an obvious improvement!

In terms of the transition, I would be surprised if the PFUI ever removed it because it's very important to make the change less jarring. Mark Jaquith linked this article on make/ui in explanation of the animations. I think the issue here is that with the potential for so many elements to change at once, animating the color/font changes helps; though since the size and position of the editor transition, perhaps it's okay.

lancewillett, I see you included the iconography in the commit; I'd say keep it if it works. The updated quote format styling (accounting for content-before-quote) didn't make it in though, so that case doesn't work, although putting only the quote in the editor, without blockquote, works and is the implied intended use.

azaozz11 months ago

comment:13 follow-up: azaozz11 months ago

TinyMCE picks the background-color from the body and applies it to the "Formats" drop-down (first on the second toolbar row). Unfortunately this only happens on init, so the background-color doesn't change when the body background-color changes on switching formats. This makes that drop-down look strange.

As much as I hate using !important, don't see another workaround for this.

Version 0, edited 11 months ago by azaozz (next)

comment:14 in reply to: ↑ 13 lancewillett11 months ago

Replying to azaozz:

TinyMCE picks the background-color from the editor (iframe) body and applies it to the "Formats" drop-down (first on the second toolbar row). Unfortunately this only happens on init, so the background-color doesn't change when the body background-color changes on switching formats. This makes that drop-down look strange.

As much as I hate using !important, don't see another workaround for this.

That's a bummer ... looks like your patch is necessary, then.

comment:15 azaozz11 months ago

Actually there is a setting (undocumented) to specify which styles are imported when TinyMCE creates the menus. Better to use that.

comment:16 azaozz11 months ago

In 24341:

TinyMCE: don't import color and background-color from the content when creating menus that have preview capabilities.

Fixes a visual glitch: when post formats styling is added in editor-styles.css, it is applied to the menus and not reset after changing format. See #24308.

comment:17 lancewillett11 months ago

In 24343:

Twenty Thirteen: fix up Quote styles for the visual editor, see #24308.

comment:18 lancewillett11 months ago

  • Keywords close added; has-patch removed

Once RTL is refreshed, we can close both this and #24298.

comment:19 lancewillett11 months ago

  • Resolution set to fixed
  • Status changed from new to closed

comment:20 follow-up: azaozz11 months ago

After removing the PF UI we are not going to save post formats in autosave and revisions. This introduces an inconsistency when showing previews for published posts or for authors different from the original post author.

As the post format is not in the autosave we cannot set it on the preview, so changing post format and previewing the post will still show the old format. This is not a regression from 3.5, however the newly introduced styling of TinyMCE according to post format makes this worse.

Not sure what would be best here. The patch on #24455 removes the TinyMCE body classes for PFs, leaving it the same as in 3.5. The other option would be to keep the PF classes and save post_format on autosave and in revisions.

comment:21 azaozz11 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:22 obenland11 months ago

FWIW, the Post Format specific styling of TinyMCE was removed in r24391.

comment:23 in reply to: ↑ 20 celloexpressions11 months ago

Replying to azaozz:

The other option would be to keep the PF classes and save post_format on autosave and in revisions.

Much better from a user's perspective if we could keep the classes and keep post_format in autosave and revisions. It would be very confusing with Twenty Thirteen if the preview displayed as a different format than updating/publishing, since the different formats have such different looks. It probably wouldn't be too much to change the class in the editor when changing formats with the old UI either; that plus the proposed additions of small icons would make the old UI much more usable (and likely to be used) with Twenty Thirteen.

Yes, the editor styles were already removed from Twenty Thirteen, but I'd like to see them added back if there's any way to make that work.

comment:24 azaozz11 months ago

Yes, we can pass the post format as a query arg and set it when showing a preview. Didn't want to hijack this ticket, opened #24483 for this.

comment:25 lancewillett10 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Closing as the changes to keep the post format class in preview is now in #24483.

comment:26 celloexpressions10 months ago

  • Keywords has-patch added; close removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Now that the post format classes are back in the editor, I suppose we should add the post formats styling back here.

Coming patch restores the styling we had and includes a few changes that were made after the removal of all of the new post formats stuff. Biggest change is with the audio format, which matches the current front-end design (by the way, is the extra container .audio-content intentional? It's not needed; both the dotted line and the audio icon can be done together, as they are here). The audio changes shrink the content width considerably, so should be reflected in the editor as well. I also added the box-sizing declarations; it was needed for the audio changes and might be a good idea to include in the editor for consistency anyway.

celloexpressions10 months ago

Restore Post Format styling in TinyMCE, update audio format layout

comment:27 obenland10 months ago

  • Keywords commit added

Patch looks good - and works!

comment:28 lancewillett10 months ago

Will the universal box-sizing cause problems in the editor layout? We didn't need that in the previous editor styles. Could we remove that?

comment:29 azaozz10 months ago

Will the universal box-sizing cause problems in the editor...

I would rather not have it inside TinyMCE. The CSS loaded there affects how the editor works in some cases and may trigger bugs, even in future versions of the browsers (looking at Chrome). So the simpler the styling is, the better. Also the universal selector * is quite problematic in many cases.

comment:30 lancewillett10 months ago

  • Owner set to lancewillett
  • Resolution set to fixed
  • Status changed from reopened to closed

In 24512:

Twenty Thirteen: add editor styles for post formats back in. Props celloexpressions, closes #24308.

comment:31 celloexpressions10 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

One more little tweak: we need to account for the padding in the width for the audio and status formats since we aren't using box-sizing: border-box. Otherwise, the widths (and line breaks) are inconsistent with the frontend.

celloexpressions10 months ago

Fix audio and status format max-widths to account for their padding

azaozz10 months ago

comment:32 azaozz10 months ago


Seeing this sometimes in both Chrome and FF on Win7. Seems the font is missing/not recognized until the user loads the front-end. Also there is always a vertical scrollbar and box-sizing doesn't affect it. Maybe make the height in .post-format-audio:before 97%?

comment:33 follow-up: nacin9 months ago

Seems the font is missing/not recognized until the user loads the front-end.

Shot in the dark: iframe issue? Chrome won't load the font, but is willing to pull from browser cache?

Sidenote, as I commented to #24595: I'm all for editor styles but I'm not sure if the background color being used for reading is always going to be as conducive for writing?

comment:34 in reply to: ↑ 33 celloexpressions9 months ago

I can't reproduce the Genericons issue; [24541] seemed to resolve everything there for me (even on a clean install of FF on Win7).

Looks like .post-format-audio:before{ height: 97%; } does the trick for the scrollbar. Weird it needs to be 97 though (vs 99).

Replying to nacin:

Sidenote, as I commented to #24595: I'm all for editor styles but I'm not sure if the background color being used for reading is always going to be as conducive for writing?

The only formats that might be questionable would be audio/video, but I think they're okay. And these formats are less likely to have as much text/writing involved.

If we don't think they're appropriate for writing then we may need to reconsider whether they are for reading. They are different tasks, but the consistency is really important for users (especially new users) and helps with discovery of one of the best features of Twenty Thirteen. And if the colors do bother some users (I'm guessing more power-user-types), they can always write the post as a standard post then change the format for publication. Then they're mostly just reading/tweaking with the publication colors, but they can still do so in the editor and have it match the frontend.

celloexpressions9 months ago

Fix audio:before height and audio/status max-widths

obenland9 months ago

Takes a different approach to avoid magic numbers.

comment:35 follow-up: obenland9 months ago

Added a patch that addresses the height issue with the dotted line background and the content width for audio post formats (also reorders some attributes).
I decided to remove the decoration in RTL as there was really no good way to make it work.

comment:36 in reply to: ↑ 35 celloexpressions9 months ago

Replying to obenland:

Added a patch that addresses the height issue with the dotted line background and the content width for audio post formats (also reorders some attributes).
I decided to remove the decoration in RTL as there was really no good way to make it work.

Definitely a step in the right direction, but now content wraps below the audio icon and dotted border if the post is taller than the editor. I think the only way to avoid it is with the absolute positioning, but that does require the additional max-width. Or alternatively the content wrapping below could be done by design with a fixed height for the decoration; that would allow us to remove an extra wrapper on the audio format on the frontend (div.audio-content)...

Status format works well now, though.

comment:37 follow-up: Joen9 months ago

  • Cc asmussen@… added

I've been thinking about this. While there's an argument to be made that a visual editor that shows pretty much exactly what you'll see on the site is as WYSIWYG as you can get, I would say there's also another side to the argument. Powerful as TinyMCE is, it's never going to be 100% WYSIWYG — the gallery is just an example of that. Couple that with what Nacin suggests, that the process of writing is a different mindset than consuming, I'm leaning towards removing the background colors and keeping text and links consistent across all the formats.

For a third reason as well: from day one I've hoped we could make it super easy to customize those colors, if not through a plugin then perhaps simply through CSS (example: http://joen.wordpress.com/2013/06/13/twenty-thirteen/). If the editor colors were baked in that could get confusing.

comment:38 in reply to: ↑ 37 ; follow-up: celloexpressions9 months ago

Replying to Joen:

I've been thinking about this. While there's an argument to be made that a visual editor that shows pretty much exactly what you'll see on the site is as WYSIWYG as you can get, I would say there's also another side to the argument. Powerful as TinyMCE is, it's never going to be 100% WYSIWYG — the gallery is just an example of that.

So just because we can't be 100%, we shouldn't be as WYSIWYG as we can? I think at the moment we're pretty close. Because the colors are so bold, not having them would put us pretty far away. A lot of newer/less experienced users use TinyMCE to change the text color on posts, not having publication colors wouldn't give them the proper context to know what a bad idea that is.

Couple that with what Nacin suggests, that the process of writing is a different mindset than consuming, I'm leaning towards removing the background colors and keeping text and links consistent across all the formats.

They're definitely different processes, but whether background color matters in uncertain. I can't find any research on this subject, so If we think it could be an issue I think we should do some user tests to confirm. I'm not quite sure how to test this, but I think we can come up with something better than just guessing or assuming. A good test would probably need to check efficiency while typing against several different background colors, then compare that to the same tests on a white background color.

For a third reason as well: from day one I've hoped we could make it super easy to customize those colors, if not through a plugin then perhaps simply through CSS (example: http://joen.wordpress.com/2013/06/13/twenty-thirteen/). If the editor colors were baked in that could get confusing.

Users (on .org, at least) are probably most likely to be using a child theme if they're changing the colors with css. There's not much to doing the extra styles for the editor if they can get as far as setting up a child theme. Even if we removed the background and text colors, the link color would still be incorrect without adding some editor styles. That could almost be worse, since it's not right but it's not broken enough to bother doing it right.

And, I really like the argument that this is another touch that sets Twenty Thirteen apart (and encourages more inventive theming in general). At the end of the day it makes WordPress more fun to use and brightens up the visually bland post screen.

By the way, it looks like the Genericons-loading issue is only happening on WordPress.com.

comment:39 in reply to: ↑ 38 Joen9 months ago

Replying to celloexpressions:

So just because we can't be 100%, we shouldn't be as WYSIWYG as we can? I think at the moment we're pretty close. Because the colors are so bold, not having them would put us pretty far away. A lot of newer/less experienced users use TinyMCE to change the text color on posts, not having publication colors wouldn't give them the proper context to know what a bad idea that is.

That's not what I'm saying. I'm saying TinyMCE is always going to be an abstraction, no matter how much we try to wrangle it otherwise.

You make a pretty good argument about previewing the bold colors right on the backend. I'm not sure that's as important as you make it out to be though, since there's nothing short of a child theme or plugin that can change that background color, so I believe previewing the color in the editor may actually confuse or frustrate.

My word on this is not final, it's just an opinion. If I were to be overruled on this, I would not cry myself to sleep.

comment:40 lancewillett9 months ago

In 24706:

Twenty Thirteen: CSS fixes for visual post editor styles. Props celloexpressions and obenland, see #24308.

comment:41 lancewillett9 months ago

  • Keywords close added; commit removed

Anything else to work on for this ticket? Or can we close?

comment:42 lancewillett9 months ago

  • Keywords has-patch close removed
  • Resolution set to fixed
  • Status changed from reopened to closed

@joen and @celloexpressions Good arguments on both sides, let's keep the colors for now and see what feedback we get from customers using the theme after release.

Note: See TracTickets for help on using tickets.