Template talk:Nowrap

From Wikipedia, the free encyclopedia

Template:Nowrap is permanently protected from editing, as it is a heavily used or visible template.

Substantial changes should be proposed here, and made by administrators if the proposal is uncontroversial, or has been discussed and is supported by consensus. Use {{editprotected}} to attract the attention of an administrator in such cases.
Any contributor may edit the template's documentation to add usage notes, categories or interwiki links.

1 Replaces
2 Stronger than non-breaking spaces
3 Template nowraplinks
4 Change of page code / looks
5 Even shorter coding
6 Template behaviour: two problems
7 In defence of nowrap
8 Nowrap how-to guide

[edit] Replaces

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

[edit] Stronger than non-breaking spaces

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

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)

[edit] Template nowraplinks

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  .

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)

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)

[edit] Change of page code / looks

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)

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

[edit] Even shorter coding

{{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 " " instead of a template, because " " (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)

Done.—Random832 17:23, 17 December 2007 (UTC)

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)

[edit] Template behaviour: two problems

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

[edit] Problem 1

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

x{{nowrap| TEXT }}y

should yield

x TEXT y

But in fact it yields

x TEXT 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)

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  , at the start or the end of the enclosed string?

– Noetica^♬♩ Talk 21:35, 23 January 2008 (UTC)

[edit] Problem 2

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

x TEXT 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   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  . 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:

See a full draft of the proposal

[Stable draft; last amended 11:04, 27 March 2008 (UTC). Development page: WT:NOWRAP.]

Better markup for the hard space
A proposal to implement ,, as markup for the hard space ( )

1. Overview

2. Technical details

3. Objections and replies

4. Implementation

1. Overview

