In visual mode, in the dark theme, the color of the letters is dark on a dark background

[Makarovtt]

Description

When enabling the Dark color theme in visual editor mode, in the block where the user enters text, the color of letters and symbols is black on a black background. Which makes it seem like nothing is working.

Proposal

I can try to change the default text color in the dark color scheme to white and make a PR

[makhnatkin]

@Makarovtt

We use Gravity UI’s built-in theming system to handle both light and dark modes. Currently, the toolbar and buttons automatically adapt to the active theme—dark mode sets a dark background with light text, and light mode does the reverse. This is achieved by applying CSS classes and custom properties defined in the Gravity UI theme provider.

However, the contenteditable area relies on YFM (Yandex Flavored Markdown) styles, which do not yet respond to theme changes. As a result, when switching to dark mode, the background becomes dark but the text remains dark as well, making it unreadable.

To fix this, we need to introduce CSS variables specifically for the editor’s content area. For example, the editor could define a --md-editor-text-color variable that maps to --g-color-text-primary from Gravity UI. These variables would ensure that text color, blockquote backgrounds, and link styles properly switch between light and dark themes. Additionally, we need to ensure that YFM styles rely on these variables rather than hardcoded values. This way, when Gravity UI’s theme changes, the contenteditable area also updates accordingly.

In the current codebase, Gravity UI styles are already integrated via ThemeProvider (see App.tsx), and relevant CSS variables are declared in the styles directory. However, the YFM-related styles in files like yc-colors.scss or yc-file.scss still need to adopt CSS variables for theming.

Once we implement these changes, we’ll achieve a consistent and unified look across the editor’s interface and content area. We also recommend creating documentation that explains which themes are supported, how they are applied, and what steps are needed to fully integrate YFM with Gravity UI’s dark mode. This will help the team maintain the theming system and ensure new developers can quickly understand and improve it.

[Makarovtt]

Hi.
Something's not working out. In the YfmNoteTooltipPlugin file, a new md-editor-text-color class was added to toolbarclassName, but it disappears from the DOM tree during rendering.

But if you add the following lines in the yc-colors.scss file

.g-root_theme_dark {
    .g-md-editor {
        color: var(--g-color-text-primary);
    }
}

It works well, but stops working in High Contrast Dark, although it is clear why.

[makhnatkin]

1. Let’s clarify the terms.
   We have two CSS variables that might seem similar but serve different purposes:

   • --yfm-color-text — text color inside the editable area
   • --g-color-text-primary — text color in the editor’s UI elements, outside the editable area

   In other words, --g-color-text-primary applies to everything except the editable area.

2. DevTools show that the text color in the editable area comes from --yfm-color-text — that’s correct. So, the first part of the chain works: the right variable is applied. Now the question is — what value does --yfm-color-text have? And more importantly — who sets it?

   

3. The color comes from _common.scss, and our first task is to find out where it’s connected. There’s no direct import in the editor code — most likely: base.scss is imported, and it includes _common.scss inside.

4. At this stage, the task is to clearly understand how common.scss is connected and whether it’s linked to theme switching.

   Only after that can we move to the next step — properly updating --yfm-color-text, possibly by assigning it the value of --g-color-text-primary.

[makhnatkin]

@Makarovtt look at diplodoc-platform/themes#1