Template talk:Nowrap

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Replaces <nobr>[edit]

This template is a replacement for the unsupported nonstandard <nobr> tag. cesarb 19:50, 20 Mar 2005 (UTC)

Stronger than non-breaking spaces[edit]

It is also even stronger than using non-breaking spaces ("&nbsp;"s) between words, viz. it will ignore (right-hand) margins, borders, etc. David Kernow (talk) 06:45, 26 November 2006 (UTC)[reply]

Lorem ipsum, quia dolor sit, amet, consectetur, adipisci uelit, sed quia non numquam eius modi tempora incidunt, ut labore et dolore magnam aliquam quærat uoluptatem. Vt enim ad minima ueniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem uel eum iure reprehenderit, qui in ea uoluptate uelit esse, quam nihil molestiæ consequatur, uel illum, qui dolorem eum fugiat, quo uoluptas nulla pariatur? At uero eos et accusamus et iusto odio dignissimos ducimus, qui blanditiis præsentium uoluptatum deleniti atque corrupti, quos dolores et quas molestias excepturi sint, obcæcati cupiditate non prouident, similique sunt in culpa, qui officia deserunt mollitia animi, id est laborum.
Lorem ipsum, quia dolor sit, amet, consectetur, adipisci uelit, sed quia non numquam eius modi tempora incidunt, ut labore et dolore magnam aliquam quærat uoluptatem. Vt enim ad minima ueniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem uel eum iure reprehenderit, qui in ea uoluptate uelit esse, quam nihil molestiæ consequatur, uel illum, qui dolorem eum fugiat, quo uoluptas nulla pariatur? At uero eos et accusamus et iusto odio dignissimos ducimus, qui blanditiis præsentium uoluptatum deleniti atque corrupti, quos dolores et quas molestias excepturi sint, obcæcati cupiditate non prouident, similique sunt in culpa, qui officia deserunt mollitia animi, id est laborum.
I don't see much of a difference. And it should: a non-breaking space is a space that will not allow breaking. How much stronger than "not" can you get? Could you be a bit more specific? Shinobu 15:33, 25 July 2007 (UTC)[reply]

Template nowraplinks[edit]

Hi everyone. I got tired of handling word wrapping in long link lists, for instance in navigation boxes. So I have made a new template similar to {{nowrap}}, but that only prevents word wraps in links. That is, it allows wraps between links and in normal text. Thus one single {{nowraplinks}} tag can surround the whole link list instead of having one {{nowrap}} tag around each link or using lots of &nbsp;.

I would like if some expert template editors (preferably with some CSS experience) take a loot at it to see that I didn't miss anything. I think this template might be used a lot once we deploy it.

Oh, I probably should mention that this template will need the addition of one line of CSS code to common.css. So I think this needs to be thoroughly checked and discussed before we deploy it. (And I am not an admin so I can not add that line of code myself.)

--David Göthberg 04:59, 10 August 2007 (UTC)[reply]

The necessary code was added to common.css some days ago so {{nowraplinks}} is now fully functional. --David Göthberg 14:18, 23 August 2007 (UTC)[reply]

Change of page code / looks[edit]

{{editprotected}}

I suggest the code between the noinclude tags be changed. (Mostly to make the page look better really.) The changes I suggest is using the new small padlock, the new {{template doc}} and the category comment, as recommended in Wikipedia:Template documentation. Here is how the full page code looks with my suggested changes:

