Template talk:Small

Category link

This protected page has been detected in [[Category:Wikipedia formatting templates]], but that category has been redirected to [[Category:Wikipedia formatting and function templates]]. Please update the category link. --RussBot (talk) 13:10, 27 August 2008 (UTC)[reply]

Done Harryboyles 17:11, 27 August 2008 (UTC)[reply]

Better code; doc page

{{editprotected}} Please replace entire thing with:

<span style="font-size:smaller; line-height:130%">{{{1}}}</span><noinclude>
<!--Categories and interwikis go in the /doc sub-page.-->
{{Documentation}}
</noinclude>

And use the {{Documentation}} link that appears after saving to create the doc page. It should include the text:

==Usage==
This template makes the font smaller. It takes one parameter: The text to shrink. The parameter may contain templates, images, etc., if a block needs to be wrapped in this template and contains such elements.  Note that if the <code>=</code> character appears in the text, the parameter must be explicitly specified as {{para|1}}:
:{{tlx|small|1=3 + 2 = 5}}

no "See also" section, and the following in the <includeonly>...</includeonly> section:

<!--Categories:-->
[[Category:Wikipedia formatting and function templates|{{PAGENAME}}]]

<!--Interwikis:-->
[[ja:Template:Small]]
[[uk:Шаблон:Small]]

This change will actually use XHTML and CSS properly, and install a /doc page so that there is some documentation, and so no more editprotecteds are needed for doc editing, categorization and interwikiing. — SMcCandlish [talk] [cont] ‹(-¿-)› 09:57, 2 October 2008 (UTC)[reply]

Seems SMC forgot the editprotected, so doing now. Martin 10:33, 16 February 2009 (UTC)[reply]

Implemented. As tlx| was not working in the manner intended, I modified the documentation slightly in the form, {{small|Hey Stanton! How goes it?}} produces Hey Stanton! How goes it?. Cheers.--Fuhghettaboutit (talk) 04:48, 19 February 2009 (UTC)[reply]

We already have wikimarkup for this

We already have the wikimarkup tag for small text. So, can anyone explain why this template is needed? Here's two code examples and what they render:

{{small|David testing some text.}}

<small>David testing some text.</small>

David testing some text.

In my browser the two text lines get the same size.

--David Göthberg (talk) 02:41, 9 March 2009 (UTC)[reply]

The template is quicker to type, and probably less confusing for newcomers. –Drilnoth (T • C) 19:23, 29 March 2009 (UTC)[reply]

Apparently only Firefox shows them differently? (As per the comment below). But FF shows as much smaller than the {{small}} tag. It is said that the template tag exists to make uniformity across platforms and browsers possible. The result however is that e.g. SineBot will use which means that if you use {{small}} for your own stuff (not only does it look too big I believe in Firefox (but that is relative, perhaps)) you will get a different size and to get uniformity even in your own browser you must then also use or start specifying sizes each time with {{resize}}, which seems a better choice. To avoid being surprised by other kinds of changes. — Dryden xx2 (talk) 22:40, 17 March 2015 (UTC)[reply]

Small template makes text large

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I saw a mistake that the small template actually makes the text large, so an administrator needs to make the text small because I can't edit the protected template. BlueEarth (talk | contribs) 00:49, 4 December 2010 (UTC)[reply]

Following up on this, there's a bug in IE8 where, when you have View/Text Size set to Large or Largest, the "small" text actually gets larger (see also Template talk:Film date#How location is displayed). One solution to this is to use a percentage-based font size instead of the "smaller" setting. Compare the following in IE8 with text size set to Largest to see what I mean:

example → example
example → example

Before I add an {{editprotected}} template to this, can anyone think of a reason not to use a percentage-based font size? It should fix the IE8 problem and I believe work properly with more modern browsers without causing any change to Accessibility, etc. – RobinHood70 ^talk 18:48, 3 October 2011 (UTC)[reply]

~~Just to be clear, the edit request is to change "font-size:smaller" to "font-size:79%" to work around an IE8 bug.~~ – RobinHood70 ^talk 02:10, 8 October 2011 (UTC)[reply]

I can see a problem: the two lines of text look different sizes to me, in Firefox 8 beta. The 85% one is 1 point larger than the "smaller" one. — This, that, and the other (talk) 09:04, 8 October 2011 (UTC)[reply]

