Ckeditor5: Missing toolbar items and editor default dimensions

[elglingo]

Feature request

💻 Version of CKEditor

CKEditor 5

Hello,
I am testing CKEditor 5 since yesterday. There's some features of CKEditor 4 that i can't find or reproduce

• i can't find 'TextColor', 'BGColor' and 'RemoveFormat' toolbar items in the API
• how to configure default width and height of the editor, and how to make it resizable

Thanks for your answers/help (and sorry for my horrible english practice)

[jodator]

Hi @elglingo. CKEditor 5 just entered alpha phase and at this point we bring only core editor features like typing, list or basic styles. The CKEditor 4 has been developed some time now and has really big feature list. Surely we want to bring some of them to CKEditor 5 but since it has completely new philosophy behind it we want to carefully craft each new feature.

As for new features as "Font Color", "Background Color" or "Remove Format" we're happy to hear about use cases:

• Why do you want those features?
  
  
  
  • What are the use cases for such features? How users will interact with them?
  
  

As for configuring size of "Classic Editor" configuration there's already an answer on SO. But as with above maybe you could help us understand your use case? How would you like to editor behave?

[elglingo]

Hello @jodator , and thanks for your reactivity.

• 'removeFormat'' allows user to remove all html tags of a selected text block. Imagine a block with bold words, underlined words and italic words mixed up. You select the block, clic on 'removeFormat' button to unformat the whole block.

• 'textColor' and 'BGcolor' features are explicit, i think. It allows user to choose a color or a background color for the selected text
  
  For my users, coloring certain words has a meaning in their work.

Thanks for the Stack Overflow link about editor sizing :)

The main reason why i want to leave CKEditor 4 for CKEditor 5 is for the right click paste on the editor, not possible with CKEditor 4, and the possibility for my users to use the browser's right click spell check (i can't use CKEditor spell check for security reasons)

[fredck]

For my users, coloring certain words has a meaning in their work.

I think that this is exactly what we need to hear more about here.

Details like this would push our heads to think and maybe come out with a solution that is much better than the previous one. One that will bring a better UX and produce better content.

We certainly don't believe that users will be going around randomly "painting" content with colors. What is the exact use case then? What are the user goals?

@elglingo, do you think you can elaborate more on this? Feedback like yours is gold for us. Thanks!

[wwalc]

