WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 2 years ago

#17391 assigned defect (bug)

Alternative color schemes and theme settings in editor styles

Reported by: bi0xid Owned by: azaozz
Milestone: Future Release Priority: normal
Severity: trivial Version: 3.2
Component: Editor Keywords: needs-patch 3.3-early
Focuses: Cc:

Description

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.

Attachments (1)

Editor-CSS-Weirdness.png (132.0 KB) - added by studionashvegas 3 years ago.
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)

Download all attachments as: .zip

Change History (11)

comment:1 nacin3 years ago

  • Milestone changed from Awaiting Review to 3.2
  • Owner set to nacin
  • Status changed from new to accepted
  • Type changed from task (blessed) to defect (bug)

Let's see what we can do for this.

studionashvegas3 years ago

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)

comment:2 studionashvegas3 years ago

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

comment:3 studionashvegas3 years ago

Added ticket [17417] to combat this as well.

comment:4 iandstewart3 years ago

  • Cc ian@… added

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.

comment:5 azaozz3 years ago

  • Keywords punt added

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.

comment:6 koopersmith3 years ago

  • Keywords 3.3-early added; punt removed
  • Milestone changed from 3.2 to Future Release
  • Owner changed from nacin to azaozz
  • Status changed from accepted to assigned
  • Version set to 3.2

comment:7 follow-ups: nacin2 years ago

  • Summary changed from Links color in editor - twenty eleven to Alternative color schemes and theme settings in editor styles

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?

comment:8 DrewAPicture2 years ago

  • Cc xoodrew@… added

comment:9 in reply to: ↑ 7 bi0xid2 years ago

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.

comment:10 in reply to: ↑ 7 azaozz2 years ago

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.

Last edited 2 years ago by azaozz (previous) (diff)
Note: See TracTickets for help on using tickets.