Right now the wysiwyg editor is hard coded to be themed by the jquery.sceditor.elk.css file in the default theme directory. And the colors are hard coded. That means that variants can't modify either of these settings.
Should they be able to?
Although if offering a light and a dark theme colored text is going to be problematic in general unless the colors are carefully chosen.
Having now played with the sceditor on it's actual page, I strongly recommend that Elk move the "remove formatting" button next to the font family/size/color buttons as it's job is to remove those formats. I didn't realize this and kept clicking the color button trying to get it to turn off, which kinda works but not so reliably and it moves the mouse cursor etc. etc. I didn't realize that button was really the intended way to say "revert to normal".
Yeah coloured text (if you mean the BBC colour options) is a nightmare if you're offering a variety of themes. Quite honestly, if you want to offer your members a set of themes that have markedly different background colours, the best option really is to disable BBC coloured text in admin.
IMO coloured text isn't actually necessary in posts. It's mostly used by nutters who also want to use odd fonts and ALLCAPS. They are also the only people who will really complain if you disable it. Restricting people to the default font colour doesn't inhibit good discussions or good post presentation.
Anyway you should, I think, be able to add the relevant classes for other editor styling to your variant CSS file. I haven't played with it for ages but that is how it should be set up. Give it a go and see what happens. If it doesn't work, something will need to be changed.
ETA: Basically, variant CSS files should be loaded after all other CSS files.
Yeah I'm debating eliminating the color option. Maybe I'll leave red as one emphasis color.
I can style everything but the wysiwyg edit box itself with the custom.css file. But the wysiwyg is loaded in an iframe and the theme hands it a css file to use for styling outside it's default. I don't think there's anyway I can alter that without using javascript to reach into the editor iframe contents. I'm happy to be shown I'm wrong though.
TBH I never tried custom.css because that was only introduced recently. If the wysiwyg can't be styled on a per variant basis at the moment, that will need to be fixed. It should be easy enough to fix it.
If nothing else works, just removing all colours from the editor CSS file and only defining them in the variant files should do the trick.
Oh about this. I did have an idea a while back about using classes rather than colours for the BBC colours. That way, it would be possible to use (for example) a slightly different red on different themes/variants by defining the hex code for that class in the CSS. AFAIK that idea was never put into practice, but it's certainly feasible. Probably overkill though.
Here's where the css for styling the wysiwyg editor iframe is supplied to sceditor. It could certainly be set up where it checks the variant for a local css file and not finding it uses the default. Or simply just require a variant to have a version of this css file.
$("#', $editor_id, '").sceditor({
style: "', $settings['default_theme_url'], '/css/jquery.sceditor.elk.css",
So that's why a changes the custom.css doesn't help. It's not being passed to that iframe.
The classes for colors is a good idea.
Probably the simplest way is just to add a call to the variant file after the standard one, if that'll work.
ETA: Oh bugger, that still wouldn't work for a custom theme that didn't have variants. Bleh.
Hmm, this is not good. You can't have all themes running default theme CSS for the editor. Wont work. Needs another solution. This really should be moved to the Bug Reports board. I'll open an issue on GitHub too.
ETA: https://github.com/elkarte/Elkarte/issues/1510