Template talk:Nowrap begin

Template:Nowrap begin is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.

Any contributor may edit the template's sandbox. This template does not have a testcases subpage. You can create the testcases subpage here.

Helper templates

If you need any more helper templates, such as other symbols as list separators (with built in wrap function), then leave a note on my talk page and I'll code them up for you. I can imagine that people might want ndashes, mdashes and pipes like {{–wrap}}, {{—wrap}} and {{!wrap}} or perhaps something even more fancy? But I think I will wait to make them until they are asked for. --David Göthberg 14:11, 23 August 2007 (UTC)[reply]

Couldn't help myself so I coded up some of them some day ago. But if anyone wants some other just tell me. --David Göthberg 16:52, 25 August 2007 (UTC)[reply]

{{·wrap}} and {{•wrap}}

Psantora: You changed the code for the helper templates {{·wrap}} and {{•wrap}}. You changed from this code:

<includeonly> • </span><span style="white-space:nowrap"></includeonly>

To this code:

<includeonly>&nbsp;•</span> <span style="white-space:nowrap"></includeonly>

I am curious why you did it? Can you give some examples of pages (and web browsers) where they malfunctioned?

Remember that these helper templates may only be used in sections surrounded by {{nowrap begin}} and {{nowrap end}} or they may cause weird behaviour of your page.

--David Göthberg 00:52, 24 August 2007 (UTC)[reply]

I was using {{·wrap}} on {{Apple hardware since 1998}} and there were wrapping problems around the · when it came right after wikimarkup italics ''. I changed the code so it works properly in that situation. Probably should have explained that in the edit summary... Sorry for the confusion. Does that clear things up? Paul^C/_T+ 01:53, 24 August 2007 (UTC)[reply]

Here is an example of the problematic code:

Test:{{nowrap begin}}''Hello! '''·''' Goodbye.'' '''·''' ''These bullets should wrap correctly, '''·''' but they may not '''·''' because of the italics.'' '''·''' Without the italics '''·''' it should work just fine. '''·''' Try it out. '''·''' Vary the width on this page '''·''' and see which bullets wrap '''·''' and which ones don't.{{nowrap end}}

And again with the code I changed it to:

Test:{{nowrap begin}}''Hello! '''·''' Goodbye.'' '''·''' ''These bullets should wrap correctly, '''·''' but they may not '''·''' because of the italics.'' '''·''' Without the italics '''·''' it should work just fine. '''·''' Try it out. '''·''' Vary the width on this page '''·''' and see which bullets wrap '''·''' and which ones don't.{{nowrap end}}

And the same thing using the template:

Test:{{nowrap begin}}''Hello!{{·}}{{wrap}}Goodbye.''{{·}}{{wrap}}''These bullets should wrap correctly,{{·}}{{wrap}}but they may not{{·}}{{wrap}}because of the italics.''{{·}}{{wrap}}Without the italics{{·}}{{wrap}}it should work just fine.{{·}}{{wrap}}Try it out.{{·}}{{wrap}}Vary the width on this page{{·}}{{wrap}}and see which bullets wrap{{·}}{{wrap}}and which ones don't.{{nowrap end}}

After mocking up this example code I see it is a problem with the bold markup with the ·... There was no reason, other than uniformity, to change the code for the •wrap template... My apologies... Paul^C/_T+ 02:14, 24 August 2007 (UTC)[reply]

I have no idea why, but your change created a new problem. You can see it in the above italicized sentence that uses the template. It doesn't wrap as it should and the italics are all messed up. Very odd. Paul^C/_T+ 02:54, 24 August 2007 (UTC)[reply]

Yeah, I was testing things while you wrote the above. I have found the cause and it is really nasty, it seems to be kind of a bug in MediaWiki. I took a look at the HTML that get rendered in the different cases. If we use wiki markup for italics or bold then one of our  gets changed to  or , while the position that should hold the end italics or end bold instead become a . My guess what happens is that MediaWiki first changes our wikimarkup for for-instance bold '''text''' first to text then in the second sweep it tries to change bold spans to HTML markup text. Problem then is that our nowrap spans and the bold spans are overlapping each other so the wrong end span tag gets converted to a .

So it isn't exactly a bug since MediaWiki does the right thing in each sweep. Problem is that it takes the detour over bold spans instead of converting wikimarkup directly to HTML markup. Of course, even if MediaWiki did convert directly in one sweep it would mean we are violating HTML rules when we let our nowrap spans overlap bold or italics sections. Although we have been spoiled with web browsers that usually handle that well.

I have to think for a while what we should do now.

--David Göthberg 03:26, 24 August 2007 (UTC)[reply]

Hmm... what about just using straight html  tags to begin with like this:

<includeonly>&nbsp;<b>·</b></span> <span style="white-space:nowrap"></includeonly>

I'm still learning this whole web development thing, so I would just change it to that and see, but you seem to do very thorough testing so I figured I would propose the change this time instead of being bold... btw, the current {{·wrap}} code is breaking the italics in {{Apple hardware since 1998}}... A bunch of older hardware isn't italicized when it should be. I can fix it, but I'd rather we got this template working correctly. Thoughts? Paul^C/_T+ 04:00, 24 August 2007 (UTC)[reply]

Ah, great minds think alike! I was just running some tests with different ways of bolding the dot including that way. And yes, simply using · seems to do the trick. I just need to test it a bit more. If that doesn't work I have one more trick up my sleeve, to use a div tag for the bolding! But the · seems to work and is shorter which is a good thing when hundreds of dots are used on a page.

