if your altering editor.css then your telling the editor what to do. That has nothing to do with joomla.
Closing as this is not a Joomla issue

This is a perfectly valid issue and should be re-opened.

The problem is that the editor uses the style in the menu itself. This clearly causes problems in various cisrcumstances such as the reported issue of the textbeing white but it will also be an issue if the text is too big.

It is not normal that the menu item is displayed in the style that it will generate.

using the editor.css to ensure that the content in the wysiwyg editor is displayed correctly is the recommended and desired behaviour. It should not also change the display in the menu.

Please re-open

Reopen due to previous comment

Honestly it might be desired behaviour that the editor.css is only applied to the content of the editor automatically, but practically more complicated than just writing the right CSS.
Prefixing every selector with .tox-edit-area will do the work easily. Someone who knows to write CSS should know how to apply it only to the editor.
I would see the file editor.css only as a good way to separate this custom CSS from other CSS.

So it is either writing it the prefixed way or having a script to generate a new prefixed CSS file.
The latter idea seems to be too error prone.

So I would close this issue with the recommendation to use the CSS prefix for the text area.
Maybe adding a editor.css.txt with some prefixed examples could help.

To use the above example:

.tox-edit-area a.button {
    color: white;
}

will do just fine.

Same goes for the toolbar with .tox-toolbar-overlord.
This is TinyMCE, not FancyMCE, whoever wants a FancyMCE should do the CSS in editor.css the right way.
In my humble opinion, Joomla should not mess with a clean TinyMCE interface.

@StefanSTS sorry to say but you misunderstood the issue completely

If I add something like
a.button { color: red; }

to the editor.css then it will be added as a selector to the menu

Your code prefixing the css will not addd the selector to the menu

The objective here is to add the selector to the menu but NOT to give it its style in the menu so that it is actually visible

I suggest we just consider a proposal to style the format menu items as indicated in the styles. But in order to see the white text, I propose to conduct an experiment on the styling of menu items only in the following styles.

• Color
• background-color
• background-image
• text-shadow
• text-decoration
  .
• WITHOUT size-font

This will work similarly in MS Word, where we see the style of the menu item exactly as the future text will look. I suggest considering this task not so that the inscription is visible, but so that it is also very convenient in the future. I'll do a test PR myself. And we will test, tell me in which file is the logic? I couldn't find it. If this offer is bad, we will return to black and white inscriptions after testing.

WYSIWYG - the essence of this name is to make it look like we are writing.

Hi Brian,

thanks for the clarification. I tried to change the editor.css and saw no change, so I did not suspect that a CSS file would generate the menu. Maybe it was a cache problem or with the min file I renamed.

To find out why and how this is applied it would be good to know where that happens.
korenevskiy wrote:
"If they tell me in which file it can be corrected, then I will correct it in my free time, and we will test everything together. I couldn't find through a content search where this code is located."
Maybe someone could give a hint so he'll find the responsible code that generates the issue.

You wrote that
a.button {color: white;}
creates an entry, but
.tox-edit-area a.button {color: white;}
not.
Maybe a combined CSS would do the trick?

a.button {color: white;}
.tox-toolbar-overlord a.button {color: white;background:menu-bg-color}
.tox-edit-area a.button {color: white;background:article-bg-color}

First rule to create the menu item, the others to apply the style. Since they are more specific, they should override the first rule.

@StefanSTS the work of these styles should not be complicated. We don't make these styles for ourselves. We, as programmers, will not find any difficulty in this. But the rest will not use it if it is false. To be honest, I myself will forget in six months, when I will be engaged in another project altogether.
I think using a chain of parent classes is bad.

@korenevskiy
Using a chain of (parent) classes is the basic of CSS, and if you work in an editor that is part of an HTML document and you want different styles in different parts of the document, this is the way to go.
Even if you manage to have a different way to set up the colors for different parts, it comes down to generated CSS that needs to be applied to those areas.
Using a chain of classes is not "bad".
Having a CSS file and let it make three things at once, create menu items and apply style to two independent areas, that might be considered bad if it leads to undefined behaviour.
One rule is set here to apply style to two different areas. Sure this doesn't work out all the time as we see.
If it was on me, those additional menu items would be defined by an XML or JSON file and only the style would be kept in editor.css.

@StefanSTS
More than 10 years ago I wrote a website with an interactive map of the city. On which the user could select an area of the area and view the rental housing. I have experience in development.
You and I will easily cope with the parent classes for the text editor. But we are not doing this for ourselves programmers. And for people with little experience. It should be borne in mind that this editor.css file is not part of the interface, but is a stylization only in the editor of the materials manager. This means that its format should be simple. Of course, if this format can already be used with a chain of parent classes, then that's exactly what I'll do to my client tomorrow. And everything will work. Thanks for the information, I'll take a note. But for people and for me in the future (in the future I will forget about the chain) I would suggest finding the right solution so that you can use it without chains.