Disabled for now till it's decided what needs to be done, if anything. I would question whether we need to do this just because of an obscure bug in one version of one browser. — Martin (MSGJ · talk) 16:39, 8 October 2011 (UTC)[reply]

(edit conflict) You're right. When I zoom in, I can see the difference readily in Chrome 14, but when I was at normal viewing, they looked the same. I couldn't find anywhere that gave specific equivalents, if any are even defined. Playing around in the various major PC browsers, nothing was utterly consistent at any size. In most browsers, "smaller" was equivalent to about 79%; that same size in Chrome produced a smaller font than "smaller" at normal viewing but the equivalent font size when zoomed in. (Browser inconsistency is fun!) Here's the same example at 79%:

example → example
example → example

Perhaps a bigger argument for the change came up in testing, though: using a fixed percentage size produced more consistent results between one browser and the next, where "smaller" was more variable. (And I was about to remove the {{Edit protected}} tag, but I see in my EC that Martin has already done that.) – RobinHood70 ^talk 16:52, 8 October 2011 (UTC)[reply]

Yes. CSS leaves it implementation-dependent exactly what ratios to use between smaller, medium and larger. 79% (or whatever is chosen) is much less ambiguous.

@MSGJ: if the question is why do we need to do it, of course you're right. But why do we need not to do it, seeing that RobinHood70's solution does the job and is so simple? --Stfg (talk) 17:59, 8 October 2011 (UTC)[reply]

(←) I've reactivated the edit request on the basis of RobinHood70's observation that "font-size:79%" gives better compatibility between different browsers than the implementation-dependent "font-size:smaller", (and it does slightly improve accessibility for a few people). --Stfg (talk) 13:50, 14 October 2011 (UTC)[reply]

Deployed. I'm just wondering why we use line-height:130% in this template? — Martin (MSGJ · talk) 20:10, 14 October 2011 (UTC)[reply]

Thanks, Martin. It's appreciated. I don't know about the 130%, but on Template talk:Film date, RobinHood70 said he thought it was the standard line height on WP and that it might be just to prevent the smaller text interfering with it. --Stfg (talk) 21:14, 14 October 2011 (UTC)[reply]

Thanks guys, I'd forgotten about this. And yeah, I think that's the standard line height, but I honestly don't know for certain why we have that in there. I suppose you can always take it out and see who complains, but that's probably not the recommended method of figuring it out...I'm just not sure what is. I see nothing in the edit history that gives any clue why it was added. – RobinHood70 ^talk 22:50, 14 October 2011 (UTC)[reply]

Okay I've taken it out. If this causes any problems it can be reverted straightaway. — Martin (MSGJ · talk) 10:36, 17 October 2011 (UTC)[reply]

~~Why doens't~~Should this template just use ...? --— Gadget850 (Ed)^talk 17:30, 9 January 2013 (UTC)[reply]

Don't know. Perhaps because  was deprecated in HTML5 at one point? — Edokter (talk) — 21:22, 9 January 2013 (UTC)[reply]

Rephrased a bit. I see this was changed from  per #Better code; doc page. HTML5 redefined  to "represents so-called “fine print” or “small print”, such as legal disclaimers and caveats." With the new semantics, should this template conform, or just perform the current size change? --— Gadget850 (Ed)^talk 22:29, 9 January 2013 (UTC)[reply]

Done -- Gadget850 (Ed)^talk 16:13, 12 April 2013 (UTC)[reply]

Employed both. This ensures consistency between browsers. — Edokter (talk) — 18:01, 12 April 2013 (UTC)[reply]

Still doesn't look the same:

Markup	Renders as
<small>IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII</small>{{small\|IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII}}	IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

As I understand it, this is supposed to replicate . -- Gadget850 (Ed)^talk 18:06, 12 April 2013 (UTC)[reply]

Markup	Renders as
<small>This is small text.</small> {{small\|This is small text.}}	This is small text. This is small text.

Only differs in Firefox, where  is too small anyway. — Edokter (talk) — 23:49, 12 April 2013 (UTC)[reply]

Protected edit request on 1 October 2015

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

please change the {{{1}}} to {{{1|}}} and/or add a tracking category to see when this template is called with empty input. currently the output from {{small}} is not the best. thank you. Frietjes (talk) 19:02, 1 October 2015 (UTC)[reply]

