132

We have the CKEditor in our CMS. Our end users will input some long articles via that CKEditor. We need a way to prevent line break at hyphens on those articles.

Is there a way to prevent line break at hyphens in all browsers?

Or does CKEditor have an option to prevent that?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Alan
  • 2,888
  • 7
  • 34
  • 36
  • 1
    You might consider changing the accepted answer since the current accepted answer has a deprecated solution – inorganik Mar 18 '20 at 15:18
  • FYI, the possibility of a new control to prevent line breaking after hyphens may be addressed in a CSSWG issue I filed: https://github.com/w3c/csswg-drafts/issues/3434 – hftf Sep 26 '20 at 09:32

7 Answers7

324

You can use ‑ which is a Unicode NON-BREAKING HYPHEN (U+2011).

HTML: ‑ or ‑

Also see: http://en.wikipedia.org/wiki/Hyphen#In_computing

Pacerier
  • 86,231
  • 106
  • 366
  • 634
deceze
  • 510,633
  • 85
  • 743
  • 889
  • 4
    Thanks very much for your reply. But what we need to do is to prevent line break on ckeditor where all the content will be entered by the end users. we cannot tell everyone to enter unicode non-breaking hyphen. Is there any other way to prevent line break? or does ckeditor have an option to convert the hyphen automatically? Thanks again – Alan Jan 06 '12 at 04:24
  • 11
    You can do a simple string replacement, replacing `-` with `‑`. – deceze Jan 06 '12 at 04:35
  • 14
    Beware of limited font support to U+2011, see http://www.fileformat.info/info/unicode/char/2011/fontsupport.htm – Jukka K. Korpela Jan 06 '12 at 07:58
  • 7
    While this is certainly more elegant in theory then plastering `nobr` tags all over the place, it does not work very well in practice. IE displays it as an en dash, Safari adds more space around it than a normal dash, and most text editors display it as a question mark or box or other meaningless character. – Tgr Aug 20 '12 at 10:14
  • @Tgr So then what do you suggest? – jakev Mar 21 '13 at 18:29
  • 6
    @jakev I would go with `white-space: nowrap` as suggested by derekerdmann. Btw on FF/Win7 the shy dash seems to be converted into a regular dash when copy&pasted outside Firefox, even if the target application is Unicode-aware. – Tgr Mar 22 '13 at 14:33
  • Note that − is not the same as the ‑ Unicode hyphen and does not prevent line breaking. – danebez May 08 '14 at 07:32
  • 1
    +1, was looking for something that works in Wordpress widget titles without actually rendering the "&" and Unicode. – chamberlainpi Jan 05 '16 at 15:28
  • 1
    Non-breaking hyphens seem to increase the height of the text in content such that they appear lower in a top aligned than text with a normal hyphen. So replacing hyphens with non-breaking hyphens can have side-effects. – Mark Freeman Jul 13 '16 at 17:30
  • 3
    Good heavens, what an awful practice. The *purpose* of separating presentation from semantics is to make web content maintainable. Sprinkling it with numeric unicode entities does exactly the opposite. – Dave Burton Mar 18 '17 at 13:04
  • 1
    @DaveBurton You can use the raw Unicode character, you don't have to use HTML entities. The Unicode character represents a meaning in a way, a hint that the word is never to be separated. To intersperse breaking hyphens and non-breaking hyphens within the same text/paragraph, there's hardly any nicer way. Of course, if you can apply a no-wrap rule to the entire text at once, this here is overkill. – deceze Mar 19 '17 at 08:02
110

One solution could be to use an extra span tag and the white-space CSS property. Just define a class like this:

.nowrap {
    white-space: nowrap;
}

And then add a span with that class around your hyphenated text.

<p>This is the <span class="nowrap">anti-inflammable</span> model</p>

This approach should work just fine in all browsers - the buggy implementations listed here are for other values of the white-space property: http://reference.sitepoint.com/css/white-space#compatibilitysection

derekerdmann
  • 17,696
  • 11
  • 76
  • 110
  • 1
    Thanks very much for your reply. But our text content will be entered by the end users via a ckeditor. we cannot tell everyone to add the around the word. Is there any other way to achieve it? Thanks anyway – Alan Jan 06 '12 at 04:26
  • 1
    @Alan - What kind of content are they adding that can't break at hypens? If it's a title or some other element that will always be on one line, then apply `white-space: nowrap` to the whole container. Otherwise, just let it go; first, there's no reason to prevent line breaks with hyphens for general content, and second, there's no way you'll be able to get what you're looking for to happen automatically unless you're willing to hack away at CKEditor. – derekerdmann Jan 06 '12 at 04:29
  • 13
    There are many situations where a line break after a hyphen is bad or just very wrong, as in “F-1” or when a hyphen is used as unary minus, as in “-42°” (and people use it that way, since they don’t know about the minus sign). – Jukka K. Korpela Jan 06 '12 at 08:03
  • This works, but the fact that it works is non-intuitive, because hyphens are not white space. `` is much clearer. – Dave Burton Mar 18 '17 at 13:09
54

