Template talk:Char/Archives/1

Reason for this template

This template exists to provide an alternative to {{code}} for articles about symbols where the clarity of the glyph is critical. Compare and contrast

• © {{Char|©}}
• © {{Code|©}}

--John Maynard Friedman (talk) 13:01, 19 May 2020 (UTC)

Paler background?

@Spitzak:, I have just edited Ł to replace multiple instances of {{tl:angbr}} (angle bracket, which have a specific use in IPA etc) with {{tl:char}} and it looks to me that the grey background is too intrusive. Yes, I know it is the same as {{tl:code}} but where code is used, the identification/highlighting/isolation is more appropriate. There may also be an accessibility issue with tiny glyphs like · (interpunct). I don't think we should go completely white but it seems to me that paler would be better. What do you think? --John Maynard Friedman (talk) 16:26, 21 May 2020 (UTC)

Probably worth trying, I would try blank/white as well. I think the color for code is also too dark.Spitzak (talk) 18:45, 21 May 2020 (UTC)

Sandbox is set to #fdfdfd, which looks good to me. #ffffff does not, per wp:SURPRISE, it suggest something odd rather than just a highlight. #fbfbfb is ok, maybe the safer bet..--John Maynard Friedman (talk) 19:37, 21 May 2020 (UTC)

Looks fine to me, it is being used on Template:Char/testcasesSpitzak (talk) 19:52, 21 May 2020 (UTC)

