Template talk:Code/Archive 1

What does this do?
Can someone explain the purpose of this template? I don't understand what it does. &mdash; Knowledge Seeker &#2470; 01:23, 19 Apr 2005 (UTC)


 * Has the question from 2005 been answered?-84user (talk) 17:10, 24 June 2008 (UTC)
 * Well, yeah, the template has documentation. — SMcCandlish  Talk⇒ ʕ(Õلō)ˀ  Contribs. 18:20, 19 June 2011 (UTC)

Template change
I changed this template to insert  and   tags around text. It should be called using the following format:. Of course, this may be more trouble than it's worth. &mdash; Knowledge Seeker &#2470; 04:54, 26 May 2005 (UTC)

Template doesn't work with ampersand
Subject. Adraeus 10:21, September 9, 2005 (UTC)


 * I believe that using  would solve this but requires a code change to the template; see Resolved for the code to make that work. &mdash;  SMcCandlish &#91;talk&#93; &#91;contrib&#93; ツ 23:24, 17 March 2007 (UTC).

Replacement notice and issue
I've just modified it so that instead of using the nowiki tag, it calls the template Nowiki. That way, it should actually work... for most things. What was happening before was that the nowiki part would always take the text "" and, of course, nowiki it -- rather than take parameter #1 and render it in a nowiki form.

The only problem now is that it won't render anything right if it's between two brackets,, they way you would want to write a template name. Instead, it will render the text of the template (or other called page) in a nowiki form. This seems to be more of a problem with Nowiki, so I might instead raise it over there. $$\sim$$ Lenoxus " * " 00:47, 24 May 2008 (UTC)

Examples
 Example contents  produces:  

 Example markup and !"£$%&/=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters  produces:  

''' leading spaces and

whitespace ''' produces:  

As far as I can see, it does not preserve whitespace and does not faithfully include all characters. -84user (talk) 17:20, 24 June 2008 (UTC)

Too small a font size
In my browsers (FF and SAF) this produces the code-text in a smaller font than the surrounding regular text. Is that a personalized CSS-setting (then how to drop it)? nyway, for this reason I avoid it in edits, which is not a good thing. -DePiep (talk) 09:43, 9 July 2010 (UTC)

How do these look:


 * Plain
 * Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.


 * code
 * Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.


 * 


 * syntaxhighlight


 * source


 * font-family&#x3a;monospace; only
 * Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