It's not supposed to be used without a parameter, so the current version at least shows that, rather than just outputting nothing. — Martin (MSGJ · talk) 13:49, 2 October 2015 (UTC)[reply]

Not done. Since the first parameter is required, output should not be empty. -- [[User:Edokter]] {{talk}} 14:29, 2 October 2015 (UTC)[reply]

sure, but you have not addressed the second part of my request "add a tracking category to see when this template is called with empty input". see sandbox. Frietjes (talk) 15:51, 2 October 2015 (UTC)[reply]

I suppose that is uncontroversial, even if I can't immediately divine the purpose.

Done with a small change — Martin (MSGJ · talk) 20:45, 5 October 2015 (UTC)[reply]

thank you, looks like there are over a thousand to fix, many like this. Frietjes (talk) 17:25, 6 October 2015 (UTC)[reply]

Protected edit request on 10 June 2016

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please change  to . The style has been implemented in MediaWiki:Common.css, so it is redundant here now. nyuszika7h (talk) 16:20, 10 June 2016 (UTC) nyuszika7h (talk) 16:20, 10 June 2016 (UTC)[reply]

Done. -- [[User:Edokter]] {{talk}} 16:24, 10 June 2016 (UTC)[reply]

The documentation needs changing too. I will do that next. Best wishes. RobbieIanMorrison (talk) 13:24, 19 December 2016 (UTC)[reply]

Template-protected edit request on 21 February 2018

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

While the documentation states that this template is a replacement for ..., it in fact does use ..., which doesn't work on Android devices. Therefore I request that this be replaced by {{{1}}}, similarly to what was done at the {{big}} template (using 120%), which states that <big>...</big> is obsolete (and BTW doesn't work on Android either). Hgrosser (talk) 07:45, 21 February 2018 (UTC)[reply]

@Gadget850: who made the reverse changed in 2013. Frietjes (talk) 14:11, 21 February 2018 (UTC)[reply]

Who has been retired for 3 yeas. Like that's gonna get you anywhere ... {{3x|p}}ery (talk) 16:39, 21 February 2018 (UTC)[reply]

3 yeas isn't that long. now, if it were 3 years, that would be another story. Frietjes (talk) 18:01, 21 February 2018 (UTC)[reply]

Of course, I meant "years", but made a typo {{3x|p}}ery (talk) 20:48, 21 February 2018 (UTC)[reply]

Seems to me like this should be fixed at the MediaWiki level (parse  as ), but I have no objections to this workaround. — Preceding unsigned comment added by Ahecht (talk • contribs) 18:27, 21 February 2018 (UTC)[reply]

Done — Martin (MSGJ · talk) 08:04, 22 February 2018 (UTC)[reply]

Android not parsing this element doesn't seem like it should be our problem, as the element is valid in HTML 5 (the reason I would guess it doesn't parse it is because the element was obsoleted in that specification for some time). I think we should revert to the use of small instead and to weed out where this should/shouldn't be used according to the specification. --Izno (talk) 16:41, 12 September 2018 (UTC)[reply]

Template not working on some pages

There seems to be an issue following a recent change by Izno. For example, in Template:2018–19 UEFA Champions League group table, the dates in the right column use {{small}}, however in my browser they now appear at the standard size. I'm not sure the issue, elsewhere the template seems normal, could this be resolved? Thanks, S.A. Julio (talk) 16:31, 12 September 2018 (UTC)[reply]

The reason this is so is because I converted the template to TemplateStyles, which has some issues with where the HTML gets placed. I've reverted the change for now and I'll have a look to see where-else this is used like this. In general, I would guess that we probably shouldn't have the small inside the link and/or there isn't a reason to have it inside the link rather than outside. --Izno (talk) 16:39, 12 September 2018 (UTC)[reply]

@Izno: Alright, thanks. I also noticed an issue on 2018–19 UEFA Champions League group stage, different local times for matches are listed in parentheses and use the small template, for example {{small|(20:00 [[British Summer Time|BST]])}}. This text was also rendered at normal size following the change. S.A. Julio (talk) 17:57, 12 September 2018 (UTC)[reply]