The hard space is an important but neglected element in good Wikipedia editing. It stops an unwanted line break, so it is also called no-break space, or non-breaking space. An example (one sort from very many): no line break should occur in "17 sq ft". At present there are two ways to achieve this: first, with the raw HTML   code (17 sq ft); second, with the {{nowrap}} template ({{nowrap|17 sq ft}}). These options are hard to remember, hard to input, and hard to interpret on the screen. Some cases are far more complex.
The solution? Introduce simple new Wikipedia markup, similar to the existing markup for italic (''italic text'') and bold ('''bold text'''). Although these are converted by the system into HTML code (italic text and bold text respectively), the text always appears in the edit box with the markup '' or '''.

The proposal simply adapts this useful and accepted idea, to include the hard space. Extensive discussion among interested editors, followed by a poll, shows that ,, (two ordinary commas) is the best markup. When it is implemented, one could type 17,,sq,,ft in the edit box, which would be converted internally to 17 sq ft, so that the reader of the article always sees an unbroken "17 sq ft". Editing, we would always still see 17,,sq,,ft. This innovation is easy for experienced editors and welcoming to Wikipedia newcomers, since it is the same style as markup for bold and italics.

Analysis shows that comma-based markup could be extended for other formatting and punctuation; but that is beyond the present simple proposal.

2. Technical details

The system's existing parsing of markup for italics ('') or bold (''') is a little complex. Those markups are "dual", requiring distinct interpretations as either beginnings (, ) or ends (, ). Those markups have to coexist with the use of ' as a single quote mark and as an apostrophe. Italics and bold are often applied together: sometimes overlapping, but more often nested like 'this' (markup: ''nested '''like 'this''''''). The WP community accepts the occasional ambiguity, and where the system fails to parse as an editor intends, there are workarounds available.
The proposed markup for the hard space will be much more straightforward – for originating editors, subsequent editors, and the system itself. There are no beginnings and ends, just single applications. Still, some slight complexities will arise, and they are easily dealt with. We start with the simplest case:

The case of ,,

Exactly two adjacent commas will always be parsed as a hard space, yielding the HTML code  . Inadvertent typing of ,, instead of , will cause no serious damage: its effect can easily be detected and repaired.

The case of ,,,

The markup ,, must coexist with the use of , as an ordinary comma in the text, though it will rarely be adjacent to such a comma. If this ever does happen, the natural parsing of ,,, would be as comma +  . This could conceivably be needed in a complex subscript, like this: W_{1, 2, 3, ... , n} (markup: W1,,,2,,,3,,,...,,,n).
It is hard to think of a case in which the reverse would be needed (  + comma); but if that ever did arise, <nowiki></nowiki>,  , and {{nowrap}} would always be available, as they are now.

The case of ,,,, (and higher even numbers of commas)

Sometimes more than one hard space is called for: in fine-tuning spacing in tabular work, for example. (This is deprecated by some, but often a convenient solution.) The natural parsing of ,,,, would be as   +  . A similar interpretation would apply to any string of 2·n commas: it would be parsed as n instances of  . And similarly for longer even-numbered strings of commas. If the editor intended comma +   + comma, the existing alternative resources should be used.

The case of ,,,,, (and higher odd numbers of commas)

The sequence ,,,,, would be most unlikely to occur, and might arise more often as an error than as meaning anything specific. But the natural parsing would be comma +   +  . And similarly for longer odd-numbered strings of commas. If the editor intended   + comma +  , the existing alternative resources should be used.

In short, there is a single rational parsing for any comma-based markup that could arise; and in the rare cases in which no comma-based markup will yield the desired non-breaking HTML code, alternative resources will meet the need as they do now.

3. Objections and replies

Objection 1
Hard spaces? I never use them! Why should I care?

Good editing requires hard spaces, even if many editors know nothing about them. Wikipedia's Manual of Style (MOS) explains some of their uses; and more uses would be added there, if only the markup were simple enough.

Objection 2
The no-break space can already be input with  . Recently this code has been attached to a button for insertion, under the edit box. Isn't that enough?

There are three points to make.

First, the code   is hard to remember, hard to type, and hard to interpret on the screen, especially to those who are unfamiliar with HTML. One simple example: an en dash often needs a hard space before it. Consider "89 sq in – 3 sq ft". To keep this from breaking improperly you need to type, or later edit, this code: 89 sq in – 3 sq ft. Under the proposal, you would simply type this instead: 89,,sq,,in,,– 3,,sq,,ft.

Second, note that the goal of wikitext is to abstract HTML codes away from the user, especially for common markup such as ''italics'' and '''bold'''. If the hard space is to be used as often as MOS advocates, it also needs this treatment.

Third, the new insert button does not help with interpreting the code seen in the edit box. It helps with inserting: but you still have to find the button, then find your place in the text again. Do you really want to do all that three times, for the example just given?

Objection 3
Why not use the Unicode character for the no-break space, attached to an insert button?

There is still a problem with insert buttons as a solution. In contrast to  , the Unicode non-breaking space is visually indistinguishable from the ordinary space. This is unacceptable, since the editor needs to be able to see the difference in the edit box.

Objection 4
There is also a {{nowrap}} template. Why not use that?

This template may be useful in some longer phrases that shouldn't be wrapped at any point; but again it is too visually intrusive to be used extensively for single no-break spaces. With the example above, the code would be {{nowrap|89 sq in –}} {{nowrap|3 sq ft}}. And many cases are more complex than that. Currently, {{nowrap}} does not behave well, since a space at the start or end of the enclosed text is rendered in HTML outside of that text, leading to unexpected breaks. There are other templates similar to {{nowrap}} that cater for specialised requirements; but all of these come up against technical inadequacies in the template system itself. And they all use the HTML  tag, which is interpreted differently by different browsers with unpredictable results. Use of   instead is simpler, more intuitively understandable, and more reliable in its results on the reader's screen no matter which browser is used. That is what the proposal for ,, achieves.

Objection 5
I use a non-standard editor with aliasing, so when I want a hard space I type /h to get  . Easy! So what's the problem?

There are two problems. The code you make is still hard to read and edit; and not everyone can do what you can do.

Objection 6
I'm used to  . That's what I'll always type!

You could do that, of course. You'd still make markup text that's hard to read and hard to edit. Some people (very few!) type  and  in the edit box. But they'd make life easier for themselves and others if they just typed '' instead.

Objection 7
The proposal is technically too hard to implement, and is not standard anywhere.

It is in fact easier to implement than '', ''', and other non-standard markup used at Wikipedia (see Technical Details). Wikipedia is the leader in these matters. Our developers have the capacity to innovate, and others would almost certainly respect their precedent, and follow it.

Objection 8
The new markup is unintuitive, and unlike anything we have already.