---— Gadget850 (Ed)  talk 14:02, 9 July 2010 (UTC)
 * The middle one, code, is a smaller fontsize. Unwanted, bad style. Too small to read. -DePiep (talk) 11:36, 3 October 2010 (UTC)


 * Which skin are you using? With FF3.6 and Monobook, I find that the last two are the same, and the plain line is shorter, ending just before "ut labore" in the second. ---— Gadget850 (Ed)  talk 14:11, 3 October 2010 (UTC)
 * I use Vector in FF 3.6.10, and afaik I have not personalised anything (CSS) (if that is possible at all - I just don't know about that).
 * I've put the three example into Template:Code/testcases. I tried all skins available there, and indeed only Vector produces the small font in example 2. -DePiep (talk) 14:20, 3 October 2010 (UTC)


 * I added two more samples: syntaxhighlight and source. How do they look? ---—  Gadget850 (Ed)  talk 15:15, 3 October 2010 (UTC)
 * I've put them in the testpage. With me, in every skin the two new ones show the same font as code does (but these two do have a transparent background; code has an off-white opaque bckgr). So also, in Vector (and Vector only) the font is small like 10->7 pt or so. I can do a screenprint if that's usefull. -DePiep (talk) 15:27, 3 October 2010 (UTC)


 * I switched to Vector, and these are the same small size as code. The code template uses and, so it looks like an issue with , and I am not surprised that  has the same issue. Vector changed the main font size and the relative sizes are sometimes off; others have had similar issues elsewhere. Let me ask around. ---—  Gadget850 (Ed)  talk 15:39, 3 October 2010 (UTC)


 * Found it at . I started a discussion at MediaWiki talk:Geshi.css. You can make an immediate fix by copying the CSS listed there to Special:MyPage/skin.css. ---— Gadget850 (Ed)  talk 15:58, 3 October 2010 (UTC)
 * I can follow this, interesting learning. Great (about three times). -DePiep (talk) 16:09, 3 October 2010 (UTC)
 * (btw, I use that page /testcases because it has the template with some 8 skin options available. Probably I'm teaching the master now, but alas. Anyway you don't have to set Vector if that's not our prefered skin ;-). -DePiep (talk) 16:12, 3 October 2010 (UTC)


 * I've implemeted a (temporary) fix, so it should show a proper fontsize now, until the &lt;syntaxhighlight> issues are solved. — Edokter • Talk  • 14:53, 19 October 2010 (UTC)
 * Naturally, IE's font is now too big... feel free to revert. — Edokter • Talk  • 14:55, 19 October 2010 (UTC)
 * In this thread and in the /testcases the syntaxhighlight and source are still small. I did purge, but nothing else. No js or any worksaround intalled actively here. -DePiep (talk) 15:35, 19 October 2010 (UTC)

Yes, now you’ve made it look like I’m shouting here. ―cobaltcigs 23:43, 19 October 2010 (UTC)


 * I changed the font-size to 105%, so it should not be too big in IE, while still be readable in other browsers. — Edokter • Talk  • 00:22, 20 October 2010 (UTC)

Actually I have Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 but thanks anyway. Given the html produced it may be best to over-ride the font-size property of class “source-text” while using the word !important. ―cobaltcigs 00:45, 20 October 2010 (UTC)


 * Sorry to Edokter, I missed the second part ("until") of your post, so my reaction was unnecessary. re cobaltcigs: I was just posting a factual and correct feedback. I do not get your arrow. By no way I have been putting time pressure in this thread, which I starteed some three months ago, and I don't appreciate your suggestion. -DePiep (talk) 10:03, 20 October 2010 (UTC)

DePiep, you have confused me with. Could you kindly explain: I’ll start by explaining myself. The goal of my previous comment, in providing the user-agent string, was not pedantry but to avoid misdiagnosis as a Windows/IE user, and to suggest an efficient way to increase the font-size of all source/syntaxhighlight tags uniformly. ―cobaltcigs 16:19, 20 October 2010 (UTC)
 * what arrows of mine you do not get?
 * what thing you believe I was doing without awareness (or competence)?
 * which suggestion are you resenting?
 * Aarrggh, the horror. This happened: instead of copying (ctrl-C) just your name to use in my post, I entered (ctrl-V) a previous and ugly text from a totally different thread. My wrong, indeed, and excuses + undo.
 * Now to clean up all the rest: your reply & link "Yes, now you’ve made it look like I’m shouting [everything ... today] " read like I was pushing for a speedy solution (the pointy arrow aimed at me). That pushing imo I did not do at all, was my reply. No more to it. On top of this, probably I could/should have read "you've made it" being Edokter, not me (The screenshot also making more sense that way)? I suggest closing this OT I started asap and folding it. -DePiep (talk) 16:47, 20 October 2010 (UTC)

Okay, thanks. I still think we should specify any font-size increase in the MediaWiki:Common.css so they affect all source/syntaxhighlight tags, not just the ones produced by this code template. ―cobaltcigs 16:58, 20 October 2010 (UTC)
 * Thank you for your patience with me. -DePiep (talk) 17:02, 20 October 2010 (UTC)

Updates

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

--—— Gadget850 (Ed)  talk  -  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:
 * gives
 * — SMcCandlish  Talk⇒ ʕ(Õلō)ˀ  Contribs. 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):  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 also match it (, etc.) — SMcCandlish   Talk⇒ ʕ(Õلō)ˀ  Contribs. 21:01, 19 June 2011 (UTC)
 * foo =
 * = bar


 * It's not broken. It's just that code is not a replacement for, but an inline version of , which not use . Example: body#content {color: #123456;} produces body#content {color: #123456;}.<span style="font-family:'Trebuchet MS',sans-serif"> — Edokter  ( talk ) — 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 <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, for code, wasn't using .  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 / 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)
 * That is not a desireable situation. Wrappig it in here creates other problems; like possible conflicting font declarations, making it impossible to override the assigned GeSHi fonts, because  also has a font assigned. And GeSHI's font declaration mechanism is already a mess (by way of it's inline declarations). GeSHi uses,  or  to contain the code. GeSHi's homepage states that  may be added in future versions. For now, it is best not to interfere with it until support for  has been added. <span style="font-family:'Trebuchet MS',sans-serif"> —  Edokter  ( talk ) — 01:19, 20 June 2011 (UTC)
 * Maybe this template should be moved, then, so that something that actually is a wikimarkup wrapper for 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 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  is a common pseudotag alias for this syntax highlighting magic, the amazingly available  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,  is actually a much more obvious name for it (or perhaps for ?), if this one remains a non- syntax highlighting shorthand. And  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  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  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  in particular inside of, 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  (actually various spans) inside the , which is perfectly normal and valid. So, I'm not seeing a clear rationale for not using  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)
 * 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"  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)
 * (←) I have to ask, but what is the advantage of creating a template version of, and for that matter, of any other HTML tags like and ? 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. <span style="font-family:'Trebuchet MS',sans-serif"> — Edokter  ( talk ) — 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 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)


 * 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)
 * 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"> — Edokter  ( talk ) — 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 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 use the semantic "phrase" elements the way they were intended, for the same reason we  use valid XHTML, well-formed XML, standards-compliant CSS, and standardized microformats,  use  for actual sub-headings not "big font" effects,  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)

