Jump to content

Template talk:Code: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Removed this section auto archiving notice and deducted archive of 6 months.
Tags: Mobile edit Mobile web edit
m Archiving 14 discussion(s) to Template talk:Code/Archive 1) (bot
Tag: Replaced
Line 14: Line 14:
*[[/Archive 1|Archive 1]]
*[[/Archive 1|Archive 1]]
}}
}}

== Updates ==

* {{tl|code}} does not need to be substituted:
** With subst: <code><nowiki>[[foo|bar]]</nowiki></code>
** Without subst: {{code|[[foo|bar]]}}
* Ampersands seem to work:
** <nowiki>{{code|&[[foo|&bar]]}}</nowiki> gives {{code|&[[foo|&bar]]}}
* You cannot use code for templates:
** <nowiki>{{code|{{fact}}}}</nowiki> gives {{code|{{fact}}}}
** <nowiki>{{code|{{code|[[foo|bar]]}}}}</nowiki> gives {{code|{{code|[[foo|bar]]}}}}
* Code will work for strings with strings that include an =, if you use 1=
**<nowiki>{{code|1=Example <html>markup and !"£$%&/()=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters}}</nowiki> gives {{code|1=Example <html>markup and !"£$%&/()=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters}}
* Code will not preserve whitespace— spaces and breaks; the only way to do this would to be use a {{tag|pre|open}} style, which will add a break at the start and end. Code should be used for short samples; longer content should use {{tag|pre}} or {{tag|source}}.

--—<i><b>—&nbsp;[[User:Gadget850|<span style="color:gray;">Gadget850&nbsp;(Ed)</span>]]&nbsp;[[User talk:Gadget850|<sup style="color:darkblue;">talk</sup>]]</b> - </i> 14:25, 6 March 2009 (UTC)

: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>{{code|&lt;nowiki&gt;{{fact|{{subst:DATE}}}}&lt;/nowiki&gt;}}</nowiki></code> gives {{code|<nowiki>{{fact|{{subst:DATE}}}}</nowiki>}}
:— <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 18:12, 19 June 2011 (UTC)

== 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):
<blockquote style="background:#EEEEEE;">
*{{tag|code|content=foo}} = <code>foo</code>
*<code><nowiki>{{code|bar}}</nowiki></code> = {{code|bar}}
</blockquote>
The {{var|bar}} example's output needs to match the {{var|foo}} one, since that style is used about umpteen zillion times all over Wikipedia, and many other templates that use {{tag|code|open}} also match it ({{tlx|tag}}, etc.) — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 21:01, 19 June 2011 (UTC)