Good. I have made it (#fdfdfd) the live version. --John Maynard Friedman (talk) 23:31, 21 May 2020 (UTC)

Underlines

I agree that there must not be underlines in the box, but I think there is some method so that links are drawn blue and not underlined. Don't know what it is however.Spitzak (talk) 16:05, 22 May 2020 (UTC)

I believe that this behaviour is browser dependent. Some just change the colour, some underline. --John Maynard Friedman (talk) 16:11, 22 May 2020 (UTC)

Wikipedia tables are able to do this with class="nounderlines" though I have no idea what the underlying html is.Spitzak (talk) 17:49, 22 May 2020 (UTC)

Yes, it's a CSS function called inline styling. I found it at https://www.computerhope.com/issues/ch000074.htm

Even if we could incorporate that in the template, I would regard it as failing wp:surprise, because it would confuse editors that the intended link hasn't happened. --John Maynard Friedman (talk) 21:57, 22 May 2020 (UTC)

Btw, I've just noticed that en.m.wikipedia suppresses all underlines. (At least on Chrome). --John Maynard Friedman (talk) 22:01, 22 May 2020 (UTC)

Missing categories?

Can anyone see why the categories aren't being picked up? I tried replacing the whole block using the equivalent block from {{code}} but that didn't work either (at least not in preview), so it must be something more subtle. --John Maynard Friedman (talk) 16:07, 22 May 2020 (UTC)

Screen-reader friendly?

This new template certainly looks nicer than {{Code}} for typographic purpose. I see that that {{Char}} has been implemented significantly more often in articles on punctuation than Code had been, presumably because Char flows better visually. The number of templates in Greater-than sign, for example, increased by about 25% in the past month, and that includes three instances of Char in the lead paragraph alone. To be frank, I'm not convinced that the second and third instances of Char are necessary or helpful, but I admit that they're not too distruptive…at least for me. I am slightly concerned about negative affects for users accessing Wikipedia with screen readers. Has anyone confirmed that the Char template is not an undue burden for them? I may be worrying about nothing, but I am worrying for the moment. ​ Cheers —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 20:17, 8 June 2020 (UTC)

The char template is just a shorthand version of a html span string (specifically, <span style="border: 1px solid #ddd; background-color: #fdfdfd; padding: 1px 1px; font-family: serif;">{{{1}}}</span>), which (I believe!) screen readers can handle (there are thousands of uses of <span> strings throughout wikipedia so I suspect we would have found out before now.

I assume you read in the sections above about the choice of a much paler background than {{code}}, so as to be more accessible to readers with some visual impairment. The choice of 'serif font' was primarily because typically the component strokes of glyphs drawn in this font are clearer than when the default sans-serif font is used. This was done for all readers, because some glyphs are actually quite difficult to decipher in sans-serif at the standard text size.

The primary reason that led to {{char}} being developed was to separate the topic of discussion from the text that discussed it, which is particularly needed when the topic is a punctuation glyph. Traditional techniques like brackets, parentheses, italic or bold, have been doing a poor job of that.--John Maynard Friedman (talk) 21:46, 8 June 2020 (UTC)

Sounds good. And, yes—I appreciate how this is vastly superior to putting a little piece of punctuation in quotes or angle brackets or relying on bold or italic formatting that may not be recognizable on a single unfamiliar glyph. With that said, I think the formatting of {{Char}} catches the eye approximately as much as bold text does, so I would generally try to limit its use to the things that the MOS would make bold by default or things that are simply too ambiguous if not so templated. In Greater-than sign, 1½ > 1 is an example of moderate importance that starts and ends with characters that all readers know and probably be able to distinguish as being italicized or upright, so I think italics remains the most appropriate formatting. Regardless of whether or not we agree on this point, if this template brings no accessibility issues, it is truly a big step forward. Bravo! —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 01:28, 9 June 2020 (UTC)

@JamesLucas: It's fine. I was pinged to this discussion by {{hidden ping}} ... which is kinda confusing for everybody. Graham87 03:56, 9 June 2020 (UTC)

@Graham87: Is it? I've always interpreted {{hidden ping}} as a nice little "in case you're interested" that doesn't oblige the recipient to respond (whereas not responding to a more public ping might make an editor appear absent or neglectful). Sorry to confuse; thanks for confirming JMF's analysis. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 15:19, 9 June 2020 (UTC)

@JamesLucas: Well I'd never heard of it before you used it in this discussion ... I can sorta see valid reasons for it but for cases where I don't feel a need to respond but want to acknowledge the ping, I just thank the editor concerned (which produces a semi-public record). Graham87 16:48, 9 June 2020 (UTC)

I have doubts about this template

In most cases I've seen this template, I do not find it to make articles clearer. The borders are somewhat confusing, to me it looks like I'm reading about keypresses (Ctrl+Alt+Del). It's especially confusing when more than one letter is placed inside one box (such as ȝe).

I've removed the serif font, it looked very out of place and often caused me to re-evaluate "wait, are we still talking about 'C' or are we talking about some similar mathematical-like C glyph?"

– Thjarkur (talk) 22:42, 14 June 2020 (UTC)

The serif font is very important because a number of characters are very difficult to discern without it. Did you read any of the template documentation? Keypress has shadows to make it appear 3D. The actual counterpart to {{char}} is {{code}}. Please don't make such major changes without discussion and consensus first. You have been around here long enough to know better. --John Maynard Friedman (talk) 23:24, 14 June 2020 (UTC)

Felt it was such a clear styling improvement for this new template, but you're right I should have discussed first. There are a handful of characters that might be clearer from the serif, but I do feel that many look out of place. – Thjarkur (talk) 23:48, 14 June 2020 (UTC)

Thank you. The primary reason for its introduction was to identify more clearly a text item being discussed, as opposed to the text that discussed it. In a number of existing cases, {{code}} was being used – but that uses a monospaced font that often distorts the glyph. In some other cases, I can see a case for using proportional spaced sanserif for the reason you say. There are certainly cases where serif really is needed (curly quotes, for example). Perhaps the template could have an option code added to support editor preference? --John Maynard Friedman (talk) 08:29, 15 June 2020 (UTC)

I think a style parameter would be great:

• style = mono
• style = serif (default)
• style = sans

Maybe super[script] and sub[script], too, but I'm thinking that might be overkill. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 16:26, 15 June 2020 (UTC)

I think it is more user-friendly to just make sure style parameters placed around it works, ie if you want bold you type '''{{char|x}}'''. If serif is a problem probably best to remove it and then editors can add serif around the call when they judge it necessary. The main reason for this template was to stop the font-setting of template:code so maybe it is best not to recreate the same problem. Also the simple one matches template:angbr.Spitzak (talk)

The problem with using {{angbr}} is that it sets the argument in angle brackets, which is the notation bfor graphemes, so a single character or at most a digraph. There have been a few occasions where I have felt justified in writing word, whereas ⟨word⟩ is just wrong.

Writing html "style" strings is not trivial, these templates are ideal for ordinary users.

Sub and super are easy to do, I don't think we need them. We don't need mono either, that is what {{code}} is for (replaces tt tags). --John Maynard Friedman (talk) 18:53, 15 June 2020 (UTC)

But does anybody here speak template?

Grand designs are all very well but does anybody know how to write it? The current version is very simple. Making it conditional is a different matter. --John Maynard Friedman (talk) 18:58, 15 June 2020 (UTC)

It's been a few years, but I'm pretty sure I could coax the templating part of my brain out of hibernation if I had a sufficient block of time. I don't foresee my schedule allowing for that for six to ten weeks. If this is still an open matter then, I'd be happy to tackle it. If someone else gets to it first or if consensus lands on a more lightweight solution, I won't be offended. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 02:05, 19 June 2020 (UTC)

examples

Shown here with a capital M to make serif and proportional spacing obvious:

• samp: M M
• lang: M
• var: M
• Unichar: U+004D M LATIN CAPITAL LETTER M
• kbd: M M
• code: M M
• char (current): M
• char (box): M
• char (serif): M
• xt: M
• bxt: M
• mxt: M
• xtd: M
• xtn: M
• strongbad: M

As seen from the xt macros, forcing things to serif has some precedent. These are supposed to be used for "example text".Spitzak (talk) 20:14, 10 July 2020 (UTC)

@Spitzak: Just FYI, {{xt}} and so on are marked This family of templates cannot be used in mainspace (the article namespace). So, actually, {{xt}}/{{tq}} are more of an argument against using serif than an argument for. Psiĥedelisto (talk • contribs) ^{please always ping!} 16:22, 14 July 2020 (UTC)

It looks like people are editing template:code back in because they are not happy with the angle brackets. This is certainly counter-productive. Code is monospace and adds space at the start and end, both are detrimental to seeing what a character looks like. Let's do something about this asap because this is completely counter-productive! My recommendation is to restore the box.Spitzak (talk) 18:57, 17 July 2020 (UTC)

You will have to write a proposal to talk:MOS first, unfortunately. Good luck with that, I won't participate actively again.

Yes, I have reintroduced {{code}} a couple of times where none of {{angbr}}-by-proxy, single- or double-quotes, nothing, parentheses or multiples thereof, as I found in more than a few cases, were appropriate to the context: I didn't search back in the history but I strongly suspect that these were cases that we [I?] changed from code to char. If you can re-establish {{char}} as a simply a variant of {{code}}, I will be very happy to go back and reinstate it. In the meantime, we have to WP:think of the reader: as you know, I've been trundling around the articles unpicking the consequences of the 'shoot first, ask questions afterwards' approach that got us here. --John Maynard Friedman (talk) 20:30, 17 July 2020 (UTC)

For example, the angle brackets kludge turned the Brackets article into risible gibberish. TBF, it is tolerable in most other cases and I've let it stand where possible. In some others, like comma, the grapheme notation is what should have been used in the first place and I've changed many to use {{angbr}} overtly. --John Maynard Friedman (talk) 08:58, 18 July 2020 (UTC)

I have not found any way to get template:code to turn off monospace or remove the spacing at the ends, so it is not a usable solution.Spitzak (talk) 21:04, 17 July 2020 (UTC)

No, because it is just a fancy wrapper for the html tag. We need a different starting point but I have no idea what it is. --John Maynard Friedman (talk) 08:58, 18 July 2020 (UTC)

Nomination for deletion of Template:Char

I have reverted the TfD tag on the template because it fails WP:think of the reader. Dozens of articles use this template and the TfD tag makes them a terrible mess. I'm not disputing this nomination, only that the standard nomination technique is inappropriate in this case - JMF

Template:Char has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. --John Maynard Friedman (talk) 09:55, 6 July 2020 (UTC)

The result of the TfD discussion was keep. --20:22, 13 July 2020 (UTC)

Template changed to no-op then to angbr

for background to this sequence, see the history of the template between 01:00 and 07:00 UTC on 7 July 2020

The text this template is replacing was never the plain character, it was various attempts to quote it (by putting parenthesis or single or double quotes or angle brackets around the character, or using code or keypress to add a box). So a no-op replacement is not right and defeats the purpose of this to make it clear what mark is actually being talked about. While this is being discussed it should be left as a something more than no-op. Perhaps angbr would be correct.Spitzak (talk) 05:27, 7 July 2020 (UTC)

@Spitzak: I am okay with {{angbr}} for now, yes. Psiĥedelisto (talk • contribs) ^{please always ping!} 05:28, 7 July 2020 (UTC)

• I consider the series of edits that led to this change to be an example of very poor practice. First, how does it make any sense to change a template in the midst of a discussion about it. Second and most important is the law of unintended consequences: dozens of articles use this template, what is the consequence for each of making such a precipitate change? At Bracket, for instance, we have the wonderful statement

Angle brackets ⟨⟨ ⟩⟩, (often substituted informally by less-than < and greater-than signs > or by "single" guillemets ‹ ›), are often used to enclose highlighted material.

(which, in case the template gets changed yet again, reads as of 10:44 UTC:

Angle brackets ⟨ ⟩, (often substituted informally by less-than < and greater-than signs > or by "single" guillemets ‹ ›), are often used to enclose highlighted material.

Would fellow editors please put brain in gear before moving off? If WP:STATUSQUO means anything, it means "leave things as they are until consensus is reached". That does not mean rolling the clock back two months! --John Maynard Friedman (talk) 10:48, 7 July 2020 (UTC)

@John Maynard Friedman: Wow, two whole months? I had no idea that this was such an enduring consensus! Numero sign was created in 2004. Pilcrow in 2002. You can't make changes like this without also changing the MOS and then posture about how your version is now the status quo because it took somebody who had the time to sink into getting this change undone a little while to notice. Oh, and regarding the brackets, that sure sounds like a solvable problem to me. But in reality, most of the uses of {{char}} I'm most concerned about haven't been around for two months. Your change to numero sign for example has been around little more than one. Psiĥedelisto (talk • contribs) ^{please always ping!} 10:58, 7 July 2020 (UTC)

Don't put words in my mouth. I am not claiming consensus, that is a straw man if ever I saw one. What I said was that the template is used extensively and every use-case will have to be checked because of your unilateral decision to pre-empt the discussion. You seem more concerned about enforcing what you see as The Rules than wp:think of the reader: this is the second occasion in 24 hours where you have done something like this. --John Maynard Friedman (talk) 11:07, 7 July 2020 (UTC)

Another example: we have many examples like '''{{char|'}}''' which are rendering as ⟨'⟩, making the frame more obvious than the glyph. How does that make any sense? (but at least it makes slightly more sense than a no-op). I really have better things to do than go round the entire "what links here" list repairing the damage caused by this presumptuous hack.--John Maynard Friedman (talk) 12:00, 7 July 2020 (UTC)

I'm going to try to catch up on the above conversation sometime today, but for now I'll say that I view the angle-bracket solution to be a poor one. That convention is valid (and reasonably clear) when the topic is linguistic, but it's is invasive to the point of being detrimental when the topic is orthographic. I'd sooner endorse simple bolding (ineffective as it sometimes is) than angle brackets. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 12:52, 7 July 2020 (UTC)

@John Maynard Friedman: Gee whiz, you have better things to do? I don't? You sure had time to add this in hundreds of places, including the two worst offenders I'm aware of, (and keep mentioning, as they make a great rhetorical device) pilcrow and numero sign. If you had time to expand Spitzak's template beyond its intention, (without adding a category parameter to even keep track of which use of {{char}} is which), well, as my mother would say, tough tooshie. Hopefully someone with time will clean up after you, I suppose. Unfortunately, my mother is not available. Psiĥedelisto (talk • contribs) ^{please always ping!} 21:15, 8 July 2020 (UTC)

Most importantly, making that change was in direct opposition to the consensus emerging at the TFD discussion that the matter needed to be considered at MOS. Truly abhorrent behavior from User:Psiĥedelisto. VanIsaac_WS^cont 23:29, 7 July 2020 (UTC)

@Vanisaac: There was no consensus that it should be left as-is until then. Some brought up WP:BRD—how is this not within the spirit of WP:BRD? Would you rather I remove all the transclusions instead? Psiĥedelisto (talk • contribs) ^{please always ping!} 04:24, 8 July 2020 (UTC)

By the way, I have no problem with an RfC being started or a MOS discussion starting (preferably the MOS discussion is itself an RfC). But I shouldn't be the one to open it. I have no positive recommendation. An RfC should be neutrally worded—I have no understanding of what this template's proponents saw in it before it was downgraded to a no-op. I can't be the one to start an RfC, nor should I need to be. John Maynard Friedman is the template's main proponent, let him explain what's good about it and where it ought to be used. Psiĥedelisto (talk • contribs) ^{please always ping!} 04:50, 8 July 2020 (UTC)

It's Bold, Revert, Discuss - in that order, not Bold, Discuss, Vandalize when I don't get my way in the discussion. VanIsaac_WS^cont 06:06, 8 July 2020 (UTC)

@Vanisaac: So you would prefer a mass reversion then? Also, wow, vandalize—even Twinkle no longer uses that word, even if the reverter clicks "vandalism". Maybe you should read the first sentence of WP:VANDAL. Is no-opping a template as part of the BRD cycle according to you deliberate obstruction of Wikipedia's purpose? Seriously? The purpose of Wikipedia is having little boxes around U+00B6 ¶ PILCROW SIGN and U+2116 № NUMERO SIGN? This level of incivility isn't called for, even if you were right that consensus is completely behind the little boxes. Which, of course, it isn't, the only thing TFD decided was that TFD can't handle this issue. There's no other clear-cut consensus for anything in that thread. Settle down. Psiĥedelisto (talk • contribs) ^{please always ping!} 08:17, 8 July 2020 (UTC)

I'm caught-up on the discussions, and I've flipped through overnight diffs. I remain convinced that the articles affected by this template are markedly worse-off than they were 24 hours ago. {{Char}} was created as a response to a legibility/comprehensibly concern that was shared by multiple editors. I'm not dismissive of Psiĥedelisto's desire for more organized discussion before this began, but it seemed to me that an organic process was working pretty well prior to the nomination for deletion. The template's first iteration was too visually prominent, but it was toned down. It was deployed too liberally, but the editor primarily responsible for that has been accepting of reverts and open to feedback. There's a still-open discussion about serifs, but it's a pretty interesting discussion! By contrast, the changes in the past day or so have been markedly detrimental. Nothing's been as bad as the decision that an in-line discussion notification was warranted, but even now the affected articles—including Numero sign and Greater-than sign which I know to be dear to multiple editors in this discussion—are less understandable as of this moment than they were at any point during {{Char}}'s first month of existence.

I've advocated for a more conservative approach to {{Char}}'s deployment, but fundamentally I like the æsthetic that Spitzak and John Maynard Friedman created, and I would prefer that it come back for the time being. I'd begrudgingly accept a no-op implementation for the short term if that would keep the aggregate frustration of invested editors to a minimum during the course of the discussion. I find the angle brackets in use as of this moment to the more disruptive to the average (i.e. non-editor) reader than either of those other two options. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 02:54, 8 July 2020 (UTC)

@JamesLucas: I'm of course completely okay with making it into a no-op again; that's why I chose to make it into one. Psiĥedelisto (talk • contribs) ^{please always ping!} 04:25, 8 July 2020 (UTC)

@Psiĥedelisto: The other solution, pending an RFC, would be to put it back the way it was before you preempted an ongoing discussion by hacking it. Although recognising my own confirmation bias, it seems clear to me that you the only one at the TfD debate who believes that this template has nothing to offer in any form, for reasons that are not much more obvious than "I just don't like it"" and "not invented here". Others are more minded to develop and scope it. Which yes, belongs at an RFC discussion at talk:MOS but this reasoned debate needs space to happen without threat of pre-emptive and precipitate actions by one of its participants. --John Maynard Friedman (talk) 09:58, 8 July 2020 (UTC)

@John Maynard Friedman: Are you saying that you can't show what this template did, (and what you want it to do again, apparently,) if it's an alias of {{angbr}}? Create Template:Char/sandbox. Psiĥedelisto (talk • contribs) ^{please always ping!} 10:05, 8 July 2020 (UTC)

Oh and don't worry, I'll definitely post every reason I don't like this template in much more exhaustive detail than "I don't like it", and go find all the worst transclusions of it, when you make the RfC. I will either argue for a move per Þjarkur to Template:Emphasize small punctuation (Maybe even as Module:Emphasize small punctuation which will check its Unicode properties to ensure compliance. Can a Lua module rasterize it and decide how many black pixels are needed for something to no longer be small? I don't know, but I intend to find out if people think this template should be used only for that.), or the strong case, that it isn't even needed for small punctuation because {{angbr}} already exists. Psiĥedelisto (talk • contribs) ^{please always ping!} 10:14, 8 July 2020 (UTC)

Psiĥedelisto, rather than wait for a new venue, could you share some of your technical and/or æsthetic thoughts now? This talk page strikes me as a reasonable place for a conversation to at least begin, and so far I don't understand your concerns beyond those having to do with a feeling that proper protocol wasn't respected. I do not, for instance, understand the reasoning for further consideration of {{angle bracket}}, but I'm interested in hearing and considering arguments. I'm also hazy on why this template would need to have robust safeguards against perceived misuse, but I'd like to learn about about that line of thinking.

It might also be good if you could share any thoughts you might have in regards to the musings offered by SMcCandlish over on the TfD entry; his thoughts, despite being off-the-cuff, struck me as the the most considered technical analysis offered so far. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 19:02, 8 July 2020 (UTC)

Sure, have a few practical reasons which I'll copy over to whatever venue,:

• It's totally unnecessary emphasis most places it's being used, as I also enunciated at Template talk:Unichar § Deviation of task in re {{mono}} in {{unichar}}.
• Where appropriate, angle brackets are normative, as can be seen, for example, on Q § Use in writing systems. But for most of this template's transclusions, not even angle brackets are appropriate. In leads, parenthesis are appropriate. One template probably can't solve this, which is why I advocate deletion.
• Boxes are no more obviously "not part of the glyph" on screen or when printed out. (Brackets of a different color would be just as "good", and screen readers can be told to ignore them. Not that I'm saying such should be used without wide consensus, I'm not even sure I agree with it!) Color alone should in any case not be used per MOS:COLORCODING/WCAG№2. So when printed out, let's say it's a black box. Q should be assumed to either appear as Q or Q So, is it then an Enclosed Alphanumeric—viz., U+1F140 🅀 SQUARED LATIN CAPITAL LETTER Q, SQUARED LATIN CAPITAL LETTER Q? Or is it a Regional Indicator Symbol, , which on many systems appear in squares. So, imagine that in black and white! And also, let's remember, many e-readers and "reader modes" in browsers, etc. might just throw the box out, and even the serif version, many reader modes/e-readers ignore chosen fonts except some smart ones which allow {{mono}} for programming books.

Addressing now SMcCandlish. They seem to mostly agree with what I'm calling the "Þjarkur solution". The only part of their comment that I strongly oppose is it's nice to have options, especially if the context already has a lot of brackets or italics in it. No, it is not nice to have options. It is not nice to change things up mid-breath on readers. Literally no less than the lead of MOS:MAIN states, Style and formatting should be consistent within an article.

@JamesLucas, Spitzak, Þjarkur, and John Maynard Friedman: ← ping line. Psiĥedelisto (talk • contribs) ^{please always ping!} 21:02, 8 July 2020 (UTC)

You've misunderstood both me and MoS. MoS not only expects different markup with different visual presentation for various things, it effectively mandates it in many cases. In a few cases, it also provides alternative options, especially at MOS:WAW, where the normal means of indicating a word or other string as such (i.e., as the thing under discussion, rather than as a normal part of the sentence) is italicization; but it also says "double quotation marks" can be used instead, if the context is already using a lot of italics for something else, such as species names, book titles, foreign terms, etc. And we also have a side variety of semantic templates that create particular formatting for the enclosed content, from {{tag}} to {{lang}} to {{var}} to {{Unichar}}. When MoS says to use a consistent style within the same article, it means do not switch from US to British English, from using serial commas to dropping them, from * List item to * list item; format, from "10 July 2020" to "July 10, 2020", from "US" to "U.S", and so on. It absolutely does not mean "never change font style or other text presentation". It is true that MoS does not want us to add pointless "décor", and this precludes most uses of most background colors, as well as underlining and colored text. However, we certainly make use of background color in infoboxes, navboxes, and other "utilities". More to the point, we are already making mid-sentence use, in main article text, of subtle background color and element left/right padding in <code>...</code> markup (including templates that use it), and background color and a hint of letter-spacing for kbd (but not the underlying <kbd>...</kbd> element), as well as using subtle text color in <samp>...</samp> (but not the underling <samp>...</samp> element). And, in addition the italics, we use a font-face change to serif in <var>...</var> (but only when necessary); similarly, <tdes>...</tdes> imposes a font-face change (because it's required by the underlying spec). And so on.

All this aside, I agree with the above observations that using a box around it is a no-go, since there are separate Unicode characters that do exactly the same thing. A faint background color, inside <kbd>...</kbd> (i.e., basically a lighter version of <kbd>...</kbd>, without the letter-spacing) is probably the most practical approach. Alternatively, <samp>...</samp> could also work, as both of these elements are only loosely defined in the HTML specs, and real-world implementation is broad. E.g., <kbd> is used in some CMSs to mark up the entire contents of user posts, and <samp> is often used for things like file paths, URLs, and directory listings. But <code>...</code> is properly used only for source code (whether interpreted or destined for compilation). In either the <kbd> case or the <samp> case, our template would use an uncommon but semantically okay element that screen readers can be told to distinguish (without the user having to learn and do anything with a WP-only CSS class), meanwhile it doesn't clutter up the visual display with extraneous characters or lines like brackets or box borders.
 — SMcCandlish ☏ ¢ 😼  19:50, 10 July 2020 (UTC)

You should also at least realize that before this template, editors were using template:code, sometimes with nested font settings, to attempt to achieve the same result. Any suggestion that makes it preferable to use that template or other methods is worse. Therefore any longer names or restrictions on what text can be in it are wrong.Spitzak (talk) 19:11, 8 July 2020 (UTC)

@Spitzak: No they were not, at least on numero sign and pilcrow, which I keep bringing up. Editors using {{code}} wrong is no reason to replace it where no one was using it wrong. It's a reason to remove the errant {{code}}'s. Psiĥedelisto (talk • contribs) ^{please always ping!} 19:47, 8 July 2020 (UTC)

Editors actually have been doing it pretty often, in many places, with many characters and strings. And it's an abuse of the <code>...</code> element, which has a pretty strict semantic definition.  — SMcCandlish ☏ ¢ 😼  19:50, 10 July 2020 (UTC)

References

References

@Psiĥedelisto: I will not descend to your level. I am ignoring everything you write. I choose not to debate with you or engage with you in any way. The reasons will be obvious to everyone except you. My choice is to work with editors who aim for consensus by calm and reasoned discussion and do not need to resort to personal attacks or believe that they can just impose their will irrespective of discussion in progress. --John Maynard Friedman (talk) 22:30, 8 July 2020 (UTC)

@John Maynard Friedman: I never personally attacked you. I've been personally attacked in the course of this discussion, (called a vandal (§ Psiĥedelisto "vandalized"), not by you, mind!,) but I'm still happy to read and reply to Vanisaac as I understand passions during these discussions. I'm quite disappointed that you saw the diff before Diff/966739523 as a silly attempt at provocation, no such thing was meant. You can check my history over at Wiktionary—the English Wiktionary is quite complete, but when I find something missing, I add it. If I had become aware that those pages were missing some other way, I would have added them as well. I did not register at English Wiktionary simply because of you. Today I discovered a very common Japanese word in formal speech was missing: でない. When I was writing jueteng I noticed tambiolo could do with a little TLC and that tambiyolo was missing. Even some of my earliest contributions came with fixes to the English Wiktionary, and I've added much ruder words than tooshie (is tooshie seriously rude in your book? 🙄), see putang ina mo, which was wildly incorrect before I fixed it as part of Tagalog profanity here.

I learned about {{FBDB}} from EEng, who I consider quite experienced, and I've seen them lower the temperature with it a few times. That it did not work in this case is disappointing. Anyway, if a MOS RfC is opened, I'll of course be copying my thoughts over with minor changes, as they took me a while to write. So, ignore me I suppose, but as you can see from my reply to JamesLucas, I've thought about this issue a lot and have a few practical, non-procedural reasons. (There seems to be broad support for the "Þjarkur solution", IMO.)

Well anyway, since you've decided to assume bad faith of me, I begrudgingly guess my assumption needs to change. Maybe you should drag me on over to WP:AN/I if you think I'm a hopeless net negative to the project. If it's really as obvious to everyone as it is to you, an indef block should be no problem to attain. Remember, these things can go stale, so if you want me blocked as a hopeless bad faith editor, now is the time. Psiĥedelisto (talk • contribs) ^{please always ping!} 22:58, 8 July 2020 (UTC)

(For the information of other editors, this thread only has...

Moved to Wikipedia:Administrators' noticeboard/Incidents/IncidentArchive1041#Please revdel edit summary containing offensive, ableist personal attack from User:John Maynard Friedman

I did not have all the facts when I wrote the parent comment, and discovered a personal attack which, in my view, clearly necessitates admin action, at minimum WP:REVDEL. Other about this template should still go here for now sans RfC, I think.) Psiĥedelisto (talk • contribs) ^{please always ping!} 00:18, 9 July 2020 (UTC)

I don't want to open this issue again but, lest future readers gain the wrong impression, the apparent attack was identified as a horrible co-incidence. It has been resolved to the mutual satisfaction of the parties involved. --John Maynard Friedman (talk) 20:22, 13 July 2020 (UTC)

The background again

CactiStaccingCrane changed the background to a darker shade of grey, saying that it improves contrast. It is not obvious to me that this is an improvement. See also #Paler background? above.

Is the change supported by any scientific analysis? 𝕁𝕄𝔽 (talk) 15:32, 2 February 2023 (UTC)

As no justification has been provided, I have reverted the change to the background. I have retained the dotted line as I agree that it is an improvement. --𝕁𝕄𝔽 (talk) 10:56, 12 February 2023 (UTC)

En vs Em space behaviour

Came here from Em (typography) where the em space in the {{char}} template is noticeably shorter than the em dash, which I thought was a typo, but apparently not, see:

En space:   Em space:  

En dash : – Em dash : —

Reading the template doc I see that the {{angbr}} template is recommended, but it suffers from the same thing:

En space: ⟨ ⟩ Em space: ⟨ ⟩

A table for comparison with other whitespace

Template	Char	Angbr
Em space		⟨ ⟩
En space		⟨ ⟩
nb space		⟨ ⟩
thin space		⟨ ⟩
hair space		⟨ ⟩

What's going on here? It feels like I'm not understanding something basic. ― Synpath 22:49, 30 June 2023 (UTC)

Strange... The only function of the char template is to surround the character in a one-pixel frame and apply a very faint grey background: "border: 1px solid #ddd; background-color: #fdfdfd; padding: 1px 1px;" Since {{angbr}} is doing the same thing, it can't be an obvious template error.

Maybe someone at Wikipedia:Village pump (technical) can throw some light on it? --𝕁𝕄𝔽 (talk) 22:59, 30 June 2023 (UTC)

I should have been more careful - I accidentally added normal spaces to the templates which made things look weirder. That being said em and en spaces are rendered as the same width on my browser (Firefox) and Chrome as well. I've been trying to find an answer online and it seems like this is something that is font dependent? ― Synpath 00:10, 1 July 2023 (UTC)

It's something going on in your browser. Viewing this on my system in Firefox, the em space and em dash are indistinguishable in terms of advance width, and are double the width of the en space and en dash at a glance. VanIsaac, GHTV ^cont_WpWS 03:25, 1 July 2023 (UTC)

Definitely a problem on my end. I opened this up on mobile and it looks as expected as well. Thanks for your replies. ― Synpath 17:06, 1 July 2023 (UTC)