Spacing issue

 * Test code relating to this issue has been moved to Template:Code/sandbox2.

This badly needs  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: with  and , and   and  , visually much closer to each other, respectively, than   and   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 and  already. I've also implemented it in Template:Code/sandbox2: 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.
 * Foo bar baz quux.
 * Old: Foo bar baz quux.
 * New: Foo  quux.
 * Foo  quux.

NB: The fact that this spacing problem also happens with plain 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)


 * 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.
 * 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)
 * 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  and, or they all need a class added after the site-wide style sheet were modified.— SMcCandlish   Talk⇒ ʕ(Õلō)ˀ  Contribs. 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. ―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  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)
 * 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  and, , , and  and  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, , , . (I'm intentionally avoiding start/begin/top and end/bottom in those draft names, since people think of stuff like  and  and other two-part "bookend" templates.) — SMcCandlish   Talk⇒ ʕ(Õلō)ˀ  Contribs. 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. — SMcCandlish   Talk⇒ ʕ(Õلō)ˀ  Contribs. 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"> — Edokter  ( talk ) — 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   spacing before/after the code, though, since (depending on the context) spacing  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)

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)

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:


 * --— Gadget850 (Ed) talk 21:36, 18 January 2013 (UTC)

Spaces
(April 2023: the uses of tt stated below have been wrapped in Syntaxhighlight to deactivate the active use of obsolete tags tt here, in order to remove the (obsolete tag) lint errors. If you need to see these tt statements visually active, you may temporarily copy them (removing Syntaxhighlight) into a sandbox to see them as is discussed below. Discussion for this action took place here. here Zinnober9 (talk) 01:35, 7 April 2023 (UTC)).

It would be nice if the  template replaced spaces embedded witin its argument with non-code/proportional font spaces. In other words, undefined would convert to undefined and would be rendered as, 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 , which is displayed with an awkwardly wider space). A longer example is undefined, which would be rendered as undefined instead of as undefined. (Please note that I am not suggesting that embedded spaces be replaced with non-breaking spaces.) — Loadmaster (talk) 02:59, 21 May 2013 (UTC)

My adjustment would be rendered as instead of as.
 * 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 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
 * , which would be rendered as instead of as.
 * 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
 * Your example would be rendered as undefined instead of as undefined
 * 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. -- Red rose64 (talk) 10:51, 21 May 2013 (UTC)


 * Yes, I used  precisely because of its transparent background properties. (Is there a specific reason that   markups have a white background color?) But   stills renders the spaces too wide, as ; I'd prefer it to render as . 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   (or any other) element? — Loadmaster (talk) 00:23, 22 May 2013 (UTC)
 * The CSS which Wikipedia has assigned to the CODE element is as follows:


 * 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  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
 * This styling affects all text between the and  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. -- Red rose64 (talk) 09:39, 22 May 2013 (UTC)
 * The only way to achieve your desire is to wrap each word in code with normal spaces between. --  Gadget850talk 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  element, though, is an exception, which implicitly preserves all spaces and newlines by default. In fact, the   tag implicitly uses the   CSS property ("pre" meaning "preserve (spaces)"). But I get your point about font widths. There is, however, a   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,   produces  . Could something like that be added to the   template? — Loadmaster (talk) 18:23, 22 May 2013 (UTC)
 * 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". -- Red rose64 (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 style? (which should be added anyway) --  Gadget850talk 19:05, 22 May 2013 (UTC)


 * It would be nice to add it, since a reasonable-looking default spacing width could be provided. And yes, should also be allowed. — 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 no that would add  to the opening   tag? — <span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius  ♪ talk ♪ 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 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)
 * Thanks! — <span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius  ♪ talk ♪ 12:29, 30 March 2014 (UTC)