And yes, with the current code we use and the current way MediaWiki seems to work you should get the problem that items after the dot do not get italicised. I see the same phenomenon in my testing. But it seems with · everything will be all right.

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

Okay, apparently I'm crazy because there doesn't seem to be a problem with the apple hardware template anymore even before the code changed. I'm not really sure what is going on, but is it possible that the bug is intermittent? The example code on this page is still broken however... Anyway, I need to pack it in. I'll check in with this in a few days. Good luck!

Oh, and I saw you testing that same code right after I posted my comment here. Funny. Anyway, thanks for doing the legwork on this. These new templates are great. I'm using them all the time! Paul^C/_T+ 04:20, 24 August 2007 (UTC)[reply]

Regarding bugs then anything is possible. But perhaps it just is some page rendering and cache delays? I sometimes have to purge the Wikipedia cache for a page for it to render properly. And yeah, I need to get into bed too. Probably good if we leave it be some day. If nothing else it might flush away any cache/rendering delays meanwhile. Oh, and I tested using div tags but they made it way worse. So far it seems the best code we have is:

<includeonly>&nbsp;<b>·</b></span> <span style="white-space:nowrap"></includeonly>

At least in my testing it seems to mostly work well even with italic text. But still fails when surrounded by bold text. I don't think we can fix the bold text problem.

By the way, are you sure we need the   ? In the three browsers I have it works well without it. Would be nifty to have a collapsing space before the dot too so it can tolerate one or more spaces before it and still just render one space before the dot. But not that important.

Anyway, I am happy to hear you enjoy the templates.

--David Göthberg 05:44, 24 August 2007 (UTC)[reply]

Testing

I've tested different versions of the code (albeit using preview and actual code, not actually transcluding a template...) and the · will get pushed to the next line without the non-breaking space... I haven't tested the • template. It could just be a Safari thing tho. You know you can test with Safari on Windows now... Just FYI. Also, it seems we have run into this problem before. Maybe it is better to have consistent code throughout the four ({{•}}, {{•wrap}}, {{·}}, {{·wrap}}) templates? Paul^C/_T+ 13:00, 24 August 2007 (UTC)[reply]