I’m afraid there’s no simpler way to do it reliably than splitting the text to “words” (sequences of non-whitespace characters separated by whitespace) and wrapping each “word” that contains a hyphen inside nobr markup. So input data like bla bla foo-bar bla bla would be turned to bla bla <nobr>foo-bar</nobr> bla bla.

You might even consider inserting nobr markup whenever the “word” contains anything but letters and digits. The reason is that some browsers may even break strings like “2/3” or “f(0)” (see my page on oddities of line breaking in browsers).

Jukka K. Korpela
  • 195,524
  • 37
  • 270
  • 390
  • 42
    The `nobr` tag is not standard, and strongly discouraged by the W3C. See http://www.w3.org/TR/html5/obsolete.html#non-conforming-features – derekerdmann Jan 06 '12 at 14:29
  • 23
    Unlike any other approach, the `nobr` markup works on all browsers, works even when stylesheets are disabled, and works independently of support to special characters. Is there a *real* problem with it? – Jukka K. Korpela Jan 06 '12 at 22:45
  • 23
    Why not ? – SineSwiper Dec 09 '14 at 23:00
  • 7
    @JukkaK.Korpela the issue with it is that modern browsers may decide to drop support for it, and can do so without violating the HTML specification. It's a "should" feature, which is merely a suggested thing to implement. In regards to the stylesheets, if a user has disabled style sheets, then they expect not to have any styles – mirhagk Dec 10 '14 at 20:44
  • 5
    I've been developing sites for 10 years and didn't even know you COULD disable stylesheets in your browser. Who does it really (aside from people who would similarly opt for the self-flagellation of disabling JavaScript by default in this day and age)? If we need to be so pedantic, where's the alternative solution on offer? – John Rix May 08 '17 at 22:43
  • 1
    Still valid answer, after 8½ years. Supported by all major browsers. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nobr – JN01 Aug 21 '20 at 09:44
5

You are unable to do it without editing every HTML instance. Consequently, I wrote some JavaScript code to replace them:

jQuery:

// Replace hyphens with non-breaking ones
$txt = $("#block-views-video-block h2");
$txt.text( $txt.text().replace(/-/g, '‑') );

Vanilla JavaScript:

function nonBrHypens(id) {
    var str = document.getElementById(id).innerHTML;
    var txt = str.replace(/-/g, '‑');
    document.getElementById(id).innerHTML = txt;
}
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Chris Happy
  • 7,088
  • 2
  • 22
  • 49
  • 1
    I like the idea here, as it doesn't involve editing every single bit of HTML that may contain a hyphen. However, I suspect you may run into performance issues processing every bit of text on an entire page like this, especially if there are a lot of elements. – Sean the Bean Aug 31 '17 at 20:55
  • @SeantheBean For sure. I propose that you only process the dynamic sections of text where there may be hyphens. In the case of static text, the developer could go and manually replace the hyphens with [non-breaking hyphens](http://unicode.org/reports/tr14/#Hyphen). – Chris Happy Jan 23 '22 at 01:03
3

Use the word joiner character (&#8288;) around the hyphen. It works in Internet Explorer as well.

Fix specific hyphens...

function fixicecream(text) {
    return text.replace(/ice-cream/g, 'ice&#8288;-&#8288;cream'));
}

Or everything...

function fixhyphens(text) {
    return text.replace(/(\S+)-(\S+)/g, '$1&#8288;-&#8288;$2'));
}
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Carter Medlin
  • 11,857
  • 5
  • 62
  • 68
1

Try this CSS: 

word-break: break-all; 
-webkit-hyphens:none;
-moz-hyphens: none; 
hyphens: none;
Chuck Le Butt
  • 47,570
  • 62
  • 203
  • 289
Ma Yubo
  • 215
  • 1
  • 10
  • 9
    While this code snippet may solve the question, [including an explanation](https://meta.stackexchange.com/questions/114762/explaining-entirely-code-based-answers) really helps to improve the quality of your post. Remember that you are answering the question for readers in the future, and those people might not know the reasons for your code suggestion. Please also try not to crowd your code with explanatory comments, this reduces the readability of both the code and the explanations! – Box Box Box Box Jun 01 '16 at 13:20
  • Wow, this is the simple and correct answer and it's downvoted, and bonkers wrong answers have more than 100 upvotes. –  Feb 01 '21 at 03:39
  • 1
    It helps also to add white-space: nowrap. –  Feb 01 '21 at 03:39
  • 1
    The question was to avoid breaking on existing hyphens, but this breaks words _anywhere_ in the middle, now. Probably, not really what the OP was looking for. – Sebastian Simon May 24 '21 at 05:12
1

You can use the CSS line-break property:

line-break: anywhere;

Although the documentation says it is only for Chinese, Japanese, and Korean (CJK) languages, it also disables line-breaks for the hyphen character in English text. I tested in Firefox (Win10), Chrome (Win10), Edge (Win10), and Safari (OSX) and it worked perfectly for a textarea holding a long authorization key with hyphens in it. Replacing hyphens in a form field would require replacing them back on every form submit, so not an ideal choice.

humbads
  • 3,252
  • 1
  • 27
  • 22