:It's not broken. It's just that {{tl|code}} is not a replacement for {{tag|code|open}}, but an inline version of {{tag|syntaxhighlight|open}}, which not use {{tag|code|open}}. Example: <nowiki>{{code|lang=CSS|body#content {color: #123456;} }}</nowiki> produces {{code|lang=CSS|body#content {color: #123456;} }}.<span style="font-family:'Trebuchet MS',sans-serif"> — [[User:Edokter|<span style="color:#008"><i>E</i>dokter</span>]] ([[User_talk:Edokter|<span style="color:#080">talk</span>]]) — </span> 22:27, 19 June 2011 (UTC)
::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 {{tag|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 {{tnull|code}}, for code, wasn't using {{tag|code|open}}. 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 {{tag|syntaxhighlight|open}}/{{tag|source|open}} does not provide any {{tag|code}} markup on the back end, either, so it honestly does need to be done here. — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 00:54, 20 June 2011 (UTC)
:::That is not a desireable situation. Wrappig it in {{tag|code|open}} here creates other problems; like possible conflicting font declarations, making it impossible to override the assigned GeSHi fonts, because {{tag|code|open}} also has a font assigned. And GeSHI's font declaration mechanism is already a mess (by way of it's inline declarations). GeSHi uses {{tag|pre|open}}, {{tag|div|open}} or {{tag|span|open}} to contain the code. GeSHi's homepage states that {{tag|code|open}} may be added in future versions. For now, it is best not to interfere with it until support for {{tag|code|open}} has been added. <span style="font-family:'Trebuchet MS',sans-serif"> — [[User:Edokter|<span style="color:#008"><i>E</i>dokter</span>]] ([[User_talk:Edokter|<span style="color:#080">talk</span>]]) — </span> 01:19, 20 June 2011 (UTC)
::::Maybe this template should be moved, then, so that something that actually is a wikimarkup wrapper for {{tag|code|open}} 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 {{tag|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 {{para|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 {{tag|source|open}} is a common pseudotag alias for this syntax highlighting magic, the amazingly available {{tlx|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 {{tnull|code}}, {{tnull|source}} is actually a much more obvious name for it (or perhaps for {{tlx|syntaxhighlight}}?), if this one remains a non-{{tag|code|open}} syntax highlighting shorthand. And {{tlx|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 {{tag|code|open}} 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 {{tag|code|open}} 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 <em>as used by this template</em> will be putting {{tag|div|open}} in particular inside of {{tag|code|open}}, 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 {{tag|span|open}} (actually various spans) inside the {{tag|code|open}}, which is perfectly normal and valid. So, I'm not seeing a clear rationale for not using {{tag|code|open}} here and improving the template's usefulness, WP code markup's semantic sense, and this template's reason for being named what it is. :-)
::::— <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 07:43, 20 June 2011 (UTC)
::::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" {{tnull|code}} is just plain text (no monospace, no highlighting), while my version at least gets the font-family right. — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 07:43, 20 June 2011 (UTC)
:(←) I have to ask, but what is the advantage of creating a template version of {{tag|code|open}}, and for that matter, of any other HTML tags like {{tag|kbd|open}} and {{tag|samp|open}}? 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 {{tl|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 {{tl|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. <span style="font-family:'Trebuchet MS',sans-serif"> — [[User:Edokter|<span style="color:#008"><i>E</i>dokter</span>]] ([[User_talk:Edokter|<span style="color:#080">talk</span>]]) — </span> 11:09, 20 June 2011 (UTC)
::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 {{em|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 {{tag|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 {{tag|code}} wrapper having undesired display consequences. If there isn't one, then please withdraw the objection. — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 22:32, 22 June 2011 (UTC)
{{editprotected|answered=yes}}
:::It's been a week now, with no evidence provided of any problem with this obvious, simple upgrade. So, please install {{tag|code}} around this template, as tested at [[Template:Code/sandbox]]. — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 15:55, 29 June 2011 (UTC)
:::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. <span style="font-family:'Trebuchet MS',sans-serif"> — [[User:Edokter|<span style="color:#008"><i>E</i>dokter</span>]] ([[User_talk:Edokter|<span style="color:#080">talk</span>]]) — </span> 16:28, 29 June 2011 (UTC)
::::I didn't come here to bicker, I came to get this template working the way it needs to, for [[Separation of content and presentation|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 {{em|do}} use the semantic "phrase" elements the way they were intended, for the same reason we {{em|do}} use valid XHTML, well-formed XML, standards-compliant CSS, and standardized microformats, {{em|do}} use {{tag|h3|open}} for actual sub-headings not "big font" effects, {{em|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 &ndash; 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. :-) — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 05:24, 1 July 2011 (UTC)

==Spacing issue==
{{Resolved|1=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 <code>padding-left:0.5em; padding-right:0.5em;</code> added to it (hmm, perhaps added to the {{tag|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 {{code|bar baz}} quux.
with <code>foo</code> and <code>bar</code>, and <code>baz</code> and <code>quux</code>, visually much closer to each other, respectively, than <code>bar</code> and <code>baz</code> 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 {{tlx|kbd}} and {{tlx|samp}} already. I've also implemented it in [[Template:Code/sandbox2]]:
*Old:&nbsp;&nbsp;Foo {{code|bar baz}} quux.
*New:&nbsp;&nbsp;Foo {{code/sandbox2|bar baz}} quux.
*{{tag|code|open}}:&nbsp;&nbsp;Foo <code>bar baz</code> 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 {{tag|code|open}} 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. — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 07:43, 20 June 2011 (UTC)

: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:
:#I see no reason for the left/right padding to be asymmetric.
:#Said padding should be introduced through a global CSS declaration for <code>span.mw-geshi</code>.
: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. ―[[special:contributions/cobaltcigs|cobaltcigs]] 08:12, 20 June 2011 (UTC)
::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 {{key press|Ctrl}}{{key press|+}} 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 {{tlx|kbd}} and {{tlx|samp}}, or they all need a class added after the site-wide style sheet were modified.— <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 08:54, 20 June 2011 (UTC)
: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. ―[[special:contributions/cobaltcigs|cobaltcigs]] 08:25, 20 June 2011 (UTC)
::Good point. A parameter, I guess. Hmph. Any better solution? Maybe it needs to be extrapolated out into a wrapper, some {{tlx|monospacer}} template or something? That would be easy, except for the need for customization for {{tl|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! — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 08:54, 20 June 2011 (UTC)
::On third thought, I think this may have to be handled in a way similar to {{tlx|'"}} and various other templates like that I've come up with over the years to deal with similar formatting annoyances. Like, a {{tlx|codelead}} and {{tlx|codetrail}}, {{tlx|kbdlead}}, {{tlx|kbdtrail}}, and {{tlx|samplead}} and {{tlx|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, {{tlx|monospacer}}, {{tlx|monolead}}, {{tlx|monotrail}}. (I'm intentionally avoiding start/begin/top and end/bottom in those draft names, since people think of stuff like {{tlx|collapse top}} and {{tlx|refbegin}} and other two-part "bookend" templates.) — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 09:07, 20 June 2011 (UTC)
:::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. — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 22:51, 22 June 2011 (UTC)
: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. <span style="font-family:'Trebuchet MS',sans-serif"> — [[User:Edokter|<span style="color:#008"><i>E</i>dokter</span>]] ([[User_talk:Edokter|<span style="color:#080">talk</span>]]) — </span> 16:37, 29 June 2011 (UTC)
::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 <code>&amp;nbsp;</code> spacing before/after the code, though, since (depending on the context) spacing {{em|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. — <span style="font-family:Trebuchet MS">'''[[User:SMcCandlish|SMcCandlish]]''' <span style="white-space:nowrap;">[[User talk:SMcCandlish|Talk⇒]] ʕ(<sup>Õ</sup>ل<sup>ō</sup>)ˀ</span> <small>[[Special:Contributions/SMcCandlish|Contribs]].</small></span> 05:43, 1 July 2011 (UTC)

== 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.[[User:1exec1|1exec1]] ([[User talk:1exec1|talk]]) 02:46, 25 August 2011 (UTC)


== 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) <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Shnowflake|Shnowflake]] ([[User talk:Shnowflake|talk]] • [[Special:Contributions/Shnowflake|contribs]]) </span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
:Something like:

{{markup|margin=5em
|<nowiki>{{code|text}} '''{{code|bold text}}''' {{code|text}}</nowiki>
|{{code|text}} '''{{code|bold text}}''' {{code|text}}
}}

:--'''''—&nbsp;[[User:Gadget850|<span style="color:gray">Gadget850&nbsp;(Ed)</span>]]'''''<sup>[[User talk:Gadget850|&nbsp;''talk'']]</sup> 21:36, 18 January 2013 (UTC)

== Spaces ==
<!-- do NOT fix any of the <tt> tags in this conversation since they were specifically addressed-->
It would be nice if the <code><nowiki>{{code}}</nowiki></code> template replaced spaces embedded witin its argument with non-code/proportional font spaces. In other words, <!-- do NOT fix any of the <tt> tags in this conversation since they were specifically addressed--><code><nowiki>{{code|int x}}</nowiki></code> would convert to <code><nowiki><code>int</code> <code>x</code></nowiki></code> and would be rendered as {{blue|<code>int</code>&nbsp;<code>x</code>}}, 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 {{blue|<code>int&nbsp;x</code>}}, which is displayed with an awkwardly wider space). A longer example is <code><nowiki>{{code|unsigned long long int}}</nowiki></code>, which would be rendered as {{blue|<code>unsigned</code> <code>long</code> <code>long</code> <code>int</code>}} instead of as {{blue|<code>unsigned long long int</code>}}.<!-- do NOT fix any of the <tt> tags in this conversation since they were specifically addressed--> (Please note that I am ''not'' suggesting that embedded spaces be replaced with non-breaking spaces.) — [[User:Loadmaster|Loadmaster]] ([[User talk:Loadmaster|talk]]) 02:59, 21 May 2013 (UTC)
:I note that you are demonstrating some of your proposed changes by using [http://www.w3.org/TR/html5/obsolete.html#tt the obsolete TT element], which doesn't look quite the same as [http://www.w3.org/TR/html5/text-level-semantics.html#the-code-element the CODE element], which is what the {{tlx|code}} template uses internally - the background is different. If I rewrite your "longer example" demo to use {{tag|code}} instead of {{tag|tt}}, you might notice it
::<code><nowiki>{{code|unsigned long long int}}</nowiki></code>, which would be rendered as {{blue|<code>unsigned</code> <code>long</code> <code>long</code> <code>int</code>}} instead of as {{blue|<code>unsigned long long int</code>}}.
:It's not so obvious in [//en.wikipedia.org/wiki/Template_talk:Code?useskin=vector#Spaces Vector] skin as in [//en.wikipedia.org/wiki/Template_talk:Code?useskin=monobook#Spaces Monobook], so here's the same but on a darker background
::<div style="background-color:#bfe4ff;padding-top:0.5em;padding-bottom:0.5em;">Your example would be rendered as <!-- do NOT fix any of the <tt> tags in this conversation since they were specifically addressed-->{{blue|<code>unsigned</code> <code>long</code> <code>long</code> <code>int</code>}} instead of as {{blue|<code>unsigned long long int</code>}}<!-- do NOT fix any of the <tt> tags in this conversation since they were specifically addressed--><br />My adjustment would be rendered as {{blue|<code>unsigned</code> <code>long</code> <code>long</code> <code>int</code>}} instead of as {{blue|<code>unsigned long long int</code>}}.</div>
: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. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 10:51, 21 May 2013 (UTC)<!-- do NOT fix any of the <tt> tags in this conversation since they were specifically addressed-->

:::Yes, I used <code>&lt;tt&gt;</code> precisely because of its transparent background properties. (Is there a specific reason that <code>&lt;code&gt;</code> markups have a white background color?) But <code><nowiki>{{code|unsigned long long int}}</nowiki></code> stills renders the spaces too wide, as {{blue|{{code|unsigned long long int}}}}; I'd prefer it to render as {{blue|{{code|unsigned}} {{code|long}} {{code|long}} {{code|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>&lt;code&gt;</code> (or any other) element? — [[User:Loadmaster|Loadmaster]] ([[User talk:Loadmaster|talk]]) 00:23, 22 May 2013 (UTC)
::::The CSS which Wikipedia has assigned to the CODE element is as follows:
<syntaxhighlight lang=css>
pre, code, tt, kbd, samp, .mw-code {
font-family: monospace,Courier
}
code {
background-color: #f9f9f9
}
</syntaxhighlight>
::::What this states goes roughly like this.
::::*HTML that is marked up using the [http://www.w3.org/TR/html5/grouping-content.html#the-pre-element PRE], [http://www.w3.org/TR/html5/text-level-semantics.html#the-code-element CODE], [http://www.w3.org/TR/html5/obsolete.html#tt TT], [http://www.w3.org/TR/html5/text-level-semantics.html#the-kbd-element KBD], or [http://www.w3.org/TR/html5/text-level-semantics.html#the-samp-element SAMP] elements, also elements to which the <code>mw-code</code> class has been assigned, is to be displayed using [http://www.w3.org/TR/CSS21/fonts.html#font-family-prop a generic monospace font], or if none has been assigned, use the Courier font
::::*HTML that is marked up using the [http://www.w3.org/TR/html5/text-level-semantics.html#the-code-element CODE] element is additionally to be given the [http://www.w3.org/TR/CSS21/colors.html#propdef-background-color background colour] <code>#f9f9f9</code> {{Color box|#f9f9f9|border=darkgray}}
::::This styling affects all text between the {{tag|code|o}} and {{tag|code|c}} 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 (typeface)|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. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 09:39, 22 May 2013 (UTC)
:::::The only way to achieve your desire is to wrap each word in {{tl|code}} with normal spaces between. --<span style="color:Turquoise">''''' &nbsp;[[User:Gadget850|Gadget850]]'''''<sup>[[User talk:Gadget850|&nbsp;''talk'']]</sup></span> 10:25, 22 May 2013 (UTC)

::::::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 <code>&lt;pre&gt;</code> element, though, is an exception, which implicitly preserves all spaces and newlines by default. In fact, the <code>&lt;pre&gt;</code> tag implicitly uses the <code>white-space:pre</code> CSS property ("pre" meaning "preserve (spaces)"). But I get your point about font widths. There is, however, a <code>word-spacing</code> 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="color:#609">&lt;code style="word-spacing:-0.2em"&gt;unsigned long long int&lt;/code&gt;</code> produces <code style="word-spacing:-0.2em; color:#00C">unsigned long long int</code>. Could something like that be added to the <code><nowiki>{{code}}</nowiki></code> template? — [[User:Loadmaster|Loadmaster]] ([[User talk:Loadmaster|talk]]) 18:23, 22 May 2013 (UTC)
:::::::It seems that such a property [http://www.w3.org/TR/CSS21/text.html#propdef-word-spacing 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". --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 18:53, 22 May 2013 (UTC)
::::::::Same here, but there are so many properties, so little time. Would we want to add this as hard-coded or add {{para|style}}? (which should be added anyway) --<span style="color:Turquoise">''''' &nbsp;[[User:Gadget850|Gadget850]]'''''<sup>[[User talk:Gadget850|&nbsp;''talk'']]</sup></span> 19:05, 22 May 2013 (UTC)

::::::::: It would be nice to add it, since a reasonable-looking ''default'' spacing width could be provided<!-- (probably something close to {{mono|−0.2em}})-->. And yes, {{mono|style=}} should also be allowed. — [[User:Loadmaster|Loadmaster]] ([[User talk:Loadmaster|talk]]) 20:30, 22 May 2013 (UTC)

== 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 {{para|wrap|no}} that would add <code>class="nowrap"</code> to the opening <code><nowiki><code></nowiki></code> tag? — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 02:15, 30 March 2014 (UTC)
:Most shortcut template allow passing class/style and such, so I did the same here. Now you can use {{para|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. <span style="font-family:'Trebuchet MS'"> — [[User:Edokter|<span style="color:#008"><i>E</i>dokter</span>]] ([[User talk:Edokter|<span style="color:#080">talk</span>]]) — </span> 12:05, 30 March 2014 (UTC)
::Thanks! — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 12:29, 30 March 2014 (UTC)

== Template is producing garbage ==

<code><nowiki>{{code|&lt;nowiki>foo&lt;/nowiki>}}</nowiki></code> now produces <code {{#if:|class="{{{class}}}"}} {{#if:|id="{{{id}}}"}} {{#if:|style="{{{style}}}"}}>{{#tag:syntaxhighlight|<nowiki>foo</nowiki>|lang="text"|inline=1}}</code>. This makes documentation for several templates, including this one and {{tl|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. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 14:04, 22 March 2016 (UTC)
:Server-side bug; not related to the template itself, but rather to the use of {{tag|nowiki|o}}. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|<span style="color:#006">User:Edokter</span>]]]] {&#123;[[User talk:Edokter|<span style="color:#060">talk</span>]]&#125;}</code> 16:38, 22 March 2016 (UTC)
::{{replyto|Hairy Dude}} This is [[Wikipedia:Village pump (technical)#Strip marker problems with nowiki tags]]. In most cases you can fix by simply omitting the {{tag|nowiki}}. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 10:38, 23 March 2016 (UTC)

== Doubled code tags ==

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

If not, I'd like to propose [https://en.wikipedia.org/w/index.php?title=Template:Code/sandbox&oldid=713991203 /sandbox], which uses <code>&lt;span></code> as a wrapper, and only if necessitated by a class, id, or style parameter. Seems okay in [[Template:Code/testcases|/testcases]]. [[User:Matt Fitzpatrick|Matt Fitzpatrick]] ([[User talk:Matt Fitzpatrick|talk]]) 04:28, 7 April 2016 (UTC)
:Seems like the {{para|enclose}} parameter is defunct. Perhaps the attributes can be passed instead, so a span is not needed at all. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|<span style="color:#006">User:Edokter</span>]]]] {&#123;[[User talk:Edokter|<span style="color:#060">talk</span>]]&#125;}</code> 10:47, 7 April 2016 (UTC)
::The <code>enclose=</code> attribute (not parameter) of {{tag|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 [[Special:PermaLink/713991203|this complicated]], when the {{tag|syntaxhighlight|o}} tag accepts the <code>class=</code> <code>id=</code> and <code>style=</code> attributes - see [[Special:PermaLink/714087399|this version]]. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 15:14, 7 April 2016 (UTC)
:::I ment as parameter to the #tag: syntax. According to the doc, <code>inline(=1)</code> should work, as does <code>enclose="none"</code> as backward compatible parameter. Class, id and style are not documented. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|<span style="color:#006">User:Edokter</span>]]]] {&#123;[[User talk:Edokter|<span style="color:#060">talk</span>]]&#125;}</code> 15:36, 7 April 2016 (UTC)
::::Ah, but they work. Have a look at this - {{code/sandbox|Some Text|class=MyClass|id=MyID|style=background:yellow;}} - in your browser's "View source" or "Inspect element" feature. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 18:17, 7 April 2016 (UTC)
:::::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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|<span style="color:#006">User:Edokter</span>]]]] {&#123;[[User talk:Edokter|<span style="color:#060">talk</span>]]&#125;}</code> 19:13, 7 April 2016 (UTC)
::::::For something {{code/sandbox|like this}} the emitted HTML does have [//www.w3.org/TR/html5/dom.html#the-style-attribute a <code>style=</code> attribute] which is empty, but that is valid since the [//www.w3.org/TR/css-style-attr/#syntax value of the style attribute] is a CSS declaration block omitting the braces, and a [//www.w3.org/TR/CSS21/syndata.html#rule-sets declaration block] may have ''zero or more'' semicolon-separated declarations. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 19:53, 7 April 2016 (UTC)
:::::::Yeah, but what is the point of emitting empty attributes? <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|<span style="color:#006">User:Edokter</span>]]]] {&#123;[[User talk:Edokter|<span style="color:#060">talk</span>]]&#125;}</code> 20:20, 7 April 2016 (UTC)
::::::::None; but it's harmless. The reason for putting <code>style=</code> outside the #if: is that it doesn't want to work inside. Compare {{code|this|style=background:yellow;}} with {{code/sandbox|this|style=background:yellow;}}. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 21:44, 7 April 2016 (UTC)
:::::::::Good catch. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|<span style="color:#006">User:Edokter</span>]]]] {&#123;[[User talk:Edokter|<span style="color:#060">talk</span>]]&#125;}</code> 11:01, 8 April 2016 (UTC)

== Template not equivalent to the <code><nowiki><code></nowiki></code> tag ==

The code <code><nowiki>{{code|<nowiki><math></nowiki><{{void}}/nowiki><nowiki>}}</nowiki></code> results in {{code|<nowiki><math></nowiki>}}, but I think the code should be equivalent to <code><nowiki><code><nowiki><math></nowiki><{{void}}/nowiki><nowiki></code></nowiki></code>, which results in <code><nowiki><math></nowiki></code> (which is what I want to get). Why don't they result in the same thing? —[[User:Kri|Kri]] ([[User talk:Kri|talk]]) 15:20, 25 June 2017 (UTC)
:{{replyto|Kri}} The {{tlx|code}} template doesn't reproduce literally, it performs some pre-mashing. Use {{tlx|tag|math|o}} → {{tag|math|o}}, or for the pair use {{tlx|tag|math}} → {{tag|math}}. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 16:00, 25 June 2017 (UTC)
::Ah, thanks. —[[User:Kri|Kri]] ([[User talk:Kri|talk]]) 16:37, 25 June 2017 (UTC)

== TemplateStyles for [[Template:Paragraph break]] ==

There's a funny interaction at {{oldid|Template:Paragraph break/doc|854960605|Template:Paragraph_break/doc#Usage}} with TemplateStyles dumping the stripmarkers to wikitext. Opinions on whether that should be solved here or {{tl|code}} removed there? --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 23:38, 14 August 2018 (UTC)

== Does this template add a space after (and shouldn't)? ==

E.g. at [[GB 18030]] for footnotes, it seems it does. I'm not sure if it's the efn-template, but both are locked so I can change neither. I would like to have no space, as with the other footnotes, for consistency. [[User:Comp.arch|comp.arch]] ([[User talk:Comp.arch|talk]]) 14:24, 20 November 2018 (UTC)
:{{replyto|Comp.arch}} Do you mean where it says
:*U+FFFF is encoded as {{code|84 31 A4 39}} on page 239
:It's not a space, it's an effect of the CSS applied to the {{tag|code}} element. You get exactly the same by using the tags directly:
:*U+FFFF is encoded as <code>84 31 A4 39</code> on page 239
:This is due to this site CSS rule <syntaxhighlight lang=css>code {
color: #000;
background-color: #f8f9fa;
border: 1px solid #eaecf0;
border-radius: 2px;
padding: 1px 4px;
}</syntaxhighlight> The culprit is the last declaration, specifically the 4px value on the padding property. This makes the text before and after the element four pixels further away than it would ordinarily be. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 18:57, 20 November 2018 (UTC)
::Ok, thanks. That's I guess it, and wanted for this template (i.e. not wanted to to take this out, by default). Do you know a workaround, with this template or other? [I also see extra space, before "f." footnote in the Notes section, for some other reason I guess.] [[User:Comp.arch|comp.arch]] ([[User talk:Comp.arch|talk]]) 21:17, 1 December 2018 (UTC)
:::We could get the site CSS altered. Begin by starting a thread at [[WP:VPR]]. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 14:13, 2 December 2018 (UTC)

== Is there a version of this template that highlights the text but doesn't change the font to mono? ==

There is a discussion at [[talk:Guillemet#Highlighting small symbols using template:code]] about an inconvenient aspect of this template when used to highlight small characters that might otherwise be misread as normal text. There wouldn't be a misunderstanding, it just causes the reader to stumble. It is easy on the eye but there is a stylistic challenge that this template changes the font to mono, which (it is argued) distorts the symbol being shown.
{{quote|Here is an example to highlight a comma: {{code|,}}. Template {{tl|highlight}} produces {{highlight|,}}, which IMO is too brash and too poorly spaced for the purpose.}}
Any other ideas? Or is a problem more perceived than real? --[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 19:25, 14 May 2020 (UTC)

This template actually runs syntaxhighlighting so it is not what is wanted. However {{tt|<nowiki><code>{{serif|,}}</code></nowiki>}} produces <code>{{serif|,}}</code>, which is better imho. Ideally just the box produced by code is wanted with no other effects but I can't figure out what command might produce that.[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 19:48, 14 May 2020 (UTC)

===Conclusion: new template:char ===
Following further discussion between [[u|Spitzak]] and myself, {{tl|char}} has been created. The reason that the new template was needed is to provide an alternative to {{tl|code}} for articles about symbols where the clarity of the glyph is critical. Compare and contrast
* {{Char|©}} <nowiki>{{Char|©}}</nowiki>
* {{Code|©}} <nowiki>{{Code|©}}</nowiki>
--[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 13:21, 19 May 2020 (UTC)

== Too many expensive function calls ==

Please see my question at [[Wikipedia:Village pump (technical)/Archive_200#Template:Code and Too many expensive function calls]]. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 04:56, 30 September 2022 (UTC)

Revision as of 02:08, 4 April 2023

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Code&oldid=1148098164"