Template talk:Wbr

Outdated

I guess this template is outdated. Not working in IE8 - renders as a space. Jack who built the house (talk) 15:51, 14 July 2011 (UTC)

Actually it was a wiki engine issue, it removes all empty tags. I replaced space with  . Now it works fine: ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss​ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss. Jack who built the house (talk) 16:22, 14 July 2011 (UTC)

Ah sorry,   is no good replace. Decision found is display:inline-block + ​ : display:inline-block helps to produce a break, and ​ (zero-width space) will appear if the text is copied, and produce a break if, for some reason, inline-block has failed. Actually, could've put even   here (despite its opposite function). May be I should, because I'm not sure what will ​ look like in older browsers and text editors (after being copypasted). Notepad renders it as a space. Jack who built the house (talk) 16:55, 14 July 2011 (UTC)

Suggest using {{indented plainlist}} for controlling line breaks?

The section Template:Wbr § Controlling line-breaking in infoboxes suggests a lot of manual control to create a list with pseudo-hanging indents, where the "indentation" is merely nbsp;s. A better method to achieve the same effect, but better-looking, and less "futzy", is to use {{indented plainlist}}:

Test Infobox II: The Revenge
Starring	Jane Smith Johannes-Friedrich Zauberzunge von der Hasenpfeffer Jean-Jacques Francois Jacques-Jean John Garcia

{{Infobox film
|name=Test Infobox II: The Revenge
|starring={{indented plainlist|
* Jane Smith
* {{nobr|Johannes-Friedrich}} Zauberzunge {{nobr|von der Hasenpfeffer}}
* {{nobr|Jean-Jacques}} Francois {{nobr|Jacques-Jean}}
* John Garcia
}}
}}

Should this be recommended instead?  — sbb (talk) 02:53, 24 August 2021 (UTC)

< wbr /> causing unintended line breaks

Just in case <wbr/> (and this template {{wbr}}) causes unintended and unexpected line-breaks for someone, using (only) &zwsp; might be a solution. See Template_talk:R#Line_breaks. --Matthiaspaul (talk) 14:07, 1 September 2021 (UTC)

transclusion count not accurate?

According to recent discussions, this template is being used on about 53,000 pages. However, the transclusion count tool shows only 1,530 transclusions. Is the tool no longer accurate? Or did we change most of those pages to not rely on this template? Ixfd64 (talk) 18:48, 1 September 2021 (UTC)

@Ixfd64: I think this is a direct-vs-indirect transclusion count issue. It may have only 1945 direct transclusions, but if you include templates which include {{wbr}} in their expansion, a change to {{wbr}} would affect tens of thousands of pages. 97.102.205.224 (talk) 17:54, 26 November 2024 (UTC)

Could we document the reason for wbr + zwsp?

@SMcCandlish: I notice that since Special:Diff/681420843 (2015) the template expands to <wbr />&8302;. After some recent edits fighting with zero-width space characters, I'm growing to hate them. They get cut and pasted easily and mess things up when they appear in context that don't expect them. So for example, {{val|1​520​698​109​714​272​166​094​258​063}} produces for reasons that are not entirely obvious to an editor. (A particularly nasty case is the output of Windows Calculator, which wraps its output in invisible text direction indicators that cause the same problem.)

<wbr /> is a piece of markup and is not included when cutting and pasting from the rendered text. Much nicer!

I'd love to remove the zero-width space, but I don't know what the "browser compatibility issue" is, to see if it's still relevant. Could we describe it on this talk page? 97.102.205.224 (talk) 17:34, 26 November 2024 (UTC)

Well, just read both sides of the diff you linked to and you have your answer. If we no longer care about IE and browsers from that era, then the ZWS is probably no longer needed. However, the {{val}} issue above would seem to be an issue with that template/module, unrelated to this one; you fed {{val}} an exact string of 1​520​698​109​714​272​166​094​258​063 without any reference to Template:Wbr; the breakage is something happening inside the module or a submodule somewhere. Module:Val and its Module:Val/units do not call Template:Wbr, nor does the Module:Convert called by Module:Val. And Windows Calculator obviously has nothing to do with this template, either. It's not helpful to mix-and-match unrelated issues.  — SMcCandlish ☏ ¢ 😼  02:48, 28 November 2024 (UTC)

@SMcCandlish: Sorry the connection wasn't clear. I was trying to describe some problems that can occur if invisible characters are present in data that might get cut & pasted. And describe some situations where those characters can come from. With strings, the problems are mostly limited to Weird Bugs like "Foobar" being one word but "Foo​bar" being two. But with numeric data, it's horrible because there are many things like {{Val}} and {{#expr:}} which choke on the invisible characters.

Fortunately, I've found that <wbr style="margin-left:.25em" /> works a treat. This creates a small gap which is a break opportunity and, like a space character, disappears if the line is broken there. But it's simply omitted if you cut & paste from the rendered HTML.

Example: 2²⁵⁶ = 115792089237316195423570985008687907853269984665640564039457584007913129639936.

I'd love to add this gap feature and a multiple-arguments form to {{Wbr}}, But given that the entire reason for doing it is to not use zwsp, resolving the question of whether it's okay to remove the zwsp from {{Wbr}} is a prerequisite.

Another discussion on the utility of zwsp characters: Wikipedia talk:Manual of Style § Stale advice: slashes have been line-breaks since 2005 (Unicode 4.1.0)

Thank you for taking the time to respond! 97.102.205.224 (talk) 17:52, 28 November 2024 (UTC)

The point about the wbr element is that it introduces a word breaking opportunity: a word occurring at the beginning of a line (other than the first line of a paragraph) can be broken by the browser into two parts, so that the first part can instead be displayed at the end of the previous line, with a hyphen added after it. If there is no end-of-line wrapping within the word, the two parts are displayed together, unbroken by any gaps or hyphens. Consider this:

• Foobar

If that does not display as a single unbroken six-letter word (and when copied and pasted into another document, increases the size of that doc by exactly six bytes), either you have an extremely narrow screen, or your browser has much more serious issues. --Redrose64 🌹 (talk) 21:27, 28 November 2024 (UTC)

FWIW, the anon's example above using 115792089237316195423570985008687907853269984665640564039457584007913129639936 does not show the desired visual spacing effect for me (Chrome, macOS), assuming the intent is for it to look something like 115 792 089 237 316 195 423 570 985 008 687 907 853 269 984 665 640 564 039 457 584 007 913 129 639 936; nor (by design) does this, using the present {{wbr}}: 115​792​089​237​316​195​423​570​985​008​687​907​853​269​984​665​640​564​039​457​584​007​913​129​639​936. If the margin-left:.25em is intended to inject visual spacing for everyone (which seems to be the case), that would be undesirable, and a major and surprising change to what this template does and is for, which would disrupt a lot of infoboxes, etc. It's not primarily intended for use in mid-number; there's another template for injecting visual spacing in numbers, so that is the template you'd want to use for that purpose to fix cases where someone's used {{wbr}} with numbers and it's causing copy-paste problems. I forget what that template's called right off-hand.  — SMcCandlish ☏ ¢ 😼  01:43, 29 November 2024 (UTC)

I have also found that introducing any nonzero-width spacing using the <wbr> tag fails on most browsers. My suggestion is to remove the zwsp Unicode character from the template anyway. The question of whether to conditionally include spacing (with default width zero) is a separate consideration, which can be done in a browser-independent way using a separate <span>, along with the multi-segment approach using #invoke:Separated entries if desired (see example template at User:Quondum/sandbox/brgaps). —Quondum 03:24, 29 November 2024 (UTC)