Template talk:·

Fixing doc

This template and the documentation are not set up properly; e.g., the Doc page is referenced in a category; not the template. Fix this by first editing Template:· (note: use source in between pre-formatted tags, as you miss seeing the &nbsp somewhere here):

<span style="white-space:nowrap; font-weight:bold;"> ·</span><noinclude>
{{protected template}}
{{{{FULLPAGENAME}}/doc}}
<!-- Add cats and interwikis to the /doc subpage, not here! -->
</noinclude>

Furthermore, the Template:·/doc subpage violates some guidelines set in WP:DOC; namely that it is locked, and has an odd and buggy structure. Use this template to edit the page (I can't!):

<includeonly>{{template doc page transcluded}}</includeonly><noinclude>{{template doc page viewed directly}}</noinclude>
<!-- EDIT TEMPLATE DOCUMENTATION BELOW THIS LINE -->

<includeonly>
<!-- ADD CATEGORIES BELOW THIS LINE -->

<!-- ADD INTERWIKIS BELOW THIS LINE -->

</includeonly>

Thanks. +mwtoews 21:42, 24 January 2007 (UTC)

Done. Unprotected /doc for the time being, as well. Luna Santin 22:18, 24 January 2007 (UTC)

Trailing space

{{editprotected}} can the template be changed to:

<includeonly><span style="white-space:nowrap; font-weight:bold;"> ·</span> </includeonly><noinclude>
{{protected template}}
{{{{FULLPAGENAME}}/doc}}
<!--Please add interwiki links etc to the /doc subpage, not here - thank you!-->
</noinclude>

The extra trailing breaking space should just make it easier to add to templates... IE:

[[ImageWriter II|II]]{{·}} [[ImageWriter LQ|LQ]]

becomes

[[ImageWriter II|II]]{{·}}[[ImageWriter LQ|LQ]]

existing uses of this template shouldn't break as an additional space in the above example will still render the same way. The only possible hiccup I can think of is if someone used the template and added a hard non-breaking space afterwards. I'm not sure why someone would do that, but this change would add a second space, which would include a line break where previously there was none. Additionally, in that hypothetical situation, the only way to rectify the situation so it performs the same way before this edit is to remove the template entirely and code the non-breaking spaces manually. I submit that it is very unlikely that someone is using the template in this way, and even if they were, the fix would be pretty obvious and probably make the code look somewhat cleaner anyway. IE:

{{·}} 

would need to be changed to

 · 

Thanks. Paul^C/_T+ 08:37, 23 May 2007 (UTC)

• Thanks for taking the time to make a suggestion!  I wonder, though, if it might be unwise, for – unless I've misunderstood the above – it removes the inbuilt linewrap management (that the use  item{{·}} item  is meant to imply, i.e. if/when linewrap is to occur, it will occur between a separator and the next item). The new syntax might also lead to less readable code, i.e. code that itself doesn't linewrap unless there are spaces in the items listed. Hope, though, I've not misread the implications. Yours, David Kernow (talk) 15:11, 23 May 2007 (UTC)

The built-in line-wrapping should still work the same way and nothing should really change for the scores of templates that already use the current version. Regarding the readability of code, you are right that it is marginally easier to read with the additional space, but this can still be remedied by adding the extra space in anyway eventhough it isn't required as it won't change how it is rendered (two spaces get condensed into one). Paul^C/_T+ 16:17, 23 May 2007 (UTC)

On a side note, this template is pretty widely used; I'll link this discussion from Wikipedia:Village pump (technical) in a moment. – Luna Santin (talk) 00:56, 24 May 2007 (UTC)

Re losing the linewrap management, I see I forgot that you'd addressed this in your suggestion; there was a delay between my reading it and repsonding, so apologies!  More or less readable code aside, I'm not sure how great the benefit might be; where I've seen {{·}} in use, it's either as suggested (i.e. with gap before the next item, serving as a visual reminder as to where a linewrap may occur) or as  item {{·}} item, i.e. ineffectually for the current or your suggested version... Anyone else...?  Yours, David (talk) 00:06, 25 May 2007 (UTC)

Psantora/Paul: I saw that you today changed your code example above from

font-weight:bold;"> · </span></includeonly>

to

font-weight:bold;"> ·</span> </includeonly>

Just wanted to point out that the discussion above and my long response below was based on your old code. Oh, and yes, what you changed to today is better and is the code I recommended below. (To have a normal wrapping and collapsing space after the end span tag.) --David Göthberg 06:11, 14 August 2007 (UTC)

Code confusion?

{{editprotected}}

I see there seems to be a lot of confusion about the current code. It seems most people who have written on this talkpage do not know the meaning of style="white-space:nowrap;". That code means that all normal blanks in the scope of that span tag will NOT allow line breaks. That is, they almost become  . And I hope you people know that   have two functions? They never allow line breaks and they never collapse together. So two   after each other takes up the space of two blanks. While two or more normal blanks collapse together to the width of one blank. (And they still collapse together even if within the scope of a style="white-space:nowrap;".)

The current code

Note: This is not any longer the current code since this template has now been updated according to this suggestion. --David Göthberg 01:15, 13 August 2007 (UTC)

Let me give some different code versions that are almost exactly equivalent.

Current upper half of the code:

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

We can use wiki markup instead of the font-weight:bold; part:

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

No need for the   since we have the white-space:nowrap; part:

<includeonly><span style="white-space:nowrap; 
 ">''' ·'''</span></includeonly>

Or why not use the   instead:

<includeonly>'''&nbsp;·'''</includeonly>

Look ma, no <span>!!!

If any of the codes above are used in any of these ways:

[[Salt]]{{·}} [[Pepper]]
[[Salt]]{{·}}     [[Pepper]]

It will render with exactly one blank on each side like this:

Salt · Pepper

Or if it line breaks the break will come neatly after the dot:

Salt ·

Pepper

However if no blank are left after the template, like this:

[[Salt]]{{·}}[[Pepper]]

Then it will NEVER line break. It will render like this, even if there is not space enough. Note the ugly lack of a blank on the right side:

Salt ·Pepper

If one or more blanks are left before the template, like one of these ways:

[[Salt]] {{·}} [[Pepper]]
[[Salt]]   {{·}} [[Pepper]]

Then it will render with two blanks on the left and exactly one blank on the right, like this:

Salt  · Pepper

But if it line breaks it might break before the dot (and then also get an extra blank before the dot), like this:

Salt

 · Pepper

The solution

Note, part of the solution I suggested here did not work. Se discussion further below. --David Göthberg 12:36, 15 August 2007 (UTC)

If the user adds blanks before then there is nothing we can do about the line breaks, no matter what template code we use. But there are several other things we can do better!

From what I understand most of us want the line breaks to always happen after the dot, and if there is no line break we want exactly one blank on each side. Preferably no matter how wrong the article editor has used the template. And we can pretty much fix that.

What we need is some kind of nowrapping blank before the dot. And a normal blank after the dot that can wrap. And we want the blanks both before and after the dot to be "collapsible". That is, if the user leaves no blanks, or blanks before or after or both, like any of these variants:

[[Salt]]{{·}}[[Pepper]]
[[Salt]] {{·}}[[Pepper]]
[[Salt]]   {{·}}[[Pepper]]
[[Salt]]{{·}} [[Pepper]]
[[Salt]]{{·}}   [[Pepper]]
[[Salt]]   {{·}}   [[Pepper]]

Then we want that to collapse to exactly one blank on each side when it renders, like this:

Salt · Pepper

And even if the user left no blanks, like this:

[[Salt]]{{·}}[[Pepper]]

Then we still want it to line wrap neatly after the dot:

Salt ·

Pepper

So, before the dot we need a collapsible blank that will not wrap. The only way to do that is to use a normal blank and protect it with a style="white-space:nowrap;". We can not use a   since it does not collapse with other blanks.

And after the dot we also want a collapsible blank, but this time we want it to allow wraps. And the only way to do that is to use a normal blank and NOT protect it with a style="white-space:nowrap;".

So let's code that. But wait, since normal blanks are collapsible we can have several of them together to make the code more readable. Note that the code I mean is the code you see when you view this page, not when you edit it. So here is the code:

<includeonly><span style="white-space:nowrap; 
 ">  '''·'''</span>  </includeonly>

Here I used wikimarkup ''' ''' for the bold dot, but we can just as well use style="font-weight:bold;". Like this:

<includeonly><span style="white-space:nowrap; 
 font-weight:bold;">  ·</span>  </includeonly>

Now, take a close look where I did put the blanks. The first blank(s) are right before the bold dot. Well protected by the nowrap span-tag. But the second blank(s) are AFTER the end of the </span>, thus not protected by the nowrap span-tag. So those blanks can wrap. But note that they are still before the </includeonly> and thus will be included in the articles.

So if we use this code then we can think of it as if this template looks like this:

{{ · }}

That is, if the user for instance writes this:

[[Salt]]{{·}}[[Pepper]]

Then we can think of it as:

[[Salt]]{{ · }}[[Pepper]]

I ran several tests and the code seems to do exactly what I say it should do. In all my three web browsers too.

Oh, by the way, I think that we shall keep the recommended usage with one blank after the template. Like this:

[[Salt]]{{·}} [[Pepper]]{{·}} [[Curry]]

That means the user code shows what is intended to happen, that the user code wraps in the edit boxes and it is more forward compatible (in case some one messes up the code within this template).

The full code I recommend for this template

<includeonly><span style="white-space:nowrap; 
font-weight:bold;">  ·</span>  </includeonly><noinclude>
{{protected template}}

{{template doc}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

Please cut and paste this code from the edit window. (But don't use the pre and nowiki tags.)

This also uses the new {{template doc}} that is recommended at Wikipedia:Template documentation.

If you want to see how this code behave then you can try {{•}}, {{ndash}} or {{mdash}}. They all use the same code but a bullet, ndash or mdash instead of a bold middot.

--David Göthberg 10:42, 11 August 2007 (UTC)

Since it's been over a day, and no one has objected, I've performed the edit. — TKD::Talk 23:43, 12 August 2007 (UTC)

Whoa! Things are moving fast, even for this kind of high risk template. Thanks for the confidence in my code. I checked some articles that use it and ran some more provocation tests. It seems to work perfectly. Now all I have to do is to update the documentation. --David Göthberg 01:15, 13 August 2007 (UTC)

To be honest, I had actually seen your suggestion a day ago, since I have this template watchlisted (along with some 4,000 other pages, but that's beside the point :)). I probably should've responded then to acknowledge that I had seen it and it looked fine to me, and that I was waiting to see whether there were objections, since this template is used in navboxes galore. I probably got distracted. — TKD::Talk 09:47, 13 August 2007 (UTC)

Is there a reason why there are two spaces in the code? Shouldn't it be this:

<includeonly><span style="white-space:nowrap; 
font-weight:bold;"> ·</span> </includeonly><noinclude>
{{protected template}}

{{template doc}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

Or, if you want the second spaces, shouldn't it be this:

<includeonly><span style="white-space:nowrap; 
font-weight:bold;">  · </span> </includeonly><noinclude>
{{protected template}}

{{template doc}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

Otherwise, the 2nd space after the span gets collapsed... right? Also, it seems to not be working correctly below, but that might have something to do with the code in that template... Paul^C/_T+ 04:42, 14 August 2007 (UTC)

The idea is that we want both A{{tl|·}}B and A{{tl|·}} B to work. With the code change that added the second breaking, collapsible space, both should work whether or not the trailing space is included. — TKD::Talk 05:56, 14 August 2007 (UTC)

Oh, never mind. I see what you mean. The second spaces within each section are redundant, and that'snot the problem you're seeing. I'll respond below. — TKD::Talk 06:16, 14 August 2007 (UTC)

First of all Psandora/Paul, you should carefully read my discussion and explanations above. All the way from the section "Code confusion?" and down. I already explained it all there. Of your two examples above the first one is the correct one and is exactly equivalent to the code I suggested and that we today are running. I only used two spaces to make the code more readable. (Apparently I was wrong and caused confusion instead.) I explained that in my discussion above. Two or more normal collapsible spaces immediately next to each other always gets collapsed together to one space by all web browsers so they mean one space.

Your second example above where you put one space between the dot and the end span tag is weird and confusing. But I think it will render the same results since the space before and after the end span tag will collapse to one space, but since the second one allows wraps (line breaks) it will still allow line breaks to happen (but now one space away from the dot).

So yes, the correct code should be:

<includeonly><span style="white-space:nowrap; 
font-weight:bold;"> ·</span> </includeonly>

Which is exactly equivalent to what we are running today:

<includeonly><span style="white-space:nowrap; 
font-weight:bold;">  ·</span>  </includeonly>

Now the next issue is your big template below. I took a close look at it and saw that you are mixing different kinds of dots and how you make the dots. And the template's edit history shows you have been mixing that since long before we changed to the new code for the middot template. (We changed the code yesterday.) But unfortunately that is not the problem. I wish it was that simple. The wrapping problem is not your fault. It's my fault. Or rather, the buggy web browser's fault.

Yesterday only hours after we deployed the new code for the middot template I too discovered that wrapping problem in my own dotted lists. That is, sometimes a dot falls down to the next row. I have been investigating the problem since then. It seems the web browsers do not fully respect our style="white-space:nowrap;" code. It's weird that I didn't discover it before. I had tested the code thoroughly before we applied it. I already used it for the {{bullet}}, {{ndash}} and {{mdash}} templates and tested them all in all kinds of provocation tests. But now they all have that wrapping problem.

Before we go ahead and change to one of the more primitive solutions I would like to get some more time to try and find a good solution. I have some more ideas to test. I hope you guys can have the patience?

--David Göthberg 06:47, 14 August 2007 (UTC)

Broken...

Checkout {{NFL}}:

The dots don't wrap correctly on the bottom rows when using the {{·}} template. What is going on here? Paul^C/_T+ 04:28, 14 August 2007 (UTC)

So it turns out that the nowrap style is not exactly equivalent to  , in that all of the browsers that I've tried (IE7, Firefox, and Safari) do not honor a nowrap style for leading spaces! In the interests of restoring the expected behavior of not breaking before the dot, we will have to reinstate the explicit non-breaking space entity, although the idea of having the collapsible space after the dot should be fine. I will restore the non-breaking space for now, because the potential for incorrect usage with the leading space could spread and become harder to fix. Like it or not, the non-breaking space was there originally, and since the new behavior is not exactly equivalent, we need to revert until we can hash out a better alternative, if any. — TKD::Talk 06:52, 14 August 2007 (UTC)

Ok, I have ran out of ideas to test. It seems TKD is right. Using a   before the dot seems to be the best option. And as TKD noted in an edit summary, it now seems "safe to remove the nowrap". I just tested it in my own test cases too. And yes, the tests I have done confirms that the space after the last span tag still works fine. So the best code now seems to be the code that TKD just changed to, that is:

<includeonly><span 
style="font-weight:bold;">&nbsp;·</span> </includeonly>

Actually, I have been playing with the thought for some hours now that it might be a good thing to not have a collapsible space before the dot. Since I noticed for the other similar templates ( {{bullet}} etc ) that now that it did not become visible for the editors that they had added spaces before the template they started doing it all over the place. Thus anyway adding the wrapping problem. So using the   means their mistakes will be visible as double spaces before the dots.

So I will add the   to {{bullet}} too. But not sure if I should use it for {{ndash}} and {{mdash}} since many just use them as regular dashes, with one space on each side in their code. And the browsers actually to some extent do respect the nowrap, but only to some extent. (That is, they seem to be slightly more likely to line wrap some where else than in the nowrap protected area.)

Ah, I hate browser bugs!

--David Göthberg 07:47, 14 August 2007 (UTC)

Instructions

Have changed slightly. Seems pointless to instruct people to use a trailing space which does nothing, and looks unbalanced in source. Changed it to "can" ... although seems almost not worth mentioning. Rich Farmbrough, 19:05 14 December 2007 (GMT).

Actually, the trailing space is needed so the code can line wrap in the edit window. You know, not all Wikipedia editors have a 2000 pixel wide screen. So adding the trailing space is a good coding habit.

--David Göthberg (talk) 03:01, 7 March 2008 (UTC)

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. It does have examples and explanations relevant to the usage of this {{·}} template. Take a look and discuss this new how-to guide on its talk page.

--David Göthberg (talk) 21:45, 11 March 2008 (UTC)

Character vs entity?

Of using the character "·" as opposed to using the entity "& middot;"? --Izno (talk) 03:20, 24 May 2008 (UTC)

We use the character "·" instead of the HTML entity "·" to save bandwidth, page rendering work and so our code becomes more readable. Many articles have several large navboxes with dotted lists, thus this dot can be used say a hundred times in such an article. So it saves page load time for users with slow connections and it saves bandwidth and CPU for the Wikipedia servers since it means less page data to process. The dot works fine in all browsers we know of, even very old ones. So there's really no reason to use the entity.

--David Göthberg (talk) 17:07, 29 March 2009 (UTC)

Why?

Why does this page exist? It seems like a completely pointless template call when you could just type the dot. Stifle (talk) 09:47, 23 October 2008 (UTC)

The real purpose of the template is the nbsp, not the dot. The idea (as I understand it) is to make sure that line wraps occur only after dots, not before them. So typing just a dot would not achieve that, and typing  '''·''' is longer than typing {{·}}. — Carl (CBM · talk) 12:34, 23 October 2008 (UTC)

Stifle: It's not just a dot, its a bold dot, since the normal dot is too small. And it has a tweak that makes the bolding work better under some very special circumstances. And as Carl explained, it has a   before the dot to handle the line wrapping nicely. So it has three extra features that a simple dot doesn't have.

Try typing  '''·''' and {{·}} and see which one you find easier to use. Or rather, since we can't type the dots, you have to cut and paste it. But cutting and pasting a lot of & and ' is more error prone, since we humans are better at seeing if we get the right number of { and }. And even if you use  '''·''' then you don't have the special tweak that fixes the bolding in some circumstances.

--David Göthberg (talk) 17:27, 29 March 2009 (UTC)

Hi people, as a newbie to Wikipedia I've wondered what was the real meaning of this template, when one can easily type just the dot. My suggestion is to add the above explanation to the documentation, probably at the very beginning. I can do it if people agree. --Ptsl (talk) 08:57, 8 October 2010 (UTC)

The character is hard to type

{{editprotected}} The character is hard to type. Accordingly, the intuitive and easy-to-type {{,}} is an alias of {{·}}. Unfortunately, the documentation makes no mention of it. Could an administrator add this bit of knowledge to the documentation? Διγουρεν_{Εμπρος!} 15:44, 9 May 2009 (UTC)

Good call. Happily, the documentation is unprotected and can be found at Template:·/doc. Please go ahead :) — Martin (MSGJ · talk) 18:36, 9 May 2009 (UTC)

Span?

Is there a reason that this uses <span style="font-weight:bold;"> rather than say <b>? Dragons flight (talk) 23:26, 11 June 2009 (UTC)

Without the white-space:nowrap; there doesn't appear to be a point for it, and it's a waste of space. 40 characters vs. 7 . . . even after gzip you can save ~9 bytes per article, and a lot of articles use this. GreenReaper (talk) 21:05, 10 February 2010 (UTC)

It is 2.5 years since I worked with this template and the related templates, but if I remember right:

We need the span to work around a page-rendering bug. MediaWiki internally converts <b></b> and ''' ''' to <span> tags and then convert them back to <b></b>. In doing so it sometimes mixes the temporary span up with other surrounding spans, which causes another end </span> to be converted "back" to the </b>, which can make whole sentences bold or make surrounding italic text end prematurely. (Wikimarkup for italic text is also internally converted to a span and then to <i></i>.)

Using <span style="font-weight:bold;"></span> directly caused less problems. Of course, the MediaWiki page rendering engine is updated every now and then, so the bug might have been fixed. But right now I can't find my old test-examples that show the bug so I can't check if the bug is still there.

--David Göthberg (talk) 04:00, 11 February 2010 (UTC)

Duke of York gambit, anyone? :-) ― ___A._di_M. (formerly Army1987) 10:58, 27 March 2010 (UTC)

Has there ever been a bug filed for this? I'd really like to know. <b> appears to be cancelled out when already surrounded by bold text that is bolded with either <b> or '''. See test below. — Edokter • Talk — 16:01, 26 December 2010 (UTC)

Bolding embedding test

Bold in wikimarkup

Bold in HTML

Bold in wikimarkup with (embedded bold) in HTML

Bold in HTML with (embedded bold) in wikimarkup

Bold in wikimarkup with (embedded bold) in wikimarkup (un-bolds as expected)

Bold in HTML with (embedded bold) in HTML

Bold in span with (embedded bold) in wikimarkup (adds <b> tags)

Bold in span with (embedded bold) in HTML (adds <b> tags)

Link · Link · Link

Bold in wikimarkup with (embedded bold) in HTML

Bold in wikimarkup with  (embedded bold preceded by &nbsp;) in HTML

It turns out that the   is breaking the embedded bolding mechanism. I have no idea why. I've filed a bugreport. — Edokter • Talk — 00:29, 31 December 2010 (UTC)

Edit request from 118.100.126.140, 7 August 2011

118.100.126.140 (talk) 03:53, 7 August 2011 (UTC)

 Not done no request. Skier Dude (talk) 04:52, 7 August 2011 (UTC)

Redirect requested

I would like to create a redirect to this template at "." so you can type {{.}} to make the bullet appear. I actually have a period on my keyboard, but I don't have this mid dot thing. However, when I enter Template:. in the search box, it doesn't let me create a page. Please help, thanks, — Preceding unsigned comment added by Dondegroovily (talk • contribs) 17:19, 17 March 2012‎ UTC

"." is an invalid character and may not be used in title. If you link to it straight (link), you will see an error. See WP:NCTR for more restrictions. — Edokter (talk) — 18:31, 17 March 2012 (UTC)

And that's why we got {{dot}} D O N D E groovily Talk to me 19:05, 17 March 2012 (UTC)

Another lunkheaded, misnamed template

Who was stupid enough to create a template called {{middot}} which gives something other than a simple, single, lone middot? I guess we're stuck with it now though. Great going. EEng (talk) 18:25, 15 March 2014 (UTC)

Protected edit request on 13 June 2014

Please replace:

&nbsp;<span style="font-weight:bold;">&middot;</span>&#32;

With:

<onlyinclude>&nbsp;'''·'''&#32;</onlyinclude>

Since this template is often transcluded many times on one page, this 37 character change will significantly reduce post-expansion template inclusion size. Replacing the &#32; with just a " " (space) will reduce the size by four more characters giving a 48.3% reduction in include size and no negative effect. — {{U|Technical 13}} ^{(e • t • c)} 12:54, 13 June 2014 (UTC)

Two things:

1. Replacing the CSS with wiki markup risks unintentional 'unbolding' if a preceding item is missing any closing markup. Using <b>&middot;</b> instead will mitigate this (though User:Foxj claims this also breaks templates), though CSS is the preferred way for presentational markup.
2. Replacing &#32; with a normal space will cause it to be stripped. We don't want that.

— Edokter (talk) — 13:23, 13 June 2014 (UTC)

Not done for now: I made the edit, but reverted after I saw Edokter's post here. Please reactivate this once there's a consensus on what change to make, if any. — Mr. Stradivarius ^{♪ talk ♪} 13:39, 13 June 2014 (UTC)

• Edokter, I see no stripping of the space, A{{·}}A{{·/sandbox}}A{{·}}A{{·/sandbox}}A{{·}}A{{·/sandbox}}A = A · A · A · A · A · A · A, they look identical. If there is no objection, I have no qualms about replacing the existing code with:

  <onlyinclude>&nbsp;• </onlyinclude>
  

  The <onlyinclude>...</onlyinclude> tags (which apparently can't be seen using {{Syntaxhighlight}}, but are used in the sandbox) ensure that the space stays in there (and doesn't affect inclusion size) and prevents any unwanted linefeeds that may be elsewhere. — {{U|Technical 13}} ^{(e • t • c)} 14:00, 13 June 2014 (UTC)

Is now a 54.1% improvement in Post-expand include size. — {{U|Technical 13}} ^{(e • t • c)} 14:06, 13 June 2014 (UTC)

Perhaps not when used directly, but when this included in another template where it ends up in a parameter or parser function (which happens a lot), the space will be stripped. So yes, the &#32; must stay. — Edokter (talk) — 14:22, 13 June 2014 (UTC)

• I could see that playing out in my head... I have no problem with the &#32; staying, per my original request (which I added the &#32; as an afterthought.). So, would

  <onlyinclude>&nbsp;<b>‧</b>&#32;</onlyinclude>
  

  which is still 46.1% improvement in Post-expand include size be acceptable to you? — {{U|Technical 13}} ^{(e • t • c)} 15:27, 13 June 2014 (UTC)

It would, but beware of the 'unbolding' monster. See #Span? above. — Edokter (talk) — 17:30, 13 June 2014 (UTC)

• That's a simple fix...

  <onlyinclude><b>&nbsp;‧</b>&#32;</onlyinclude>
  

  Will make it display correctly per this example: Bold in wikimarkup with  (embedded bold preceded by &nbsp;) in HTML. As such, and since I see no other objections, I'm reactivating this request. — {{U|Technical 13}} ^{(e • t • c)} 18:26, 13 June 2014 (UTC)

That results in a double space. — Edokter (talk) — 18:56, 13 June 2014 (UTC)

• It's suppose to... Show me an example of " &nbsp;" that doesn't result in a double space. — {{U|Technical 13}} ^{(e • t • c)} 19:08, 13 June 2014 (UTC)

Since I just found we also have a {{•}}, which

<onlyinclude>&nbsp;• </onlyinclude>

should go in, I'd suggest we use

<onlyinclude>&nbsp;<b>‧</b> </onlyinclude>

which is still a 46.1% improvement in Post-expand include size. — {{U|Technical 13}} ^{(e • t • c)} 14:21, 13 June 2014 (UTC)

And post-expand include size is the metric needing optimization because...? In the statistics linked it appears this change works a 5% increase in CPU usage. Is that the right tradeoff? EEng (talk) 14:49, 13 June 2014 (UTC)

Those values flex with general server usage and tolerance is about 50% ± — {{U|Technical 13}} ^{(e • t • c)} 15:27, 13 June 2014 (UTC)

I'm sorry, but you're saying CPU time varies with load? Really? Um... can you explain that? Anyway, why do we care about post-expand size? EEng (talk) 17:09, 13 June 2014 (UTC)

• I can show that CPU and real times vary with load. I set the template to test the sandbox version of the page, and hit preload ten times recording the data each time and coming up with (.168, .176, .172, .12, .108, .164, .132, .132, .124, .18) for CPU (Ave: 0.1476) and (.136, .136, .128, .136, .196, .196, .14, .132, .136, .176) for real (Ave: 0.1512). Then I repeated the process with the template set to main (the live template) and came up with (.196, .2, .191, .14, .128, .186, .154, .152, .138, .206) for CPU (Ave: 0.1691) and (.155, .151, .144, .159, .217, .212, .163, .152, .157, .196) for real (Ave: 0.1706). Currently, based on these averages, the sandbox version is 12.7% faster on CPU usage, 11.4% faster on real time usage, uses 7.9% fewer visited nodes, uses 0.7% fewer generated nodes, and most importantly (as this is what is causing pages to get dumped into an error category and causing renderings to fail) has a Post-expand include size that is 46.1% smaller. This change would trim ~6,500 bytes off of Wikipedia:Dashboard/Requests_for_comment which may help prevent pages transcluding it from being dumped in Category:Pages where template include size is exceeded. — {{U|Technical 13}} ^{(e • t • c)} 17:30, 13 June 2014 (UTC)

May? Can you point to a page with a rendering problem which would be fixed thereby? EEng (talk) 18:02, 13 June 2014 (UTC)

• User:Technical 13/dashboard will have rendering problems when there is no AfC BLD running (and the number of pending submissions are closer to 2000—2500 than the 500 it is currently at) and this would help alleviate the problem. — {{U|Technical 13}} ^{(e • t • c)} 18:26, 13 June 2014 (UTC)

Any pages affected other than your personal dashboard? EEng (talk) 20:51, 13 June 2014 (UTC)

• I'm sure there are, but I'm not going to do a database dump to find them. Are you opposed to improving every aspect of this template? The current version is faster and smaller on every statistic that is reported. I don't understand why you are so concerned about making this template faster and smaller. Can you explain that? — {{U|Technical 13}} ^{(e • t • c)} 20:55, 13 June 2014 (UTC)

User:Madhero88/OthersBM, User:Millifolium/Sandbox, User:Quisquillian/Sandbox are currently in that error category and would benefit from this change. — {{U|Technical 13}} ^{(e • t • c)} 21:29, 13 June 2014 (UTC)

(edit conflict) All other things being equal, making things faster and smaller is fine. But all other things aren't equal -- there's a function risk here. As is abundantly clear from earlier interactions in this very thread, it's very hard to be sure that "trivial" changes to a high-visibility template won't break something. You seem to want to risk that in order to improve some numbers whose significance I don't think you understand -- if CPU times vary greatly from run to run then there are caching or other effects you're not taking into account, or there's something wrong with the performance instrumentation. On top of this, the profile for User:Technical 13/dashboard reports Post-expand include size 1174270/2048000 bytes, so what's the size problem you're talking about? EEng (talk) 22:17, 13 June 2014 (UTC)

• That is why things are tested out. I'm seeing no new technical challenges that would cause issues here, and I've addressed all of Edokter's issues above. The variance in the CPU run times is 1-2 tenths of a second. 2 tenths of a second is 200% of 1 tenth of a second, but not hardly anything to worry about (your body can't even process information that fast). So, currently, the post-expand include size is about 50% of capacity, and Template:AFC statistics is (122,749 bytes) [expands to 477,197 bytes] at the moment... Two weeks ago, it was peaking at (459,811 bytes) [expands to about 1,787,554 bytes]. That means that when no BLD is running at AfC, the current Post-expand include size 1,174,270/2048000 bytes becomes Post-expand include size 2,961,824/2048000 bytes (commas added by me for clarity) which sets this about 913,824 above the limit and dumps it into Category:Pages where template include size is exceeded just like User:Madhero88/OthersBM, User:Millifolium/Sandbox, and User:Quisquillian/Sandbox are. If I can get this template to trim 6-8K off of that, then I'm making "some" progress and it is helping. — {{U|Technical 13}} ^{(e • t • c)} 22:44, 13 June 2014 (UTC)

I don't even know what this "BLD" is you're talking about, sorry -- should I? The discussion above shows clearly that just because you "don't see any further technical challenges" doesn't mean there aren't any. Am I correct in understanding that you project this change will reduce the 913,824 figure by 6000-8000? Really? I'm sorry, but this seems like a classic preoccupation with some numbers which happen to be available -- Wikipedia:Don't worry about performance.

I'd very much like to hear what other editors think about this. EEng (talk) 00:40, 14 June 2014 (UTC)

You seem to be overlooking the Wikipedia:Don't worry about performance#Editors still have a role to play clause. If pages are being put into Category:Pages where template include size is exceeded which is a category that is populated automatically by the MediaWiki software. It contains pages which exceed one of the template limits, other than the limits on expensive parser functions and template argument size more specifically, Wikipedia:Template limits#Post-expand include size. The most important factor about this is that These pages should be simplified by removing or simplifying calls to templates, or they will not render properly, which is what this edit request aims to do. A BLD is a ]BackLog elimination Drive. — {{U|Technical 13}} ^{(e • t • c)} 02:21, 14 June 2014 (UTC)

"Removing or simplifying calls to templates" means, to me, that maybe one dashboard shouldn't concatenate each and every "status" template from the entirety of Wikipedia, as yours seems to do. I'm still hoping others will weigh in. EEng (talk) 14:37, 14 June 2014 (UTC)