Theme background shows in editor window

This happens because editors like TinyMCE implement their editing area using an iframe, which of course contains a body tag. That body tag gets whatever style is set on the "main" body tag because the theme stylesheets are by default included into that iframe's header. (If not, it would be more like a What-You-See-Is-Not-At-All-What-You-Get-Editor.)

In the case of TinyMCE, it adds an extra class to the body in the editing area called mceContentBody. You can use this class to override whatever styles your main body tag has.
You can also change this behaviour on the admin/settings/wysiwyg/profile/#/edit page (where # is the profile number). This should work fine for TinyMCE but might not work at all for other editors since I guess that part of the administration GUI was modeled after TinyMCE.

I think it would be really hard to make a generic solution for this problem as the editors create their editing area in different ways, some might not even use an iframe. Instead I think this has to be solved via custom code as the editor implementations mature.

I avoid this by using the Editor default CSS instead of the Theme CSS which can be configured in WYSIWYG settings (as described by TwoD).

Cheers,
Louis

This applies to all editors and many themes.

Another solution is to use an additional wrapper DIV for your page directly below the BODY, so you do not assign a background/margin/padding to the BODY, but to the wrapper DIV instead. That way, the BODY of the editor IFRAME won't inherit wrong styles like this.

Can someone add a new handbook page about this? Should be titled "Wysiwyg API Configuration" (following after the existing "Installation" handbook page).

I too have been running into this, and the fix suggested in #369422: TinyMCE text editor missing white background wasn't working for me. Seeing sun's comment above that this will happen in all editors, I thought about his suggestion. Not wanting to add another DIV, I simply changed my CSS.

The regular BODY tag gets the simple background: (#fff or whatever).

Then right below it, add body tags with the .front and .not-front classes, so that your regular page gets a CSS declaration that's more specific than the iframe, and therefore overrides it. .front and .not-front will cover every page in your site.

body {
(simple background CSS)
}
body.front, body.not-front {
(desired page background CSS)
}

Just another way to attack it using only CSS...a bit of a hack, I know, but aren't all these solutions? :)

That's a good hack, mschutz! And yes, most ways around this would be hacks to some extent.

We probably could make it so the editor implementations add an extra class or something to the editing area body so people could specifically target the editor instead of the other way around. But then we'd need to dig even further into the guts of each editor to know exactly when they update or recreate the iframe contents, which isn't always obvious. We still have to do this to some extent to know when to let Drupal plugins run their attach/detach routines, but then we're not messing with the editor's "template" so it's a bit easier.

Anyway, this will have to be something to consider for a future version if the workarounds here aren't enough. Documenting this annoyance and the workarounds will do for now. If someone hasn't made a handbook page on this yet, I'll put together a summary of what we have in this issue later.

I found the font in editor is smaller than the front-end.
As of comment #5, I revised all my theme css body class, revised as body.front, body.not-front

but smaller font in editor is still appear.

Any help ?

Can you check with Firebug in FF to see what makes the font smaller? It is perhaps some of the styles set internally by the editors, which you may have to override by creating style rules where the selector doesn't include body.front, body.not-front so that they just target what's in the editor.

I'm confusing how Drupal selecting the right css stylesheet.
My site use zen_ninexity theme.

In editor, the font size use the tinymce skin theme content.css which is higher priority of all css of my theme.
However in editor, the ul,li,ol,p tag use my theme reset.css which may different in margin, padding as of front-end.
Front-end use my theme html-element.css as higher priority them reset.css

It'a big head-ache to make front-end and editor css style consistent. ><

Who can provide your experience /tips to make both of them in consistency.

Drupal doesn't do any special CSS selecting.
If you've set Wysiwyg module to use the Theme's CSS on the editor profile page, it will include all the styles normally included on your pages (some problems may arise with modules which allow their colors to be changed by the users).

You need to somehow find selectors which can be more specific than those currently used in the editor. I don't know how to be of more help with this other than if I had access to your site. If you're willing to give me access, send a message via my contact form and I'll get back to you as soon as I have time.

What u mean of access my site ?
site url ? or drupal site login account ?

I cannot figure it out what more specific css selector should be.

I noticed that the zen_ninesixty theme reorders the stylesheets before writing them to the page, which is probably why the styles are not in the same order in the editor and the node page (Wysiwyg doesn't know it should do this).
Wysiwyg 2.x-dev now has a hook_editor_settings_alter which you can use to change the settings before they are sent to the editor, so I wrote a quick emulation of the reordering function in the theme. If you have a 'custom'* module where you do site specific customizations, implement hooks etc, put this code in the .module file and update to Wysiwyg 2.x-dev. There's no danger in running the -dev module on a live site, it doesn't interact with any other modules or database tables and is IMHO more stable than 2.0.

// This goes in custom.module, don't forget to create custom.info as well.
/*
 * Implementation of hook_wysiwyg_editor_settings_alter().
 */
function custom_wysiwyg_editor_settings_alter(&$settings, $context) { // Change 'custom' to match your module name
  global $theme_info;
  $framework_files = array();
  $other_files = array();
  if ($theme_info->name == 'zen_ninesixty') { // Change to the name of your theme
    // Emulate zen_ninesixty_css_reorder().
    if ($context['profile']->editor == 'tinymce') {
      $styles = explode(',', $settings['content_css']);
      foreach($styles as $i => $file) {
        if (strpos($file, 'framework') !== FALSE) {
          $framework_files[] = $file;
        }
        else {
          $other_files[] = $file;
        }
      }
      $settings['content_css'] = implode(',', $framework_files) . implode(',', $other_files);
    }
  }
}

@TwoD

I would like to say thank you.
As you said zen_ninesixty theme reorder the css file, then I studied it's template.php,
you are right, it has a function theme_css_reorder.
And it described why editor css go first because of the reorder css, module > framework > basetheme > subtheme

I'm curious, without this reorder function, what is the order of css being loaded in Drupal

I'll go a try with this new alter function.

update:
I added this alter function in my custom module but I still found problem.
since zen_ninesixty framework has text.css, reset.css for reset and text styling say h1,....h6, ol,ul, and I have my own text styling css html-elements.css, then I remove text.css and reset.css in my theme info file and flush all possible caches.

I digged in the source, text.css and reset.css are not included. However, the editor didn't use the html-elements.css for styling but using web browser default css ( I guess). I scroll down to the bottom of the css panel of firebug, and cannot find html-elements.css.

I'm not sure it is a zen_ninesixty problem or something else.

Thank you so much it was the proper direction! I have it fixed Thank You for your help!!!

Drupal 7 Using Wysiwyg with CKeditor 3.5

File paths I found in D7 Admin panel

http://www.mysite.org/#overlay=admin/config/content/wysiwyg

http://www.mysite.org/#overlay=admin/config/content/wysiwyg/profile/filt...

Editor CSS Drop dropdown menu > use Default OR use Use Theme

Cross-posting from #914618: CKEditor background:
If you're using CKEditor, you can tell it to apply a specific ID or classname to the body tag, to make it easier to target with CSS selectors:

function MYMODULE_wysiwyg_editor_settings_alter(&$settings, &$context) {
  if($context['profile']->editor == 'ckeditor') {
    $settings['bodyId'] = 'wysiwygEditor'; // This will set <body id="wysiwygEditor">
    $settings['bodyClass'] = 'wysiwygEditor'; // This will set <body class="wysiwygEditor">
 }
}

The bodyId and bodyClass settings are specific to CKEditor, but if other editors have similar settings it might be possible to set them via hook_wysiwyg_editor_settings_alter() too.