Ok, thanks for the detailed report. So we have to use   for our "helper templates" to work correctly in Safari. (I guess I will download and install Safari too. Hope it runs on my WinME. And don't laugh. My WinME has ran flawlessly without reinstall since spring 2001. Must be some kind of world record.) I have added an example with all the helper templates in the {{nowrap begin}} documentation so you can easily test their behaviour. Feel free to add the   to all of them if they malfunction. But test first, it might be the bolding that causes it.

And regarding "run into this problem before": This isn't the exact same case since I later figured out that in Firefox, IE and Opera it isn't the space before the dot that causes the line break alone, it is the start or end of span + a space that causes it. And that "start/end of span" is what I use in {{wrap}} since it has no space, just a end of span and start of span. Oh, could you please test that {{wrap}} works on Safari? And I guess I have to test what happens with {{wrap}} if it is used without a space before or after it. (Its OK if it doesn't wrap then, just curious.) --David Göthberg 13:58, 24 August 2007 (UTC)[reply]

Now this was fun: In Opera {{wrap}} wraps even if not having any spaces before or after it at all. While in Firefox and IE {{wrap}} only wraps if it has a space before or after it, just as I expected. (Note, spaces in the surrounding code/text, not inside the {{wrap}} itself.) But Anyway, that is OK, since in just any reasonable usage case {{wrap}} should be used with at least one space on some side. Now I'd like to hear how it works in Safari? --David Göthberg 14:31, 24 August 2007 (UTC)[reply]

I've tested the current versions of the template code in the latest version of Safari on {{nowrap begin/doc}} using bold or italics (I also tested them together, but I will address this case in a second) that both end before and travel through each {{*wrap}} template, with spaces and without. I've also tested the spacing without any wiki formatting markup. {{·wrap}} works correctly in all cases (except the bolditalics case). {{wrap}} works similarly to Opera, when there are no spaces it doesn't wrap correctly, otherwise it is fine, even when using bold or italics (but not both). {{!wrap}}, {{•wrap}}, and {{–wrap}} all wrap incorrectly when using markup that travels through a wrap tag, however, the markup is correct even if the separator doesn't wrap correctly; when there is no wiki markup or if the markup is closed correctly before passing through a template they work without an issue, regardless of spacing. Bolditalics did not wrap correctly AT ALL when it passed through a template, but if closed correctly it works without issue. So, solely due to the issue with bold and italics markup when traveling through the wrap templates, {{!wrap}}, {{•wrap}}, and {{–wrap}} could be changed to the code with   similarly to how {{·wrap}} is coded. So either there are very explicit instructions on {{nowrap begin}} regarding using text formatting or we should change the code to include non-breaking spaces. I'm not sure which would be more appropriate, but at least we have a better handle on the issue. I'd prefer having the non-breaking space, but I'm just one person. Paul^C/_T+ 18:29, 24 August 2007 (UTC)[reply]

Yes, I agree. Let's use the   on all the templates. I prefer to make things as easy to use as possible for our users (Wikipedia editors), and using the   on all the helper templates now seems to be the most userfriendly alternative. But of course we should also explain on the doc page that bold and italics should not be used around those templates, but instead closed before it and then started again after it. I feel slightly silly that I didn't come up with the idea to test the bold+italics case myself. But as they say: "With many eyeballs all bugs are shallow."

So I'll go right ahead and change the helper templates to use   then I am going to bed so I'll do more testing tomorrow. (I am tired after a long night dancing with the girls. :))

--David Göthberg 03:48, 25 August 2007 (UTC)[reply]

Testing with bold and italics

Most of the helper templates

Most of the helper templates has the same code as the "bullet wrap" {{•wrap}} so they should work the same.

1. Normal usage of "bullet wrap" with no bold or italics:

Salt • Pepper • Curry • Saffron • Salt • Pepper • Curry • Saffron.

2. Bullet wrap with wikimarkup bold around the whole line:

Salt • Pepper • Curry • Saffron • Salt • Pepper • Curry • Saffron.

3. Bullet wrap with wikimarkup italics around the whole line:

Salt • Pepper • Curry • Saffron • Salt • Pepper • Curry • Saffron.

4. Bullet wrap with wikimarkup bold and italics around the whole line:

Salt • Pepper • Curry • Saffron • Salt • Pepper • Curry • Saffron.

5. Bullet wrap with HTML markup bold and italics around the whole line:

Salt • Pepper • Curry • Saffron • Salt • Pepper • Curry • Saffron.

The middot wrap

The "middot wrap" {{·wrap}} internally uses code to bold the dot, thus it might work slightly differently.

11. Normal usage of "middot wrap" with no bold or italics:

Salt · Pepper · Curry · Saffron · Salt · Pepper · Curry · Saffron.

12. Middot wrap with wikimarkup bold around the whole line:

Salt · Pepper · Curry · Saffron · Salt · Pepper · Curry · Saffron.

13. Middot wrap with wikimarkup italics around the whole line:

Salt · Pepper · Curry · Saffron · Salt · Pepper · Curry · Saffron.

14. Middot wrap with wikimarkup bold and italics around the whole line:

Salt · Pepper · Curry · Saffron · Salt · Pepper · Curry · Saffron.

15. Middot wrap with HTML markup bold and italics around the whole line:

Salt · Pepper · Curry · Saffron · Salt · Pepper · Curry · Saffron.

The plain wrap

The plain "wrap" {{wrap}} differs from the others since it does not internally have any   or normal space before the first span tag. But at the moment it has a normal space between the span tags, just like the others.

21. Normal usage of "wrap" with no bold or italics:

Salt Pepper Curry Saffron Salt Pepper Curry Saffron.

22. Wrap with wikimarkup bold around the whole line:

Salt Pepper Curry Saffron Salt Pepper Curry Saffron.

23. Wrap with wikimarkup italics around the whole line:

Salt Pepper Curry Saffron Salt Pepper Curry Saffron.

24. Wrap with wikimarkup bold and italics around the whole line:

Salt Pepper Curry Saffron Salt Pepper Curry Saffron.

25. Wrap with HTML markup bold and italics around the whole line:

Salt Pepper Curry Saffron Salt Pepper Curry Saffron.

The pipe wrap

The "pipe wrap" {{!wrap}}, at the moment with a normal space instead of a   for testing purposes. (No one is using this template yet so ok to experiment with it for the time being.)

31. Normal usage of "pipe wrap" with no bold or italics:

32. Pipe wrap with wikimarkup bold around the whole line:

33. Pipe wrap with wikimarkup italics around the whole line:

34. Pipe wrap with wikimarkup bold and italics around the whole line:

35. Pipe wrap with HTML markup bold and italics around the whole line:

Errors

With the current version of the templates we use (they all use   now) I get the exact same errors in all three browsers I have (Firefox 2.0, IE 5.5 and Opera 9.02). So I guess I don't have to describe the errors since anyone else testing with any of those browsers will see the same thing. And that is at least a good thing, that most/all editors will see the same errors.

So Psantora/Paul, do they look the same in Safari too? (Sorry, Safari only runs from WinXP and up so I can not install it.) And does the pipe wrap (right now without the  ) look different from the others when using Safari? Sorry, I am stubborn, I really want to make sure if the   is necessary or not. In the browsers I have the   makes no difference. The only example above that differs from the others for me is the "middot wrap".

Note that using bold or italics that starts before and ends after any of the wrap tags really is incorrect HTML. Since it causes the bold/italics to overlap the span tags created by our wrap tags. But I have studied the HTML source that gets rendered and MediaWiki seems to on purpose try to fix those overlaps. And it does so correctly if we use only bold or italics. But MediaWiki fails if we use bold and italics at the same time. And of course, MediaWiki has no chance to fix the overlaps if we use bold around {{·wrap}} since it internally used bold to bold the dot.

--David Göthberg 19:47, 25 August 2007 (UTC)[reply]

After playing around more with examples and code I added a space (a normal collapsing wrapping one) inside the {{wrap}}. That makes it behave better in some cases. It then wraps even if it does not have any spaces outside of it. Sure, it will add a visible space in those cases but that makes it visible that it has been used "wrong" which I think is a good thing. In most other cases the space inside {{wrap}} will collapse together with the spaces outside so no extra spaces gets added. --David Göthberg 21:36, 25 August 2007 (UTC)[reply]

Navbox cleanup?

This discussion was moved here from the talk page of TigerK 69.

I have noticed that you go around removing the {{nowrap begin}} etc tags in many navboxes. The last case was the Template:Google Inc.. So I guess I have to explain to you what they are for: We use those tags on link lists when they word wrap (line break) the wrong way in Firefox and Internet Explorer. (I promise, those link lists that get rendered wrong look terrible. But you use Safari so you wouldn't know.) We also use them on some link lists that wraps in unwanted ways in ALL browsers, not due to browser bugs but simply when we want more control over where wraps end up. One of the editors that uses them the most for that purpose is a Safari user just like you.

So please stop removing the {{nowrap begin}}, {{wrap}}, {{·wrap}} and {{nowrap end}} tags. They are there for very good reasons.

--David Göthberg 03:54, 26 August 2007 (UTC)[reply]

Ok, I didn't know that. What about {{nowrap}}? Everyone is replacing that with {{·}}. —TigerK 69 18:02, 26 August 2007 (UTC)[reply]

Oh dear, that's a short question but it needs a long answer:

Well, the simple case where you have a normal link that doesn't misbehave in the browsers etc and want a dot after can be coded in any of the following manners:

[[Salt]]&nbsp;• [[Pepper]]

{{nowrap|[[Salt]] •}} [[Pepper]]

[[Salt]]{{•}} [[Pepper]]

They all render "Salt • Pepper" and line wrap only after the dot. I guess you can agree on that using the {{•}} causes neater easier to read code, right?

Then there are the more complex case of links with spaces in. Then they might wrap inside the link, and we don't want that. Like these examples:

[[Salt and pepper]]&nbsp;• [[Curry and saffron]]

[[Salt and pepper]]{{•}} [[Curry and saffron]]

Will both risk line wrapping like this:

Salt and pepper • Curry

and saffron

So until now people have then resorted to using   or {{nowrap}} for those cases, like this:

[[Salt and pepper|Salt&nbsp;and&nbsp;pepper]]&nbsp;• [[Curry and saffron|Curry&nbsp;and&nbsp;saffron]]

{{nowrap|[[Salt and pepper]] •}} [[Curry and saffron]]

{{nowrap|[[Salt and pepper]]{{•}}}} [[Curry and saffron]]

Which only can line wrap like this:

Salt and pepper •

Curry and saffron

And it works fine in all browsers. But all of the methods in the previous example give us pretty messy code in long link lists.

So some weeks ago I created the solution {{nowraplinks}}. It is both a set of two templates and a CSS class now added to common.css. Then you only have to surround the whole link list with nowraplinks, instead of using {{nowrap}} around each link, like this:

{{nowraplinks}}
[[Salt and pepper]]{{•}} [[Curry and saffron]]
{{nowraplinks end}}

It will only line wrap between links, just like we want:

Salt and pepper •

Curry and saffron

And we have also added the nowraplinks CSS class in the header of the standard navboxes so now the users in most cases don't even have to surround link lists in those navboxes with anything. But they still have to use {{•}} to avoid line wraps before the dot.

So far so good. But then we got bitten by the browser bugs, and there are cases where we don't want line wraps even in normal text between the links. Like these two cases:

{{nowraplinks}}
[[Salt]] and [[pepper]]{{•}} [[Curry]] and [[saffron]] ...
{{nowraplinks end}}

{{nowraplinks}}
([[Salt and pepper]]){{•}} ([[Curry and saffron]]) ...
{{nowraplinks end}}

The first line above will "correctly" line wrap around the "and" in all web browsers, but we don't want that, we often only want the wraps to happen right after the dots. And the second line with parenthesis around the links will behave VERY odd in both Firefox and Internet Explorer. (But Opera and Safari seems to handle the parenthesis case perfectly.) Note that these browser bugs only happen when we use nowraplinks.

So one solution that works perfectly is to go back to old school   or {{nowrap}} for those cases. But as before that gives very messy code in long complex link lists.

So since I am a programmer that like to think outside the box I thought: So why not use negative logic instead, and instead tell the web browser where wraps may occur? And since we anyway mostly are using the {{•}} exactly at those positions lets make a similar template that tells the browser where wraps may occur. So I coded that up as the {{nowrap begin}} and its "helper templates". Its used like this:

{{nowrap begin}}[[Salt]] and [[pepper]]{{•}}{{wrap}}[[Curry]] and [[saffron]] ...{{nowrap end}}

{{nowrap begin}}([[Salt and pepper]]){{•}}{{wrap}}([[Curry and saffron]]) ...{{nowrap end}}

Both the lines above will only line wrap after the dots, and they will behave perfectly in all browsers we tested so far: Firefox, IE, Opera and Safari. Sure we have to add a {{nowrap begin}} before the list and a {{nowrap end}} after the list. But for a long list that is nothing, since inside we only have to use the {{•wrap}} and perhaps the occasional {{wrap}}.

Note that for long lists I prefer to put each "item" on its own line since that gives us more readable and easier to maintain code, which prevent editors from making mistakes. ~~When we do that in navboxes or other wikitables then we have to surround it with some div tags otherwise the navbox/wikitable behaves weird.~~ (The div tags are not needed anymore.)

So I usually do like this:

{{nowrap begin}}
[[Salt]] and [[pepper]]{{•}}{{wrap}}
[[Curry]] and [[saffron]]{{•}}{{wrap}}
([[Salt and pepper]]){{•}}{{wrap}}
([[Curry and saffron]])
{{nowrap end}}

Our navboxes already use the nowraplinks class in their headers and this works well for most link lists. Thus so far most of us have only bothered to convert those link lists that misbehave to use {{nowrap begin}}. (But I prefer to at least convert the whole link list, not just part of it, since that makes more readable code.) That is why you may see navboxes with just some of the link lists converted.

--David Göthberg 19:42, 26 August 2007 (UTC)[reply]

{{wrap}} in {{nowrap}}?

Can you use the {{wrap}} template within the {{nowrap}} template to allow wraps where you want them? Or will the closing braces break it?

It seems to work when I test it out, but is there something I'm missing? Will {{nowrap|Non-wrapped text.{{wrap}}(br, if needed) More non-wrapped text.}} work?

~ Paul^T+/_C 18:20, 18 February 2008 (UTC)[reply]

Since I was the one that created {{wrap}} I guess I should answer this. I took a look at the code for {{nowrap}} and {{wrap}}. And yes, {{wrap}} should work inside {{nowrap}}. (But I have not tested it at all so I don't know for sure.) However that is not an intended use and future changes to the code of {{wrap}} or {{nowrap}} might break that since they were not intended to be used together. Thus to avoid future problems I suggest you use {{wrap}} the way it was intended:

{{nowrap begin}}
Non-wrapped text.{{wrap}}(br, if needed) 
More non-wrapped text.
{{nowrap end}}

(By the way, I took the liberty to edit your question slightly for readability. Just revert it if you dislike it.)

--David Göthberg (talk) 05:27, 21 February 2008 (UTC)[reply]

{{nowrap begin}} – {{·wrap}} – {{nowrap end}}

This discussion was moved here from the talk page of David Göthberg.

Hi David,
Your wikibreak message above nothwithstanding, I noticed you'd recently added to {{nowrap begin}}'s talk page, so I thought I'd try asking the following.

I've recently discovered the above combination while trying to streamline some templates, diligently using {{·}} as a wrap-sensitive and more discreet divider than the bullet or vertical-line characters. I've noticed, though, as I think you/Psantora have, that it's not ideal in that it can step over borders/margins occasionally. I'm hoping, therefore, that the above combination you've devised is the solution – but, having scanned {{nowrap begin}}'s talk page, I'm no longer so confident. So, I'm simply wondering if you/Psantora reckon it (still) is the solution, or have left it as an almost-ran like {{·}}...?

If it is the solution to {{·}} drawback, then I'm up for:

Asking for {{·}} to be renamed, so {{·wrap}} may take over its short name;
Asking for a bot to work through all the templates using {{·}} (and its more obtrusive alternative {{nowrap| ... •}}) inserting {{nowrap begin}}s and {{nowrap end}}s at the starts and ends of lists within.

What do you think? As you're meant to be on a wikibreak, I wouldn't ask for anything more than your confirmation/approval! Thanks, Sardanaphalus (talk) 23:00, 22 February 2008 (UTC)[reply]

Ehm, your question/suggestion is a tricky one to answer. Especially since it is some time since I worked with this stuff. I hope my response here will be technically correct...

Short answer: For technical reasons I do not agree with your suggestion.

Long answer:

1: As far as I remember the "floating over the right border problem" with the usual link lists occurred in Firefox and Internet Explorer but not other web browsers, and was only really bad when some of the links in the list contained parentheses "( )". I don't remember if we found any other special characters or situations that caused the same problem. So I think the fix is only needed when a link list contains parentheses. Note that this "floating over the right border problem" occurs no matter what separators we use in the list, it is not a problem with the dots, it is only a problem with the parentheses. Oh, and I think the problem only occurred when using {{nowraplinks}} or the nowraplinks CSS class. {{nowrap begin}} – {{·wrap}} – {{nowrap end}} solves that problem even if the list is still surrounded by the nowraplinks tag or class.

2: The "bold middot" · is the dot size most people prefer for dotted lists. However that specific size we can only achieve by BOLDING a middot. And that causes problems when using {{nowrap begin}} and {{·wrap}} on a line of text that is bolded or italicised. Then you have to end the bold/italics text before the {{·wrap}} and then start the bold/italics text after it again. And it didn't matter what kind of notation one used for the bolding (wikimarkup, the HTML bold tag or the HTML/CSS span font-weight:bold tag), the problem still occurred. It's because Wikimedia rendering internally converts all kind of bold tags to the "HTML/CSS span bold tag", then does some usually good conversion that solves other problems but in our case instead causes a problem... (Wikimedia usually do "smart" handling of overlapping bold/italics tags but in our case thus confuse which end span tag is which.) Note that the other separators like bullet {{•wrap}} and pipe {{!wrap}} only get into trouble when the text line is bolded and italicised at the same time, which is a rare problem.

So the {{nowrap begin}} + {{·wrap}} + {{nowrap end}} has problems with bold or italicised text the way some editors use it. While I think the old {{·}} does not have that problem since it works differently.

3: Also note that the bold middot {{·}} is sometimes used in other places than in lists. That is, sometimes as a single occurrence. So if we renamed {{·wrap}} to {{·}} then the editors would be forced to write {{nowrap begin}} – {{·}} – {{nowrap end}} just for one single use. That would be evil...

So I think we have to keep using two solutions. Well three solutions really:

{{·}} for simple use in text.
{{nowraplinks}} + {{·}} + {{nowraplinks end}} for normal linked lists. But note that the nowraplinks CSS class is built into the {{navbox}} so most users don't need to be aware of {{nowraplinks}} and can simply just use {{·}}.
{{nowrap begin}} + {{·wrap}} + {{nowrap end}} for linked lists that "float over the right border" (usually due to having parentheses) or has non linked text that we don't want to wrap either.

Oh, and I guess all this should be further tested so we know exactly what happens and what is the best usage. And then documented as a Wikipedia "how-to guide" with code examples etc. And that guide should be linked from all nowrap related templates and pages.

--David Göthberg (talk) 01:04, 23 February 2008 (UTC)[reply]

Thanks for your comprehensive reply. Point 1 intrigued me as I didn't know the "[something] wraps but [something]{{·}} doesn't" problem was limited to Firefox/IE (I missed its mention above; apologies). I'm also intrigued to learn of the "bolding problem" (point 2), as I've yet to stumble across it. So, I guess my impression is that this bolding problem with {{nowrap begin}}+{{·wrap}}+{{nowrap end}} is sufficiently rare to make a strong case for incorporating {{nowrap begin}} and {{nowrap end}} in the navbox code handling lists, leaving folk to use {{·wrap}} as the list item divider. My instinct is to believe this can be done in a way that can handle cases where folk use something else as a divider (despite encouragement otherwise). Hence, with no need to prefix/suffix lists with {{nowrap begin}}/{{nowrap end}}, folk would only need to be inputting/pasting {{·wrap}} in their navbox code – which would much less verbose if it could be renamed {{·}}. Perhaps a bot could be tasked to work through renaming the current {{·}} as (say) {{nbsp·}} in all pages that aren't templates, leaving the way open for {{·wrap}} to be renamed {{·}}...? Or, perhaps better still, the current {{·}} could be made to detect whether its being used in a navbox template (hence use the current {{·wrap}} code) or elsewhere (hence use the current {{·}} code)...? Thanks again for your input. Sardanaphalus (talk) 08:22, 24 February 2008 (UTC)[reply]

Actually, you are right and you are kind of right. :)

That is, yes I agree that the bolding problem (point 2) probably is sufficiently rare that we can more or less ignore it. I just wanted to mention it here for completeness. And the documentation for {{·wrap}} which is at {{nowrap begin}} do explain the problem so people should be able to find out what the problem is and fix it if they stumble on it.

And yes, I too think we can make bold middot {{·}} autodetect when it is inside {{nowrap begin}} + {{·}} + {{nowrap end}} and then make it behave like the current {{·wrap}}. And I think I know how to do it since I used similar CSS tricks before. However, that will be pretty tricky and might cause a lot of confusion in some other situations. And for web browsers that doesn't support that CSS trick it will probably wreak havoc. (I wish we had variables we could set and check in Wikimedia markup so all this could be done at the server side and thus be more independent of what web browser the user has.)

If we do it, then we will have to modify bold middot {{·}}, bullet {{•}} and perhaps ndash {{–}}, mdash {{—}} and some more. Modifying {{!}} that way will be risky since that one is used inside a lot of advanced template code so we should probably not touch that one. Instead if they want a pipe separated list I guess we will have to force them to use {{!wrap}} instead.

But if we do it it might be easy to do the conversion. Since then first we can have a bot change all occurrences of {{·wrap}} to {{·}} etc in all navboxes. Then change the navboxes to use {{nowrap begin}} and {{nowrap end}}.

However I am very hesitant. Since:

There are a LOT of different navboxes.
This will only work right in the web browsers that support that CSS trick.
This will make the code for {{·}} very complex and will confuse future template editors that want to service / update the {{·}} template.
And I don't think it is so bad to use the full {{nowrap begin}} + {{·wrap}} + {{nowrap end}}. Especially since this is only really needed on the lists that contain parentheses "( )". Sure, even other {{nowraplinks}} + {{nowraplinks end}} surrounded lists do float onto or close to the box border in Firefox and IE, but they only float far over the box border when there are parenthesis.

So I think I just came up with a simpler solution. Let's make shorter names for {{·wrap}} etc. Like this: {{nowrap begin}} + {{·w}} + {{nowrap end}}

What do you think?

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

I have now created such short names for most of the helper templates and added them to the documentation of {{nowrap begin}}.

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

Floating over the border problem

Now I have been editing some navboxes. I have noticed that the really bad "floating over the right border problem in Firefox and Internet Explorer" occurs when link lists contain any of:

Parenthesis ( ).
Quotation marks " ".

So that is the situations when we need to use {{nowrap begin}} + {{·wrap}} + {{nowrap end}} since it solves that problem.

As I've mentioned before, this only happens when a link list uses {{nowraplinks}} or its CSS class. But we use that CSS class in {{navbox}} thus this happens a lot. Note that not using {{nowraplinks}} would mean having to use {{nowrap begin}} + {{·wrap}} + {{nowrap end}} on all link lists which would be more work and more code.

See examples at Template talk:Nowraplinks#Floating over the border problem.

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

Thanks, David, for this detective work and your coding work prompted by the previous thread - and for your note on my talkpage! Apologies not to've responded more promptly.

It looks to me that all that's now required is:

including your first paragraph above in the Navbox documentation;
perhaps comandeering a bot to amend all templates that feature {{·}} and parentheses/quotation marks in their lists so they use {{nowrap begin}}+{{·w}}/{{•w}}+{{nowrap end}} instead. Do you think that's possible/worthwhile?

Sardanaphalus (talk) 12:18, 26 February 2008 (UTC)[reply]

0: Well, both yes and no. The result I mention above about parenthesis and quotation marks is not complete. I have read that Internet Explorer causes problems at some other special characters too like the normal dash "-" etc. but I have not had the time nor interest enough to check all that. So this do need more checking and testing. But I really just popped into Wikipedia to answer some questions about the templates I made six months ago. I don't really have the time to work on Wikipedia anymore.

1: I am thinking of writing up all nowrap related advice as a how-to-guide and link to that guide from any related pages, including linking to it from the documentation for {{navbox}}. But sure, go ahead and ad some advice at {{navbox}}.

2: I don't run any bot but I imagine it would be messy to correctly configure a bot to do that conversion. Since from what I have seen when I checked around and edited some navboxes people are miss using those templates so badly that most navboxes have to be hand corrected. But sure, there are so many navboxes that needs to be corrected that a bot probably is the only way to do it.

That people keep using the wrong nowrap solution in the wrong place shows that we must make better documentation for all this. So I think a how-to-guide really is needed. One that covers everything from basic   usage to {{nowrap begin}} + {{·wrap}} + {{nowrap end}} and clearly tells when to use which solution. I might do that some day if I get the time.

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

Now I have investigated this problem further and documented it properly at the new how-to guide Wikipedia:Line break handling.

--David Göthberg (talk) 14:26, 12 March 2008 (UTC)[reply]

Noinclude tags etc

Note, this explanation is only relevant for you that are thinking of changing the code of these templates, not for you that intend to use these templates.

This is an explanation regarding why I reverted the edits done by User:Malyctenar today on the templates {{nowrap begin}} and {{nowrap end}}. I thought the explanation might interest others too so I put it here.

The template code for {{nowrap begin}} and all its helper templates needs to be surrounded by <noinclude> </noinclude> tags. This is because they use negative logic. That is, for instance {{nowrap begin}} begins a  tag but doesn't end it. If it is not surrounded by noinclude tags that span tag and thus the nowrap functionality will affect the rest of the {{nowrap begin}} page, that is it might cause weird behaviour of the documentation page that is shown there.

The same goes for {{nowrap end}}. That one contains an end  tag. If you don't surround that one with noinclude tags you get invalid HTML code on the template page. Also, tradition here at Wikipedia dictates that the working template code should be at the top of the page and the explanation below it. Not the other way around as Malyctenar tried to do it. Also the usage explanation you put there will cause confusion, since for code clarity and correctness any page that use a {{nowrap begin}} should always end that section with a {{nowrap end}}. Ending it in some other way will be confusing to later editors.

The same goes for all the other helper templates such as {{·wrap}} etc. Their template code needs to be surrounded by <noinclude> </noinclude> or you get invalid HTML code with erroneously open span tags and that might cause weird effects on any documentation on those pages.

--David Göthberg (talk) 16:37, 4 March 2008 (UTC)[reply]

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:36, 11 March 2008 (UTC)[reply]

Templates with nowrap problems

I have compiled a list of templates with obvious nowrap problems. (Mostly navboxes.) There are 228 templates in the list. Anyone that is in the mood is welcome to help out to fix them. See the list and read all about it at: List of templates with nowrap problems. That is in no way a complete list of the navboxes with nowrap problems, but those were the easiest to detect. They are likely to be the worst cases. If we fix those ones then other editors might learn from what they see.

--David Göthberg (talk) 07:44, 26 March 2008 (UTC)[reply]

Possible redirects to {{·wrap}}

{{dot}} redirects to {{·}}, which is very useful since a "·" is a non-standard character - at least it's not straightforward to produce.

Before I create them, is there any reason not to have redirects for {{dotw}} and {{dotwrap}} that point to {{·wrap}}? GDallimore (Talk) 11:56, 21 May 2008 (UTC)[reply]

Can't think why not at time of this message, but I've found typing Alt-0,1,8,3 (on a PC) becomes pretty straightforward after a while. Sardanaphalus (talk) 15:18, 21 May 2008 (UTC)[reply]

Agreed, easy when you're used to it. I'm just trying to cater to those who don't do it so often and forget the code (like me :) ). GDallimore (Talk) 15:21, 21 May 2008 (UTC)[reply]

Created {{dotw}} and seems to work. GDallimore (Talk) 18:40, 21 May 2008 (UTC)[reply]

Even though I created these templates I didn't know how to type them and always have to copy and paste the {{·wrap}} or {{·w}} template name. I for one call it "dot wrap" when I pronounce the name. So yeah, {{dotw}} and {{dotwrap}} are pretty decent names for it. I see only two very minor problems: It might cause more confusing code where it is used, since "dotw" doesn't show as good what it creates and having many different names might be confusing. But if you feel {{dotw}} is easier to use, then perhaps you should use it.

GDallimore: And since you said "seems to work": Yes, redirects work for templates so your redirect will work fine if/when used.

--David Göthberg (talk) 02:46, 22 May 2008 (UTC)[reply]

More seemantic and more accessible alternative

{{flatlist}} is available to improve accessibility and semantic meaningfulness by marking up what is clearly a list, as such, rather than using dot characters which are read out ("one dot two dot three dot...") by the kind of assistive software used by, for example, people who are blind. If you wish to propose stylistic changes, please do so at {{flatlist}}. Thank you. Andy Mabbett | Talk to Andy Mabbett 20:45, 28 August 2008 (UTC)[reply]

Oh, thanks for pointing out that method! Yeah, using regular HTML list items like that and then use a CSS class to make the list appear horizontal must be much more accessible for screen readers etc. And it seems very convenient to use from an editor point of view too. And I just tested: At least the basic method you show there also works in my really old Internet Explorer 5.5, so seems pretty compatible.

I'll investigate and see if I can make it look like our current usage with different offers of dots and dashes and proper line wrapping and so on. Seems doable, I have some ideas. And if we can make it work with dots then we could automate it in the navboxes. That is, we can perhaps make it so that dotted lists inside navboxes automatically turn into horizontal dotted lists!

--David Göthberg (talk) 11:32, 29 August 2008 (UTC)[reply]

Thank you; note that the separator is applied in CSS, as a border; there is no HTML character involved. Andy Mabbett | Talk to Andy Mabbett 16:45, 29 August 2008 (UTC)[reply]

Right. And that means if we want dots instead of that vertical line then we have to add a dot character from CSS. Which is possible, but usually is messy. It will take some serious testing...

--David Göthberg (talk) 17:20, 29 August 2008 (UTC)[reply]

Unfortunately after I have tested this and also analysed the different suggested approaches on other discussion pages, I have come to this conclusion: We currently have no way to do horizontal lists by using HTML lists that doesn't break in several of the older browsers, thus we can not use it. So using these nowrap templates still is our best option.

--David Göthberg (talk) 12:24, 20 October 2008 (UTC)[reply]

{{flatlist}} does not "break in several of the older browsers". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:28, 20 October 2008 (UTC)[reply]

I have three browsers installed: Firefox 2.0, Internet Explorer 5.5 and Opera 9.02. The example in the documentation for {{flatlist}} is currently broken in all three of my browsers.

--David Göthberg (talk) 16:18, 20 October 2008 (UTC)[reply]

You don't say how you; think they're broken, nor provide evidence (such as screenshots); are you perhaps mistaking templates which degrade gracefully as being broken? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:27, 20 October 2008 (UTC)[reply]

I have explained to you multiple times on multiple talk pages why that template breaks in many browsers. Among other things it is because it uses the CSS selector ":last-child", which is not supported by the older browsers. That you pretend to not know that is just silly.

And I am actually right now writing up the explanation, again, to put on the talk page of {{flatlist}}. But I don't write that explanation for you, I write it for the benefit of other users so they will not be tricked into using a broken template.

--David Göthberg (talk) 16:47, 20 October 2008 (UTC)[reply]

So, not broken, just a minor aesthetic niggle in deprecated browsers. Thank you for the clarification. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:55, 20 October 2008 (UTC)[reply]

My Firefox 2.0.0.16 version is just a couple of months old, that's not what I call a "deprecated browser".

That your {{flatlist}} template who's main purpose it is to place a list separator between items in a list doesn't place such a list separator between the items in such a recent browser is a major malfunction of the template. And remember, Wikipedia is not only for the rich people who always use the latest computers and thus can run the latest software. We try to make Wikipedia compatible for users with older computers and thus older operating systems and thus older browsers.

--David Göthberg (talk) 18:40, 20 October 2008 (UTC)[reply]

Wikipedia's {{flatlist}} (it's not mine) works just fine for such people; there are only minor aesthetic drawbacks, which someone running out-of-date software must expect. As Firefox tell us, "Firefox 2.0.0.x will be maintained with security and stability updates until mid-December, 2008. All users are strongly encouraged to upgrade to Firefox 3". That sure sounds like deprecation to me. One the other hand, Wikipedia is not only for the rich sighted people who always use the latest computers and thus can run the latest visual software. We try to make Wikipedia compatible for users with sight problems or other disabilities and thus non-visual browsers. {tl|flatlist}}'s main purpose it is not to place a list separator between items in a list; it is to present correctly marked up lists in a horizontal format to sighted users and as semantically-meaningful, parsable list to others. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:37, 20 October 2008 (UTC)[reply]

