import type { CSSProperties } from "react";
import type { PaletteProps } from "../../Theme/tokens/types";
/**
 * Maps this library's active palette to the CSS custom properties Jodit's own light/dark theme
 * CSS reads (`node_modules/jodit/es2021/jodit.css`). Jodit's `theme: "dark" | "default"` config
 * only toggles which of ITS OWN selectors apply (`.jodit_theme_dark`, `.jodit-ui-input_theme_dark`,
 * …) — those selectors are still driven by Jodit's own hardcoded `--jd-dark-*` / `--jd-color-*`
 * custom properties (a generic mid-gray `#575757` canvas, a blue `#1e88e5` accent, …), so toggling
 * the theme alone renders the editor in Jodit's palette instead of ours. This is what shipped the
 * reported "editor is not black" bug in dark mode.
 *
 * `PaletteProps.background`/`.text` are role-stable ColorScales whose LIGHTNESS (not index)
 * flips between modes — e.g. `background[50]` is `#ffffff` in light and near-black in dark, and
 * `text[900]` is near-black ink in light and near-white ink in dark (see
 * `Theme/tokens/builders/buildDarkPalette.ts`). So the *same* token expression already resolves
 * correctly in both modes; only the Jodit CSS-variable NAME differs (`--jd-dark-*` only takes
 * effect inside `.jodit_theme_dark`, `--jd-color-*` is what the default theme reads), which is why
 * this still branches on `isDark`.
 */
export declare const getJoditThemeVars: (colors: PaletteProps, isDark: boolean) => CSSProperties;