<includeonly><span style="white-space:nowrap">{{{1}}}</span></includeonly><noinclude>
{{pp-template|small=yes}}
{{template doc}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

--David Göthberg 14:31, 23 August 2007 (UTC)[reply]

Done. --- RockMFR 20:30, 23 August 2007 (UTC)[reply]

Even shorter coding[edit]

{{editprotected}} 17-Dec-2007: The coding currently uses "<includeonly>" which I don't think is needed in a highly size-critical template: the includeonly-tag adds 27 characters, and when the includeonly-tag is omitted, the result just shows "{{{1}}}" above the documentation, which is harmless and emphasizes that parameter-1 is required. Also, I recommend using a shorter comment, to reduce Template:Nowrap by 21%, from 185 bytes to 146 bytes:

<span style="white-space:nowrap">{{{1}}}</span><noinclude>
{{documentation}}<!--put categories & interwikis in /doc subpage, only!-->
</noinclude>

I am concerned about the template size, in conjunction with other templates used on a page, because I've hit template-buffer limits when repeated sub-templates contained only 500 characters. However, I really recommend using "&nbsp;" instead of a template, because "&nbsp;" (used once per wikilink) adds only 6 characters, not 185, and not even 146 characters to each non-wrapped wikilink. Remember, the MediaWiki language version 1.6 treats pages as template-expansion buffers, repeating all template contents as inline text. -Wikid77 (talk) 11:14, 17 December 2007 (UTC)[reply]

 Done.—Random832 17:23, 17 December 2007 (UTC)[reply]
  • Thank you. Excellent improvement: template shortened by 43% to 129 characters. Now it can be used in very large tables, such as a table of painters and their most famous paintings, or a table of all the notable towns in Germany. -Wikid77 (talk) 04:45, 2 January 2008 (UTC)[reply]

Template behaviour: two problems[edit]

{{editprotected}}

 Not done, impossible. change made to documentation (but you could have done that yourself) —Random832 17:04, 23 January 2008 (UTC)[reply]

Problem 1[edit]

From the description of the template's action we have a certain expectation.

x{{nowrap| TEXT }}y

should yield

x<span style="white-space:nowrap"> TEXT </span>y

But in fact it yields

x <span style="white-space:nowrap">TEXT</span> y

I therefore request that the documentation be changed; or, preferably, that the coding of the template be fixed so that it behaves as specified. As things stand, breaks occur in unpredicted ways.

Alternatively, see the better but more radical alteration suggested below.

Use {{nowrap|x TEXT y}}, this is impossible without fundamental changes to how the parser works. —Random832 17:04, 23 January 2008 (UTC)[reply]
Thanks for fixing the documentation, Random. I didn't want to do it myself without raising the matter here first.
Could you point me to a fuller documentation of that rather serious problem in the parser? And please: could you look at the problem below and comment on it also? In particular, do you confirm that the same inadequacy in the parser rules out spaces being rendered as &nbsp;, at the start or the end of the enclosed string?
– Noetica♬♩Talk 21:35, 23 January 2008 (UTC)[reply]

Problem 2[edit]

Even if the behaviour of the template is altered as suggested above, there is a difficulty with the way browsers treat this code:

x<span style="white-space:nowrap"> TEXT </span>y

In recent versions of Firefox and IE at least, this code allows breaks to occur between x and TEXT, and between TEXT and y. Since this behaviour is itself unruly, I request that the coding of the template be altered so that a &nbsp; is substituted for each ordinary space in the enclosed text. This would ensure the desired result. It has the added advantage that multiple ordinary spaces would yield multiple instances of &nbsp;. Whether or not these are deprecated, they are sometimes convenient and sometimes intended.

These concerns arose out of investigations regarding markup for the hard space. See our draft proposal, which I have just amended in light of the anomalies raised above:

There is active discussion of the proposal at WT:MOS. Template editors will be very welcome there.

– Noetica♬♩Talk 23:53, 22 January 2008 (UTC)[reply]

Remark 1[edit]

The behaviour signaled above is part of a larger pattern. Also a'' x ''b leads to HTML a <i>x</i> b, with the spaces pulled out of the italic tags. −Woodstone (talk) 10:50, 23 January 2008 (UTC)[reply]

That's interesting. I wonder why things have been done in such a way? I suppose this behaviour with italics is safer than the behaviour that affects line breaks; but I can imagine situations in which this one might make a difference too.
– Noetica♬♩Talk 11:42, 23 January 2008 (UTC)[reply]

Remark 2[edit]

Even coding

x<span style="white-space:nowrap">&nbsp;TEXT&nbsp;</span>y

still results in a possible break before TEXT in IE (though not after it). Mysterious! −Woodstone (talk) 23:08, 23 January 2008 (UTC)[reply]

Confirmed! (And it makes no difference if &#160; is substituted for &nbsp;.) Firefox handles the code correctly. But you'll love this:

x&nbsp;<span style="white-space:nowrap">TEXT</span>&nbsp;y z

This also breaks before TEXT! In IE, not in Firefox. Note: I add " z" to permit a standard break, in testing. What else remains to be discovered? Woodstone, please let me write a report at WT:MOS, OK? I'll also amend WP:MOS, since these anomalies really should be noted. They certainly advance the case for ,,. They also tend to cast doubt on any template solutions for hard spaces.
– Noetica♬♩Talk 00:56, 24 January 2008 (UTC)–AMENDED CONTRIBUTION: A stray unmatched CODE tag is now deleted from an example.– Noetica♬♩Talk 06:07, 25 January 2008 (UTC)[reply]

{{nowrap}}, {{nowraplinks}} and {{nowrap begin}}[edit]

As a webmaster and Wikipedia editor I have worked a lot with line breaking issues. In the end I created {{nowraplinks}} and {{nowrap begin}} and their helper templates to solve/handle the problems with {{nowrap}}. I took a look at the suggestion above to use the wikimarkup 34,,kg to mean 34&nbsp;kg and it seems to me it is a good suggestion.

Of course what really is needed is that the World Wide Web Consortium (W3C) finally accept and standardise the old well working and easy to use HTML markup <nobr> + + </nobr>.

--David Göthberg (talk) 09:40, 26 February 2008 (UTC)[reply]

In defence of nowrap[edit]

Much said about the defiencies of the template and how &nbsp; does the job better but if its a non-breaking hyphen, en dash, degree sign, etc. you want, this is your template. Jɪmp 22:09, 25 January 2008 (UTC)[reply]

Actually not quite (in IE). Try {{nobreak|aaaaaa—}}bbbbbbb. The intention is to keep the em-dash attached to the left part and allow a break after it. Strangely enough IE does not allow the break after the em-dash. Actually a straight aaaaaa—bbbbbbb has the desired effect in IE. I did not delve deeper, but behaviour seems to be very erratic. −Woodstone (talk) 23:29, 25 January 2008 (UTC)[reply]
Yes, confirmed.
We note that {{nobreak}} is an alias for {{nowrap}}. Where are these aliases documented?
These codes behave in IE the same as the code Woodstone describes:
{{nowrap|aaaaaa–}}bbbbbbb [en dash]
{{nowrap|aaaaaa…}}bbbbbbb [preformed ellipsis]
For none of these markups does Firefox allow any breaks.
What other anomalies remain to be uncovered?
– Noetica♬♩Talk 05:26, 26 January 2008 (UTC)[reply]
For this particular case, a solution that works as intended in both IE and Firefox uses the HTML code for zero-width space:
aaaaaa–&#x200B;bbbbbbb
In the extensions section this is currently proposed by markup ,^,, leading to
aaaaaa–,^,bbbbbbb
Woodstone (talk) 12:31, 26 January 2008 (UTC)[reply]
Hmmm, some potentially unpredictable stuff and possibly more to be uncovered but the point I hoped to make is that this template (or equivalent) can do what you've noted. That is, aaa-bbb, 20–30&nbsp;°C allow breaks which may be undesireable. Jɪmp 07:04, 27 January 2008 (UTC)[reply]
I have just tried a whole bunch of methods to allow line wraps without causing any visible space and all of them failed in some way in at-least one of my web browsers...
The zero-width space caused visible blobs both in my old IE 5.5 and my recent version of Opera. But it worked fine in Firefox. So I don't think the zero-width markup ,^, should be deployed since it will only work in some browsers. But at-least it did wrap properly in all my browsers. (I have not tested with Safari since Safari is not available for my OS.)
But Jɪmp is right, {{nowrap}} does what it is supposed to do, it prevents line wraps in the text that it surrounds.
--David Göthberg (talk) 03:25, 14 March 2008 (UTC)[reply]

Nowrap how-to guide[edit]

I first rough version of Wikipedia:Line break handling is done. Its a how-to guide about how to handle word wraps (line breaks) at Wikipedia. Take a look and discuss it on its talk page.

--David Göthberg (talk) 21:40, 11 March 2008 (UTC)[reply]

Template broken?[edit]

Hi, this template doesn't seem to be working here: Nitrogen dioxide#Monomer-dimer equilibrium. It simply shows up as {{{1}}}. Not sure why the template parameter isn't being substituted; can anybody help?—Tetracube (talk) 19:10, 19 October 2009 (UTC)[reply]

It's the equal sign, which is not allowed in a parameter. Can be solved by using "1=" before the parameter. This is stated in the templates documentation. −Woodstone (talk) 20:27, 19 October 2009 (UTC)[reply]

Space in Documentation after j[edit]

Hello, ist there a reason to have a space after the j in the dokumentation?

We saw {{j |1 [[black rhino]]}} but {{j|800 [[zebra]]s}}. <br>May render like this: :We saw {{j |1 [[black rhino]]}} but<br>800 [[zebra]]s. <br>Or like this: :We saw {{j |1 [[black rhino]]}}<br>but 800 [[zebra]]s. <br>But ''not'' render like this: :We saw 1 [[black rhino|black<br>rhino]] but 800 [[zebra]]s.

--Diwas (talk) 21:07, 25 September 2011 (UTC)[reply]

Hello, to fix texts like “6 ft 6in (1.98m) and 17st 9 lbs (112 kg)” to a correct text and simple source text, I extended this template to up to five texts, see Template:Nowrap5. What you are thinking about it. The first use --Diwas (talk) 00:14, 25 November 2011 (UTC)[reply]

It has flaws. The most important one is that unused parameters will show as "{{{4}}} {{{5}}}". Not really convinced that it adds any functionality. The example in George Kruis is better served with {{convert}}. Edokter (talk) — 01:13, 25 November 2011 (UTC)[reply]
Thanx. The unused parameters, I saw it a while later. The {{convert}} is very good, especially for the autor of an article. I'm using it sometimes yet, but I'm not sure about it. May someone stated as 5 feet 4 inches and as 164 cm but {{convert}} will show 5 feet 4 inches (163 cm)? {{nowrap}} don't changes anything of the content, {{convert}} may change it by nuances.
And {{convert|6|ft|6|in|m|abbr=on}} and {{convert|17|st|9|lb|kg|abbr=on}} is not a very short and easy source text. --Diwas (talk) 04:17, 25 November 2011 (UTC)[reply]

Removed links[edit]

I see that the following were removed from Template:Nowrap/doc#See also with the edit note "removed links to obsolete methods":

  • {{nowraplinks}} – Prevents wraps inside links and only allows wraps between the links and in normal text. Very useful for link lists and easy to use.
  • {{nowrap begin}} – Prevents wraps in both text and links. For the trickier wrapping cases when you need full control, for instance in very complex link lists.

Are these really obsolete? The latter is recommended in Wikipedia:Line break handling. Both seem likely to be useful. — Quondumtc 06:03, 7 January 2012 (UTC)[reply]

brackets and escaping[edit]

Brackets within the Nowrap template, it has been suggested, might be a problem which can be solved by escaping or representing with the HTML character entities & # 91; (minus spaces) for the opening bracket and & # 93; (minus spaces) for the closing bracket. Is that so and, if it is so, should we add it to the template documentation? Nick Levinson (talk) 16:19, 7 August 2012 (UTC) (Corrected my link error: 16:24, 7 August 2012 (UTC))[reply]

Edit request on 01 February 2015[edit]

A protected redirect, Template:J, needs an incorrect redirect category (rcat) template removed and the correct rcat added. Please modify it as follows:

  • from this...
#REDIRECT  [[Template:Nowrap]] {{R from template shortcut}}
  • to this...
#REDIRECT  [[Template:Nowrap]]

{{Redr|from template shortcut}}
  • WHEN YOU COPY & PASTE, PLEASE LEAVE THE MIDDLE LINE BLANK FOR READABILITY.

Template Redr is an alias for the {{This is a redirect}} template, which is used to sort redirects into one or more categories. No protection rcat is needed, and if {{pp-protected}} and/or {{pp-move}} suffice, the This is a redirect template will detect protection level(s) and include them automatically. Thank you in advance! – Paine EllsworthCLIMAX! 19:35, 1 February 2015 (UTC)[reply]

I replaced it with {{R from template shortcut}}. I'm not sure what the benefits are using {{redr}}, apart from being able to add multiple categories. -- [[User:Edokter]] {{talk}} 20:32, 1 February 2015 (UTC)[reply]
Hi Edokter – one big added benefit is that Redr automatically senses protected redirects like this one. So the usual protection rcats are not needed, and they don't have to be manually removed if and when protection is lifted. Please use the Redr template to tag this redirect and any future redirects you protect. – Paine EllsworthCLIMAX! 20:43, 1 February 2015 (UTC)[reply]
Done --Redrose64 (talk) 23:19, 1 February 2015 (UTC)[reply]
Thank you, Redrose64! – Paine 

Wraponce?[edit]

Is there a version of this template that will permit wraps but limit it to a certain number? Like if you want to limit a string of text to being wrapped into only two lines, when window resizing might otherwise force it into three or more lines, and it isn't feasible to manually insert a line break or to use <wbr>. postdlf (talk) 16:55, 4 April 2015 (UTC)[reply]

Edit request on 27 November 2015[edit]

This template needs an update to commented text near the bottom. Please modify it as follows:

  • from this:
<span class="nowrap">{{{1}}}</span><noinclude>
{{documentation}}
<!--interwikis/categories go inside doc-->
</noinclude>
  • to this:
<span class="nowrap">{{{1}}}</span><noinclude>
{{documentation}}
<!-- Categories go on the /doc page; interwikis go to Wikidata. -->
</noinclude>

Thank you in advance!  Paine  18:15, 27 November 2015 (UTC)[reply]

Not done: The only change is to a hidden comment, so it's not critical. Doing this would put 430572 pages in the job queue for nil gain. --Redrose64 (talk) 00:00, 28 November 2015 (UTC)[reply]
I understand your concern for the queue and servers, Redrose64; however, this is an editor communication that confuses those who read it and then go to the /doc page to find very different interwiki instructions. It is not 2 or 4 million transclusions, only less than a half-million. It has to be updated at some point, so why not now?  Paine  01:52, 28 November 2015 (UTC)[reply]
When was somebody last confused? The last time that anybody added an interlanguage link to the doc page was in December 2012, which was a perfectly valid edit made some three months before Wikidata became available. You could update the template sandbox, so that next time an actual change to the template is proposed, they can go through together. --Redrose64 (talk) 09:50, 28 November 2015 (UTC)[reply]
I made the edit. As the change occurs inside a noinclude block, the job queue should not be affected. Still monitoring though. -- [[User:Edokter]] {{talk}} 10:16, 28 November 2015 (UTC)[reply]
Ah, but it will - when transclusions are processed, the whole template is expanded, and the noinclude block is stripped out after expansion processing is complete. --Redrose64 (talk) 10:23, 28 November 2015 (UTC)[reply]
That sounds broken... Anyway, the job queue didn't break a sweat. -- [[User:Edokter]] {{talk}} 16:22, 28 November 2015 (UTC)[reply]

To editors Edokter and Redrose64: – thank you both very much for your concerns and my edification in this matter! Happy holidays! Paine  19:43, 28 November 2015 (UTC)[reply]

Hinky[edit]

Not sure what needs tweaking but, on several occasions, {{nowrap}} used around an open parenthesis and the subsequent text has been leaving the parenthesis on the first line and only keeping the following text together. Obviously, the parenthesis needs to move with the rest of the text. — LlywelynII 06:20, 19 May 2016 (UTC)[reply]

I would need an example where this happens. Chrome has a bug where it allows a break before a nested element. -- [[User:Edokter]] {{talk}} 07:04, 19 May 2016 (UTC)[reply]

Test case from Xenon hexafluoride fails to suppress wrapping[edit]

Compare use of {{nowrap}}:

Salts of the octafluoroxenate(VI) anion (XeF2−
8
)
are very stable

and use of <span style="white-space:nowrap">:

Salts of the octafluoroxenate(VI) anion (XeF2−
8
)
are very stable

on both desktop and mobile. Both work on desktop; the former fails to suppress a line break before the subscript/superscript stack on mobile. Hairy Dude (talk) 23:12, 15 July 2017 (UTC)[reply]

Since you have demonstrated that this occurs when you use <span style="white-space:nowrap">...</span> instead of {{nowrap}}, the problem cannot lie in that template and so this talk page is not an appropriate place to report a problem that lies elsewhere.
However, examining the page source, I notice that the part between "(XeF" and ")" is enclosed in a <span>...</span> which has the style declaration display:inline-block;, and I'm pretty sure that white-space:nowrap only works on purely inline text, the problem is in {{su}} for which the code is at Module:Su. --Redrose64 🌹 (talk) 09:48, 16 July 2017 (UTC)[reply]
I beg your pardon?! I demonstrated exactly the opposite! It happens with {{nowrap}} and not <span style="white-space:nowrap">...</span>, not vice versa. Besides, it reproduces in the absence of {{su}}. From Pains and Penalties Bill 1820:
In private, the Queen also turned the tables on the King by saying, "[I] never committed adultery but once, and that was with Mrs Fitzherbert's husband."
In private, the Queen also turned the tables on the King by saying, "[I] never committed adultery but once, and that was with Mrs Fitzherbert's husband."
Hairy Dude (talk) 14:48, 19 July 2017 (UTC)[reply]
I didn't say it was vice versa. I said that it happens with both. --Redrose64 🌹 (talk) 20:43, 19 July 2017 (UTC)[reply]
It does not happen with both. The failure to prevent wrapping only happens with the template, on mobile. Hairy Dude (talk) 12:57, 29 July 2017 (UTC)[reply]

This template fails in Natural logarithm[edit]

In the very first paragraph of Natural logarithm one finds loge x within the nowrap template, and one sees (if one's window geometry is so adjusted) this:

loge
x

Obviously that should not happen. Michael Hardy (talk) 17:36, 4 August 2017 (UTC)[reply]

I don't think there is anything which could be done with this template. It apples the appropriate CSS nowrap style. Browsers are free to interpret that as they see fit. I think in this case having a picture of the rhs make it hard for the browser to format things properly, so the browser takes the least worse option and splits on a space.--Salix alba (talk): 20:03, 4 August 2017 (UTC)[reply]
which browser? I don't see this in FF on Linux (as far as I can tell). Frietjes (talk) 20:41, 4 August 2017 (UTC)[reply]
As I tried and, frustratingly, failed to explain in the previous section, it fails on mobile and ONLY on mobile - I have confirmed with Chrome and Firefox on Android, and both Firefox and Chromium on Linux, that it happens with the mobile stylesheet and not with the desktop one (Monobook). I believe the class in question doesn't have the proper styles applied to it on the mobile stylesheet. Inspecting the element in desktop Firefox using the mobile stylesheet shows its word-wrap property provided by the content class and set to break-word, and no value for white-space (the computed value is normal). Hairy Dude (talk) 15:23, 12 September 2017 (UTC)[reply]

Edit request on 11 November 2017[edit]

I'd like to request that {{lowercase title}} be added to the template page under <noinclude> tags. There is easy confusion over the intended formatting of the template title, which is, according to the documentation, intended to be {{nowrap}} instead of {{Nowrap}}. I had initially confused this as well, myself, simply looking at the title of the template with the first letter capitalised. I had to have a fellow editor (@GAV80:) tell me that this is not the actual title of the template. Confusion can easily be prevented by adding a {{lowercase title}} to force a lowercase first letter in the template's name. – PhilipTerryGraham (talk · contribs · count) 18:11, 11 November 2017 (UTC)[reply]

@PhilipTerryGraham: Not done: Like article names, template names (without exception) are case-insensitive on the first letter (see H:T#General description, paragraph beginning "How to do it"). It makes no difference at all whether you use {{nowrap}} or {{Nowrap}}. --Redrose64 🌹 (talk) 21:36, 11 November 2017 (UTC)[reply]
@Redrose64: I get that, but people do care about the explicit use of the template’s original name. – PhilipTerryGraham (talk · contribs · count) 23:56, 11 November 2017 (UTC)[reply]
I've chosen to update the template's documentation page instead, making it clear that both versions of the name can be used. – PhilipTerryGraham (talk · contribs · count) 01:24, 12 November 2017 (UTC)[reply]
@PhilipTerryGraham: People shouldn't care about such capitalisation. It makes no difference at all to what is seen when viewing the page. A few years ago, there was a highly-prolific administrator who persistently uppercased the first letter of all template names wherever used in articles; they were frequently asked not to do it but continued to do so. They were eventually taken to the arbitration committee, the outcome of which was that they lost their administrator rights (which have still not been reinstated) and were blocked for a year. Whoever is insisting upon one particular capitalisation should be asked to cease making such changes; if they won't, bring them here. --Redrose64 🌹 (talk) 08:01, 12 November 2017 (UTC)[reply]

Wordbreak template[edit]

We have a {{nowrap}} template, but can we also have a {{wordbreak}} template? (Or {{word-break}}.)

This (note the bold part):

<div style="width:150px; border:1px solid #000000; padding:7px; word-break:normal;">This div contains a very long word: thisisaveryveryveryveryveryverylongword. The long word will not break or wrap to the next line.</div>

Results in:

This div contains a very long word: thisisaveryveryveryveryveryverylongword. The long word will not break or wrap to the next line.

This (again, note the emphasis):

<div style="width:150px; border:1px solid #000000; padding:7px; word-break:break-all;">This div contains a very long word: thisisaveryveryveryveryveryverylongword. The long word will break and wrap to the next line.</div>

Results in:

This div contains a very long word: thisisaveryveryveryveryveryverylongword. The long word will break and wrap to the next line.

A wordbreak template could help make fixing things like this easier. It's a screenshot made with my Samsung Galaxy S7 when viewing the intro of MDMA. You can also fix it by adding a span tag around it (screenshot of the result) but a template similar to nowrap would be more convenient.

Any thoughts? Cheers, Manifestation (talk) 11:33, 17 July 2018 (UTC)[reply]

Ok, changed this a little. I've replaced word-wrap:break-word; with word-break:break-all;. I incorrectly believed they both had the same effect. The former, however, will always break the word at the hyphen if there is one, even if the hyphen is not at the edge of the element. The latter will always and only break the word at the edge of the element, regardless if there is a hyphen somewhere earlier in the word. So I believe word-break to be superior. Also changed my previous edit at MDMA. - Manifestation (talk) 16:52, 17 July 2018 (UTC)[reply]
Your example is flawed, since for me every line has a broken word - even when the word is short. The first line ends after the "o" of "long"; the third ends after the "T" of "The"; the fourth ends after the "n" of "and".
A better technique uses the HTML <wbr /> tag, which is used to indicate word breaking opportunities - that is, places where a broken word would be acceptable:
This div contains a very long word: thisisaveryveryveryveryveryverylongword. The long word will break and wrap to the next line.
Anyway, I'm pretty sure that this has been discussed before, not necessarily here but much more likely at WP:VPT. IIRC opinion was against it, in that (i) it overcomplicates the wikitext; (ii) you don't know how wide anybody else's screen is, so you don't know which words might need breaking. --Redrose64 🌹 (talk) 19:24, 17 July 2018 (UTC)[reply]
@Redrose64:
"The first line ends after the "o" of "long"; the third ends after the "T" of "The"; the fourth ends after the "n" of "and"."
Really? That's weird. It doesn't do that with me. Doesn't matter though, because the template I propose would primarily be used to break a single, long word. There is no point in telling the browser to wrap two or more words because, naturally, the sentence will and should be broken at a white space by default. We could put a cautionary statement in the template's documentation, stressing that it should only be used on single words. <wbr /> would also work, yes. But still, I think it would be better to have the browser figure out for itself where to break, instead of randomly placing a <wbr /> tag somewhere in the middle the word. - Manifestation (talk) 10:08, 21 July 2018 (UTC)[reply]
To make a rough gauge on the potential usefulness of this template, I have browsed through all entries of Category:Stimulants on my Samsung Galaxy S7. I found the following articles with very long words in the lead that caused problems on my phone. 'Before' shows a screenshot of how it originally looked like. 'After' shows the result of applying word-break:break-all.
I've started a new thread on this at the Village Pump, see here. Cheers, Manifestation (talk) 10:08, 21 July 2018 (UTC)[reply]
Please don't upload screenshots to imgur, I can't access them - either my antivirus software complains or my PC slows to half speed and I need to reboot it. We have an established system described at WP:WPSHOT.
Anyway, if we let the browser figure out for itself where to break, how do we know that it will break sensibly? The point about <wbr /> is that it isn't placed randomly, and since all chemical compound names are made up of shorter components, we would put the tag between two of those components: Isothio<wbr />cyanato<wbr />benzoyl<wbr />ecgonine. --Redrose64 🌹 (talk) 11:47, 21 July 2018 (UTC)[reply]
Ok, forget about this. At the Village Pump, a user pointed out to me that the CSS property word-break does not work in all browsers. So the wbr tag would be a better bet. I've added a note about this on the top of the template page so that no one has to repeat the mistake I made. - Manifestation (talk) 16:31, 21 July 2018 (UTC)[reply]

Is there an equivalent template that uses div tags?[edit]

Is there a template that has the same function as this one but uses <div>...</div> tags instead of <span>...</span> tags? I ask because editors sometimes use {{nowrap}} around list templates like {{hlist}} and its siblings, which causes a Linter error, since div tags are not allowed to be wrapped by span tags. – Jonesey95 (talk) 17:58, 4 December 2018 (UTC)[reply]

Jonesey95, you _should_ be able to add |class=nowrap or |style=white-space:nowrap to the {{hlist}}, but that will nowrap the entire thing. if you just want to nowrap the list items, |item_style=white-space:nowrap should work. it would be good to have |item_class=nowrap, but I don't think that is supported. Frietjes (talk) 21:19, 4 December 2018 (UTC)[reply]
I've been replacing the {{nowrap}} template with <div class="nowrap">(content, including hlist or similar template)</div> (example edit), but a template that does the same thing would be more elegant and probably less prone to error. – Jonesey95 (talk) 21:58, 4 December 2018 (UTC)[reply]
Jonesey95 I think this is better. Frietjes (talk) 22:52, 4 December 2018 (UTC)[reply]
It does indeed. I will make a note for future fixes. Thanks. – Jonesey95 (talk) 22:57, 4 December 2018 (UTC)[reply]

Edit request 4 May 2019[edit]

The current wikicode seems to be producing a linter error. The solution, according to mw:Help:Extension:Linter/pwrap-bug-workaround is to add a newline above the initial <span> tag. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 01:50, 4 May 2019 (UTC)[reply]

@Wugapodes:  Not done for now: This is an inline template; adding a newline will break that. Please give examples of pages where this linter problem occurs, and a description of how it is manifested. Or at the very least, per WP:TESTCASES, provide sandbox and testcases, and in the latter show that existing uses will not be broken. --Redrose64 🌹 (talk) 20:08, 4 May 2019 (UTC)[reply]
Wugapodes: See the above section. Use of this template to wrap a <div>...</div> element, and using it in other ways that are incompatible with the wikicode contained in the template, will cause Linter errors. If you provide examples, we can usually recommend a better way to resolve the issue. There are currently no pages listed at Special:LintErrors/pwrap-bug-workaround. – Jonesey95 (talk) 21:31, 5 May 2019 (UTC)[reply]
Well that's strange, I had seen one in there yesterday but looking now you're right that it's empty. I'm not sure how but regardless it seems resolved. Thanks for the help. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 21:39, 5 May 2019 (UTC)[reply]
I replace a line break with a space inside a nowrap template. – Jonesey95 (talk) 21:59, 5 May 2019 (UTC)[reply]

Nowrap makes template topicboxes too wide[edit]

What is this template for? It creates a fixed width element inside of something that needs to be at the very least editable with break tags to limit width. When images or other graphical elements are too wide, the body text is pinched and unreadable. -ApexUnderground (talk) 19:53, 26 June 2019 (UTC)[reply]

Presumably by "template topicboxes" you mean infoboxes. Where does it say that {{nowrap}} is only intended for use in those? --Redrose64 🌹 (talk) 20:29, 26 June 2019 (UTC)[reply]
Because it is used for those, and because it doesn't allow for <br>reaking, it presents a problem.-ApexUnderground (talk) 06:42, 27 June 2019 (UTC)[reply]
Can you point to the article(s) where it is causing a problem? Nardog (talk) 18:03, 27 June 2019 (UTC)[reply]
Yes, his issue is with the width of the infobox on Syrian Civil War. – wbm1058 (talk) 03:07, 7 July 2019 (UTC)[reply]
OP has been blocked as a sock; this thread can just be closed. postdlf (talk) 12:31, 7 July 2019 (UTC)[reply]
The problem at Syrian Civil War is that the infobox has four columns. Nowrap is involved, but is not the primary cause. --Redrose64 🌹 (talk) 18:25, 7 July 2019 (UTC)[reply]

Nowrap inserted automatically[edit]

I just want to put some nbsp in a div and nowrap is added automatically. This makes the template expansions too big. 217.162.112.133 (talk) 03:52, 24 September 2019 (UTC)[reply]

Which page is this on? --Redrose64 🌹 (talk) 19:25, 24 September 2019 (UTC)[reply]

Proposed merge of Template:Wrap and Template:Allow wrap[edit]

See Wikipedia:Templates for discussion/Log/2020 April 26 for a proposal to merge {{Wrap}} and {{Allow wrap}}, which appear to be essentially the same. – Jonesey95 (talk) 04:26, 27 April 2020 (UTC)[reply]


Sparingly?[edit]

This documentation says to use this template sparingly, but offers no definition of 'sparingly", and no suggestions to regulate usage. What dose it really mean? When should or should not this template be used? -- Mikeblas (talk) 21:33, 21 October 2020 (UTC)[reply]

For example, it one uses it just to keep long phrases together, lines will be extremely uneven. Additionally, it may require text in narrow columns to be scrolled on order to be read, which is a great nuisance to readers. I would suggest that one should only use it when line-breaking within the argument makes the text very hard to read. For example, "a great nuisance" is easier to read if the three words are on the same line, but {{nowrap|a great nuisance}} would be excessive use of the template. --RichardW57 (talk) 02:27, 22 October 2020 (UTC)[reply]

Nowrap inside infoboxes doesn't work on mobile[edit]

I can only speak for Chrome on Android:

{{nowrap}} works as described in WP:NOWRAP, but not inside infoboxes, where it's ignored entirely, while &nbsp; and {{US$|anything here}} prevent wrapping fine. Why? 70.163.208.142 (talk) 09:53, 23 August 2022 (UTC)[reply]