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.

[arnaudriegert]

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' );

2. 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

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

4. 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.

[raphink]

Just got here as we use PimCore which embarks CKEditor and it took me a while to figure out why all my non-breaking spaces were disappearing from my texts.

Seconding @long-lazuli as another French-speaking person: in French standard typography, double punctuation marks (such as "?", "!", ":" or ";") are preceded by a non-breaking space. When CKEditor replaces them with standard spaces, we occasionally end up with punctuation on a newline, which is pretty bad.

I still don't really understand the reason for replacing nbsps with normal spaces in the first place. Why not honor the text users are entering?

[raphink]

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.

@Reinmar in the case of French, nbsp before a punctuation mark would be a case of "really really obvious (and simple)" intention.

[raphink]

As a note @long-lazuli @arnaudpeich, narrow non-breaking spaces don't get replaced, and are technically the proper nbsps to be used in French.

[raphink]

Any news?

[josefglatz]

just for the records: I found a working example in the official docs where every option+space (on mac) creates a nbsp: https://ckeditor.com/docs/ckeditor5/latest/features/special-characters.html. I created a quick video if the demo get's edited in future or functionality will be changed: https://www.youtube.com/watch?v=0sjbET_iTKA

---

the main purpose of this video was not this issue. It's related to an issue of the CMS https://github.com/typo3/typo3 https://forge.typo3.org/issues/82024

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).