DFW needs to use theme-defined editor styles

[markjaquith]

Right now DFW is not using theme-defined editor styles.

[aaroncampbell]

Looking at the font using firebug the issue seems to be that both editor-style.css and content.css both define the font using * {} and since content.css is included later it take precedence.

[duck_]

Attached patch to switch order of CSS includes -- full screen CSS before the editor-style.css. This allows editor-style.css styles with the same specificity to take precedence.

Need to modify the minified editor_plugin.js for testing since TinyMCE never includes the .dev.js versions of plugins.

[aaroncampbell]

Works for me with Twenty Eleven on FF4, Chrome 11, Safari 5, and IE 9.

[aaroncampbell]

What I thought was an unrelated IE9 issue seems to be caused by this patch. The background color gets messed up: ​http://i1187.photobucket.com/albums/z397/aarondcampbell/dfw-IE9.png

[azaozz]

I was originally against using editor-style.css in Distraction Free mode since the theme can make DFW useless. IMHO in DFW it's more important to have nice readable fonts with nice line height and constant background color. That's what makes it "distraction free", it should be easy on the eyes.

Also some themes set the editor body width through CSS which makes the keyboard shortkuts for setting the width useless.

The current way of including the theme's editor-style.css but overloading it with nice predefined styles is a compromise to let the theme style some aspects only. If the UX team decides that WYSIWYG is more important than the Distraction Free aspect in DFW, we can remove the extra stylesheet for it and let the theme take over completely. Will remove the keyboard shortcuts for setting the width there too.

[aaroncampbell]

It's just my opinion, but I would definitely prefer that the theme's editor styles persist (completely). I think a theme author should have the same control over DFW as the regular TMCE. If they screw something up then people will use a different theme.

[nacin]

Replying to azaozz:

I was originally against using editor-style.css in Distraction Free mode since the theme can make DFW useless. IMHO in DFW it's more important to have nice readable fonts with nice line height and constant background color. That's what makes it "distraction free", it should be easy on the eyes.

This was discussed ad nauseam and decided on in a dev chat like a month ago.

If anything, JavaScript should detect the background color defined by editor-style.css and set the rest of the canvas to the same color. Otherwise, DFW should accept editor-style.css completely. There should also be a way to target, via CSS alone, DFW in editor-style.css. That way using a single stylesheet, someone can offer editor styles that are tweaked for DFW vs Visual.

[azaozz]

Replying to nacin:

This was discussed ad nauseam and decided on in a dev chat like a month ago.

Yes, I remember some discussions there but think it was decided to not let the theme set background-color, color, body width, etc. i.e. any styles that would break DFW (or perhaps I missed it).

If anything, JavaScript should detect the background color defined by editor-style.css and set the rest of the canvas to the same color.

This is probably doable. Would have to change all colors in DFW: toolbar, word count, etc. But what about switching to the HTML editor in DFW? Are we resetting all colors to default (as themes don't style the HTML editor) or are we keeping all changed colors?

Otherwise, DFW should accept editor-style.css completely. There should also be a way to target, via CSS alone, DFW in editor-style.css. That way using a single stylesheet, someone can offer editor styles that are tweaked for DFW vs Visual.

Accepting editor-style.css completely may change DFW drastically making it distracting, show horizontal scrollbar, etc. The problem is that some themes would need to be upgraded in order to work properly there. So the question is: do we make DFW work everywhere or let it break/look bad for themes that are very aggressive in styling the editor.

[nacin]

Replying to azaozz:

Replying to nacin:

This was discussed ad nauseam and decided on in a dev chat like a month ago.

Yes, I remember some discussions there but think it was decided to not let the theme set background-color, color, body width, etc. i.e. any styles that would break DFW (or perhaps I missed it).

Per IRC discussion, the opposite was decided.

If anything, JavaScript should detect the background color defined by editor-style.css and set the rest of the canvas to the same color.

This is probably doable. Would have to change all colors in DFW: toolbar, word count, etc. But what about switching to the HTML editor in DFW? Are we resetting all colors to default (as themes don't style the HTML editor) or are we keeping all changed colors?

Might as well keep changed colors. Will need to bring over body text color too then.

Accepting editor-style.css completely may change DFW drastically making it distracting, show horizontal scrollbar, etc. The problem is that some themes would need to be upgraded in order to work properly there.

Yes.

So the question is: do we make DFW work everywhere or let it break/look bad for themes that are very aggressive in styling the editor.

The latter.

[markjaquith]

Patch looks good in Chrome. Can someone figure out what's going on in IE9?

[azaozz]

In [18103]:

Make DFW use the exact same style as the normal editor, remove width resizing in DFW as it would clash with editor-style.css for some themes, fixes #17644

[azaozz]

Replying to nacin:

Couldn't find the IRC logs for when exactly this was decided, but hopefully there was some UX feedback then.

[azaozz]

In [18104]:

Remove reference to wp-fullscreen-content-css, see #17644

[azaozz]

In [18108]:

Set DFW background color to match the admin theme's background, see #17644

[nacin]

Replying to azaozz:

remove width resizing in DFW as it would clash with editor-style.css for some themes

-1 to the nth degree. What would it clash with? We're adjusting the width dynamically. If it clashes for some themes, then the theme should address that, and the user will know when they try the shortcuts that it'll look poorly.

[markjaquith]

Yeah, the resizing shouldn't be removed. We'd decided to have width resizing so that people could make better use of the space they have in DFW. The editor style will set the default.

[azaozz]

Replying to nacin:

-1 to the nth degree. What would it clash with? We're adjusting the width dynamically. If it clashes for some themes, then the theme should address that, and the user will know when they try the shortcuts that it'll look poorly.

Some themes have max-width on the editor body, having that renders setting the outer width dynamically completely useless (and may make the editor look weird/not centered, etc.). Unfortunately until we add specific DFW support in editor-styles.css themes cannot address that.

[nacin]

Could we not detect max-width? After all, we use it in Twenty Ten and will in Twenty Eleven.

[nacin]

For reference: ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2011-05-04

Starts at around May 04 16:15:30 +0000 2011 and continues in spurts for the next half hour. Conversation primarily involved nacin, markjaquith, westi, azaozz, janewells. Nearly everyone leaned in the direction I've outlined.

Also worth pointing out that in the same discussion, we agreed that Twenty Eleven's editor-style.css would be limited width, but that hasn't happened yet either. :-)

[azaozz]

Replying to nacin:

Could we not detect max-width? After all, we use it in Twenty Ten and will in Twenty Eleven.

We could (not very easy), but then what? Overwrite the CSS to remove max-width or disable DFW resizing? If we are going to overwrite the CSS, we may as well put back the extra stylesheet exactly as it used to be only limit it so it doesn't affect fonts, background, etc.

For reference: ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2011-05-04

Maybe I'm reading it wrong but I think we all agree there to add editor-style.css support but limit it so it doesn't change DFW drastically. From the comments above it sounds like it was agreed to make DFW completely match the normal editor (and I've missed it), so that's what I did.

[iandstewart]

In [18121]:

Twenty Eleven: editor-style should have max-width; Props bi0xid; Fixes #17393 #17649; See #17644

[azaozz]

In [18137]:

DFW: restore editor width shortcuts, restore limited overwriting of the theme styling in TinyMCE, show the toolbar on mouse move in TinyMCE, improve the help, fixes #17503, fixes #17644, fixes #17664, fixes #17596