When a non-breaking space is tried to add to a text in an editor by typing (Alt+Space on OS X or Alt+0160 on Windows) or by pasting, a non-breaking space is really added to the HTML code and the added space acts like a non-breaking space in the editor.
When a non-breaking space is tried to add to a text, a regular space is added and it acts like a regular space.
You can add non-breaking space if you go to the code mode (when the Code Beautifier plugin if off) and type a non-breaking space symbol or . On a site it acts like non-breaking space but in the editor it acts like a regular space.
Safari 10.0.2 (OS X), Chrome 55 (OS X and Win 10), Firefox 50.1.0 (OS X and Win 10), IE11 (Win 10), Edge 14 (Win 10) (every browser I've tested).
@FinesseRus the editor is making use of simple spaces and non-breaking spaces in order to provide a true WYSIWYG experience. For example when you hit a regular space, the browser by defaults inserts multiple spaces which are collapsed and the user doesn't see nothing. We have in place some custom code which combines the simple spaces with non breaking ones so that the users can actually see what they type. Unfortunately, this makes non breaking characters unusable when using ALT+space or ALT+0160. We're constantly looking for better approaches and if we find one, then it would definitely be implemented.
@stefanneculai I don't imply the case when a user wants to make a big gap by typing multiple spaces. I imply the case when a user needs to make 2 words to always stay on a single line. For example, phone numbers (+40 21 460 4260) or values and their units (2π rad) are strongly desired to be not wrapped to separate lines, and non-breaking space can solve this issue. But user can't do it in the editor because the editor replaces non-breaking space between the words to a regular space.
Unfortunately, this makes non breaking characters unusable when using ALT+space or ALT+0160.
This is more than unfortunate. Couldn’t this be an option? I’ve never found a need to honour multiple spaces in text content, but am very often shocked by missing non-breaking space behaviour!
Agreed. This is very annoying. I tried disabling this behaviour using htmlUntouched: true, but that doesn't work.
Please urgently solve this, as it makes Froala unusable for the generic use case.
In the current version, we're leaving this as a wontfix because there are some things in the core which rely on that. This issue will be addressed in further major editor versions.
Hello !
I'm working at Laval University in Quebec, and we are in the process of getting a solution for rich text editing in our LMS. Froala is on of the best solutions we found on the market at the moment but this non-breaking space issue is really a problem for us too.
Non-breaking space are an important part of good formating practices and lacking this functionnality is almost a deal breaker here at Laval. At least it would be good to allow inserting it from the special characters popup.
@stefanneculai, do you think that could be possible even with your custom code in place ?
About that custom code dealing with multiple normal spaces user may input, I think normal spaces should be strip server side (even if wysiwyg would not be respected in that specific case), and let user enter explicitly non-breaking space if he really wants to format his text with spaces, which is a bad idea from my point of vue. Formating should be achieve with RTE functionnality, not with spaces... But again, that's only my opinion and I can imagine cases where this could be needed.
Thanks for your excellent work on that piece of software.
I think this problem is caused by browsers because a plain contenteditable element behaves the same way.
I've made some tests and native content-editable behaviour toward spaces in chrome is indeed just like Froala :





I've tested native content-editable behaviour in Edge and Firefox also, both don't transform normal space in nbsp, so you can enter as many following normal spaces ou want. But in all 3 browsers, it seems impossible to type or copy/paste a nbsp.
I'm really surprised at this because nbsp are necessary in languages like french and many others, for example to make correct use of ponctuation like « » or :. Maybe I'm missing something ?
As I mentionned in my previous comment, I think Froala should enable simple nbsp via special characters popup, like other editor does.
@jipigi thanks for your input regarding this matter. We have some custom actions there for space and custom rules for placing non-breaking spaces. If we'd leave the browser to put in just simple spaces without non-breaking ones, then we might end in a lot of scenarios where you type multiple spaces and you actually see only one which is not correct. We had such a behavior in version 1 and we redesigned it like so in version 2. Maybe it is not the best way, however, with the way contenteditable works at this point is the approach with works in fairly most of the cases.
@stefanneculai, thank you for your answer.
I can see why you redesign it in the version 2. And yes, it's probably better for most cases. But it's still a requirement for lots of languages to be able to use nbsp. The best solution would keep this behaviour, but still allow insertion of a via special character modal and prevent Froala (or chrome) to replace it by a normal space later on, only in this case.
Do you think we could have a work around which works like this ?
Unfortunately, in the version 2 that won't be possible. We have all the core designed based on the way non-breaking spaces currently works.
The writers in my company comply a lot about the lack of nbsp. This fact can make us switch to another WYSIWYG editor. Is it going to be fixed in Froala Editor v3?
I've found out that one can add an almost persistent non-breaking space by adding the following HTML code to the desired space position:
<span style="white-space: nowrap;"> </span>
Unfortunately, the no-break space becomes a plain space when the «Clear formatting» button is clicked.
I think I can make a plugin that adds a button that creates a no-break space. But I believe it's a dirty solution.
There is another simple way to add a no-break space: add a usual space and make it bold. But it doesn't work in Safari.
Note that non-breaking spaces are not just about one-lined phone numbers and suffixes, it is a base element in typography since it enhances readability of text – for example joining prepositions with nouns following them etc. (see examples below) For good text writters / typers it is obligatory feature. You have to use it in your bachelor / master thesis as well or any academic work.
We use Froala inside of Mautic (the world's first e-mail marketing software) and this issue really stresses us as we have to deal with it every single e-mail or landing page hacking it with <span> </span> or something similar. As we are sending e-mails, responsiveness is very important to us and there is no responsiveness without nbsp (with a little exaggeration). Without it, it just... the content does not work the best way it could.
We need to use Alt+0160 (or similar on different OS) and we need to actually see that there is nbsp typed (some highlightment).
Can you please reconsider state and priority of this issue?
I had a feeling that it could be a
good idea.
vs.
I had a feeling that it could be a good
idea.
(Czech date format)
Událost se bude konat
- 2019.
vs
Událost se bude konat 12.
- 2019
You can reach me at +420 756
485 958.
vs.
You can reach me at
+420 756 485 958.
etc.
Using @dakur's hint about <span> </span> I made a plugin. Yes, this is a workaround but I don't see a better way. This is specific to Angular, but I hope it helps others too:
froala.plugin.insert-nbsp.ts:
import FroalaEditor from 'froala-editor';
export function registerInsertNbspButton() {
FroalaEditor.DefineIcon('insertNbsp', { NAME: 'code-commit' }); // This is a FontAwesome5 Icon, find something that suits you
FroalaEditor.RegisterCommand('insertNbsp', {
title: 'geschütztes Leerzeichen einfügen', // This is the toolbar button title, translate to your gui language
focus: true,
undo: false,
refreshAfterCallback: true,
callback: function (cmd: string, val, params) {
this.html.insert('<span class="nbsp"> </span>');
this.undo.saveStep();
},
});
}
froala.component.scss:
/deep/ {
.fr-view[contenteditable="true"] .nbsp:before {
content: '·';
position: absolute;
color: #888;
}
}
froala.component.ts:
import { registerInsertNbspButton } from './froala.plugin.insert-nbsp';
export class FroalaComponent implements OnInit {
ngOnInit() {
registerInsertNbspButton();
}
}
froala.config.ts:
export const Config = {
options: {
toolbarButtons: [
'fullscreen', 'bold', 'italic', 'underline', 'strikeThrough', 'subscript', 'superscript', '|',
'fontFamily', 'fontSize', 'textColor', 'backgroundColor',
'paragraphFormat', '|', 'align', 'formatOL', 'formatUL', 'outdent', 'indent', 'quote', '-',
'insertLink', 'insertImage', 'insertVideo', 'embedly', 'insertFile', 'insertTable', '|',
'fontAwesome', 'specialCharacters', 'insertHR', 'insertNbsp', // <--- place new button where it fits best
'selectAll', 'clearFormatting', '|', 'print', 'help', 'html', '|',
'undo', 'redo',
],
}
};
Most helpful comment
Agreed. This is very annoying. I tried disabling this behaviour using htmlUntouched: true, but that doesn't work.
Please urgently solve this, as it makes Froala unusable for the generic use case.