as far as I can tell, the point of template style is to reduce the data loaded each time the page is loaded. in this case, it looks like  is 25 characters vs.  is 28 characters. so, some saving, but not much once you consider the additional style sheet. but, if it works as intended, I suppose there is no strong reason not to use templatestyles here.

Per invocation, it saves 3 characters. If you use it 16 times on a page, that's 48. --Izno (talk) 03:37, 13 September 2018 (UTC)[reply]

The bigger part is that it allows stylesheets that we don't control more control over the page. That's a Good Thing regardless of any byte savings, and allows for separation of content and style, which is also a Good Thing. --Izno (talk) 03:38, 13 September 2018 (UTC)[reply]

Izno, unfortunately, it appears as though this template is frequently substituted on talk pages. an insource search like this one returns over 1800 places where it was substituted before the safesubst: was added in February. so, I assume it is still being substituted, but with clean results. it would be a shame if that feature were broken. Frietjes (talk) 17:00, 13 September 2018 (UTC)[reply]

* Incoherent gibberish. * --Izno (talk) 17:14, 13 September 2018 (UTC)[reply]

Why is Template:Small smaller than Template:smaller?

Small is 85% and Smaller is 90%... --Guy Macon (talk) 04:06, 26 February 2019 (UTC)[reply]

Because one template is used a magnitude more than the other? Because {{small}} matches the size of ? Why is that important? Why is the question you're asking not "why do we have two templates that do the same thing?"? --Izno (talk) 04:13, 26 February 2019 (UTC)[reply]

@Izno and Guy Macon: I think the question (which I had as well) is, why doesn't the size difference match the convention in English that "small", "smaller", and "smallest", go from largest to smallest. See Comparison (grammar). -- Beland (talk) 19:38, 17 December 2021 (UTC)[reply]

"shrug" is my only answer. As I suspect my comment may have indicated, WP:TFD is probably the reasonable response to delete a template that isn't fundamentally needed. Izno (talk) 19:46, 17 December 2021 (UTC)[reply]

@Izno and Guy Macon: Nominated for merging at Wikipedia:Templates for discussion/Log/2022 January 10#Template:Smaller. -- Beland (talk) 01:02, 10 January 2022 (UTC)[reply]

{{Smaller}} is now just a redirect to {{Small}} so the documentation in {{Font size templates}} and {{Resize shortcuts}} need updating too — GhostInTheMachine ^{talk to me} 12:17, 26 January 2022 (UTC)[reply]

Tracking category

MOS:ACCESS says not to use {{small}} inside infoboxes. Is there any chance we could we get a tracking Category for that? i.e. all the uses of small inside the scope of Infobox.

Also while I'm here I should mention that Project Comics seems to deliberately ignore MOS:ACCESS and frequently uses {{small}} within in the Infobox title for character articles, Batman being a fairly clear example. -- 109.76.147.128 (talk) 17:07, 25 April 2021 (UTC)[reply]

The small template has no way of knowing that it exists inside of another template, so there is no way to track that sort of use.

As for Batman, the small template is used within a parameter that enlarges text, so the resulting text in the subtitle is 93.5% of normal, which is fine. – Jonesey95 (talk) 17:26, 25 April 2021 (UTC)[reply]

That's a pity. It is amazing with some programmers can do with a bit of creative pattern matching but maybe it is too complicated and impractical to implement. Also, if as you say the guideline is not as clear as it seems, and there are many many exceptions to it then a tracking category would not be as useful as I might have thought. I expected MOS:ACCESS to be more important and come above and before other rules (and maybe editors would be advised to force the main text text bigger instead of contradicting the guideline to force text smaller.) Thanks anyway for trying to answer my question. -- 109.76.147.128 (talk) 23:44, 25 April 2021 (UTC)[reply]

The relevant text at that guideline is should not be applied to plain text within those elements. Infobox titles are not plain text within those elements; they are enlarged. – Jonesey95 (talk) 00:01, 26 April 2021 (UTC)[reply]

It wouldn't be Wikipedia if the guideline didn't include exceptions or contradictions. -- 109.79.67.213 (talk) 03:48, 9 May 2021 (UTC)[reply]

Protected edit request on 30 November 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

2409:408A:1C10:A100:0:0:7948:1D0B (talk) 08:28, 30 November 2023 (UTC)[reply]

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Liu1126 (talk) 10:27, 30 November 2023 (UTC)[reply]