Implement the font and background color feature

[oleq]

Is this a bug report or feature request? (choose one)

🆕 Feature request

---

The ckeditor5-highlight feature works with a pre-defined (finite, limited) set of markers/pens and works best with structured highlights, for instance, to establish a communication between a content creator and a proofreader in a document.

We've already had some feature requests suggesting that the Highlight feature is unsatisfactory for certain integrations, and a free text/background coloring tool is necessary, offering a full palette of colors without any restrictions, just like the CKEditor 4 feature. This feature would have a different (no) content semantics and a different UI/UX.

Related:

• How to create a command that will change text color? #481
• https://github.com/ckeditor/ckeditor5-highlight/issues/33

cc @Reinmar @dkonopka

[pjasiun]

Idea: usually you use the limited set o colors. It would be nice if the color pallet suggests you colors you already used or which are already applied in the document.

In fact, this is where highlight and color features are similar: highlight feature might have an option to add a custom "highlights" in the runtime and add automatically colors/highlights which are already applied in the document.

[mlewand]

Just a short summary of the scope for our MVP:

UI

• In toolbar we're going to use the split button. Down arrow will open the dropdown where more colors might be selected, whereas button's face applies lastly selected color (if no color was yet selected the first one from the color palette gets used) .
• Dropdown will feature the remove color button, that will essentially remove the style. It's position should be determined during UI design phase.
• Both foreground and background color will get a separate button.
• Preferrably: let's not go crazy with the default color palette size.
• Column count should be figured out automatically based on config.
• There should be "last color" section, that lists most recently used colors. It should consider recent colors used by the end user, colors pasted from external sources as well as font/bg colors in loaded editor content.
• Data-wise, there needs to be support for all kind of proper CSS color formats. So hex format, rgb, rgba, hsl etc.

Nice to haves

• Reflecting the active color on the button icon is to be verified. It might be as well pushed back to implement it later on.
• It would be nice to give possibility to make a separate groups of colors using the configuration.

Followups not suitable for MVP

• The "more colors" option - not suitable yet for MVP.

Config example

Simplified config might look something like this:

[
	[ 'ff0000', '0f0', '00f' ],
	'|',
	[ 'f30', 'f30', 'f30', 'f30', 'f30', 'f30', 'f30' ],
	[ 'f30', 'f30', 'f30', 'f30', 'f30' ],
	[ 'f30', 'f30', 'f30', 'f30', 'f30', 'f30', 'f30' ],
	[ 'f30', 'f30', 'f30', 'f30', 'f30' ]
]

There should be also a possibility to specify custom labels.

[dkonopka]

1. Color palette

Choosing default grid with 5 colors in a row, we shouldn't go crazy with color variations.
See: Gist with colors pallete

15 default colors

25 default colors

2. Color grid size

I've researched others color/background background features and there are a lot of differences from google docs 16px to even 32px, I'm not quite sure if 25px fits well in our case.

Anyway, still it will be possible to change this size via CSS Variable.

25px

20px

3. Remove button position

There is question how often users will use this button - instead of using default color/background of text (black or white).

Just an idea: with CSS flex possibilities we can easily manipulate it via order property and introduce this option to the config.

Top

Bottom

4. Focused single color

I decided to make a border as outline instead of inner border, it's more visible.

[msamsel]

@dkonopka @mlewand
Above we have defined:

Column count should be figured out automatically based on config.

Should be allow customised amount of colors in panel or we should stick to 5? WDYT?

[msamsel]

@dkonopka what with "last color" visualisation. Does the toolbar icon will get some sort of color indicator on it?

[msamsel]

Also should there be any indicator that current selection has given color?
E.g. Imagine that in point 4, entire text is green, and current selection is in green text. Shouldn't be marked it somehow, that current selection is green?

[oleq]

@dkonopka Great research!

1. I'd stick with the smaller palette. If an integration needs more, they'd probably define their own palette because it must match a specific set of colors (of the company, CI, etc.). We can leave a bigger palette as an example in our documentation.

2. I wanted to say less is more but now I figured the "remove color" label could be much longer in some languages and it will stretch the layout. Maybe we can start with 20px but the layout must be flexible (CSS grid?) so if the label is longer, the grid adjusts to it, either by

   • increasing the number of columns
   • increasing the size of the color

   This is also closely related to:

   Column count should be figured out automatically based on config.

   can you research this, @dkonopka? Which option is possible?

3. Top feels more natural to me but I'm open to any position.

---

what with "last color" visualisation. Does the toolbar icon will get some sort of color indicator on it?

AFAIR we decided that MVP has a static icon.

Also should there be any indicator that current selection has given color?
E.g. Imagine that in point 4, entire text is green, and current selection is in green text. Shouldn't be marked it somehow, that current selection is green?

Isn't the button pushed ("on") enough in the MVP?