WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#17644 closed defect (bug) (fixed)

DFW needs to use theme-defined editor styles

Reported by: markjaquith Owned by: azaozz
Milestone: 3.2 Priority: high
Severity: normal Version:
Component: General Keywords: ux-feedback
Focuses: Cc:

Description

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

Attachments (2)

dfw-css-issue.png (8.3 KB) - added by aaroncampbell 10 years ago.
17644-wpfullscreen-js.diff (743 bytes) - added by duck_ 10 years ago.

Download all attachments as: .zip

Change History (26)

#1 @aaroncampbell
10 years ago

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.

#2 @duck_
10 years ago

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.

#3 @aaroncampbell
10 years ago

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

#4 @aaroncampbell
10 years ago

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

#5 follow-up: @azaozz
10 years ago

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.

#6 @azaozz
10 years ago

  • Keywords ux-feedback added

#7 @aaroncampbell
10 years ago

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.

#8 in reply to: ↑ 5 ; follow-up: @nacin
10 years ago

  • Milestone changed from Awaiting Review to 3.2

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.

#9 in reply to: ↑ 8 ; follow-up: @azaozz
10 years ago

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.

#10 in reply to: ↑ 9 ; follow-up: @nacin
10 years ago

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.

#11 @markjaquith
10 years ago

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

#12 follow-up: @azaozz
10 years ago

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

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

#13 in reply to: ↑ 10 @azaozz
10 years ago

Replying to nacin:

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

#14 @azaozz
10 years ago

In [18104]:

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

#15 @azaozz
10 years ago

In [18108]:

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

#16 in reply to: ↑ 12 ; follow-up: @nacin
10 years ago

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.

#17 @nacin
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#18 @markjaquith
10 years ago

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.

#19 in reply to: ↑ 16 @azaozz
10 years ago

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.

#20 follow-up: @nacin
10 years ago

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

#21 @nacin
10 years ago

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. :-)

#22 in reply to: ↑ 20 @azaozz
10 years ago

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.

#23 @iandstewart
10 years ago

In [18121]:

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

#2 @azaozz
10 years ago

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

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

Note: See TracTickets for help on using tickets.