Alternative color schemes and theme settings in editor styles

[bi0xid]

Hello there.

There is no support for links color change in editor-style.css.
If you change it in Theme Options, you will see the same:

a {
	color: #1b8be0;
	text-decoration: none;
}

As we want the editor to be WYSIWYRG, maybe we should include this change in editor-style.css too.

I have tried to do that with add_editor_style(), but it is only intended for .css archives.
I have tried to add it as a filter extending twentyeleven_print_link_color_style in mce_css and tiny_mce_before_init, unsuccessfully.

All ideas for what can I use to make tinyMCE read the options are welcome.

[nacin]

Let's see what we can do for this.

[studionashvegas]

The plot thickens... two different browsers, same thing happening. It won't show both bold and italic - one or the other, depending on which one I used first. ALSO, when I put the hyperlink in first, I can't see a hyperlinked bold OR italic text - it just hovers with an underline. Basically, I can only have bold, italic, or hyperlink, but not all three at the same time. (left side is chrome, right is FF, both on Ubuntu 11.04 with WP 3.2beta1)

[studionashvegas]

I know it's a LITTLE OT, but it looks like they are all (somewhat) connected with something happening in TinyMCE.

[studionashvegas]

Added ticket #17417 to combat this as well.

[iandstewart]

If we're adding the choice of custom link colors to the editor styles would we also add the styles for the dark color scheme option? I wonder if that might clash with the admin. That said, if we're going that route adding a declaration block to the head and a class (.dark) for the the dark colors would work.

[azaozz]

This is possible to do but will take some coding and serious testing. Currently the TinyMCE API doesn't support adding <style> in the iframe header, will need to add new functions for that.

[nacin]

Let's re-purpose this slightly. A theme's current settings -- layout, link color, and color scheme, in the case of Twenty Eleven, as well as background -- should likely be reflected in the editor style. That's basically a given. Now, the question is, how practical it is for writing, and for technical implementation.

If in 3.4 we were to introduce global support for a theme to register a color scheme, a corresponding editor style, link color, etc., ... perhaps?

[bi0xid]

Replying to nacin:

Now, the question is, how practical it is for writing, and for technical implementation.

I don't know for technical implementation right now. For writing, all of my users/clients have asked about it and I have done custom editor-style.css for all of them. We have them used to see what they are writing as the final visualization (that WYSIWYRG thing that came with twenty ten – ​http://2010dev.wordpress.com/2010/02/06/wysiwyrg/ –).

That's why I think it's a widely-liked feature. I think we have to try to maintain and improve the achieved things while WordPress changes focus and looks for the next goals.

[azaozz]

Replying to nacin:

Now, the question is, how practical it is for writing, and for technical implementation.

The technical implementation is to add another (PHP generated) <style> tag in the editor's iframe. As that iframe is generated with JS, the <stile> tag should be generated with JS too (not very hard).

The problem is with standardization. Adding a variable, core generated styles to the editor may interfere with some themes editor_style.css. I've seen wildly different styling in some editor_style.css files, thinking best would be to try and standardize what can be added there and what shouldn't. Then we can safely implement this.

[chriscct7]

Is this still a valid concern post-3.8's MP6 redesign?

[SergeyBiryukov]

Replying to chriscct7:

Is this still a valid concern post-3.8's MP6 redesign?

This doesn't seem related to admin color schemes, it's about reflecting the theme's alternative color schemes in editor style.