Template talk:Para
Page contents not supported in other languages.
 | Template:Para ispermanentlyprotected from editing as it is aheavily 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 byconsensus, 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'sdocumentation to add usage notes orcategories. Any contributor may edit the template'ssandbox. Functionality of the template can be checked usingtest cases. |
 | Text has been copied to or from this page; see the list below. The source pages now serve toprovide attribution for the content in the destination pages and must not be deleted as long as the copies exist. For attribution and to access older versions of the copied text, please see the history links below. |
 | Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
Please change the template to use <code> rather than <tt>. The <code> element is more appropriate, since the text represents computer code (namely, Wiki markup). Thanks.Eubulides (talk)15:26, 12 September 2009 (UTC)[reply]
| Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
<code><spanstyle="white-space:nowrap;">|{{{1|}}}{{#if:{{{1|}}}|=}}{{{2|}}}</span></code>
Tested and working on another wiki I maintain. Thanks —capmo (talk)22:51, 17 February 2013 (UTC)[reply]
<code><spanstyle="white-space:nowrap;"><nowiki>|</nowiki>{{{1|}}}{{#if:{{{1|}}}|<nowiki>=</nowiki>}}{{{2|}}}</span></code>
{{{1}}} is not given, the #if has to check its "else" clause and return it (in fact, an empty string); without this | it would return nothing, which is possibly more efficient. But if you check the changes above, the #if syntax was simplified even more by removing the first parameter from inside it. —capmo (talk)01:48, 18 February 2013 (UTC)[reply]<span>...</span> element has the same scope as another HTML element, the attributes may be moved from the SPAN to the other); and I've set upTemplate:Para/testcases. These do not demonstrate problems inside either tables or templates, therefore there is no problem with not implementing proposal 1. --Redrose64 (talk)10:57, 18 February 2013 (UTC)[reply]
Done --Redrose64 (talk)14:13, 18 February 2013 (UTC)[reply]The 22 July 2014<code>...</code> css change adds unnecessary boxes. I propose to replace<code>...</code> with<kbd>...</kbd> which is more semantically correct and displays the text in the same monospaced font.
—Trappist the monk (talk)15:56, 10 August 2014 (UTC)[reply]
<code> as recommended at VPT, to preserve the semantic meaning. –Jonesey95 (talk)22:35, 11 August 2014 (UTC)[reply]<kbd>...</kbd> is not correct, except for the value of the parameter, not its name or the = character (i.e., in a case of|foo=bar, thebar part should be in<kbd>...</kbd>, but thefoo and= part in<code>...</code>. So, fix that, then do as Jonesey95 suggests with regard to use of<code>...</code> here. In general, no change to what MediaWiki is doing, or the en.wiki site-wide style sheets for that matters, should ever lead to us proposing to replace the underlying tag to work around a style problem; just fix the style. And perhaps keep closer watch on and inject more input into discussions that are resulting in questionable site-wide or MW-wide style changes (and there sure have been a lot of them this year). — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:41, 13 August 2014 (UTC)[reply]The kbd element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).To use this template, editors must 'input' the entire template from the opening bracket to the closing bracket into the edit window.
<code> element redundant, yet it's been kept, and so has<kbd> (and<samp> and<var>, but not<tt>, which really was redundant with<samp>). The<code> element is expressly for code asdistinguished from user input (i.e. values supplied). In actual practice<kbd>, because it's too tedious (and some think it never belongs in there, interpreting<kbd> as solely representing interactivity). When found in the wild and used with the related tags, and not being abused for non-semantic purposes or the wrong one, it's almost exclusively used for user, not coder, input to an application/device/process, e.g. typed responses to prompts, data entry into fields, or spoken commands likeSiri: redial last number. The<samp> element represents output. Proper usage of all four of the (current) relevant markup elements would be "The command <code>fink install <var>port-name</var></code> may prompt you to select a specific variant. At the <samp>Please select which package to install</samp> prompt, enter your choice as a numeral, e.g. <kbd>3</kbd> for the third option in the list. (Renders as: The commandfink installport-name may prompt you to select a specific variant. At thePlease select which package to install prompt, enter your choice as a numeral, e.g.3 for the third option in the list.) An utter purist would also wrap that particular<var> in a<kbd> since it represents a momentary user choice, not pre-determined code, but in practice you'd be hard pressed to find anyone anywhere being that anal about the semantics. Another nitpicker might change part of that example to</code><var>port-name</var>, but that's the finest hairsplitting, and debatable semantics.Since the<tt> element is no longer supported as of HTML5, we need figure out what the MW devs' migration plan is, if they have one. We're either going to have to stop using it, or they're going to have to translate it on-the-fly into something else. If the former, we could: A) Use<samp> to encompass former use of<tt> (which was meant to reflect "teletype", or machine-mediated human communication; that a subclass of machine output, represented by<samp>). Or, B) Use a template to wrap content in<span>...</span>, with no particular semantic value. The latter is probably better, since editors have been broadly abusing the<tt> element as a quick-and-dirty way to get monospace, just as they misuse''...'', for emphasis not purely typographic italicization, when they should be using<em> (or{{em}}) for emphasis. But editors are loath to give up what they're familiar with, so the least "brittle" way to do this would be for MW to translate<tt> on the fly, while we deprecate its use so that people move away from it and no new editors pick up the habit. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 19:26, 20 July 2015 (UTC)[reply]
<kbd>...</kbd> is that the style for that element may be changed at some point as has just been done with<code>...</code>, and then we're back here again. If we stick with<code>...</code> and just style it ourselves, we avoid that potential problem. –Jonesey95 (talk)13:18, 13 August 2014 (UTC)[reply]<code>...</code> to<span>...</span>.
Moved fromTemplate talk:Tag § StyleWhile the display problem noted atHelp talk:Citation Style 1/Archive 5#Restore error message style is an unintended consequence of the CSS changes to the<code>...</code> element (they don't seem to have considered that some inline uses don't work well with boxes), the effect the changes have on{{para}} and{{tag}} are not, but are precisely the intended effect of that change. I personally still disagree with the addition of the boxes to this element, but that's a discussion to raise with the MediaWiki developers in the long term, to fix common/shared.css, and in the short term to bring up atMediaWiki:Common.css to fix at en.wikipedia site-wide, if a consensus develops on this site to buck this change. We should not be monkeying with it, in ways that break semantic HTML, on a template-by-template basis. Doing so would also produce inconsistent results. Quite a few templates are used in marking up source code, and they all use (or should use) the<code>...</code> element appropriately (I'm unaware of any that don't). Failing to account for even one of them when making tweaks like any of those suggested above will result in boogered template documentation pages that use such templates to lay out source. Might also affect actual articles that illustrate source code. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 19:22, 13 August 2014 (UTC)[reply]
<code> to render <code> without a border or changing the background – should this be<code> (or something like it) instead..?Sardanaphalus (talk)11:05, 11 October 2014 (UTC)[reply]inherit (but three of them, not two) was first suggested by me atWikipedia:Village pump (technical)/Archive 129#Displaying 'code' font text where I proposed<code>Example</code> →Example← and this has been mentioned elsewhere, such asHelp talk:Citation Style 1/Archive 5#Restore error message style andTemplate talk:Tag#Style - which is where this thread originated. --Redrose64 (talk)19:27, 11 October 2014 (UTC)[reply]inherit as a problem? --Redrose64 (talk)12:36, 12 October 2014 (UTC)[reply]inherit rather than the specific styling (transparent/none) should be preferred – but I imagine it won't matter if the styling ends with e.g. a "{{{style|}}}" to accommodate a situation where neither is desired.Sardanaphalus (talk)11:54, 14 October 2014 (UTC)[reply]transparent might be the better choice. Currently, CS1 citations useinherit. See the CS1 error message this user pageconversation, the error message doesn't display as I think it should. A quick experiment showed that usingtransparent might be preferable.[1]This (as of this message, the current) version in the sandbox includes a|plain option that adds the styling"background:transparent;border:none;{{{style|}}}" to the<code>...</code> used by the template, i.e. renders it more plainly (see testcases). Should I request that the live version is updated accordingly?Sardanaphalus (talk)09:28, 12 October 2014 (UTC)[reply]
{{parap}} or{{ppara}} or{{plp}} or some such other quick and easy name, that would take the same parameters as{{para}} and add the plain parameter:{{para|plain|{{{1}}}|{{{2}}}}} – this particular snippet is not tested{{paraplain}} are a bad thing and will seek to have them deleted. I don't care either way, but it is why I suggested a typing-aid template instead of a fork.{{para|plain|...}} plus shortcut preferable, so will now request the sandbox version. Regards,Sardanaphalus (talk)10:22, 18 October 2014 (UTC)[reply] | Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
Per the discussion above, please replace the current template withthis sandbox version (the current version as of this message).Sardanaphalus (talk)10:28, 18 October 2014 (UTC)[reply]
-- [[User:Edokter]] {{talk}}13:42, 18 October 2014 (UTC)[reply]{{paraplain}} in order for this update to make sense. –Jonesey95 (talk)00:58, 19 October 2014 (UTC)[reply]
Not done:@Sardanaphalus: There doesn't seem to be a consensus for this at the moment. Jonesey95's suggestion of a TfD at{{paraplain}} sounds like a good next step. —Mr. Stradivarius♪ talk ♪11:28, 20 October 2014 (UTC)[reply]<includeonly>...</includeonly>, I'm restoring the request here: | Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
Sardanaphalus (talk)16:56, 1 November 2014 (UTC)[reply]
-- [[User:Edokter]] {{talk}}21:36, 1 November 2014 (UTC)[reply] | Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
{{para|name|val|plain=yes}}, rather than{{para|plain|name|val}}. Using the first positional parameter for both formatting and for content is going to be confusing. Also, what happens when you want to display a parameter that is named "plain", "pln", "pl" or "p"? I bet that there are already some transclusions out there that do exactly this that would be broken by the proposed update. —Mr. Stradivarius♪ talk ♪13:00, 6 November 2014 (UTC)[reply]{{#if:|...}} to allowplain=1. Also, is the open style parameter an intended feature?-- [[User:Edokter]] {{talk}}14:14, 6 November 2014 (UTC)[reply]{{{style}}}, I just included it because Sardanaphalus did. Personally, I don't think it's really necessary. —Mr. Stradivarius♪ talk ♪16:15, 6 November 2014 (UTC)[reply]-- [[User:Edokter]] {{talk}}20:38, 6 November 2014 (UTC)[reply]{{para}} has only one parameter?|ps=|ps=none-- [[User:Edokter]] {{talk}}21:11, 6 November 2014 (UTC)[reply]|plain= option as a named parameter.-- [[User:Edokter]] {{talk}}08:27, 7 November 2014 (UTC)[reply]-- [[User:Edokter]] {{talk}}22:13, 7 November 2014 (UTC)[reply]Should the values handed to this template be stripped of any whitespace etc..?
<code><includeonly<nowiki>|</nowiki></includeonly>{{#if:{{{1|}}}|{{#if:true|{{{1}}}}}<nowiki>=</nowiki>}}{{#if:true|{{{2|}}}}}</code>Sardanaphalus (talk)10:19, 26 October 2014 (UTC)[reply]
| Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
To improve readability, please change:
<nowiki>=</nowiki>to:
<nowiki>= </nowiki>(i.e. add a space after the equals sign). Better still, perhaps the protection level could be lowered, so that template editors can make such changes?Andy Mabbett (Pigsonthewing);Talk to Andy;Andy's edits12:30, 27 October 2014 (UTC)[reply]
Not done: please establish aconsensus for this alteration before using the{{edit protected}} template. This proposal is contrary to that in the previous section. Personally I disagree with the addition of a space, because the absence of the space assists in the association of all four tokens (pipe, name, equals, value) so that when you're explaining something to a newbie by way of a code sample on a talk page, they see that the whole string is to be copied. --Redrose64 (talk)12:38, 27 October 2014 (UTC)[reply]{{para|something|else}} →|something=else{{para|something |else}} →|something =else{{para|something| else}} →|something= else{{para|something | else}} →|something = elsePlease replace the hardcoded code tag from<code> to<{{{tag|code}}}> so the fixed width font can represent a semantic. For me I like to use<code> to mean "toward the computer" and<kbd> to mean "toward the person". Someone else will have a semantic for when they like to use<tt>. I did{{param}} already. —CpiralCpiral08:09, 14 July 2015 (UTC)[reply]
It seems alike a nice addition toa more general solution, and it looks to be perhaps cleaner coding internally than the setup using|plain=. —CpiralCpiral08:26, 14 July 2015 (UTC)[reply]
{{{2}}} (<kbd>#switch to whitelist specific valuescode (default),kbd, andvar. The<tt> element has been killed in HTML5 so we need to wean away from it;<samp> doesn't apply; and other values would be semantically wrong or useless, depending on what someone put in there. If we want to satisfy purists, also have a switch option forkbdvar to use both at once. This doesn't affect or relate to|plain=, which strips thestyle=... code (the box and grey background).What it would look like:
|para=code|para=kbd|para=var|para=kbdvar|plain=:|para=code|para=kbd|para=var|para=kbdvarThe most common use case for this would be{{para|tag=var|content}}, which is the same character length asn{{para|{{var|content}}}} but visually easier to parse and less error-prone, while obviously shorter than{{para|<var>content</var>}} which is also a mixture of wikimarkup and HTML, which not everyone cares for.
Additional transclusion code conciseness could be achieved (at the cost of source code detail) by using{{{3}}} as an alias of{{{tag}}}:{{para|content|var}} or{{para|content|3=var}} when necessary. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:11, 20 July 2015 (UTC)[reply]
| Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
I would like to be able use this template to show key=value pairs for other types of blobs. For example given this URL
Given a hypothetical new|sep= argument:
&pg=PA165This would work with any separators like "?" or "," .. or if blank then no separator such as showing a basic key=value pair
The display "sep" would default to "|"
--GreenC16:43, 3 January 2019 (UTC)[reply]
This template is for giving examples of template parameter source code.
Not done: please make your requested changes to the template's sandbox first; seeWP:TESTCASES. --Redrose64 🌹 (talk)14:19, 5 January 2019 (UTC)[reply]The current output allows line-breaks, which in most cases makes it hard to read. This is clearly seen on mobile devices when viewing the table in the doc for this template.
In{{val}} people have attempted to avoid this by setting the size of columns in the table, which I think is a work-around, not a solution. The real solution is to make this template output html/css to prevent line breaks. Either by default, or make that an option you can enable with a parameter.—SkyLined(talk)14:12, 3 April 2023 (UTC)[reply]
| Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
I used{{para}} and got a line break after the pipe character. This looked ridiculous and makes little sense. I assume other line breaks would be possible, such as after a hyphen in the parameter name. Adding{{nowrap}} or equivalent would make far more sense than requiring editors to code, e.g.,{{nowrap|{{para|archive-url}}}}. While Note 2 below the table at "General-purpose formatting" speaks of nowrap options, I'm at a loss to see how they help my situation. In any event, I don't see how automatic, unconditional nowrap for all uses of{{para}} could be the slightest bit controversial. At the very least, an option could be added to suppress the default of nowrap for cases where horizontal space is limited, such as in tables.
See also#no line-breaks in output, where a request for this was ignored (or never seen) 13 months ago. As toIf the proposed edit might be controversial, discuss it on the protected page's talk pagebefore using this template.
, well, we've seen how effective that was. ―Mandruss ☎19:24, 5 May 2024 (UTC)[reply]
Not done for now: please establish aconsensus for this alterationbefore using the{{Edit template-protected}} template. --Redrose64 🌹 (talk)21:26, 5 May 2024 (UTC)[reply]class="nowrap" changed toclass="tpl-para"; don't know where that class is definedAtWikipedia:Village pump (proposals)/Archive 212#Add nowrap for para, we have a consensus for preventing line breaks after the pipe character, but it was never actioned. I'm still encountering the problem in spades and developing a rash. PingingRedrose64 andTrappist the monk. ―Mandruss ☎ IMO.21:15, 15 February 2025 (UTC)[reply]
<code>. My next comments start from that.tpl-para does not seem to be defined anywhere. I don't know its purpose (TheDJ is the one to ask). Assuming that it does nothing, what we have (when no parameters other than|1= and|2= are supplied) is a progressive replacement ofstyle="white-space:nowrap;" withstyle="word-break:break-word;". I consider that to be the primary cause here: neither the pipe nor the equals sign are part of the word that precedes or follows, so there is an explicit line-breaking opportunity on both sides of each of those characters. --Redrose64 🌹 (talk)22:17, 15 February 2025 (UTC)[reply]break-word value isdeprecated fortheword-break property, being treated by modern browsers as if it wereword-break:normal, which is the initial (i.e. default) state. So it's as if the declaration simply wasn't there. --Redrose64 🌹 (talk)23:16, 15 February 2025 (UTC)[reply]I think that I've got itis a bit vague. I still see the line break problem. ―Mandruss ☎ IMO.07:16, 16 February 2025 (UTC)[reply]
Is there a template that can easily highlight the "bar" in{{Foo|bar=baz, without the need for{{Foo?{{Para}} or{{Param}} seem like the most appropriate places to find this, but I could not. This would be very useful for template documentation.
Unfortunately, all permutations of|bar= on its own only produce|bar=. ~ Tom.Reding (talk ⋅dgaf) 12:54, 4 July 2024 (UTC)[reply]
<code dir="ltr">|<span>bar</span>=</code> →|bar=|bar= ←{{para|bar|mxt=yes}}|bar= ←{{para|bar|!mxt=yes}}|bar=, say|syn=yes, for "syntax"? ~ Tom.Reding (talk ⋅dgaf) 15:03, 4 July 2024 (UTC)[reply]{{para/sandbox|foo|syn=yes}} →|foo={{para}} templates that use either of|mxt= or|!mxt=. That makes me wonder if the better solution is to get rid of those two parameters in favor of|color= or|highlight= or some such withsyntax as the default coloring so editors don't have to remember multiple parameter names so:{{para|foo}} →|foo= – default uses<syntaxhighlight>...</syntaxhighlight> for coloration{{para|foo|color=red}} →|foo={{para|foo|color=green}} →|foo={{para|foo|color=none}} →|foo= – don't know why this would be necessary but some editors might not want to colorize because reasons<code>...</code> tag as it exists now and then switch on{{{color|}}} to create the opening<span> tag and its attribute:<span{{#switch:{{{color|}}}|red=style="color:#8B0000;"|green=style="color:#006400;"<!-- this 'green' color choice might want to be revisited -->|none=|#default=class="nl"}}>{{{1|}}}</span>
|style= is not used so I would propose that we delete support for that parameter.|color=/|highlight= (|highlight= can be the alias) are both more intuitive than|mxt=/|!mxt=. Also, the boolean pair|mxt=/|!mxt= logically doesn't work when 3rd & 4th options are available,syntax &none, so it makes sense to retire|mxt=/|!mxt=.<code>...</code> tag is preferable, since 2 adjacent tags produce an undesired thin vertical separator between them, visible inTemplate:Para/testcases#Spacing + syn=y & elsewhere.|style= seems harmless to keep, and potentially useful, but I don't feel strongly either way. However, if keeping it makes implementing the above significantly more difficult, then remove it. ~ Tom.Reding (talk ⋅dgaf) 11:41, 6 August 2024 (UTC)[reply]|style= is gone. Here is a new sandbox version. In all of these examples, the pipe and 'bar' are colored#333, '=' is colored#666, these are the current<syntaxhighlight>...</syntaxhighlight> colors{{para/sandbox|foo|bar}}|foo=bar – 'foo' uses<syntaxhighlight>...</syntaxhighlight> colors (currently#767600){{para/sandbox|foo|bar|color=none}}|foo=bar – nothing in the output is colored{{para/sandbox|foo|bar|color=red}}|foo=bar – 'foo' uses#8B0000; same color used by{{!mxt}}{{para/sandbox|foo|bar|color=green}}|foo=bar – 'foo' uses#008000; a slightly brighter green than the color used by{{mxt}} (#006400){{para/sandbox|foo|bar}}<codeclass="tpl-para"style="word-break:break-word; "class="mw-highlight mw-highlight-lang-wikitext mw-content-ltr"dir="ltr">|<spanclass="nl">foo</span><spanclass="o">=bar</span></code>{{example|foo=bar, which Ifixed.|section vs.|=section (Live vs. Sandbox). ~ Tom.Reding (talk ⋅dgaf) 09:53, 8 August 2024 (UTC)[reply]<syntaxhighlight>...</syntaxhighlight> renders over a background color of#f8f8f8. Should we mimic that? Or, should we strike out on our own and develop new colors (assuming we can figure out how to detect dark mode)?|mxt= and|!mxt= need to be replaced with|color=green and|color=red respectively. Seethis search.{{para}} on Minerva undark skin renders with the background color used by<syntaxhighlight>...</syntaxhighlight>. Does not change rendering on Minerva dark skin.I have hacked the sandbox and createdTemplate:Para/styles.css. These changes, at the least, make the rendered text somewhat readable. No doubt, there are better color choices to be made that look more-or-less the colors used by the undark mode. The chosen colors also need to be contrast accessible.—Trappist the monk (talk)18:42, 11 September 2024 (UTC)[reply]
<syntaxhighlight>...</syntaxhighlight> in both light and dark modes. ~ Tom.Reding (talk ⋅dgaf) 11:17, 12 September 2024 (UTC)[reply]<syntaxhighlight>...</syntaxhighlight>. So what do you really mean?<syntaxhighlight>...</syntaxhighlight>. If that happens, then both{{para}} &<syntaxhighlight>...</syntaxhighlight> should look the same in dark & light modes, right? In the testcases, to me, they do. Perhaps I'm not seeing styles.css being applied? All I did was purge the page. Is there anything more I should be doing? I have minimal experience with CSS. ~ Tom.Reding (talk ⋅dgaf) 12:36, 12 September 2024 (UTC)[reply]|color=green which has a color difference that is slightly underspec at 496, should be >=500). Color evaluations were made using snook's color contrast checker (https://snook.ca/technical/colour_contrast/colour.html).<syntaxhighlight>...</syntaxhighlight> undark-mode colors. I did change the color for|color=green so that it would be WCAG 2 AAA compliant. More detail inTemplate:Para/styles.css.<syntaxhighlight>...</syntaxhighlight> but that just broke<syntaxhighlight>...</syntaxhighlight> rendering in dark mode. Perhaps when<syntaxhighlight>...</syntaxhighlight> is made to be compatible with dark mode... | Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request. |
Description of suggested change:
Kindly update the mxt and !mxt equivalents per the Codex design system standards as well as how it appears now at those respective templates:var(--color-content-added, #006400); andcolor: var(--color-content-removed, #8B0000); for compatibility with custom CSS/custom skins/dark mode/ARIA/some accessibility technology... 😄 Thanks.
Also are you aware of what the goal of giving it classtpl-para was? Because there's no mention of that in any site-wide CSS sheets, and thsi template doesn't call any TemplateStyles? If the aim was so peopel could target the output oftm:para with their own custom CSS much easier, the better option would be anid=tpl-para-id as#tpl-para-id far more specific. Anyway.
waddie96 ★ (talk)07:46, 14 September 2025 (UTC)[reply]
Ywaddie96 ★ (talk)14:14, 14 September 2025 (UTC)[reply]id will be invalid HTML if the template is used more than once on a page, since IDs are supposed to be unique.Anomie⚔18:38, 14 September 2025 (UTC)[reply]id attribute value must be unique amongst all the IDs in the element's tree".Anomie⚔19:15, 14 September 2025 (UTC)[reply]