Created

The middot-nowrapper Template:·w was created by long-term user Davidgothberg on 25 February 2008 as a short name (as a redirect) for Template:·wrap, to be used after {{nowrap begin}}. -Wikid77 08:56, 12 April 2010 (UTC)[reply]

Identical wrapping as Template:·wrap

The short-named, middot-nowrapper Template:·w is intended to be a short name for the older nowrapper Template:·wrap, and to provide the identical results for inserting a bolded middot. The difference is just in having such a very-short template name to be repeatedly specified within long lists of wikilinks in navboxes. -Wikid77 08:56, 12 April 2010 (UTC)[reply]

Change to bypass Template middot-wrap

{{editprotected}} 12-Apr-2010: The middot-nowrapper Template:·w should be replaced from Template:·w/sandbox to directly specify the nowrap markup, and no longer re-direct to Template:·wrap. As of 8 April 2010, the transclusion count for Template:·w had reached 218,829 pages, and there is no need for edit-preview of those many thousand pages to also list Template:·wrap (as a redirect target). Instead, Template:·w should just directly contain the middot-nowrap-span markup as in Template:·wrap, and no longer drag {·wrap} into those "218,829" pages. The table, below, lists test-cases which show the sandbox version as functionally identical, even though it directly inserts the middot-markup, quickly, without using any other templates.

