Some themes define CSS selectors that are not compatible with WYSIWIG. For example, 

.node p
{
 /* Some styles here */
}

Because textarea is within an iframe, and it's not a decedent of the div tag with class="node", the above style doesn't take any effect in WYSIWIG. Of course, if you preview, the content is included in the div tag, so you can see the correct style (but requiring preview is against the purpose of using WYSIWYG).

My question is, how people are dealing with such a situation. I happened to find this issue with async theme, but there seems many themes that uses similar CSS selectors.

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Title: Some CSS selectors in theme's style.css don't take effect in WYSIWIG editor » Theme CSS selectors do not apply to WYSIWYG editing areas (IFRAME)
Version: 6.x-2.2 » 7.x-2.x-dev
Component: Editor - CKEditor » User interface
Category: support » feature

There's no solution for this problem space yet.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

One alternative is to mimic the styles set by the theme in a new stylesheet made just for the editor, and tell Wysiwyg to include them via the settings under "CSS" when configuring an editor. It may take some time though if the theme has many of those style rules.

Another solution would be to change the template the editor uses inside the editing area, but that might take even longer and I don't know if it is even possible for all editors in a way that doesn't break some of its features.

bostonclimber’s picture

bostonclimber commented

Thank you sun and TwoD. I thought about making a new style sheet for the editor, but that would be hassle if I need to maintain the 2 style sheets (one for the regular view, one for the editor).

So, for now, I use a theme that doesn't have complicated selector under class='node' or id='content'. But it would be really nice if this issue is addressed sometime in the future.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

Well, we are of course open to suggestions, but it doesn't look like it can be completely solved.
Part of the problem - which is true for all occasions when one need a true WYSIWYG experience - is predicting where the contents will be rendered. Not all fields represent node or block bodies... It gets even more fun when adding Views or Panels to the picture. ;)

jdln’s picture

jdln commented

Subscribing, id love this feature too.

bryancasler’s picture

bryancasler commented

subscribe

FrequenceBanane’s picture

FrequenceBanane commented

subscribe

grasmash’s picture

grasmash commented

What if we were able to inject a css class into a wrapper element contained within the iframe?

For example, the wysiwyg editor would be rendered like this:

<div>
  <iframe>
    <body>
       <div class="injected-class">
          <!-- wysiwyg editor content -->
       </div>
    </body>
  <iframe>
</div>

To start, you could use a global class (set in the wysiwyg settings) to simply target all wysiwyg editors.
For instance, if you only use wysiwyg for the node body field, you could set the injection class to ".node" and force the editor to inherit descendants of ".node".

From there, you could permit users to specify classes on specific content types (for the body field), blocks, cck fields, views, or panels. Since all but the first of these rely on other modules, it may be best to simply create a hook which other module developers could use to inject an additional css class. This would be particularly useful for the cck module.

What do you think?

bostonclimber’s picture

bostonclimber commented

I love the idea of injecting a class. For me, it would be easier if there's a setting that can specify the class name (or default to 'node') because my main focus is just a regular node so far. A hook will also help experts.

If this is implemented, it'll be a strong reason to move D7 (assuming that it'll be implemented only 7.x version).

bewhy’s picture

bewhy commented

I have butted up against this a couple times when building sites for clients. To make things easy I've created a whole new css file specifically for text in which each element (p) also controls the ckeditor element (.cke_show_borders p). which results in stuff like:

p, 
#cont-col .content p,
.cke_show_borders p {
padding-bottom: 7px;
padding-top: 7px;
}

sure it's ugly but it keeps the clients happy that their wysiwyg behaves like a real wysiwyg