Color names are no longer available to colorButton_foreStyle

[markegli]

Type of report

Regression blocking my migration to CKEditor 4.12 or newer.

Provide detailed reproduction steps (if any)

I am migrating some code from pre 4.12 that uses the color name in colorButton_foreStyle. Unfortunately color name is not available in foreStyle starting at 4.12 due to the fix to #1478. The fix for that bug makes sense, but if would be nice if setStyle provided the color name to foreStyle in another variable (say, colorName).

Existing code:

config.colorButton_colors = 'subtext/777, red-text/dd4b39';
config.colorButton_foreStyle = {
  element: 'span',
  attributes: {'class': '#(color)'},
  overrides: [{
    element: 'span',
    attributes: {
      'class': /.text/
    }
  }]
};

Suggested possible code after fix:

config.colorButton_colors = 'subtext/777, red-text/dd4b39';
config.colorButton_foreStyle = {
  element: 'span',
  attributes: {'class': '#(colorName)'},
  overrides: [{
    element: 'span',
    attributes: {
      'class': /.text/
    }
  }]
};

Expected result

Able to make use of the color name from colorButton_foreStyle.

<span class="subtext">styled text</span>

Actual result

Only the hex value is available.

<span class="#777">styled text</span>

Other details

• CKEditor version: 4.12 and newer

[f1ames]

Thanks for reporting and digging into this issue @markegli!

From our perspective it would be the best to restore the previous behavior (so staying with color) to make upgrading CKEditor 4 to newer versions as smooth as possible.

Reproduction demo - https://codepen.io/f1ames/pen/PoqaMYN.

[jacekbogdanski]

Ok, so after digging into the issue, it seems like the change about passing (color) property as a value, not color name has been done on purpose and previously treated as a bug (#1478). It overall makes sense, because it's less likely that such property would be used to compose class names. You can read information about this change in config.colorbutton_colors docs:

Since 4.12.0: Defining colors with names works in a different way. Colors names can be defined by colorName/colorCode. The color name is only used in the tooltip. The output will now use the color code. For example, FontColor/FF9900 will be displayed as the color #FF9900 in the selector, and will be output as #FF9900.

Back to the main topic:

The fix for that bug makes sense, but if would be nice if setStyle provided the color name to foreStyle in another variable (say, colorName).

I think it's the most reasonable approach here, so instead of reverting fix, let's introduce additional style definition property:

color - we are keeping changes introduced in 4.12, so color is passed as a value in hex notation
colorName - we are passing color name if defined by colorButton_colors by a user, otherwise nothing

It also means that the issue should be treated as a feature, not regression.