Table of test-cases for {{·w}}
The following examples use {{·w}} for ''Currently'', versus {{·w/sandbox}}: Currently: aa · bb · cc Sandbox: aa · bb · cc
Currently: multiple words 1 · multiple words 2 · multiple words 3 Sandbox: multiple words 1 · multiple words 2 · multiple words 3
Currently: longer list · showing · multiple words · which should not · be wrapped between middots. Sandbox: longer list ·showing · multiple words · which should not · be wrapped between middots.
Currently: aaa · · · · · zzz Sandbox: aaa · · · · · zzz

After the update, then the above table should still show identical results, until the sandbox version is later modified for some other change.

Transclusion counts: The usage count for the older, bypassed Template:·wrap should then drop about -85%, from 257,600 to around 39,000 transclusions, dropping in rank from 104th to become the 380th most-used template on the English Wikipedia. -Wikid77 (talk) 08:56, 12 April 2010 (UTC)[reply]

Done Ronhjones ^(Talk) 00:42, 13 April 2010 (UTC)[reply]

Edit request from Jgulbis, 5 January 2011

{{edit protected}} Vanuatu citizens may remain in Vanuatu indefinitely, not 1 month as currently stated under vanuatuan passports.

Jgulbis (talk) 08:12, 5 January 2011 (UTC)[reply]

This seems unrelated to this template. —TheDJ (talk • contribs) 10:15, 5 January 2011 (UTC)[reply]

Nowrap_begin#Technical_details sample HTML

Is the Template:Nowrap_begin#Technical_details sample HTML code as intended? The sequence   looks odd. NeilOnWiki (talk) 16:40, 20 January 2021 (UTC)[reply]