When I read about using colors to give words meaning I immediately think about a part of the population that is excluded from using such a system (https://nei.nih.gov/health/color_blindness/facts_about). E.g.

As many as 8 percent of men and 0.5 percent of women with Northern European ancestry have the common form of red-green color blindness.

Just a note to explain why we're digging the usage of colors feature in CKEditor 5.

[elglingo]

@fredck, a common use case

• a user A writes a report
• a user B reads the report and colors text blocks according to their priority, or according to whether the information is important or negligible.
• it helps user C to make decisions.

The whole process is a bit more complex, but i can not give more details

@wwalc,

As many as 8 percent of men and 0.5 percent of women with Northern European ancestry have the common form of red-green color blindness.

Just a note to explain why we're digging the usage of colors feature in CKEditor 5.

Just to satisfy 8% of potential users you are depriving the remaining 92% of a feature ... I find this a bit rough

Anyway i hope my feedback will help you
Thank you for your interest in the comments and requests made to you

[scofalik]

For the provided use case, the best option would be to have "highlight feature". It could change either background or font color.

This feature wouldn't be a complicated feature. It might use markers mechanism. In short, markers are ranges defined on content. They are automatically updated as the content changes. Thanks to that if you would paste some content into "highlighted" part of a document, you wouldn't need to color it. It would be automatically, well, marked.

Another gain is that in the editing context, the marker can be converted to highlight (so when editing you see that the font is red). But, in the data pipeline (when you use editor.getData() to get the content and save in database) you can easily drop markers. This way you don't have to remove coloring when you publish your document.

What I wanted to show you, is that it seems that you don't need font-color feature per-se (at least for that case). We are just used to do tasks using the tools we had, even if these were wrong tools. It seems that you'd be better of with highlight / comments feature.

[fredck]

@scofalik, yes, that's a way of seeing this. It's a more complex feature, but it is indeed a good way to handle a workflow of text review and validation.

Instead, @elglingo brought a valid use case; a case I was expecting in fact. A case that can be handled by simple formatting features.

I'm unsure what's the better name for it... highlight or "marker". By marker, I mean the classic ones used on paper documents:

So, wouldn't it be more valuable to bring a "marker" feature, designed to that specific scope, than the old "Color Background / Foreground" set? It could have a better UX for that purpose... some ideas (brainstorming):

• 6 default "marker like" colors (configurable ofc), instead of a whole palette.
• A much more interesting UI to select the color then.
• Once you click the button, the maker stays active so whichever selection you make gets marked, until you click again or press Esc.

Then, what about the "foreground color" feature?

How do you guys see this?

[oleq]

Once you click the button, the maker stays active so whichever selection you make gets marked, until you click again or press Esc.

I'm afraid people would get stuck in the "marker (painter) mode" and they would ruin their document before they get out of it. At best, there would be lots of undoing when they finally find out how to do it. Analogous to the _"I can't exit Vim"_ syndrome.

I'd rather see the user enter the marker mode first and be notified about this:

then choose the right marker from the panel upon selection:

or use some more advanced menu with named styles:

[jodator]

@oleq so after marking some text it would jump off the highlight mode?

[fredck]

Hum.. I'm not convinced about this as well... maybe it's not a good idea. Even with your proposal people may still feel like stuck on the feature. The usual "select + click button" could be enough... especially in the first version.

What we could think of later may be a way to quickly repeat the previous styling with a keystroke. This would expand the benefit not only to the marker feature but also to any other styling that I want to repetitively apply over the document.

[pjasiun]

Have you seen that MS OneNote does not have background color anymore and rename it to highlight?

But: why the discussion about highlights is in "Missing toolbar items and editor default dimensions" topic?

[fredck]

Another thing that came to my mind is that some people would like to use the "foreground" color to mark text. For example making it red.

So this feature could be expanded to replace both the old "foreground + background" color thing with a more modern approach. We could call it "Highlight" where it is possible to use either a "pen" or a "marker"

As for the UI, I got an idea to share... I've just put down this piece of art:

It is a "smart" button:

• Icon changes to either pen or marker, depending on my last use.
• My last used color is displayed in the icon as well.
• If I click in the icon side of the button, the selection is highlighted as the icon shows.
• If I click on the button arrow, it opens the options where we show larger beautiful boxes. For pens it shows a pen-like line with that color and a letter or two styled that way. For markers, it shows a marker-like stroke in the color.

Developers would be able to configure as many pens and markers they want. We can come with a small and nice good enough set.

How do you guys like it?

PS: In the drawing, I show both variations of the button... they should not be two buttons.

[fredck]

@elglingo, do you like the shape this discussion is taking?

[fredck]

When it comes to implementation, these highlights would be simple <span class="my-highlight-class"> elements, therefore controllable by CSS (and less dangerous if accidentally output a front-end.

[scofalik]

I just wanted to say that I like @oleq's mocks. I am glad that you picked up the idea :). I am not sure about "pen" though. It's becoming too similar to the old tools. I also wonder how many bug reports we will get when people won't have their background retained in data :).

[fredck]

I am not sure about "pen" though. It's becoming too similar to the old tools.

What do you mean with old tools? It is proposed in the context of "highlighting".

I've proposed this because I've seen often enough pieces of legal documents being marked using foreground colors, especially red, blue and green.

I also wonder how many bug reports we will get when people won't have their background retained in data :).

I don't understand this. Can you explain differently?

[scofalik]

Oh sorry, I got confused a bit. I guess what I meant then is that people will think that this feature will apply styles that will be visible in output data.

[fredck]

Oh sorry, I got confused a bit. I guess what I meant then is that people will think that this feature will apply styles that will be visible in output data.

Well, it can be visible in the output if you wish, but just having the same CSS defined there. Just like many other features in the editor (e.g. images).

Formatting with CSS is in any way much probably the way we'll go with most of the features.

[scofalik]

Yes, I know, but people will think that this will work out of the box. That was just funny comment that we will probably get bug reports about this.

Anyway, honestly, for a second I thought that the <span>s won't be in final data at all. Unfortunately, I don't know how we could do this, as you need to save them in a database (so other users can see them when editing).

[oleq]

@oleq so after marking some text it would jump off the highlight mode?

@jodator: No, it would stay in this mode. Just like Accessibility Checker. Well, maybe not exactly, but it would enable the balloon attached to the caret upon selection.

Even with your proposal people may still feel like stuck on the feature.

@fredck: But then they don't wreck their content. Note that this will be also in collaboration so a desperate user in the marker frenzy could be a disaster.

BTW:

1. In your mockup, how would user finish marking?
2. What would indicate that the marking mode is on? If the icon is supposed to be pushed (e.g. like bold), what would then indicate that the marker X is enabled for current selection?
3. When in marker mode on the text would be marked by mouse selection only or by keyboard selection too? Can we differentiate with our current API (cc @scofalik)?
4. How to remove a marked text? A "remove marker" marker?

[fredck]

In your mockup, how would user finish marking?

I've abandoned this idea of "ckick to start -> mark, mark, mark -> click to finish". As I said earlier, it sounds like a bad idea now.

What would indicate that the marking mode is on?

There is no "marking mode" in this proposal anymore.

If the icon is supposed to be pushed (e.g. like bold), what would then indicate that the marker X is enabled for current selection?

It would never indicate the color of the current selection. It is not a context-sensitive button.

How to remove a marked text? A "remove marker" marker?

Good question and probably a good answer. One of the tools would be a "rubber" :)

[fredck]

Although I like your suggestion, Olek, I was immediately worried about the number of clicks and complexity of the feature. It is so focused on one of the use cases, that it left behind another common case when I want to select and mark text just once. Here is your proposal:

1. Click the toolbar button (on).
2. Select text.
3. Click to choose (even if I want to use always the same) the desired color and apply it.
4. Click the toolbar button again (off).

Ideally, we should have this:

1. Select text.
2. Click to apply the marker.

The curious thing is that even if for the use case marking several parts of the content, the number of clicks stays the same in both cases, except for the first and the last marking.

[oleq]

I've abandoned this idea of "ckick to start -> mark, mark, mark -> click to finish". As I said earlier, it sounds like a bad idea now.

That's cool. Dropping the "marker mode" makes your proposal much better IMO. It makes sense now.

Another question: Would markers overlap? If yes, how to erase them with the rubber (seriously, see the movie)?

[fredck]

Would markers overlap?

I don't think so, for simplicity... we can just consider pen and marker overlap.

If yes, how to erase them with the rubber (seriously, see the movie)?

Well, it would remove everything then, leaving the clean text.

And ofc, I used the wrong term... it's "eraser" :)

I would even call it "Highlight eraser", to not mess it up with the "Remove formatting" feature, which has a larger scope.

[wwalc]

Some idea on how the highlighted text could look like (the default styles in demos etc.), to make the separation from background color even more obvious https://cssreset.com/cool-css-effects-realistic-text-highlighting/

Not sure how it would work with larger highlighted objects, like images, tables (that e.g. I "highlight" by drawing a circle/ellipse around them).

[elglingo]

@elglingo, do you like the shape this discussion is taking?

@fredck A lot of good ideas here. I agree to keep the feature as simple as possible. You don't have to focus specifically on my use case, but create a simple and generic highlighting feature : select the text, clic the button, select the color, et voila.

[oleq]

@wwalc I'm afraid it's a no go. There's no way to precisely tell with the gradient where the marker starts and where it ends. It's a crucial knowledge for the user who applies the markers. And it's also a major a11y issue (the contrast between _5% yellow_ and white).

[Reinmar]

OK, I think that the following tickets cover all that was discussed here, so let's close this ticket.

• Highlight feature,
• Alignment feature,
• Font size and family.