Can `customStyleMap` specify a CSS class so the style can be managed in a CSS file?

Styles defined in customStyleMap are specified in JavaScript objects. I was wondering if there’s a way to specify a CSS class name instead of the hardcoded JS-based styles and have my styles managed in a separate CSS file (or LESS/Sass/Stylus/etc…). Is that possible?

[thibaudcolas]

This is really hacky but you could (ab)use CSS selectors on the style attribute to make this work without any changes in Draft.js. Here’s an example:

// Pass this style map to the editor.
const styleMap = {
  'CUSTOM_STYLE_MANAGED_WITH_CSS': {
    // Pick a CSS property that has no actual impact on your styles, eg. something from SVG.
    strokeDashoffset: '0',
  },
};

// Write your styles using an attribute selector targeting this prop-value combination.
.public-DraftEditor-content [style*="stroke-dashoffset: 0"] {
    color: red;
}

// The actual styles are defined in CSS, so media queries are no problem.
@media screen and (min-width: 768px) {
    .public-DraftEditor-content [style*="stroke-dashoffset: 0"] {
        color: blue;
    }
}

Two things:

• We need to use a *= attribute selector, because if there are multiple styles applied to the same text they will all be defined in the same element’s style attribute.
• If you want to do this with multiple inline styles, you need to use a different non-significant CSS property for each style, for the reason I just described.

Small demo GIF:

[donomans]

We are currently running into a huge need for this. Our issue being font-size and line-height need to scale happily via media queries; a user chooses a font size of “5” and the output results in something that’s sensible in desktop and mobile relative to the rest of the content. We have a fairly strict requirement for this type of behavior and maybe it’s just late and I’m jumping towards desperation, but I’m completely failing to find another elegant way to do this without a customClassMap or customClassFn-like addition.

I wonder if there’s a reason the draft team has chosen to only concentrate on inline styles. It makes me wonder if it just goes against how they see draft being used and implemented?

I’m thinking about making a PR for this, though I suspect with how swamped the team is, we’d be waiting for a while on merge (which isn’t a problem in itself, but if there’s a good chance it’ll never be merged, that’s an actual problem, because I can’t justify forking draft long term). Looks like it’s a fairly trivial add, at least.