In fact it is quite intuitive, at least for editors who are already used to '' and '''. Beginners have to learn that markup: the new markup simply uses , instead of ': similar but distinct characters, both with their own stand-alone uses as apostrophe (or single quote mark) and comma, and both also used in markup.

Objection 9
Markup with commas is impractical, and a dead end in development.

The comma markup has potential to be extended in all sorts of useful ways. Because a comma hardly ever occurs without a space or a digit after it, it is quite readily available for alternative use. We might in future consider markup like this: ,., (to force a break: equivalent to ; ,--, (for an en dash: equivalent to – or –); and so on. Such markup could be combined: ,,,--, (for an en dash with a hard space before it: equivalent to  – or  –). But any such extensions would be negotiable. Accepting the present proposal does not commit anyone to any such extensions.

Objection 10
German and some other European languages use the character „ as an opening quote. Markup with ,, could easily be confused with that; and that markup might be needed in future for „ or for some other purpose.

In fact there is little likelihood of the two being confused. Their appearances on the screen in common fonts are less similar than the appearances of '' and " are: and we all live with those quite happily. As for reserving ,, for some other purpose, the present proposal makes its own strong case. If others want to make their claim as well, well and good. But we see no evidence of any such claim; and the hard space is of such importance that it is unlikely to be trumped by anything more pressing. After all, those who use „ already have their own established ways of inputting it, just as we do for ".

Objection 11
Other changes in the wiki-markup system would be more sweeping and more "wiki-like".

Certainly the suggestion is unusual in that it proposes substitution of the single HMTL-entity   for the single marker ,,. But the fact that this is easy to implement is not a principled objection, and certainly not a convincing technical objection. The logic of the subsitution is laid out in full above. As for the possibility of overall changes that would make this change redundant, this can be no serious objection either. We have been promised solutions to problems like the one we address here for a long time; but they are not forthcoming, and there seems to be no consultation about them beyond the technical development community within Wikipedia. The present problem has been identified by serious, active editors concerned with style and ease of use, and we find that the proposed solution does all that is needed. If a better solution eventually comes along, no harm has been done in the meantime.

Objection 12
It's all too hard! How can editors bring about a change like this?

It is hard work to bring about such a change. But the rewards for this simple innovation are significant. And Wikipedia is made up of editors with good ideas that they pursue energetically. That's really what it's all about! Developers and decision-makers will take seriously a proposal that grows out of the concerns of competent and committed editors.

4. Implementation

After appropriate discussion at WT:NOWRAP, and possibly at MetaWiki, the coding and system changes for the new markup are a matter for developers. This proposal simply outlines the desired behaviour of the markup (see full specification in Technical details, above), and responds to predicted and actual objections so far.
Once the new feature is in place, it would remain harmless and unnoticed by most editors, since they would rarely if ever input two adjacent commas. (This is a virtue of the proposed markup, in fact.) The community will therefore need to be informed of the change. This can be done at a variety of forums, including:

Village pump (proposals); Village pump (technical); Village pump (policy); and other Village pump pages

Manual of style; Manual of style (dates and numbers); and other MOS pages and talkpages

Various community noticeboards

Helpdesk; New contributors' help page; How to edit a page; Cheat sheet; and other articles outlining basic editing and markup

The details can be determined once the new markup has been accepted for incorporation. In the meantime, nothing is lost through uncertainty and confusion, since the proposal adds a feature, but does not take anything away. In this respect it is safer than almost any alternative. For example, :: has meanings in mathematics (and : has meaning in current wiki markup); ;; may occur when HTML entities fall adjacent to a semicolon (and ; has meaning in wiki markup); `` has a meaning in some existing systems of wiki markup; etc.
By notifications as outlined above, and through general community interactions, the new ,, feature should soon become a part of accepted practice, just as '' and ''' are already accepted and appreciated.

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)

[edit] Remark 1

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

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)

[edit] Remark 2

Even coding

x TEXT y

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

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

x TEXT 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)

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

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

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

[edit] In defence of nowrap

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

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)

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)

For this particular case, a solution that works as intended in both IE and Firefox uses the HTML code for zero-width space:

aaaaaa–bbbbbbb

In the extensions section this is currently proposed by markup ,^,, leading to

aaaaaa–,^,bbbbbbb

−Woodstone (talk) 12:31, 26 January 2008 (UTC)

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 °C allow breaks which may be undesireable. J ɪ m p 07:04, 27 January 2008 (UTC)

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)

[edit] Nowrap how-to guide

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)

Template talk:Nowrap

From Wikipedia, the free encyclopedia

Contents

[edit] Replaces <nobr>

[edit] Stronger than non-breaking spaces

[edit] Template nowraplinks

[edit] Change of page code / looks

[edit] Even shorter coding

[edit] Template behaviour: two problems

[edit] Problem 1

[edit] Problem 2

[edit] Remark 1

[edit] Remark 2

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

[edit] In defence of nowrap

[edit] Nowrap how-to guide

Views

Navigation

Interaction

Search