Jump to content

Template talk:Wbr

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

This is a replacement for the deprecated HTML tag or the zero-width space ​ which is not supported in all web browsers (most notably the Internet Explorer). It is used as a potential word-break in long strings and character-sequences like formulas or SMILES strings.

See also

[edit]

Compatibility

[edit]

N.B.: The template was partially changed, so these results can be irrelevant.

  • Mozilla 1.7: works fine
  • Firefox 1.0.6: works fine
  • MS Internet Explorer 6.0.2900: renders as a space of 1 pixel
  • Netscape Communicator 4.75: renders as a space

Outdated

[edit]

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)[reply]

Actually it was a wiki engine issue, it removes all empty tags. I replaced space with  . Now it works fine: ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss. Jack who built the house (talk) 16:22, 14 July 2011 (UTC)[reply]
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)[reply]

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

[edit]

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)[reply]

< wbr /> causing unintended line breaks

[edit]

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)[reply]

transclusion count not accurate?

[edit]

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)[reply]

@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)[reply]

Could we document the reason for wbr + zwsp?

[edit]

@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 Error in {{val}}: parameter 1 is not a valid number. 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)[reply]

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)[reply]
@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: 2256 = 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)[reply]
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)[reply]
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}}: 115792089237316195423570985008687907853269984665640564039457584007913129639936. 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)[reply]
There are three independent things considered here:
  • Remove the zwsp character: it causes unwanted copy-paste issues; <wbr/> seems to work on all modern browsers (I support this).
  • Add spacing when a named parameter gives the width; <span style=...><wbr/></span> seems to achieve this on all browsers (I'm neutral).
  • Allow multi-argument separation #invoke:separated entries when there is at least one parameter supplied (I'm not sure this was even proposed).
—Quondum 13:54, 29 November 2024 (UTC)[reply]
(SMcCandlish, {{val}} and {{gaps}} inject visual spacing, but these are non-breaking and not useable for this). —Quondum 14:00, 29 November 2024 (UTC)[reply]
To take all that in the order given:
  • I would also support removing the zwsp and just using <wbr />, if we are certain this is not going to cause any problems for any modern browser users, including on mobile.
  • We don't have a need for a parameter to inject visual but non-semantic spacing, since the only use-case for that is numeric, and this template isn't designed for numeric input, meanwhile we have templates that are.
  • Multi-argument separation: if you mean accepting input like {{wbr|Johannes-Friedrich|Zauberzunge|von der Hasenpfeffer}}, I don't think that's practical. For one thing, <wbr /> is like <br /> and <hr />: it injects something at a point, and is not a wrapper, so no one would expect wrapper behavior. Next, the purpose of <wbr /> is indicating that a string can break at a specific point, but it does not induce creation of other whitespace. In my Johannes example, adapted from an example in the /doc page, each of these elements needs a {{nobr}} around it individually, and each should actually be separated by a space, and they are coded that way in the /doc example. Here someone would expect spacing between them if all on one line, but they would not get that spacing. If we forced spacing, then someone expecting the canonical behavior of <wbr />, with no extraneous spacing added, would not get that behavior. W3C/WHATWG's own canonical example: XML<wbr />Http<wbr />Request Object [shown here with the optional  / because the lack of it breaks our own internal syntax highlighter as well as various other parsers], in which "XMLHttpRequest Object" can have additional break points besides the literal space, would be coded here as XML{{wbr}}Http{{wbr}}Request Object. That is, {{wbr}} is a drop-in replacement for <wbr />. If we did want a wrapper template, it should have a distinct name like {{linebreak control}}, and a parameter to indicate whether spaces are added between elements or not (or two separate templates to do the two different kinds of output). Odds are we already have templates for this anyway. It's also subtle but important that the Johannes example in the /doc is using &nbsp; after the wbr to force a slight indentation if a linewrap does occur at that wbr, so that it is clear that the line after the wbr is a continuation of the previous unbulleted list entry, not a new entry. It's not clear to me right off-hand that a separate-template approach to this could reliably replicate such behavior, at least without complex additional parameters. Such a feature would only be desirable in a list circumstance (or something closely analogous, like table entries), not in general prose. In short, it seems to me that the present situation of using {{wbr}} in conjunction with particular uses of {{nobr}} and &nbsp;, while somewhat complex, is more intuitive and less complex than adding more templates with more switches.
  • For numeric input, if we want a choice between spaced and not spaced (and perhaps comma), then the places to make that happen are in the code of {{val}} and {{gaps}} (and I see that at least one of them already has such options). Really nothing to do with the {{wbr}} template.
 — SMcCandlish ☏ ¢ 😼  09:25, 2 December 2024 (UTC)[reply]

Let's table everything except the one point (the diversion was mainly due to me anyway; anyone can continue any of these in a separate thread), and focus on only the original point: removing the extraneous zwsp character, leaving only the <wbr />. I think we all agree this would be good, but that we just need to have confidence that it works on all modern major browsers. I'll record my observations below, and others can annotate or add. —Quondum 16:09, 2 December 2024 (UTC)[reply]

Given what is claimed at HTML element § wbr (that <wbr /> was standardized in HTML5 and is supported by all major browsers), we can simply assume that enough time has passed that any versions of browsers that do not support it (primarily pre-IE7, released 2007) can be safely ignored. Although I have not tested Android browsers, what I have tested shows compatibility and the probability of issues seems to be vanishingly small. I am correspondingly making the edit request below. —Quondum 01:50, 3 December 2024 (UTC)[reply]

Please replace the template content <wbr />&#8203; with <wbr />. The time for supporting non-compliant browsers at which this was aimed seems to be long gone, and this change eliminates a subtle and potentially frustrating issue of hidden characters when the text is copied and pasted. I can update the template documentation to match when this has been done. —Quondum 01:50, 3 December 2024 (UTC)[reply]

 Done Great discussion. I have somewhat boldly removed the zwsp character, on the (to me) reasonable presumption that browser compatibility has greatly improved since 2015, and that any old browsers that needed this workaround will have all sorts of other incompatibilities. If I broke anything significant, post here, or revert my edit if necessary. – Jonesey95 (talk) 02:33, 3 December 2024 (UTC)[reply]

Browser compatibility of <wbr />

[edit]

Display test (anyone can add their test results, just don't include discussion here):

aaaaabbbbbbbbbbccccccccccccccccccccddddddddddddddddddddddddddddddeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

This should wrap cleanly at the transitions a→b, b→c, c→d, but no wrapping and no gap should occur when there is enough space on the line.

Desktop
Mobile
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Wbr&oldid=1260881919"