Jump to content

Template talk:Code

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

This is an old revision of this page, as edited by Kri (talk | contribs) at 16:38, 25 June 2017 (→Template not equivalent to the tag: Thanks). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Updates

  • {{code}} does not need to be substituted:
    • With subst: [[foo|bar]]
    • Without subst: [[foo|bar]]
  • Ampersands seem to work:
    • {{code|&[[foo|&bar]]}} gives &[[foo|&bar]]
  • You cannot use code for templates:
    • {{code|{{fact}}}} gives <sup class="noprint Inline-Template Template-Fact" style="white-space:nowrap;">&#91;<i>[[Wikipedia:Citation needed|<span title="This claim needs references to reliable sources.">citation needed</span>]]</i>&#93;</sup>
    • {{code|{{code|[[foo|bar]]}}}} gives '"`UNIQ--syntaxhighlight-0000000F-QINU`"'
  • Code will work for strings with strings that include an =, if you use 1=
    • {{code|1=Example <html>markup and !"£$%&/()=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters}} gives Example <html>markup and !"£$%&/()=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters
  • Code will not preserve whitespace— spaces and breaks; the only way to do this would to be use a <pre> style, which will add a break at the start and end. Code should be used for short samples; longer content should use <pre>...</pre> or <source>...</source>.

--—— Gadget850 (Ed) talk - 14:25, 6 March 2009 (UTC)[reply]

It actually does work with templates as input, as long as you ensure MediaWiki doesn't parse them as templates and cause them to be substituted:
  • {{code|<nowiki>{{fact|{{subst:DATE}}}}</nowiki>}} gives {{fact|{{subst:DATE}}}}
— SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 18:12, 19 June 2011 (UTC)[reply]

Display problem

Someone broke something. These no longer have the same CSS styling (not obvious unless you see it on a colored background instead of a white one):

  • <code>foo</code> = foo
  • {{code|bar}} = bar

The bar example's output needs to match the foo one, since that style is used about umpteen zillion times all over Wikipedia, and many other templates that use <code> also match it ({{tag}}, etc.) — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 21:01, 19 June 2011 (UTC)[reply]

It's not broken. It's just that {{code}} is not a replacement for <code>, but an inline version of <syntaxhighlight>, which not use <code>. Example: {{code|lang=CSS|body#content {color: #123456;} }} produces body#content {color: #123456;}. — Edokter (talk) — 22:27, 19 June 2011 (UTC)[reply]
I hadn't noticed this. Since this template doesn't exist for any reason other than formatting code, the entire thing needs to be surrounded by <code>...</code> anyway, for obvious semantic markup reasons; I think that would solve the issue entirely and transparently. Yep, it works perfectly: Template:Code/sandbox. It's pretty weird that a template called {{code}}, for code, wasn't using <code>. Looking over the history, I see that it's been through radical changes many times, so this oversight isn't so surprising after all, perhaps. I've examined the final XHTML that is sent to the user agent, and <syntaxhighlight>/<source> does not provide any <code>...</code> markup on the back end, either, so it honestly does need to be done here. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 00:54, 20 June 2011 (UTC)[reply]
That is not a desireable situation. Wrappig it in <code> here creates other problems; like possible conflicting font declarations, making it impossible to override the assigned GeSHi fonts, because <code> also has a font assigned. And GeSHI's font declaration mechanism is already a mess (by way of it's inline declarations). GeSHi uses <pre>, <div> or <span> to contain the code. GeSHi's homepage states that <code> may be added in future versions. For now, it is best not to interfere with it until support for <code> has been added. — Edokter (talk) — 01:19, 20 June 2011 (UTC)[reply]
Maybe this template should be moved, then, so that something that actually is a wikimarkup wrapper for <code> can be here. We certainly need one, and it gets used as if it is one all the time. But it's becoming clear that, if it won't be wrapped in <code>...</code> it really should not be used at all except for things that GeSHI has specific syntax highlighting for. Indeed, it should probably default to a nonsense |lang=foobarbaz if the parameter is missing or empty, so that it always throws its informative error message if it isn't fed a valid value. Right now, this template's name is grossly misleading. Given that <source> is a common pseudotag alias for this syntax highlighting magic, the amazingly available {{source}} is an obvious choice. Just for sanity's sake, I have redirected it to this template right now pending the outcome of the discussion, since even if this template remains at {{code}}, {{source}} is actually a much more obvious name for it (or perhaps for {{syntaxhighlight}}?), if this one remains a non-<code> syntax highlighting shorthand. And {{syntaxhighlight}} would appear to either need to be merged, or very clearly differentiated in both templates' documentation.
That said, I'm skeptical about my original, alternative proposal being problematic in any way. I guess I'd need to see a real-world demo of some kind of failure that can't be worked around. Putting <code> around it couldn't, to my mind, create conflicting font styling, since CSS is, well, cascading; my own demo shows that it does not conflict at all with the syntax highlighting, which overrides the code element's default in the natural course of the cascade of style rules being applied in order, just as expected. And <code> does not conflict with any of the containers GeSHi likes, since they are not phrase (semantic) markup, but meaning-free structural and presentational markup; the two really don't have much to do with each other. If GeSHI as used by this template will be putting <div> in particular inside of <code>, then I think that would be a markup problem, but I just did a view-source on the /sandbox test page, and it isn't doing that at all; it's putting a <span> (actually various spans) inside the <code>, which is perfectly normal and valid. So, I'm not seeing a clear rationale for not using <code> here and improving the template's usefulness, WP code markup's semantic sense, and this template's reason for being named what it is. :-)
— SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 07:43, 20 June 2011 (UTC)[reply]
Update: Actually, my solution is what makes this markup look even a little bit like correct at all on the mobile version of Wikipedia. Test http://en.m.wikipedia.org/wiki/Template:Code/sandbox in Android or whatever. The output of the current "live" {{code}} is just plain text (no monospace, no highlighting), while my version at least gets the font-family right. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 07:43, 20 June 2011 (UTC)[reply]
(←) I have to ask, but what is the advantage of creating a template version of <code>, and for that matter, of any other HTML tags like <kbd> and <samp>? In each of these cases, using the tags is just as easy as using the templates (if not easier), as the templates do not provide any extra functionality. Unlike {{dfn}}, which assign a class for consistent formatting and adds hint-popups. This template was not devised as a tag replacement, and we should not get hung up on HTML tag/template name matching. Not that I would appose a move to {{source}} per se, but this template is in very wide use.
I am not willing to mess with GeSHi's font declarations; I spent a better part of one day to get it to display properly to begin with. Wrapping GeSHi in any other tags with font-assignments may break that, resulting in inconsistent monospace font-sizes again (which sparked me to fix it in the first place). So any GeSHi formatted text (these include .js and .css pages) will not be wrapped in code tags.
Why GeSHi does not work on mobiles is entirely a different matter. I cannot test, but it seems it is somehow disabled for mobiles. — Edokter (talk) — 11:09, 20 June 2011 (UTC)[reply]
I have a longwinded response to this if you want it (with all sorts of detail on why wikimarkup wrappers for HTML tags are useful and do provide extra functionality, the most obvious being that the vast majority of today's Wikipedia editors to not know and will never know and should not be forced to know HTML and CSS). No one asked you in particular to do anything with anything. This isn't your userpage, and what you're personally "willing to mess with" isn't germane to the discussion. I've already demonstrated that properly wrapping this in <code>...</code> does not do anything to GeSHi's font declarations, nor affect the output of GeSHi (and explained why, in CSS cascading terms). Please provide an actual, non-hypothetical, non-trivial example of a <code>...</code> wrapper having undesired display consequences. If there isn't one, then please withdraw the objection. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 22:32, 22 June 2011 (UTC)[reply]
It's been a week now, with no evidence provided of any problem with this obvious, simple upgrade. So, please install <code>...</code> around this template, as tested at Template:Code/sandbox. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 15:55, 29 June 2011 (UTC)[reply]
OK, first off... no one asked anyone to do anything here! I saw a problem and I fixed it. So don't pass this off as some personal issue. Second, you need to demonstrate the need for the change, and not asume all is OK by waiving any objections and then expect to have consensus. I'm disabling the request and investigate any possible issues this change may generate. If I find there are no issues, I will make the change. If there are issues reported, don't be suprised if the change is undone. — Edokter (talk) — 16:28, 29 June 2011 (UTC)[reply]
I didn't come here to bicker, I came to get this template working the way it needs to, for broader purposes than this particular template as a thing unto itself, and hopefully transparently. I've linked several times to the article on the topic (and just did again); the need for the change is self-evident. Now that MW finally supports them, we do use the semantic "phrase" elements the way they were intended, for the same reason we do use valid XHTML, well-formed XML, standards-compliant CSS, and standardized microformats, do use <h3> for actual sub-headings not "big font" effects, don't code things so that color vision is required, and so on and so on: It's the correct and most useful way to do it. (I'm assuming you really know all this, since I offered the long explanation of why semantic markup is important and you didn't ask for it. I think I'd just point to you that article and to the several years of bugzilla on the topic anyway – it's taken a lot of developer work to make this happen. Template talk pages are for improving templates, not for Web development and information architecture lessons, and I think it'd be rather condescending to go into such a lecture at you.) If the change, despite my tests, actually does cause problems, then let's figure them out and work through them. We're both pretty smart, I think. :-) — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 05:24, 1 July 2011 (UTC)[reply]

Spacing issue

Resolved
 – Dead end; manual explicit spacing more practical than CSS effects.
Test code relating to this issue has been moved to Template:Code/sandbox2.

This badly needs padding-left:0.5em; padding-right:0.5em; added to it (hmm, perhaps added to the <code>...</code> proposed above...). The width of spaces in monospaced fonts is larger than in (sane) proportional fonts, so the results look really weird in constructions like:

  • Foo bar baz quux.

with foo and bar, and baz and quux, visually much closer to each other, respectively, than bar and baz are to each other, despite being grouped as part of the same phrase; it's visually very confusing and hard to parse, much less scan. I've implemented slight padding adjustments like this at {{kbd}} and {{samp}} already. I've also implemented it in Template:Code/sandbox2:

  • Old:  Foo bar baz quux.
  • New:  Foo bar baz quux.
  • <code>:  Foo bar baz quux.

for immediate testing. Tested myself in Firefox 4 (Windows 7), IE 9 (Win 7), Samsung Internet (Android 2.2), Firefox4 (Android 2.2), Motorola Browser (Android 2.2), Chrome 12 (Win 7), Safari 5 (Win 7). The results are all remarkably consistent and positive.

NB: The fact that this spacing problem also happens with plain <code> markup is a clear indication (among many others) of the need for a wrapper template for it here to which style adjustments like this can be applied. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 07:43, 20 June 2011 (UTC)[reply]

What you’re doing here is approximating the difference between the widths of the space characters U+0020 of two different fonts at the same font-size, which is far from being an exact science. Two suggestions:
  1. I see no reason for the left/right padding to be asymmetric.
  2. Said padding should be introduced through a global CSS declaration for span.mw-geshi.
Taking it to Common.css (rather than hard-coding the template) would be friendlier to the job queue and also accommodate anyone whose unorthodox font selections make this a change for the worse. ―cobaltcigs 08:12, 20 June 2011 (UTC)[reply]
The asymmetry was an error on my part; since corrected (including above; I didn't see that you'd already commented). It's not an exact science, but I've gotten this one really, really close. The results can be literally measured with a ruler and are consistent within less than one milimeter even at a huge font size (hitting Ctrl+ 5 or 6 times), and even on platforms like Droid phones. So, at least that's something. Heh.
The padding doesn't have anything to do with span.mw-geshi specifically, but all of these code-related elements and their monospacing; see the newly added block of tests at the bottom of Template:Code/sandbox2. It could be added to the global CSS, but would have to be overridden for one of them anyway, and adding custom CSS to a grand total of I think 3 templates isn't going to kill anyone (it's already in 2 of them, just not this one). I guess I don't really care either way, but this template would need modification to handle it, either for directly-added CSS as in {{kbd}} and {{samp}}, or they all need a class added after the site-wide style sheet were modified.— SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 08:54, 20 June 2011 (UTC)[reply]
Of course the issue will become slightly complicated when the template (or code-tag, or whatever) is adjacent to something other than a regular space in the default font (e.g. programming keywords may appear at the start of a paragraph, immediately before a comma/period, or inside quotation marks, parentheses, etc.) and I can’t think of any intelligent way to address that. ―cobaltcigs 08:25, 20 June 2011 (UTC)[reply]
Good point. A parameter, I guess. Hmph. Any better solution? Maybe it needs to be extrapolated out into a wrapper, some {{monospacer}} template or something? That would be easy, except for the need for customization for {{kbd}} (assuming its differentiated formatting, with a hint of letter-spacing, stays as-is; it's experimental to begin with). There just has to be some way to get around the problem that putting monospaced stuff next to proportional stuff looks awful and even directly misleading because of the much wider space character size in the former. I'm really tired right now (nearly 3am, my time), so maybe it will be clearer tomorrow! Nitey-nite! — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 08:54, 20 June 2011 (UTC)[reply]
On third thought, I think this may have to be handled in a way similar to {{'"}} and various other templates like that I've come up with over the years to deal with similar formatting annoyances. Like, a {{codelead}} and {{codetrail}}, {{kbdlead}}, {{kbdtrail}}, and {{samplead}} and {{samptrail}} that are variants that drop the no-longer-appropriate padding (L or R) either for leading a paragraph (or other such construction - table cell, etc.) or being the trailing end of one. Or maybe the whole model could be extrapolated out into containers, {{monospacer}}, {{monolead}}, {{monotrail}}. (I'm intentionally avoiding start/begin/top and end/bottom in those draft names, since people think of stuff like {{collapse top}} and {{refbegin}} and other two-part "bookend" templates.) — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 09:07, 20 June 2011 (UTC)[reply]
It was easier to just do this as parameters, since they won't be needed much. See Template:Code/sandbox2, bottom of page for tests. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 22:51, 22 June 2011 (UTC)[reply]
I really don't see a problem here. And all the suggestions above makes these templates needlesly complicated. Whatever spacing you try to include, it is always going to be inconsistent, as you always have to account for different fonts. The best way to deal with this is to simply include the spaces in the pre-formatted block or line. — Edokter (talk) — 16:37, 29 June 2011 (UTC)[reply]
Quite possibly. The results I get are actually remarkably consistent, though, across (so far) 7 browsers on multiple platforms, including even cell phones. I think it's probably better to use &nbsp; spacing before/after the code, though, since (depending on the context) spacing inside a block of code may actually have some semantic meaning (e.g. code indentation levels, or two spaces not one space in a filename, or whatever) and not be purely visual. Anyway, I've basically abandoned this CSS spacing experiment, for now at least. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 05:43, 1 July 2011 (UTC)[reply]

What's the purpose of ZWSP?

What's the purpose of the Zero-width space characters placed at both sides of the code argument? It produces various kinds of frustrating breaks, when the code output from a wiki page is copy-pasted into an editor, since the ZWSP characters are usually not visible, yet unrecognisable to common toolchains. I don't see what advantage does the ZWSP bring, since other templates, that implement similar functionality, can manage without it. I propose to remove the ZWSP characters.1exec1 (talk) 02:46, 25 August 2011 (UTC)[reply]


Bolding in Code

It explicitly tell you that if you use triple quotes it will not bold, and will instead show up as the triple quotes. Is there a way that you CAN actually create boldface in code? I am looking for a way to do so.

ღ Shnow 17:56, 18 January 2013 (UTC) — Preceding unsigned comment added by Shnowflake (talk • contribs)

Something like:
Markup Renders as 
{{code|text}} '''{{code|bold text}}''' {{code|text}}

text bold text text

--— Gadget850 (Ed) talk 21:36, 18 January 2013 (UTC)[reply]

Spaces

It would be nice if the {{code}} template replaced spaces embedded witin its argument with non-code/proportional font spaces. In other words, {{code|int x}} would convert to <code>int</code> <code>x</code> and would be rendered as int x, using the default proportional/non-fixed font for the embedded (breaking) space, and thus provide words having the same inter-word spacing as the surrounding non-code text, (instead of being rendered as int x, which is displayed with an awkwardly wider space). A longer example is {{code|unsigned long long int}}, which would be rendered as unsigned long long int instead of as unsigned long long int. (Please note that I am not suggesting that embedded spaces be replaced with non-breaking spaces.) — Loadmaster (talk) 02:59, 21 May 2013 (UTC)[reply]

I note that you are demonstrating some of your proposed changes by using the obsolete TT element, which doesn't look quite the same as the CODE element, which is what the {{code}} template uses internally - the background is different. If I rewrite your "longer example" demo to use <code>...</code> instead of <tt>...</tt>, you might notice it
{{code|unsigned long long int}}, which would be rendered as unsigned long long int instead of as unsigned long long int.
It's not so obvious in Vector skin as in Monobook, so here's the same but on a darker background
Your example would be rendered as unsigned long long int instead of as unsigned long long int
My adjustment would be rendered as unsigned long long int instead of as unsigned long long int.
Notice how the spaces no longer have the same background as the words either side. This is not the only reason that I oppose this change. Another is that it is very complicated to loop through a string, character by character, looking for spaces and inserting additional markup. --Redrose64 (talk) 10:51, 21 May 2013 (UTC)[reply]
Yes, I used <tt> precisely because of its transparent background properties. (Is there a specific reason that <code> markups have a white background color?) But {{code|unsigned long long int}} stills renders the spaces too wide, as unsigned long long int; I'd prefer it to render as unsigned long long int. Given my druthers, I'd prefer both behaviors, the transparent background and the proportional inter-word spacing. Is there a CSS property that defines the inter-word spacing for the <code> (or any other) element? — Loadmaster (talk) 00:23, 22 May 2013 (UTC)[reply]
The CSS which Wikipedia has assigned to the CODE element is as follows:
pre, code, tt, kbd, samp, .mw-code {
  font-family: monospace,Courier
}
code {
  background-color: #f9f9f9
}
What this states goes roughly like this.
  • HTML that is marked up using the PRE, CODE, TT, KBD, or SAMP elements, also elements to which the mw-code class has been assigned, is to be displayed using a generic monospace font, or if none has been assigned, use the Courier font
  • HTML that is marked up using the CODE element is additionally to be given the background colour #f9f9f9  
This styling affects all text between the <code> and </code> tags indiscriminately. The CODE element - like all other HTML markup - has no concept of a "word" - it cannot distinguish spaces from other characters. For all characters (including spaces), the physical characteristics, such as appearance and dimensions, are governed by the font. One of the characteristics of a monospace font (such as Courier) - indeed its defining characteristic - is that all characters - including spaces - are exactly the same width as each other. Unless you have explicitly marked up the spaces in some manner that is different from the remaining text, there is no HTML, and no CSS, which can say "treat text one way, but treat spaces another way". In order to have the spaces narrower than the other characters, the font itself would need to define the space character to be narrower. I do not know of any such fonts. --Redrose64 (talk) 09:39, 22 May 2013 (UTC)[reply]
The only way to achieve your desire is to wrap each word in {{code}} with normal spaces between. --  Gadget850 talk 10:25, 22 May 2013 (UTC)[reply]
It's not entirely accurate to say that HTML does not have a concept of "words". HTML does in fact distinguish between spaces, newlines, and printing characters. Within the content of all elements, runs of spaces and newlines are collapsed into a single space. The <pre> element, though, is an exception, which implicitly preserves all spaces and newlines by default. In fact, the <pre> tag implicitly uses the white-space:pre CSS property ("pre" meaning "preserve (spaces)"). But I get your point about font widths. There is, however, a word-spacing CSS property, which specifies an extra space to add between words and which can be negative. That's what I was hoping could be used. For example, <code style="word-spacing:-0.2em">unsigned long long int</code> produces unsigned long long int. Could something like that be added to the {{code}} template? — Loadmaster (talk) 18:23, 22 May 2013 (UTC)[reply]
It seems that such a property does exist in CSS 2.1, something of which I was unaware, probably because I've never seen it being used or needed to look it up. It does state "This value indicates inter-word space in addition to the default space between words. Values may be negative, but there may be implementation-specific limits". --Redrose64 (talk) 18:53, 22 May 2013 (UTC)[reply]
Same here, but there are so many properties, so little time. Would we want to add this as hard-coded or add |style=? (which should be added anyway) --  Gadget850 talk 19:05, 22 May 2013 (UTC)[reply]
It would be nice to add it, since a reasonable-looking default spacing width could be provided. And yes, style= should also be allowed. — Loadmaster (talk) 20:30, 22 May 2013 (UTC)[reply]

Nowrap option

It would be useful in some cases to avoid wrapping the output produced by GeSHi. For example, a few of the Lua tables in Module:TableTools/doc are wrapping across two lines, but I think they would be easier to understand if they didn't wrap. How about adding a parameter |wrap=no that would add class="nowrap" to the opening <code> tag? — Mr. Stradivarius ♪ talk ♪ 02:15, 30 March 2014 (UTC)[reply]

Most shortcut template allow passing class/style and such, so I did the same here. Now you can use |class=nowrap. Be carefull thoug; this is an inline template and applying nowrap to long lines may result in horizontal scrollbars. Consider splitting up long lines of code. — Edokter (talk) — 12:05, 30 March 2014 (UTC)[reply]
Thanks! — Mr. Stradivarius ♪ talk ♪ 12:29, 30 March 2014 (UTC)[reply]

Template is producing garbage

{{code|<nowiki>foo</nowiki>}} now produces foo. This makes documentation for several templates, including this one and {{track gauge}}, totally meaningless. I had to purge this page's cache to see it here, so it must result from a pretty recent change. Hairy Dude (talk) 14:04, 22 March 2016 (UTC)[reply]

Server-side bug; not related to the template itself, but rather to the use of <nowiki>. -- [[User:Edokter]] {{talk}} 16:38, 22 March 2016 (UTC)[reply]
@Hairy Dude: This is Wikipedia:Village pump (technical)#Strip marker problems with nowiki tags. In most cases you can fix by simply omitting the <nowiki>...</nowiki>. --Redrose64 (talk) 10:38, 23 March 2016 (UTC)[reply]

Doubled code tags

I'm not sure when this changed, but {{#tag:syntaxhighlight}} now wraps itself in a <code> element. This makes this template's output <code><code>...</code></code>. Is there any reason to double up the <code> tags?

If not, I'd like to propose /sandbox, which uses <span> as a wrapper, and only if necessitated by a class, id, or style parameter. Seems okay in /testcases. Matt Fitzpatrick (talk) 04:28, 7 April 2016 (UTC)[reply]

Seems like the |enclose= parameter is defunct. Perhaps the attributes can be passed instead, so a span is not needed at all. -- [[User:Edokter]] {{talk}} 10:47, 7 April 2016 (UTC)[reply]
The enclose= attribute (not parameter) of <syntaxhighlight>...</syntaxhighlight> has been inoperative since 26 June 2015, round about the time that they rewrote it to use Pygments instead of GeSHi. For a few days or weeks, everything was displayed inline; after a lot of complaints about multiline code examples being broken, it was altered to enclose everything in a div. AFAIK that can't be turned off.
But it shouldn't be necessary to be this complicated, when the <syntaxhighlight> tag accepts the class= id= and style= attributes - see this version. --Redrose64 (talk) 15:14, 7 April 2016 (UTC)[reply]
I ment as parameter to the #tag: syntax. According to the doc, inline(=1) should work, as does enclose="none" as backward compatible parameter. Class, id and style are not documented. -- [[User:Edokter]] {{talk}} 15:36, 7 April 2016 (UTC)[reply]
Ah, but they work. Have a look at this - Some Text - in your browser's "View source" or "Inspect element" feature. --Redrose64 (talk) 18:17, 7 April 2016 (UTC)[reply]
Perhaps that is standard parser behaviour. As you may have noticed in the sandbox, passing an empty style parameter results in an empty style attribute. -- [[User:Edokter]] {{talk}} 19:13, 7 April 2016 (UTC)[reply]
For something like this the emitted HTML does have a style= attribute which is empty, but that is valid since the value of the style attribute is a CSS declaration block omitting the braces, and a declaration block may have zero or more semicolon-separated declarations. --Redrose64 (talk) 19:53, 7 April 2016 (UTC)[reply]
Yeah, but what is the point of emitting empty attributes? -- [[User:Edokter]] {{talk}} 20:20, 7 April 2016 (UTC)[reply]
None; but it's harmless. The reason for putting style= outside the #if: is that it doesn't want to work inside. Compare this with this. --Redrose64 (talk) 21:44, 7 April 2016 (UTC)[reply]
Good catch. -- [[User:Edokter]] {{talk}} 11:01, 8 April 2016 (UTC)[reply]

Template not equivalent to the <code> tag

The code {{code|<nowiki><math></nowiki>}} results in &lt;math&gt;, but I think the code should be equivalent to <code><nowiki><math></nowiki></code>, which results in <math> (which is what I want to get). Why don't they result in the same thing? —Kri (talk) 15:20, 25 June 2017 (UTC)[reply]

@Kri: The {{code}} template doesn't reproduce literally, it performs some pre-mashing. Use {{tag|math|o}} → <math>, or for the pair use {{tag|math}} → <math>...</math>. --Redrose64 🌹 (talk) 16:00, 25 June 2017 (UTC)[reply]
Ah, thanks. —Kri (talk) 16:37, 25 June 2017 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Code&oldid=787473800"