If it was on me, those additional menu items would be defined by an XML or JSON file and only the style would be kept in editor.css.

Our community is still unable to decide in what format to store the date in XML. And you already offer to store a list of styles in XML. How did you think to propose to implement it? An elementary student makes a website for his airplane modeling circle. He goes to the Joomla help site, and there is an instruction written on 5 monitor screens. With a description of how to create XML, and how to map XML to CSS, while we break the rule of programmers "Everything that can be done simply, should be done simply".

The editor.css seems to be made for people that know what they do.
Beginners will use the editor as it is and be happy with it.

From my point of view, TinyMCE ist just a tiny MCE, that should be kept and treated as a tiny MCE. Leave the fancy stuff to other editors. Just my opionion.

If the suggested way with the chained CSS works for you, please leave a note, maybe someone is willing to write a line in docs.joomla.org, so interested users can just copy and paste some CSS.

You are right, the site should be made by people who understand this. And in general, we want competent people to do any business. These are our dreams, we want to have smarter children, relatives, directors, presidents. But in fact we have what we have. We have those who at this moment can do something useful, not ideal, but do something. And therefore, the sites will be made by little competent people. And also, as a website creator, I will eventually forget about these features of the site. There are people who repair websites every day, and there are people who do it once a year, because they are the owners of the site, but they do not want to waste time studying references.

a.button { color: white;}
.tox-toolbar-overlord a.button {color: BLACK;background:menu-bg-color}
.tox-edit-area a.button {color: BLACK;background:article-bg-color}

I just tried this code in editor.css.
It didn't work out for me, it doesn't work. The format menu item is still white. Of course I updated the cache.

Thanks for testing, @korenevskiy. That means the cascaded rules are ignored.
Then it might need a change in core to use those.

a 2 second look at the editor would show you that you cannot achieve what you want just by using an editor.css change because of the way that tinymce is formatting the menu items with inline styles and not classes.

To achieve what you want to do you need to look at the available options in the API for tinymce (not joomla) and then when you find what you need you need to implement that in the joomla tinymce plugin displaytrait.

Hint: you are probably looking for the tinymce 'preview_styles' settings https://www.tiny.cloud/docs/configure/editor-appearance/#preview_styles

@Hackwar its a feature not a bug imho

Yes, yes, Linus Torvalds said that if everyone starts using the bug, then the bug becomes a feature. ?
ok. In our case, it needs to be corrected.

I never would expect a .css statement to become a menu entry.

@N6REJ you might not expect it but it has been the default behaviour for 16 years

@korenevskiy For your case you might want to try the second and third rule above in custom CSS of your backend or frontend template. Depending on, if you use the editor in FE or BE.
I expected the editor.css to be at least loaded as a CSS file, but seems it's just used for generating the menu.

I expected the editor.css to be at least loaded as a CSS file, but seems it's just used for generating the menu.

no it is not

@brianteeman This is nuts. Is this tiny doing this?
using a .css to generate things other then applying styles is insane.

@N6REJ how else do you think the editor is able to display a visual representation of those styles or to add new ones to the menu. I am shocked that someone who has used Joomla since the beginning has never noticed or taken advaantage of this

Just because people haven't seen it and therefore don't know. Let's remember that how people demanded the functions in MS Word that were in it.
Have an idea, But what if you place a text file of formatting styles in the template folder? But it should be done so that this file is installed when installing Joomla, but it does not overwrite when updating. In this case, there will be more creators who will stumble upon this file using content search.
But it would also be nice to add default styles for links in the form of buttons. Maybe someone will come up with more styles for tables, lists.
If you have any ideas, write.
Maybe we'll come up with something valuable.

@N6REJ When was the last time you searched for class names in files by content?

@brianteeman I've always used it to add styling NOT to add content.
My brain doesn't say "Hey I need to add a menu item so lets alter a .css file"

@korenevskiy exactly, never

@korenevskiy exactly, never

Which editor do you use? Does this function even exist there?

I think I found all the magic in this file.
\media\vendor\tinymce\themes\silver\theme.js
But it has 35,000 lines. ?

Does anyone know how directories differ?
\media\vendor\tinymce\themes\mobile\
\media\vendor\tinymce\themes\silver\
In the settings of the TinyMCE editor plugin, I did not find a setting for selecting these themes.
\media\vendor\tinymce\themes\mobile\theme.js It has 13,000 lines.

theme.js The file is connected to JS through a variety of functions without explicitly specifying the URL, of course it can only be determined by searching through the content.

@korenevskiy I use tiny & jce depending on the site. But the thing is I've never "searched" thru a .css using verbage. Always visually with rem's.

Closing as having a pull request. Please test #40206 . Thanks in advance.