-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't use non-breaking-space in the editor #1669
Comments
Additional details:
|
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 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 order to implement a real support for nbsps, we need to do at least this:
|
@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:
editor.setData( 'foo\u00A0bar' );
editor.setData( 'foo bar' );
So, I think that mostly there are two things to be done:
|
Vote up for shortcut or plugin button to insert |
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();
} ); |
Thank you for your snippets, and explanations, @scofalik and @Reinmar, I still would like to express a little bit of frustration about that. Overall I strongly believe in CKEditor5's architecture. 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. But for the moment, I would consider this issue resolved with just the snippets to add keystrokes, It would be beneficial even if we paste rich text from Office software. |
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 |
Seme here and +1 Phone Numbers and Opening Hours without nbsp looking awefull. |
Am I correct that your use case is that you want to be able to insert (type) non-breaking spaces? Would #1669 (comment) work for you? A "special char" plugin, like in CKEditor 4, is in our backlog (#1110), but not plans for it yet. |
Yes @Reinmar this will be a workaround. |
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? |
@Reinmar in the case of French, nbsp before a punctuation mark would be a case of "really really obvious (and simple)" intention. |
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. |
Any news? |
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 |
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. |
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). |
Is this a bug report or feature request? (choose one)
🐞 Bug report
📋 Steps to reproduce
[option]
+[space]
on OSX)" ".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.
The text was updated successfully, but these errors were encountered: