DFW: text unreadable

[iseulde]

When the theme sets the background to a dark colour and the text to a light colour, the text in DFW is unreadable. This can probably only be solved by setting the same background colour in DFW.
To reproduce, activate the Twenty Thirteen theme and switch to the quote post format. Enter DFW and you'll see that the text is very difficult to read.

[Ipstenu]

Removing transparent corrects that without any (apparent) adverse effects

[Ipstenu]

Interestingly, it's the background of TRANSPARENT that does this in the DFW editor. I removed the line and tested on both light and dark backgrounds and it appears to work.

[helen]

Replying to Ipstenu:

Interestingly, it's the background of TRANSPARENT that does this in the DFW editor. I removed the line and tested on both light and dark backgrounds and it appears to work.

Does that mean that part of the screen is one color and the editor area is another? Screenshot with a dark background?

[Ipstenu]

Without the change, the DFW editor background is always white. WITH the change it properly inherits the background color from the Theme CSS. Light bg is light, dark is dark.

The surrounding background, outside the text field, remains white. So that matches how it looks on the regular editor.

[iseulde]

I think we should make the whole background coloured, I don't think it would look okay otherwise. We can detect the background colour, and the colour, add it to the overlay and colour the title.

[Ipstenu]

We *could* but we don't on the non DFW editor, and I was aiming for parity with that. If we did, we'd have to change all the colors, buttons too, which currently are not changed. Try the diff I attached and see how it feels, though.

[iseulde]

Maybe something like this?

[celloexpressions]

Note that, in the Twenty Thirteen editor styles, the background color changes as users switch the post format. So I'd guess that something like 28330.2.patch​ probably wouldn't work unless it accounted for that as well.

That being said, it would look a lot better with the full-screen approach. The dashed border would need some sort of color-adapting as well, though.

[iseulde]

Replying to celloexpressions:

Note that, in the Twenty Thirteen editor styles, the background color changes as users switch the post format. So I'd guess that something like 28330.2.patch​ probably wouldn't work unless it accounted for that as well.

You can't change the post format in DFW, and the colours are recalculated whenever you enter DFW.
The patch has been tested with Twenty Thirteen.

That being said, it would look a lot better with the full-screen approach. The dashed border would need some sort of color-adapting as well, though.

The patch changes the dashed border based on the color of the editor body with 0.5 opacity.

[celloexpressions]

Should've actually tested the patch :) Looks like the border color part isn't working for some reason (it's always #ccc, but flashes darker sometimes), but it actually looks fine anyway. And the full-screen color looks considerably better, so I'd say we should go for that approach. (the toolbars remain on a white background, just the content area is changed, for those following along). I also needed the background: transparent; from 28330.diff​, in addition to 28330.2.patch​, though.

[iseulde]

Replying to celloexpressions:

Looks like the border color part isn't working for some reason (it's always #ccc, but flashes darker sometimes), but it actually looks fine anyway.

Weird, I'll take a look again later.

I also needed the background: transparent; from 28330.diff​, in addition to 28330.2.patch​, though.

28330.2.patch​ extends 28330.diff​. You may need to empty your browser cache for that file.

[celloexpressions]

Testing again, I think the following is happening with 28330.2.patch​ applied:

• When the DFW controls are supposed to be shown, the border color is correct.
• When the DFW controls should fade out (I think I remember them doing that?), the border color fades to #ccc instead (controls do not fade out).

Not positive how that's supposed to work, but something isn't quite right here regardless.

[iseulde]

Just using the color for the border-color is simpler... See patch .3. If we want some opacity though, we need to do it like patch .2. I think, to solve celloexpressions issue, we just need to remove the important or add an important to background-color: transparent. But again, not necessary when we go for patch .3. I'm don't mind using the full color instead of the color at 0.5 opacity.

[markjaquith]

Patch .3 seems to work quite nicely. Any objections to just going with that?

[markjaquith]

In 29340:

Match background color in DFW and adapt the dashed outline color.

fixes #28330. props avryl, ipstenu.

[azaozz]

Not feeling much "distraction free" any more... Maybe better to force the text color to #333 and keep the background as it was before (the "global" admin background)?

[markjaquith]

What's the distraction? That it's not greyscale? Might not forcing a text color lead to other editor style clashes?

[azaozz]

What's the distraction? That it's not greyscale?

Yeah, the strong background color looks pretty "strange", especially in a full-screen browser window on a larger 24" - 27" monitor. Also has nothing to do with how it is going to look on the front-end.

On top of that the Text editor has the default colors, making it look even more "strange" :)

[azaozz]

When DFW is open the html element inside TinyMCE gets a class wp-fullscreen which can be used to set or reset all colors. Both core and the themes can use that to keep DFW nice looking and distraction free.

28330.4.patch reverts the forced background color and adds default text color for DFW.

[azaozz]

This also breaks/throws JS error when TinyMCE is not used or not initialized, i.e. when the Text editor is the default and the user opens DFW.

[azaozz]

In 29533:

DFW: revert applying the Visual editor body color and background-color for now. Set the color to #333 and the background to transparent. Fixes #28330.