Template is producing garbage
now produces. 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)
 * Server-side bug; not related to the template itself, but rather to the use of .  16:38, 22 March 2016 (UTC)
 * This is Village pump (technical). In most cases you can fix by simply omitting the <nowiki ></nowiki>. -- Red rose64 (talk) 10:38, 23 March 2016 (UTC)

Doubled code tags
I'm not sure when this changed, but  now wraps itself in a   element. This makes this template's output. Is there any reason to double up the  tags?

If not, I'd like to propose /sandbox, which uses  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)
 * Seems like the enclose parameter is defunct. Perhaps the attributes can be passed instead, so a span is not needed at all.  10:47, 7 April 2016 (UTC)
 * The  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 tag accepts the     and   attributes - see this version. -- Red rose64 (talk) 15:14, 7 April 2016 (UTC)
 * I ment as parameter to the #tag: syntax. According to the doc,  should work, as does   as backward compatible parameter. Class, id and style are not documented.   15:36, 7 April 2016 (UTC)
 * Ah, but they work. Have a look at this - - in your browser's "View source" or "Inspect element" feature. -- Red rose64 (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.  19:13, 7 April 2016 (UTC)
 * For something the emitted HTML does have [//www.w3.org/TR/html5/dom.html#the-style-attribute a   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. -- Red rose64 (talk) 19:53, 7 April 2016 (UTC)
 * Yeah, but what is the point of emitting empty attributes?  20:20, 7 April 2016 (UTC)
 * None; but it's harmless. The reason for putting  outside the #if: is that it doesn't want to work inside. Compare this with . -- Red rose64 (talk) 21:44, 7 April 2016 (UTC)
 * Good catch.  11:01, 8 April 2016 (UTC)

Template not equivalent to the tag
The code  results in, but I think the code should be equivalent to  , which results in   (which is what I want to get). Why don't they result in the same thing? —Kri (talk) 15:20, 25 June 2017 (UTC)
 * The template doesn't reproduce literally, it performs some pre-mashing. Use  →, or for the pair use  → <math ></math>. -- Red rose64 &#x1f339; (talk) 16:00, 25 June 2017 (UTC)
 * Ah, thanks. —Kri (talk) 16:37, 25 June 2017 (UTC)

TemplateStyles for Template:Paragraph break
There's a funny interaction at with TemplateStyles dumping the stripmarkers to wikitext. Opinions on whether that should be solved here or code removed there? --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. comp.arch (talk) 14:24, 20 November 2018 (UTC)
 * Do you mean where it says
 * U+FFFF is encoded as 84 31 A4 39 on page 239
 * It's not a space, it's an effect of the CSS applied to the <code ></code> element. You get exactly the same by using the tags directly:
 * U+FFFF is encoded as  on page 239
 * This is due to this site CSS rule  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. -- Red rose64 &#x1f339; (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.] comp.arch (talk) 21:17, 1 December 2018 (UTC)
 * We could get the site CSS altered. Begin by starting a thread at WP:VPR. -- Red rose64 &#x1f339; (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 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. "Here is an example to highlight a comma: ,. Template highlight produces ,, which IMO is too brash and too poorly spaced for the purpose." Any other ideas? Or is a problem more perceived than real? --John Maynard Friedman (talk) 19:25, 14 May 2020 (UTC)

This template actually runs syntaxhighlighting so it is not what is wanted. However produces , 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.Spitzak (talk) 19:48, 14 May 2020 (UTC)

Conclusion: new template:char
Following further discussion between u|Spitzak and myself, char has been created. The reason that the new template was needed is to provide an alternative to code for articles about symbols where the clarity of the glyph is critical. Compare and contrast --John Maynard Friedman (talk) 13:21, 19 May 2020 (UTC)

Too many expensive function calls
Please see my question at Village pump (technical)/Archive_200. Johnuniq (talk) 04:56, 30 September 2022 (UTC)