Ckeditor5: Can't use non-breaking-space in the editor

[long-lazuli]

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

🐞 Bug report

📋 Steps to reproduce

1. type an non-breaking-space into the editor ([option]+[space] on OSX)
2. copy the character generated, paste it in a javascript console, surrounded by quotes: " ".charCodeAt(0)

✅ Expected result

the charCode should be 160

❎ Actual result

the charCode is 32 (which is normal space)

📃 Other details that might be useful

when you paste the character into the editor, nothing is produced.

---

If you encountered this issue and would like it to be fixed, please add 👍 reaction to this post.

[arnaudpeich]

Additional details:

• If I paste  ? into CKE (where the space is non-breakable), it is also converted to a normal space
• If I paste foo bar into CKE (still with a nbsp), the space is correctly non-breakable

[Reinmar]

We made a decision at an early stage to skip support for non-breaking spaces in some scenarios.

In general, when a virtual rich-text content (think – e.g. our data model) is being converted to HTML, some spaces need to be converted to  s. For instance – x x becomes x  x and <paragraph>foo </paragraph> becomes <p>foo&nbsp;</p>.

This conversion, unfortunately, means losing information about the original data. If you typed "foo" and then inserted a non-breaking space to the data model, in HTML this will look identical to typing "foo" and pressing a normal space.

Therefore, there's a range of issues when handling pasted or input HTML. Some browsers wrap spaces in additional spans and try to (theoretically) preserve the original information, but it's all 💩.

So, to not spend too much time on this initially, we simplified this and assume that   in an HTML was a normal space in the initial data, unless it's really really obvious (and simple) to tell it wasn't.

In order to implement a real support for nbsps, we need to do at least this:

• wrap nbsps in additional markup on output (data, copy, cut),
• read this markup on data input (pasting, setting data) and make sure that nbsps are not lost,
• review places like https://github.com/ckeditor/ckeditor5-clipboard/blob/master/src/utils/normalizeclipboarddata.js

[scofalik]

@Reinmar you described the current status in a kind of a grim way but I think it is better than you wrote. It is true that we didn't want to spend too much time on handling nbsps at the early stage. However, I think that current "support" is better than one might deduce from your post:

1. Both of these work as expected:

editor.setData( 'foo\u00A0bar' );
editor.setData( 'foo bar' );

1. We have tests checking if nbsps are correctly preserved in view to dom conversion: https://github.com/ckeditor/ckeditor5-engine/blob/master/tests/view/domconverter/view-to-dom.js#L297

2. There is nothing blocking us from inserting nbsp in the model.

3. Pasting foo bar works as expected. When nbsp is at the beginning or at the end of posted content AFAIR it doesn't work. BTW. pasting empty nbsp doesn't work, but pasting empty regular space doesn't do anything either. Maybe it is simply trimmed and it shouldn't.

So, I think that mostly there are two things to be done:

1. Handle some kind of shortcut, like Ctrl + Space so it correctly inserts \u00A0 into the model.

2. Make sure that &nbsps aren't recklessly removed from the input data (editor.setData(), pasting).

[memboc]

Vote up for shortcut or plugin button to insert   in text

[Reinmar]

@Reinmar you described the current status in a kind of a grim way but I think it is better than you wrote

You're right that it's better than I wrote. I focused on those tickier cases (multiple subsequent spaces, spaces at the end of the content) where we would be losing them. But in simple scenarios such as "foo bar" vs "foo bar" most of the things should work fine. We, indeed, took them into consideration.

Anyway, you can add the keystrokes like this:

editor.keystrokes.set( 'Alt+space', ( key, stop ) => {
    editor.execute( 'input', { text: '\u00a0' } );
    stop();
} );

[long-lazuli]

Thank you for your snippets, and explanations, @scofalik and @Reinmar,
Those pieces of code will be helpful really soon for us.

---

I still would like to express a little bit of frustration about that.

Overall I strongly believe in CKEditor5's architecture.
But this issue, for me, expresses something that should be avoided.
We recreating native behavior of the browser / operating system.

It's nearly impossible for us to know every way a user can input a non-breaking-space. (different OS/Browser/KeyboardDisposition, etc...)

I think we should eventually attempt to keep non-breaking-spaces as the user inputs them.
Maybe avoid some of them in rare occasion. like a blacklist instead of whitelist, if that makes sense.

---

But for the moment, I would consider this issue resolved with just the snippets to add keystrokes,
if the pasting of non-breaking-spaces is allowed.

It would be beneficial even if we paste rich text from Office software.
And in Windows OS, it's easier to do Ctrl+C/Ctrl+V than Alt+0160 ...

[Reinmar]

It's nearly impossible for us to know every way a user can input a non-breaking-space. (different OS/Browser/KeyboardDisposition, etc...)

I certainly share this frustration with you. Unfortunately, that's the current state of the web that some information is not available to us. We could cover it with hacks (with 95%+ certainty), but the amount of work that it requires was not justifiable at the early stages. For instance, it should rather be doable to implement a heuristic which would detect whether a typed space was meant to be an nbsp or a normal space (so you wouldn't need to set keystrokes for that). In fact, with beforeInput it's certainly doable. It's just something we need to work on still.

[marcohanke]

Seme here and +1 Phone Numbers and Opening Hours without nbsp looking awefull.
A charmap for the special chars like tinymce uses would be great as well.

[Reinmar]

Am I correct that your use case is that you want to be able to insert (type) non-breaking spaces? Would https://github.com/ckeditor/ckeditor5/issues/1669#issuecomment-478934583 work for you?

A "special char" plugin, like in CKEditor 4, is in our backlog (https://github.com/ckeditor/ckeditor5/issues/1110), but not plans for it yet.

[marcohanke]

Yes @Reinmar this will be a workaround.