Jump to content

Template talk:Xt/Archive 1

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

Fleshing out details

Exploring size

All the following are in 8A0010 color. For comparison…

  1. This section is 54.1%R-0%G-6.3%B
  2. Maroon is R=50%-G=0%-B=0% (headbomb finds this too dark)
  3. {{xt}} currently is 56.5%R-0%G-7.1%B (Tony finds this too bright and I find it somewhat bright but acceptable)

The xt template is currently at 114%. The range of 111–114% if fine for me. Noetica likes 113%. PMAnderson, who has a common platform, likes 100% and can handle no more than 108%.

  1. Here is an example at 100%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  2. Here is an example at 107%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  3. Here is an example at 108%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  4. Here is an example at 109%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  5. Here is an example at 110%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  6. Here is an example at 111%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  7. Here is an example at 112%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  8. Here is an example at 113%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  9. Here is an example at 114%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  10. Here is an example at 115%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  11. Here is an example at 116%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  12. Here is an example at 117%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  13. Here is an example at 118%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs

The following section uses <font> because I didn’t want to take the time to figure out how to make face="times new roman" to work with <span> commands. This is an experiment to see if we have more consistent results across different platforms by specifying the typeface rather than leaving it up to the browser preferences setting to substitute any given serif face for “serif”.

  1. Here is an example at 100%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  2. Here is an example at 107%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  3. Here is an example at 108%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  4. Here is an example at 109%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  5. Here is an example at 110%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  6. Here is an example at 111%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  7. Here is an example at 112%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  8. Here is an example at 113%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  9. Here is an example at 114%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  10. Here is an example at 115%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  11. Here is an example at 116%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  12. Here is an example at 117%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  13. Here is an example at 118%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs

Let’s all weigh in. Greg L (talk) 20:54, 18 December 2008 (UTC)

  • I like this color just fine. In the lower "times new roman" set, the range of 111–114% if fine by me. Who here can tolerate 111%? I find this compromise color acceptable. It may be too dark for Headbomb and too bright for Tony. Greg L (talk) 20:54, 18 December 2008 (UTC)

The proposed color has to me an "alarming" tinge. Have you considered this better visible and less disquieting variant?:

  • Here is an example at 111%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
woodstone (talk) 21:14, 18 December 2008 (UTC)
  • Honestly? No. I wouldn’t have considered a fuchsia-like color because I think it garish and would assume many others would feel likewise. But maybe that’s just me. Given that Tony wants it as absolutely as dark as possible, my hunch is that Tony’s wife will need some ECT paddles on his temples to break him out of an epileptic fit now. BTW Woodstone, since you used 111% (which is fine by me), does that mean you find 111% to be OK? And does specified "times new roman" look (bottom set) look any different from the first set? Greg L (talk) 23:08, 18 December 2008 (UTC)
  • P.S. This is like sitting down in a circle and kicking on a 25 kg piece of clay until it moves into a certain spot and begins to take a stable shape. Here is a 108% example of 45.1% green, "font-family: serif;":
Write 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs.
The reason I throw this one out is that reds denote broken links, blues denote links, and greens currently aren't used at all. I’ve looked at this using GammaToggle X set to “PC gamma” and it seems OK. I pointed Gamma Toggle X to Tony since he too uses OS X; it allows our Macs to “act neolithic.” So perhaps Headbomb will find that, while somewhat dark, this color is still distinctly a green on his monitor. Greg L (talk) 23:22, 18 December 2008 (UTC)
  • I don’t think it will necessarily look different to others, Anderson. My hunch is that you have your browser’s preferences set so some typeface other than Times New Roman is your default font. I assume, when you say “stringy”, you are finding that the later set, which is forced as Times New Roman, has less pronounced serifs. I think we will all have greater assurance of across-the-board consistency of appearance and size if we specify an actual typeface in the <span> code rather than simply request the browser display the “serif” style per its preferences setting. The *size* of fonts isn’t a product of the appearance of the lowercase characters, but is a product of the leading (line spacing) that the font foundry intended for the typeface. We could specify the font as face="times new roman, times, palatino". Then, if someone doesn’t have Times New Roman installed, they will almost certainly have Times or Palatino to fall back upon. The following text is specified like this using the following: <span style="color: #007300; font-family: times new roman, times, palatino; font-size: 108%;">, which produces: five cats and thirty-two dogs. Greg L (talk) 03:15, 19 December 2008 (UTC)
  • My fonts are "Times New Roman" (and "Courier New"), the MS defaults. Nor is the difference a matter of serifs; the main strokes are visibly thicker in the lower set. The upper set may be Courier; it's hard to recognize in this color; but if so, IE won;t let me substitute TNR. (In any case, we should not require our readers to tweak their computers; that's contrary to accessibility.) Septentrionalis PMAnderson 03:55, 19 December 2008 (UTC)
  • Feedback please. Things to discuss:
  1. 108% ?
  2. 45.1% green? Good? Bad? Shoot Greg L?
  3. Woodstone’s fuchsia-like color? Good? Bad? Put a stick between Tony’s clenched teeth so he doesn’t swallow his tongue?
  4. 54.1%R-0%G-6.3%B? This is what the above two charts (and the below screen capture) are in.
  5. Does specifying Times New Roman produce more consistent opinion on appearance and/or size?
Greg L (talk) 03:46, 19 December 2008 (UTC)


The color of Tony's sig works for me; and it has a name, "darkgreen", which makes for transparent code. Septentrionalis PMAnderson 04:02, 19 December 2008 (UTC)

Very well. Let’s look at some dark greens. Let’s start with taking a look at “Tony green”, which I suspect is 50%, (later proved to be 39.2%) not 45.1%: Here is an example of <span style="color: darkgreen; font-family: times new roman, times, palatino; font-size: 108%;">: Editors should write 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
And here is 45.1% green: Editors should write 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs. Greg L (talk) 04:15, 19 December 2008 (UTC)

Proper technique for controlling serif

This paragraph has the proper span code for controlling serif for the greatest possible consistency in appearance and size. It does so using the following span code: <span style{{=}}"color: #900012; font-family: 'Times New Roman', Times, serif; font-size: 108%;">: Editors should write 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs.

Note that it does so by specifying Times New Roman as the preferred typeface. If a computer doesn’t have that face installed, then the above span resorts to the second choice of Times. Failing that, the fall-back position is to default to the serif typestyle as directed by the browser’s preferences setting. By specifying Times New Roman, we have maximum confidence that our relative size specification is acting on a known typeface; in this case, Times New Roman, which has characters that are smaller than many typefaces. Adjusting Times New Roman to roughly 108% ensures it is displayed as closely as possible to the same size as the sans-serif typeface used for the rest of the text.

This paragraph is the same as above except that it uses a 39.2% green, which is precisely the same as Tony’s signature. It does so using the following span code: <span style{{=}}"color: #006400; font-family: 'Times New Roman', Times, serif; font-size: 108%;">: Editors should write 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs.

I’ve taken the liberty of adjusting {{Example text}} for the Times New Roman preference at 108% but have left its color as is. We haven’t received hardly any feedback on the use of dark green. Given that PMAnderson and I (remarkably) agree on this point, suggests to me that a dark green is worth exploring. Greg L (talk) 16:09, 19 December 2008 (UTC)

Everyone should now go to MOS and look at the size of the example text. Is it about right? Greg L (talk) 16:39, 19 December 2008 (UTC)

  • I’m beginning to sense that there is enough interest in this to merit giving dark green a whirl in order to elicit wider input. I’ve specified the color as 006400 in {{xt}}. I chose not to use the named color. Dark green and 006400 are identical. However, specifying it as an RGB hex color will allow us to fine-tune the darkness. Greg L (talk) 17:40, 19 December 2008 (UTC)

Fixed image of what text looks like in OS X

The below “text” is a screen-capture image showing the appearance of text size on Macs running OS X 10.5.6. As you can see below, on Macs running OS X 10.5.6, 100% looks too small. Anything from 107% to 114% works for me. For those editors running Windows, or other OSs, you won’t be able to see the color as Mac users see it; just the absolute and relative sizes of the text. Greg L (talk) 01:34, 19 December 2008 (UTC)

Sizes with Times New Roman

For those who use a different default serif font than Times New Roman, I've made a new list of sizes at Template:Xt/Sandbox, using the current font-face specification. (FWIW, on my laptop 115% looks best...) -- Army1987 – Deeds, not words. 17:49, 19 December 2008 (UTC)

  • Remember, by forcing Times New Roman, only those who don’t even have it installed on their system won’t see it. And even then, the new specification then defaults to Times. Only if the user doesn’t have either Times New Roman and Times installed, will the new span tag specify “serif”, in which case, the browser looks to the user preferences setting. Greg L (talk) 18:20, 19 December 2008 (UTC)
    • Yes, what I meant is that someone who has a different default serif font (like me) doesn't see the same thing with the current version of the template as in the "Exploring sizes" list above on this page. (For example, to me, in the list above even 107% is slightly too large.) -- Army1987 – Deeds, not words. 18:39, 19 December 2008 (UTC)

Army: I like your sandbox the sandbox you made. I find that the darkest I can tolerate is “darkgreen” which is 39.2%, decimal 100, and hex 64. As for size, my Mac bins the range of 107% to 114% at the same size, which all looks fine to me. PMAnderson seemed to be suggesting that 108% was the max he could go. But that might be old news because I didn’t get a distinct answer posting an example with force-Times New Roman. I’ll direct his attention to your sandbox. Greg L (talk) 18:29, 19 December 2008 (UTC)

(I don't consider the sandbox to be "mine", that's way I created it here and not in a user subpage... -- Army1987 – Deeds, not words. 18:51, 19 December 2008 (UTC))

On my laptop:

  • With Epiphany on Ubuntu, and with Firefox on both Ubuntu and Windows, ≤106% are too small, 107%–114% are perfect, 115%–130% are larger than ideal but still acceptable, and ≥131% are too large;
  • with Internet Explorer on Windows, ≤105% are too small, 106%–113% are perfect, 114%–121% are larger but acceptable, and ≥122% are too large;
  • with Opera on Windows, ≤116% are too small, 117%–124% are slightly larger but the best I can get with that browser, and ≥125% are too large.

-- Army1987 – Deeds, not words. 22:29, 19 December 2008 (UTC)

Pretending I believed that rendering only depends on the browser (probably doesn't), it seems that the ones from 107% to 113% should look OK with Firefox, IE and Safari, which comprise about 98% of the usage share of web browsers. What browser are you using, PMA? -- Army1987 – Deeds, not words. 22:42, 19 December 2008 (UTC)

  • I agree Army, 107–113% (inclusive) amounts to a +1 size at twelve points. I tweaked the template to 110% to put it right smack in the middle of this. Greg L (talk) 00:44, 20 December 2008 (UTC)
  • It’s not complex, PMA and there are no other variables; the binning is due to the granularity of type size. If you have 12-point Helvetica and Times New Roman but the latter seems too small—even though it too is 12 points—you might want to boost its size a notch. Most (maybe all) browsers like to work in full point increments so the next step up from 12-point text is a font size of 13 points. Twelve-point text is actually 13 points tall from the top of the tallest character to the bottom of the lowest descender. So to stretch 13 points of stuff upwards, you have to go to 1413, which is 107.7%. Scaling more, to 1513 is 115.4%. I’m sure the details are not only somewhat different than this, but also vary by browser. But this illustrates the concept. Greg L (talk) 00:34, 20 December 2008 (UTC)
    It's somewhat more complex than that due to the ridiculous kluges the Wikipedia stylesheets use:
/* Font size:
** We take advantage of keyword scaling- browsers won't go below 9px
** More at http://www.w3.org/2003/07/30-font-size
** http://style.cleverchimp.com/font_size_intervals/altintervals.html
*/

body {
	font: x-small sans-serif;
	background: #f9f9f9 url(headbg.jpg) 0 0 no-repeat;
	color: black;
	margin: 0;
	padding: 0;
}

/* scale back up to a sane default */
#globalWrapper {
	font-size: 127%;
	width: 100%;
	margin: 0;
	padding: 0;
}
  • Not all browsers will agree on what "x-small" exactly means, or on when to round when multiplying by 1.27 first and then by 1.08 or whatever, yadda yadda yadda. Also, there are more ugly kluges forcing some style declarations to be obeyed only by IE, or only by particular versions of IE, to compensate for its bugs. All those things can interact in unpredictable ways. -- Army1987 – Deeds, not words. 01:05, 20 December 2008 (UTC)
    Indeed. I used this, and now, magically, 100% in our template looks only slightly smaller, and 102%–108% all look OK; the granularity of sizes is much less bad: there are many small steps, as opposed to few big ones as exemplified by the absurd discontinuity between 114% and 115% in your screenshot above. IMO the "sane default" would be, well, the default (i.e., not specifying any size at all). But apparently whoever wrote http://en.wikipedia.org/skins-1.5/monobook/main.css felt like that wasn't complicated enough. -- Army1987 – Deeds, not words. 01:19, 20 December 2008 (UTC)
  • What I got out of all of that is this: When HTML and style sheets make me feel like a Barbie doll ready to declare that “Math class is hard!”, I’ll just call you. Greg L (talk) 01:27, 20 December 2008 (UTC)
    The nicest thing is that I can't even reply in the way you said you'd be tempted to do if you saw a FA nomination, because... wait for it... “We can't edit that file (only the developers can change it)″ [1]. Developers? What "developers"? Has there been any "development" in MediaWiki in the last years? So, there is no person on whom such a reply could possibly be addressed. I'm left with the other alternative ("my blood pressure might rise"), and fortunately my blood pressure is usually low enough. Duh. -- Army1987 – Deeds, not words. 01:39, 20 December 2008 (UTC)
  • Same frustration here with {{val}} and {{delimitnum}}. Both need a character-counting parser function because the math-based technique sometimes results in rounding errors and false output. No volunteer developer wants to make the new parser function because they huddled on the relay chat-whatever and decided that making it would “set a precedent” and might encourage us riff-raff editors to ask for even more parser functions. Bad riff-raff editors… BAD. Greg L (talk) 02:00, 20 December 2008 (UTC)
  • Let’s talk about color. I can live with darkgreen 64. If it needed to be tweaked at all, I could do with it being made a bit lighter. How to you feel about the existing color? Greg L (talk) 00:34, 20 December 2008 (UTC)

Why 1= ?

The following example text is coded as {{xt|1= This expression doesn’t contain an equal sign.}}: This expression doesn’t contain an equal sign. But, as you can see, it works. I am confused. Why not include that “1=” feature as a built-in capability? The downside is what?

With the “1=”, I can write emc2

A quotation box with “1=”? Let’s see…

Preceding text… This expression doesn’t contain an equal sign. And trailing text.

Please explain. Greg L (talk) 02:14, 20 December 2008 (UTC)

See the last three paragraphs in http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AManual_of_Style&diff=257711855&oldid=257708716, basically if you write Example text MediaWiki believes that  mc2 is the value of argument e, (see the source to understand what I mean, I'm too tired to put nowiki tags everywhere) but the template has no such named parameter, so it is ignored. 1= means that the following is argument 1, which is the default when there are no equals sign, i.e. foo is "shorthand" for foo. As for including it "as a built-in capability", I have no idea of how to do that, and I strongly suspect that it might not be possible to do that at all. -- Army1987 – Deeds, not words. 02:27, 20 December 2008 (UTC)

If you get insomnia, try reading Help:Template. -- Army1987 – Deeds, not words. 02:31, 20 December 2008 (UTC)

  • Yes: make the template treat all contents as ‘argument 1’. Not a biggie, but too bad that it’s not-possible/really obscure to implement it. Or, substitute “=” with Wiki markup {{=}} numeric &#61; or hex &#x3D; , right? Greg L (talk) 02:55, 20 December 2008 (UTC)

Typefaces and consistent appearance

I just saw this implemented while looking at Wikipedia:Lead_section#First_sentence_format. The combination of roman, bold and italic in green, intermixed with blue and purple links, and the contrast in font size with successive paragraphs, is very fragmented looking. With respect, it looks like an homage to the Batman's nemesis the Joker. I don't see the point in changing colour at all.

Regarding font choice: the Wikimedia philosophy for choice dictates that the monobook skin only specifies “sans-serif” font-family. It would make sense to specify only “serif” and respect the reader's choice of serif font, as well as his choice of serif and sans-serif font size.

If we must dictate our favourite font, then please don't start the list with Times New Roman. Better to put Times first. It has about identical metrics but looks much better on the Mac; it isn't found on most Winboxes, so it will fall back to TNR on those machines.

But why not at least start the list with a non-crappy screen font, like Georgia, which is found on every Mac and Win box? Michael Z. 2008-12-28 23:14 z

Ideally, I would prefer just "serif", too; but, then, it would be much harder to specify a size which works for all editors. A size such as 110% in my browser looks just right with TNR but enormous with the default serif font.
But let's try with Georgia, it has a larger x-height so the problem could be mitigated... See the sandbox. If nobody objects, I'm going to change it with <span style="font-family: 'Georgia', serif; color: darkgreen">, which produces this output. -- Army1987 – Deeds, not words. 12:40, 30 December 2008 (UTC)
I like this better than the default font (Courier?), but I still like the look of TNR. This has narrow strokes, like Courier, but not as narrow. Septentrionalis PMAnderson 13:55, 30 December 2008 (UTC)
With respect, what we like is irrelevant. Each user may already have his own browser set to display the font that he wants, so I would object to specifying any font except the generic keyword “serif”. No matter what font we specify, we can't get the size right for every reader.
But if we must specify, then putting Times before TNR will give both Mac and Win users the font they are more accustomed to (both have identical metrics, but different-looking antialiased rendering). I also suggest that Georgia is demonstrably superior to either, because it is 1. present on practically all Win PCs and Macs, 2. doesn't have the unusually small x-height of Times/TNR, and is therefore more readable at the same size, 3. is designed for the screen and acknowledged by designers as being very readable on the screen.
(The default font is only specified with the generic keyword “sans-serif”, which renders as Helvetica on the Mac. Definitely not Courier or Courier New, which are typewriter fonts, and fall under the keyword “monospace”.) Michael Z. 2008-12-30 17:46 z
  • Michael, I know that users can specify a default serif font for their browsers to use. That’s the problem; no one does it the same. The problem with that is they come to Wikipedia and if all we specified was “serif”, different people would see different size text. That is precisely what happened when we tried “serif”. We know everyone has Times or Times New Roman but that text looks too small unless enlarged to 108–110%. But we still are left with different operating systems and browsers and technology conspires to make our lives complicated. So…

    We must control the font if we are to overcome that fact that generic serif fonts are smaller than san-serif fonts. I think your suggestion of using Georgia @ 100% is a fine idea.

    As for color, there is going to be a never-ending amount of opinion on this issue. Blue is taken. Red is too (broken link). Anything chosen must be a dark version of something so the text doesn’t “pop” and drive people crazy with a look like we’ve had an explosion at the Disney factory. Dark green seemed to make everyone else here happy. Yes, it is a distinct color from the others—but that is by design to avoid confusion; ergo, you’re “Joker” comment.

    Bottom line: If there is a problem to fix (108% isn’t satisfactory for Army or Michael), then I propose we go to 100% Georgia. That should solve the lingering size issues. I rather dislike the descending numerals because it makes it look at first like my browser is getting screwed up by the change in typestyle, but that is a very minor issue. But, if this is largely academic (arguments about what official “rules and philosophy” are and what the most “pure, scientific method” for controlling fonts ought to be), then to blazes with all that(!); we follow WP:IGNORE. If it ain’t broke, don’t fix it.

    So… fact finding first: Who here doesn’t like the size of 108% Times New Roman but does like the size of 100% Georgia? Let’s look at these:

    Georgia @ 100% →   Write 5 cats and 32 dogs or five cats and thirty-two dogs, not five cats and 32 dogs.
    TimesNR @ 108% → Write 5 cats and 32 dogs or five cats and thirty-two dogs, not five cats and 32 dogs

    I like either just fine. Greg L (talk) 18:26, 30 December 2008 (UTC)

Exactly what facts we are finding here?—as I mentioned, what we like should not be used to determine how to format this. Can we please encourage some kind of objective criteria instead? And why ignore the Times font on Macs? Michael Z. 2008-12-30 18:55 z
  • Trying to solicit huge input from a huge number of readers in a gigantic RfC just isn’t practical on Wikipedia; nothing gets done in the end. The best way to get something actually done around here is assume good faith and do a good technical job as a “representative”. When I last tackled “appearance” issues with another template, the involved parties went the extra effort to look at the results on friends’ computers and computers at work, and on iPhones of all things. We exchanged screen shots and explored options. And, BTW, I am on a Mac, so don’t assume I like sending Mac users to the back of the bus. Please assume that we are on your side here: we want as many people happy with {xt} as possible. If you have a constructive suggestion that solves a specific problem, then bring it on. I have to go right now. I encourage you to work with Army for a bit more here. Just be very explicit with what you think is broken and suggest a fix. I don’t understand your jones for Times. We tried it and it requires 108–110% enlargement. I don’t understand what you are trying to solve. Greg L (talk) 19:04, 30 December 2008 (UTC)
(edit conflict) Both [TNR@108% and Georgia@100%] have the right size on my system, and Georgia has the advantage that the code in places such as ...your right to say it.{{" ' "}} doesn't become too large: ...your right to say it.{{" ' "}} It is also more resistent to the fact that font sizes may not scale identically under zoom (try looking at Template:Xt/Sandbox with different zooms).
(As for "objective criteria", look at eeeeeeeee, ttttttttt, aaaaaaaaa, ooooooooo, iiiiiiiii, nnnnnnnnn, if your default serif font is Times New Roman, in which case it'll look exactly like eeeeeeeee, ttttttttt, aaaaaaaaa, ooooooooo, iiiiiiiii, nnnnnnnnn, and look at eeeeeeeee, ttttttttt, aaaaaaaaa, ooooooooo, iiiiiiiii, nnnnnnnnn.) -- Army1987 – Deeds, not words. 19:15, 30 December 2008 (UTC)
I'm saying let's see examples of both Times 108% and Times New Roman 108% for comparison (various machines have either or both installed). If Times is chosen, then the font spec ought to be “Times, Times New Roman, serif”, giving both Mac and Win users what they're more accustomed to, with no practical differences in their display.
I appreciate the efforts to test here. Let's just ask which is better, and why, not which do we likeMichael Z. 2008-12-30 19:27 z
  • It’s already specified as font-family: 'Times New Roman', Times, serif, which is the very common way to do it on the Web. Times New Roman and Times are quite similar to each other. Rather than research all the nuances, we simply adopted this well-known Web convention on the assumption that it has proven to be a tried & true method that spread virally. You are suggesting Times first, then Times New Roman. What problem are you trying to solve with this? Please also, if you can, post a fixed screen shot of your various experiments and examples, as I did above in Fixed image of what text looks like in OS X. We’ve found this procedure to be very helpful in understanding what the others are seeing.

    Try marking up various examples of this code: TimesNR @ 108% → Write <span style{{=}}"color: #006400; font-family: 'Times New Roman', Times, serif; font-size: 108%;">5 cats and 32 dogs</span> or <span style{{=}}"color: #006400; font-family: 'Times New Roman', Times, serif; font-size: 108%;">five cats and thirty-two dogs</span>, not <span style{{=}}"color: #006400; font-family: 'Times New Roman', Times, serif; font-size: 108%;">five cats and 32 dogs</span>.. Make your various comparative versions, post them in live text below, and then follow up with a fixed screen shot of what that section appears like on your computer. Subtleties in color won’t translate, but everything else—and relative sizes—will be properly conveyed. Greg L (talk) 20:20, 30 December 2008 (UTC)

    P.S. You were the one who suggested using Georgia, which Army now seems to have taken a shine on. Where are you now with your own original suggestion? Greg L (talk) 20:22, 30 December 2008 (UTC)

Sorry if I didn't make myself clear. I suggest not specifying a font, but if you insist, then Georgia is probably better than any Times font, but if you insist on Times, then “Times, Times New Roman, serif” is probably best declaration. In my years in web design I haven't seen anyone put forward the reverse order as a “well-known web convention”. Perhaps you could put forward an actual reason to prefer it? As I said, since there is no practical difference between the two versions of times, then my suggested order will show the familiar Apple-licensed Times to Mac users (since Macs have both fonts installed), and the familiar MS-licensed TNR to Win users. Why subject Mac users to a slightly off-looking Windows font without any reason?
(PS: threaded discussions are easier to follow if you just indent with colons, rather than introducing 1-item bulleted lists.) Michael Z. 2008-12-30 21:28 z
  • I’ll be the first to admit that counting Google hits can be a hazardous activity if not done carefully. But I tried it anyway. Google (mostly) ignores punctuation. Searching on phrases within quotes avoids finding irrelevant hits. Here’s what the following searches come up with:

    Search on "Times New Roman Times serif" (here) = 259,000 hits.
    Search on "Times Times New Roman serif" (here) = 1,980 hits.
    Search on "Times New Roman Times serif" HTML (here) = 126,000 hits.
    Search on "Times Times New Roman serif" HTML (here) = 571 hits.

    This explains why when I researched “Specifying font” HTML on Google, the Times New Roman-first option is the only example I encountered. I don’t know why it is this way… it just is. I also don’t think it is an invalid stretch of faith to assume that the majority of Web masters know what they are doing and do things for a reason.

    As for Georgia, I’m not so sure this will be problem-free for Linux users. See Linux Web Fonts. It seems, Linux users would only have Georgia if they installed Microsoft fonts for the Web. This might be common for Linux users, or not; I have no expertise in Linux. I do however, note this Google search:

    Search on "Georgia Times serif" HTML (here) = 15,900 hits. So it seems that, though it is relatively rare to specify Georgia, it is far more common than specifying Times first.

    I’m at a loss though to divine whether you have a solution in search of a problem. MOS has been using {xt} for a while now and there has been no complaints once we settled at Times New Roman → Times → serif @ 108%. If it ain’t broke, don’t fix it. We need stability in templates and shouldn’t mess with it unless there is a good, sound reason for doing so.

    Finally, as I stated above, I have no problem—personally—with Georgia. But I think we need to listen to what Army1987 says about Georgia. As you can see above, he has carefully and thoroughly looked into the typeface and, at one point, seemed to be an advocate of it. I even see that he gave Georgia a whirl for four minutes on the {xt} template so he could apparently see how it looked on MOS. He backed out though. Given his thoroughness on this, his (very) logical mind, and his conservatism, I would put very great weight on his findings here. I have also advised him on his talk page that I think he should factor “stability” considerations into the equation and not unnecessarily mess with things without a good reason to do so. If there is anything at all that Wikipedians are adverse to, it is “change.” Greg L (talk) 03:18, 31 December 2008 (UTC)

So you've carefully counted Google results, which shows what? I looked at the first page of results for those searches. Most of them are just random mistakes with broken HTML which reveals the code. All this shows is that many webmasters naively put the most common font first.
The only advice I found on a couple of the pages in your search is “In general, it's better to specify the more unusual Macintosh font first. Because it's missing in Windows, they will default to Times New Roman instead,”[2] and “Times is just about the worst font they could have chosen. . . . As you can see here, it is small and more difficult to read than most other fonts.”[3] Michael Z. 2008-12-31 18:22 z

← "Georgia serif" gives 91,200 hits—why would one explicitly specify Times as a fallback for Georgia? They're quite different serif fonts. -- Army1987 – Deeds, not words. 12:10, 31 December 2008 (UTC)

  • Yes, I agree, Georgia isn’t an odd little Martian we keep hidden in our garage, Army. I agree with what you wrote on your talk page: being WP:BOLD is worthwhile when there is something that needs fixing (v.s. “stability”, which can be important at times). In this case, your revisions to {xt} to get a consistent look across a very wide set of operating systems, user configurations, font packs, and browsers; including the crazy world of Linux, looks very to be very well researched work to me and doesn’t unnecessarily upset the apple cart. As always, I am highly impressed with the work you do here on Wikipedia. Greg L (talk) 18:04, 31 December 2008 (UTC)
One of the reasons why I'd prefer <span style="font-family: 'Georgia', serif; color: darkgreen;"> to the current version of the template is the KISS principle. (Others are that the current version of template would make any <code> element contained within it way too large, and the fact that Latin small vee looks too much like a Greek small nu in italic Times.) Given that all the objections which have been made (except the one about non-lining figures) also apply to the current version, I am going to be bold, after all. Feel free to revert if you want. -- Army1987 – Deeds, not words. 20:51, 1 January 2009 (UTC)
Regarding darkgreen, the reason it doesn't work in some browsers is because it is not one of the 16 standard colours in HTML[4] and CSS2.[5] I believe the many other colour keywords suggested by some guides are widely-supported Netscape extensions.
It's just dumb luck that you happened to discover the problem in your mobile. This is another example of why we should follow published standards, for HTML, CSS, and accessibility, rather than just rely on common sense or our own limited experience. Michael Z. 2009-01-08 15:30 z

Accessibility

I had only seen this used in blocks of text, but from the examples on this page I realize that it is meant for inline examples, and the format is applied using an HTML span element. The span is a semantically empty element, and only used to apply formatting. To convey meaning through this technique contradicts important accessibility guidelines, specifically WCAG 6.1 “Organize documents so they may be read without style sheets.... [Priority 1].”[6]

Better for editors to use good written style, punctuation, paragraph breaks, and block quotations to show their examples, than to rely on this template and assume that everyone on the web will see green serif text. Michael Z. 2008-12-30 19:20 z

  • We don’t “assume everyone on the web will see green serif text.” That is an assumption of yours regarding what we assume. We’ve been all through this. The idea with “accessibility” is to not convey important information by relying only upon the distinction between two colors; particularly green and red. For instance, we would never use only green text in a table to mean one thing and red text to mean another. In the case of {xt}, green is being used to facilitate highlighting for normal-sighted people; the change in face to serif is what everyone—even those who see zero color whatsoever—still see regardless of handicap. Note that the totally color blind can’t see our blue links on Wikipedia without some sort of style sheet to make those stand out in some other fashion. What we have is better than this by a mile.

    Did you know we had lengthy discussions here on WT:MOS on this very subject? We even touched upon the subject of the totally blind and how voice-out screen readers might factor into all of this. I might add that my son-in-law has red-green color blindness. He and I looked at various options here, on two different monitors, on this very page when he was up here a few weeks ago. I know you are well-intentioned here. But you know as well as I do that you are new to this template and the discussions that lead up to it. So why are you creating a whole new discussion thread here and presuming to counsel and *enlighten* us on the subject of color and accessibility like we just fell off the turnip truck and don’t understand anything about accessibility? Perhaps you should read all the that has transpired on both WT:MOSNUM and WT:MOS, and then look at our sandbox, and then read the above. Seriously, we’re going over old territory and you might have a better appreciation for how we got to where we are. Greg L (talk) 20:44, 30 December 2008 (UTC)

Sorry, I probably won't read through all that or create a bunch of screenshots—but that doesn't mean my concerns should be disregarded. “The totally blind” is not just a subject to touch upon. Accessibility requirements like the one I cited make it a top priority that HTML should work without any CSS. We're talking about people with and without disabilities who are using alternative browsers, handhelds, audible screen readers, text-only browsers, braille displays and other technologies that we may not anticipate.
Marking up samples with span tags means nothing to all of these readers. I'm saying that editors will use {xt} and think that it distinguishes the text to all readers of Wikipedia, when it does not. Better to let editors use the conventional editing techniques which will make the sample text obvious to all, than to lull editors into using this template to apply spans which will convey no meaning to an underrepresented minority of readers, including some who are already dealing with disadvantages.
The only fix I can think of offhand is to use a meaningful element, such as samp for inline samples and blockquote for block samples. Michael Z. 2008-12-30 21:16 z
{ How is that? This text is intended to be used only on WP:MOS and WP:MOSNUM. Those two venues present very unique circumstance because the formatting and style of text is being discussed at length. These are clearly venues for *editors*, where they can learn how to create content on Wikipedia. I have no doubt that there are thousands of blind people using screen readers to *read* Wikipedia content. Technology is amazing in that it allows this. How many totally blind people are authoring Wikipedia content?!? If there are any, they are exceedingly rare. WP:MOS and WP:MOSNUM are clearly venues where >99.999999% of the visitors are sighted. To criticize that we are using special typeface and color to set off example text on MOS and MOSNUM (in disregard for the totally blind) is like criticizing construction workers as they build a wheelchair ramp in the sidewalk at a street corner because they are using concrete tools that only able-bodied construction workers can use. Greg L (talk) 22:15, 30 December 2008 (UTC) }
{ How is that? At least when the default san-serif font is, well, san-serif, then the sudden jump to serif is clear. My son-in-law has no trouble whatsoever. Greg L (talk) 22:15, 30 December 2008 (UTC) }
Blind people don't edit Wikipedia? You think it's your job to decide that the “totally blind” (as if that were of issue) have less right than you to make use of the MOS? B.S. The accessibility guidelines apply to all web pages and web applications, and they are for the benefit of people with various disabilities (and with no disabilities), or with various devices, both readers and editors. I suggest you familiarize yourself with Wikipedia:Accessibility.
Again, I am not criticizing using green serif font here. I am criticizing “marking” text as a sample using only CSS styling, without using appropriate text or HTML markup. This is to ignore the most basic accessibility. Michael Z. 2008-12-30 22:31 z

Quoting you: Blind people don't edit Wikipedia? { You’re missing the point. And please dismount from your high horse or get off your soap box, or whatever is your pulpit. As I said, we’ve gone all through this accessibility issues before and you are arriving late to the discussion and aren’t adding anything constructive here other than a metric butt load of weapons-grade bullonium in an obvious attempt to prove how you are somehow more *enlightened* and concerned over the plight of the disabled and all the other issues that you like to shovel onto others here on Wikipedia. Hogwash. I sat down right here at this very computer with someone who is color blind for a half hour as we discussed all this stuff and I personally made sure he had no problem seeing the example text as clearly distinguished from the rest of the body text. What have you done? Cite WCAG 6.1 recommendation, criticize technology you don’t sufficiently understand, and annoy the living crap out of editors by not even having the common decency to read up on the previous discussions before riding in here like the Lone Ranger to rescue us because you assume we’re going to all go “Golly gee Wally, we were all goopy here by not realizing there are color blind people.” If you want to one-up us on accessibility, go find a blind editor and see how much the green-serif typeface {xt} text on MOS and MOSNUM causes him or her v.s. all the many other challenges they face on Wikipedia. You know what you will hear(?): {xt} is a complete and total non-issue. The issue is whether the combination of green serif causes an accessibility problem here on Wikipedia. Clearly it doesn’t. The {xt} template produces text that is more accessible than the blue color which is the sole indicator of links—a feature used nearly everywhere throughout Wikipedia. In other words, you are wasting our time on this “accessibility” thing; there is no real problem, just one of your imagination. Greg L (talk) 02:05, 31 December 2008 (UTC) } You think it's your job to decide that the “totally blind” (as if that were of issue) have less right than you to make use of the MOS? { See what I said above regarding pulpits. Greg L (talk) 02:05, 31 December 2008 (UTC) } B.S. The accessibility guidelines apply to all web pages and web applications, and they are for the benefit of people with various disabilities (and with no disabilities), or with various devices, both readers and editors. I suggest you familiarize yourself with Wikipedia:Accessibility. { I know all about it. What is clear is that you think you do. Greg L (talk) 02:05, 31 December 2008 (UTC) }
Again, I am not criticizing using green serif font here. I am criticizing “marking” text as a sample using only CSS styling, without using appropriate text or HTML markup. This is to ignore the most basic accessibility. Michael Z. 2008-12-30 22:31 z { There is no real problem, just one of you imagination. Note Army1987’s comment below about the various technologies used on Wikipedia to generate visual content. Further, your proposed *solution* (to use quotation boxes for the example text) would be a colossal pain in the ass and look stupid. Further, I checked your block log and can see that you will go to considerable lengths to prevail in arguments at any cost. I suppose that has prejudiced me a bit here about what I can further expect out of you. I can nevertheless see that further engaging you will likely only spin you up further. I will no longer respond to you as you are no longer even trying to be helpful and constructive. I will allow you the last word since that seems to be a need of yours. Army1987 can deal with you now on anything related to “accessibility.” If you have something constructive to add regarding fonts (above), I will work with you. Other than that, Goodbye. } Greg L (talk) 02:05, 31 December 2008 (UTC)

Too bad that the samp tag is ignored by MediaWiki (i.e. not kept in the HTML). I'm using no ampersand and no nowiki tag in writing this. BTW, what about thousands of articles which write F = ma, where the bold and italics are rendered by <b> and <i>, which simply mean "this is in bold" and "this is in italics"? How is the totally blind user going to figure out that we mean "this is a vector" and "this is a scalar"? BTW, did you know there exist aural style sheets, too? Feel free to add them to this template.
(Also, I would support simply using <span class="example"> for this template, and moving all the formatting to MediaWiki:Common.css, so that each editor can do what the fuck they want with that class, by adding whatever style to their own stylesheet. But, given that that page is protected, we'd better wait until the choice of format settles down before doing that, so that meanwhile non-admins can experiment, too.) -- Army1987 – Deeds, not words. 01:09, 31 December 2008 (UTC)
BTW, could you explain how the hell
  • Write 5 cats and 32 dogs, or five cats and thirty-two dogs, not five cats and 32 dogs.
  • Symbols for variables are normally italicized, and symbols for units of measurement are usually upright: for example, T = 293.15 K, m = 5.4 kg.
  • For nested quotations, use double quotes for the outermost level, single quotes for the next inner level, and continue alternating: for example: The Dalai Lama stated in his book The Universe in a Single Atom: "I am told that one of the greatest of all quantum theorists, Richard Feynman, wrote 'I think I can safely say that nobody understands quantum mechanics', so at least I feel I am in good company."
can possibly be any worse than
  • Write 5 cats and 32 dogs, or five cats and thirty-two dogs, not five cats and 32 dogs.
  • Symbols for variables are normally italicized, and symbols for units of measurement are usually upright: for example, T = 293.15 K, m = 5.4 kg.
  • For nested quotations, use double quotes for the outermost level, single quotes for the next inner level, and continue alternating: for example: The Dalai Lama stated in his book The Universe in a Single Atom: "I am told that one of the greatest of all quantum theorists, Richard Feynman, wrote 'I think I can safely say that nobody understands quantum mechanics', so at least I feel I am in good company."
? Frankly, I'm not intelligent enough to understand that myself. -- Army1987 – Deeds, not words. 02:12, 31 December 2008 (UTC)
  • Me neither. They sound absolutely identical when read by OS X’s screen reader; at least to my ear. The higher plane of consciousness at which he operates in order to be able to sniff out problem areas (we’re so insensitive) certainly exceeds my ability to detect a real problem here. Greg L (talk) 02:20, 31 December 2008 (UTC)
Greg L, you are missing the point that some readers will not see any font at all, for example when listening to audio output or reading in text-only. Army, this is exactly why for some the first and second example effectively are identical, and not good enough. <b> and <i> are not ideal, but at least some screen readers do recognize them, while a span is ignored.
I don't see any justification for making up a special template for these examples, which substitutes real HTML formatting with styled spans. Plain old Wikitext does a good job of reproducing normal editorial conventions, and is accessible. I would probably mark up the first with italics, and the second as block quotations, or perhaps an unordered list. The third could go either way.  Michael Z. 2008-12-31 18:16 z

Write 5 cats and 32 dogs, or five cats and thirty-two dogs, not five cats and 32 dogs.


Symbols for variables are normally italicized, and symbols for units of measurement are usually upright, for example:

T = 293.15 K

m = 5.4 kg

Symbols for variables are normally italicized, and symbols for units of measurement are usually upright, for example:

  • T = 293.15 K
  • m = 5.4 kg

For nested quotations, use double quotation marks for the outermost level, single quotes for the next inner level, and continue alternating. For example, The Dalai Lama stated in his book, The Universe in a Single Atom, “I am told that one of the greatest of all quantum theorists, Richard Feynman, wrote ‘I think I can safely say that nobody understands quantum mechanics’, so at least I feel I am in good company.”


For nested quotations, use double quotes for the outermost level, single quotes for the next inner level, and continue alternating. For example:

The Dalai Lama stated in his book, The Universe in a Single Atom, “I am told that one of the greatest of all quantum theorists, Richard Feynman, wrote ‘I think I can safely say that nobody understands quantum mechanics’, so at least I feel I am in good company.”

(unindent) I am a totally blind editor. User:Academic Challenger, User:Lalue]], and User:Fastfinge also use screen readers, and there are a few others out there whose names I've forgotten. So totally blind people are as rare as hens' teeth on Wikipedia, as they are in the general population of the developed world, but they are out there. The issue as far as I can tell is that the examples above won't degrade gracefully in browsers that don't support CSS. These days, not many blind people would have this problem - most modern screen readers at least support inline CSS. I can't check this easily, but I'm sure version 4.0 of the most popular screen reader, JAWS (released in 2001) would be able to tell that the text in the samples above was green and was in a different font to the other text. (Moving the classes to Monobook.css would cause JAWS versions below 6.0 (before 2004) to completely ignore it). I'm almost certain that NonVisual Desktop Access, a free Windows screen reader, would be able to figure out the font and colour change as well. Most creen readers don't read font and colour changes automatically - they have to be told to do it by the user. But I can tell which text is part of an example in the Manual of Style by context - I have no need for the fancy font and colour changes. Having said all that, I think that some form of emphasis should be used that doesn't rely on CSS. However the editor base that would benefit from this change is vanishingly small, so I don't see this as a high priority. Graham87 05:47, 1 January 2009 (UTC)

The points tightly made by Graham87 notwithstanding, HTML provides us with the tools to do this job properly - the Q and Blockquote elements. We should be using them, an the semantically correct-mark-up, rather than work-arounds of dubious semantic legitimacy. As to "the change [my emphasis] in face to serif is what everyone—even those who see zero color whatsoever—still see regardless of handicap" - what about people who have set their default font to serif? It's also telling for an editor who claims to "know all about" Wikipedia:Accessibility to present his comments in a manner which, through both the use of small fonts and an idiosyncratic quoting style is highly inaccessible to some readers. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:48, 1 January 2009 (UTC)
Replacing colons with <blockquote> in places such as Wikipedia:Lead section TT first sentence format does make sense, but also using {{xt}} within such a blockquote element wouldn't hurt. (If/when the actual formatting is moved to Common.css, we might just use <blockquote class="example">.) As for <q>, it's disabled in wikitext (the source of the beginning of sentence contains no ampersand) – only these tags are allowed, none of which seems appropriate for this usage, so we have no choice but to stick with <span>. -- Army1987 – Deeds, not words. 21:04, 1 January 2009 (UTC)
But why would someone add a blockquote when the text is green? I provided five accessible examples above, using standard editorial and wikitext techniques, but this template provides an inaccessible alternative for all of them. It encourages un-accessibility. And I notice that it's already starting to appear in mainspace articles. Michael Z. 2009-01-04 00:19 z
FWIW, I've removed the only occurrences of this template in the article namespace (in Sonata Theory), where it was used for no reason whatsoever (to wrap unspaced em dashes within sentences). -- Army1987 – Deeds, not words. 01:32, 4 January 2009 (UTC)
As for "those who set their default font to serif", if/when the formatting is moved to common.css, they will be able to write .example { font-family: sans; } or whatever they like most in their own Monobook.css. -- Army1987 – Deeds, not words. 21:17, 1 January 2009 (UTC)
We shouldn't style our content such that people only see differentiated text if they hack the stylesheet. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:04, 1 January 2009 (UTC)
People who don't hack the stylesheet have sans-serif font for text outside the xt template, so they do see differentiated text. -- Army1987 – Deeds, not words. 23:28, 1 January 2009 (UTC)
People who set a global font to override site-specific settings are not hacking Wikipedia's style sheet. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:20, 2 January 2009 (UTC)
Yeah, let's just cut the hacking BS. The font-family is also invisible to “hackers” who use some mobile browsers, text-only browsers, screen readers, or braille displays.
This template is now in 2 articles. Who's going to do something about that? If there are no volunteers, then I'll be glad to delete the template to prevent further reoccurrence. Michael Z. 2009-01-27 04:33 z
I can't find them. (Maybe someone has removed it from them, meanwhile.) BTW, which alternative would you support, given that the <samp> element is not permitted in wikitext (the source of this sentence contains no ampersand) and that using italics or quotation marks would defeat the very reason the template was created in the first place? I've also created a template {{xt2}} for examples to be displayed, and it uses <blockquote> (and the suorce this does contain ampersands), which is the most logical tag to use.
I've also increased the brightness of the text; this way the difference should be visible also to totally color-blind people. If you can read this, and distinguish this from this, you are also able to distinguish this from this, and a fortiori this from this.
As for screen readers, feel free to add aural style sheets to the template. And if this is not enough, feel free to bring it to TfD, if you dare. -- Army1987 – Deeds, not words. 10:48, 27 January 2009 (UTC)
Yeah, they got removed from two article in the wee hours.[7][8] What are you going to do to avoid this?
I've made it clear that I prefer an appropriate editorial technique to be used in every situation, instead of creating a lazy-man's one-size-fits-none “solution” using a span and inline CSS. Piling aural style sheets on top of non-semantic HTML wouldn't do anything about its inherent inadequacy either—bad markup remains bad markup. Using appropriate wikitext or HTML elements is the right way to mark up text. Michael Z. 2009-01-27 17:33 z

← OK, OK. Considering that the <samp> element is disabled in wikitext, what "appropriate HTML element" would you use? See Help:HTML in wikitext for the list of HTML elements enabled in wikitext. It's way too easy to point out problems without suggesting solutions. Also note that {{xt2}} uses <blockquote> which is the appropriate element in that situation. -- Army1987 – Deeds, not words. 17:51, 27 January 2009 (UTC)

I made a few examples in the white box above, following “I would probably mark up the first with italics”. Michael Z. 2009-01-27 18:21 z
Those italics are obtained with '' which gets converted to <i> by the renderer. Now <i> simply means "this is in italics"; how the hell it is supposed to convey the meaning "this is an example" any better than {{xt}} does? Also, there are things which change meaning when italicized (and this is one of the reasons why this template was proposed in the first place). Would you really use a blockquote for each example using the symbol of a unit of measurement? How about cases where examples where italics and quotation marks are being themselves discussed, and are being used within sentences? How would you cope with Wikipedia:MOS#Italics, point "Words as words"? Or with a sentence like "Don't mix words with unit symbols: for example, write 10 m, 10 metres, or ten metres, but not ten m." -- Army1987 – Deeds, not words. 19:51, 27 January 2009 (UTC)
What's wrong with doing this the normal way?: “don't mix words with unit symbols: for example, write 10 m, 10 metres, or ten metres, but not ten m.” Quotation marks would work too, if you really want to emphasize not.
The i element is readable in screen readers, so unlike your span, it works. In some cases an em or cite would be better still (but in others, like names of ships, i is appropriate). Somehow black ink and italics have been adequate for 500 years of typography—to claim that removing that distinction and (for some readers) adding green serif font is an improvement is ridiculous.
If I keep suggesting solutions, will you keep asking for more? There's nothing wrong with any of these examples. Somehow we managed to conduct five and a half centuries of publishing, and create an entire free encyclopedia without your invention. It's not only unnecessary, but it's inferior because it complicates editing, introduces novel conventions, and treats users of alternative browsers like they don't matter. Michael Z. 2009-01-27 21:01 z
Except that if the MoS suggests that unit symbols should never be italicized regardless of surrounding text (which is what the standards actually say), and then it italicizes them itself, it would be ridiculously inconsistent. And, according to Graham87 who really uses a screen reader (see above), my span works as well. -- Army1987 – Deeds, not words. 21:15, 27 January 2009 (UTC)
On 8 December 2008, Noetica wrote: "All I would add is this (that has also been pointed out before): many style guides have all of their examples set off in new lines, or use a distinctive typeface, or both. Given the particular complexity of MOSNUM, and the overwhelming need for clarity and precision, it really ought to be managed like that. Shorter examples in running text but with a distinctive typeface; longer ones set off, but with that same distinctive typeface." So changing font for example isn't exactly a novel idea. I've seen a different font used for strings-as-strings than in normal text in a book written eight years before I was born. -- Army1987 – Deeds, not words. 22:07, 27 January 2009 (UTC)
Yes Army, I did write that. And Greg L suggested a different colour, then we moved forward with a combination of those two ideas. The idea of setting more of the longer examples on new lines fell by the wayside, for reasons that remain obscure.
Because of the way things have turned out, I regret giving early support to exploring these changes. I gently urged that we not implement the template you developed, Army, without further discussion, and without sufficient orderly experimentation in a sandbox – one which I provided, in fact. But Headbomb, you, and Greg would have none of that. Greg responded with this at WT:MOS:

I don’t quite see the concern for a disastrous setback if Headbomb goes ahead and implements the use of [the template] on MOS. It is the biggest sandbox there is. [sic]

I regard that whole sprawling discussion as unruly and unnavigable, and it failed to secure consensus. Most regrettable.
I have used {{xt}} at Wikipedia:Reference desk/Language‎, where it is quite handy. But the whole process has been a typical WP tech-heavy move, that perniciously alienates editors from their tools. {{xt}} and the entirely unheralded and undiscussed {{xt2}} have been implemented above the heads and despite the genuine concerns of many. Changes continue to be made to them in the most appallingly ill-documented or undocumented fashion. Most editors are oblivious to these templates, or mystified by them  – or silently resigned to such things being, in effect, beyond their influence. Myself, I am in a position to engage in discussion; but I find it unappetising, and I don't relish those flurries of invective and ill-considered dismissive replies. Many of us are virtuosos at that atavistic art; but most of us have learned to avoid such fruitless and destructive wrangling.
¡ɐɔıʇǝoNoetica!T23:11, 27 January 2009 (UTC)
I have to concur with Noetica on all of that. I'm rather apalled at the level of snotty hostility heaped on those raising issues with these templates, the accessibility problems with which are painfully obvious. And the hostility was right off the bat, not the product of a long debate (we have a long debate now, but that's beside the point). I have to concur with other opinions higher up that the core problem is the use of span instead of q or samp and blockquote for xt2 (or something else with semantic value; I can't think of anything better really). Seems like a simple fix. I for one am not going to use any of the related templates until this is fixed, and just stick with "example" or example markup, whichever works better with the passage in question in its context. And, yes, I'm well aware of the tediously belabored point that these templates are not intended for article-space usage. That's just not relevant, since blind editors exist. — SMcCandlish   Talk⇒ ʕ(Õلō  Contribs. 23:14, 28 December 2009 (UTC)

Alternative bxt and !bxt for code examples (and other non-serif needs)

The descending numerals and other quirks of the serif font look stupid and confusing, like some kind of intentional subscripting or font miniaturization in source code examples, which run in bulky, monospace font:

You must number the parameter: {{FooTemplate|1=value}}.

I've fixed this with templates {{bxt}} and {{!bxt}} that substitute the font family (typeface) change with a boldfacing (thus "b") font weight change (i.e., they don't depend just on color, so they're not an accessibility problem).

You must number the parameter: {{FooTemplate|1=value}}.

They can also be used in running prose where the font family change is considered so distracting that it's causing editwars.

Capitalizing the common names of animal species is jarring, childish and illiterate-looking: "Smith's Carrier Pigeon was eaten by his Domestic Cat, who choked to death, so he got a Dog and a Guinea Pig instead."

The templates use typographic boldfacing in CSS, not <strong>...</strong> since emphasis in the sense of importance is not generally intended (if it is, you can use a construction like Blah blah {{bxt|{{strong|yak yak yak}}}}. If you needed to differentiate between regular and emphasized text in a bxt string, try something like Blah blah {{bxt|{{em|yak yak yak}} woot woot}}.

Oh, and the templates do not make use of <code>...</code>; while I created them for use in template documentation, the animals example demonstrates that we can't count on their use being restricted to code. So, for code do something like <code><nowiki>{{#if:</nowiki>{{bxt|<nowiki>{{{1|}}}</nowiki>}}|Foo|Bar}}</code> to get: {{#if:{{{1|}}}|Foo|Bar}}.

PS: This template is actually necessary for code accessibility, since:

  • Right:   {{term|''{{lang|fr|esprit de corps}}''|esprit de corps}}
  • Wrong: ''{{term|esprit de corps}}''

produces output that is only distinguished by color, because the font stuff of the {{xt}}/{{!xt}} templates is overridden by that of the later {{tnull}} template.

SMcCandlish   Talk⇒ ʕ(Õلō  Contribs. 19:01, 2 February 2012 (UTC)

The title parameter

Please add:

{{#if:{{{title|}}}|title="{{{title}}}"}}

to match all the other templates in this series. It goes just before the end of the opening <span>, before {{{1}}}. — SMcCandlish   Talk⇒ ʕ(Õلō  Contribs. 00:14, 5 February 2012 (UTC)

 Done. Edokter (talk) — 01:07, 5 February 2012 (UTC)

Use of color

I realize red and green are standard for forbidden and permitted, and that the great majority of people have normal color vision. However, I have deuteranomaly, so when I first saw these templates I had no idea the colors were different. I didn't realize it till I edited something and saw that there were different templates. Now if I look closely, I can barely see a difference. Maybe the colors could be changed according to this guideline, or something other than colors could be used. —JerryFriedman (Talk) 05:09, 19 February 2012 (UTC)

This template talk page probably doesn't have a lot of visibility. Perhaps try raising the issue on the talk pages of Wikipedia:WikiProject Accessibility and Wikipedia:Manual of Style/Accessibility#Color? Senator2029 (talk) 14:05, 8 May 2012 (UTC)

The entire point of this template series is that they use both a color and a font change of some other kind, and further are intended to be used with clear language for the completely blind, e.g. "Use good example, not bad example", or a table column of good examples and a table column of bad examples.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  20:31, 26 December 2017 (UTC)

Example formatting

A comment at Wikipedia talk:Manual of Style/Dates and numbers#Feedback requested on formatting innovations posted by EEng has inspired this conversation. The suggestion was that lists of consecutive examples can become confusing as the comma between this may appear to be part of the example, and that it would be clearer to use semicolons and spacing between them:

  • Peter, Paul, Mary
  • Peter; Paul; Mary
  • Peter ; Paul ; Mary

The discussion was related to Wikipedia:Manual of Style/Dates and numbers but could have wider application.

I don't really notice it much since I customised my CSS with the following:

.example, .example-bold {
	border-style: dotted; border-width: 1px; border-color: #006400; 
	padding: 0px 3px; 
	background-color: #E8FFE8; 
}
 
.bad-example, .bad-example-bold {
	border-style: dotted; border-width: 1px; border-color: #8B0000; 
	padding: 0px 3px; 
	background-color: #FFE8E8; 
}
 
.neutral-example, .neutral-example-bold  {
	border-style: dotted; border-width: 1px; border-color: #303030; 
	padding: 0px 3px; 
	background-color: #E8E8E8; 
}
 
.deprecated-example, .deprecated-example-bold {
	border-style: dotted; border-width: 1px; border-color: #696969; 
	padding: 0px 3px; 
	background-color: #D0D0D0; 
}

Thus, the above examples appear to me as:

  • Peter, Paul, Mary
  • Peter; Paul; Mary
  • Peter ; Paul ; Mary

This formatting may be too garish for others' tastes, but I thought I would open the discussion to see whether anyone would be interesting in adjusting the style of the {{xt}} and related templates to make it clearer where they start and end. Perhaps with some light shading and a small amount of horizontal spacing? For example:

  • Peter; Paul; Mary     (background-color: #F0FFF0; padding: 0px 1px;)
  • peter; paul; mary     (background-color: #FFF8F8; padding: 0px 1px;)

sroc 💬 03:49, 19 January 2014 (UTC)

Though something in between might be best of all, in a choice between the current standard and either of the heavier shadings you show above, I'll take the heavier versions (and, specifically, I like the borders, though I wonder what happens at linebreaks...?). I don't know how much {{xt}} and friends are used outside MOS (or more broadly, outside WP:) but it may or may not be acceptable to change xt itself vs. inventing a new set of templates implementing the new shading, and leaving the old templates alone. EEng (talk) 03:58, 19 January 2014 (UTC)
I tried the bordered-version with linebreaks:
Extended content

The bold asterisks (*****) are were I inserted a linebreak (the first using whitespace and the second using <br />).

  • No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors. Pilots new to the Hornet enter No. 2 OCU after first qualifying to fly fast jets at No. 79 Squadron and undertaking initial fighter combat instruction at No. 76 Squadron. Once qualified on the F/A-18, they are posted to one of No. 81 Wing's operational Hornet units, No. 3 Squadron, No. 75 Squadron or No. 77 Squadron. ***** The unit was established as No. 2 (Fighter) Operational Training Unit (No. 2 OTU) in April 1942. During World War II it provided training on a wide range of aircraft, including P-40 Kittyhawks, Vultee Vengeances, Avro Ansons, CAC Boomerangs, Supermarine Spitfires and Airspeed Oxfords. Disbanded in March 1947, No. 2 OTU was re-formed at Williamtown in March 1952 in response to the demand for more highly trained pilots in the Korean War. It was renamed No. 2 (Fighter) Operational Conversion Unit in September 1958, and since then has conducted training with the CAC Sabre, Dassault Mirage III, and Macchi MB-326, prior to taking delivery of the Hornet. *****
    Taken from the intro section of today's TFA (No. 2 Operational Conversion Unit RAAF).
And if choosing between the light-shading one and the bordered one, I also prefer the borders as I can't see the light heading unless I look closely (in fact I wouldn't have noticed them at all if I didn't know they were supposed to be there).
Also maybe adding the heavier version as an optional parameter of the current xt template is another possibility. ~ benzband (talk) 10:44, 19 January 2014 (UTC)
Good to see some positive early feedback; I expected this to be shouted down with howls of derision! Here's a few more examples.
Formatting examples
  • 1. slight padding, no shading or border
padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 2. added light shading
background-color: #F8FFF8; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 3. slightly darker shading
background-color: #F0FFF0; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 4. slightly darker shading
background-color: #E8FFE8; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 5. darker shading
background-color: #E0FFE0; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 6. darker shading
background-color: #D8FFD8; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 7. dotted border, no shading
border-style: dotted; border-width: 1px; border-color: #006400; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 8. added light shading
border-style: dotted; border-width: 1px; border-color: #006400; background-color: #F8FFF8; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 9. slightly darker shading
border-style: dotted; border-width: 1px; border-color: #006400; background-color: #F0FFF0; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 10. slightly darker shading
border-style: dotted; border-width: 1px; border-color: #006400; background-color: #E8FFE8; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 11. darker shading
border-style: dotted; border-width: 1px; border-color: #006400; background-color: #E0FFE0; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 12. darker shading
border-style: dotted; border-width: 1px; border-color: #006400; background-color: #D8FFD8; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 13. solid border, no shading
border-style: solid; border-width: 1px; border-color: #006400; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 14. solid border in slightly lighter colour, no shading
border-style: solid; border-width: 1px; border-color: #40A440; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 15. solid border in lighter colour, no shading
border-style: solid; border-width: 1px; border-color: #80D080; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 16. solid border in lighter colour, no shading
border-style: solid; border-width: 1px; border-color: #90F090; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
  • 17. solid border in lighter colour, no shading
border-style: solid; border-width: 1px; border-color: #D0F0D0; padding: 0px 1px;
Capitalise the first letter in proper names: Peter; Paul; Mary
Separate names in a list with semicolons: Peter; Paul; Mary
Taken from the intro section of No. 2 Operational Conversion Unit RAAF: No. 2 Operational Conversion Unit (No. 2 OCU) is a fighter training unit of the Royal Australian Air Force (RAAF). Located at RAAF Base Williamtown, New South Wales, the unit trains pilots to operate the McDonnell Douglas F/A-18 Hornet, conducts refresher courses for pilots returning to the type, and trains future Hornet instructors.
Note that the borders do not show at the start/end of the line where the text wraps around the line. Thus, there is a visible distinction between:
Jones, J. (20 Sep 2008)
Smith, J. (Sep 2002)
and:
Jones, J. (20 Sep 2008)
Smith, J. (Sep 2002)

sroc 💬 12:40, 19 January 2014 (UTC)

While I'm personally most partial to n° 6, n° 12 or n° 16, I'm guessing that each editor will have their own preference. Also in this case I fear the problem will be lack of input and consensus, rather than a shouting match. benzband (talk) 16:09, 20 January 2014 (UTC)
Your crystal ball appears to be working extremely well. EEng (talk) 20:07, 11 March 2014 (UTC)

Change font to Times

I believe the font for all example templates should be changed to Times. The main reason is that the current Georgia has 'lower case' numerals, which is fairly problematic where examples using numbers is concerned. Compare these two examples:

  • (Georgia) ...for example, T = 293.15 K, m = 5.4 kg. This is positive example text.
  • (Times) ...for example, T = 293.15 K, m = 5.4 kg. This is positive example text.

I have created the .times-serif class which uses the same font stack ("Times New Roman", "Nimbus Roman No9 L", Times, serif;) already in used for .texhtml (inline math), which should render properly on all platforms. Edokter (talk) — 15:40, 11 March 2014 (UTC)

Sorry to be dense, but what's the problem with the Georgia example? — Preceding unsigned comment added by EEng (talkcontribs)
The numbers. Many examples are dependent on proper formatting of digits, ie. equal height and width. Georgia does not handle this well at all. Take for example 3.500+0.0000
−0.6789
 mm
vs. 3.500+0.0000
−0.6789
 mm
. Edokter (talk) — 20:52, 11 March 2014 (UTC)
Looks good, but the Times looks somewhat larger than Georgia and the default font (Arial?) on my screen. I tried creating manually-formatted examples to illustrate this, but they looked about the same, so I'm not sure what's happening there. What exactly is the list of fonts you're using? sroc 💬 23:22, 11 March 2014 (UTC)
They're listed above: "Times New Roman", "Nimbus Roman No9 L", Times, serif;. Times does look larger, because Georgia uses 'lower case' numbers. Edokter (talk) — 01:20, 12 March 2014 (UTC)
I fear this is going to be one of these situations where differences in configurations make it impossible for us each to know what the others are seeing on their screens. Yes, in the Georgia example the 7 and 9 appear as "descenders", but I don't see why that's a problem. If you're seeing something more serious than that you may need to prepare a screenshot. (I'm on IE 11.0.9600.16518, Windows 7 Home Premium, if that matters.) EEng (talk) 01:41, 12 March 2014 (UTC)
Can't believe I missed this—you really use IE?! sroc 💬 12:37, 12 March 2014 (UTC)
I tried re-creating your example using <span style="font-family: 'Times New Roman', 'Nimbus Roman No9 L', Times, serif;">...</span> and it appears much smaller than your example.
  • (Times) ...for example, T = 293.15 K, m = 5.4 kg. This is positive example text.
sroc 💬 02:54, 12 March 2014 (UTC)
How this discussion appears on sroc's screen.
How about this? Increasing the font size by 110% mimics the default font size on my screen.
<span style="font-family: 'Times New Roman', 'Nimbus Roman No9 L', Times, serif; font-size:110%; color: #006400;">...</span>
  • (Times New Roman, 110%) ...for example, T = 293.15 K, m = 5.4 kg. This is positive example text.
sroc 💬
Sroc's screenshot shows exactly what I see here directly, so I ask Edokter again: what's the problem with the current typography? Other than the descenders already mentioned -- what I don't mind at all -- and that the −0.6789 is the tiniest smidgen to the right relative to the +0.0000 above it -- which isn't ideal but of little consequence -- I don't see anything amiss. Do you agree, Sroc Of Ages? EEng (talk) 04:53, 12 March 2014 (UTC)
I have already accounted for the fontsize difference in the .times-serif class. And you're right, the descending characters are the main argument, but that is not to say trivial. Especially in math related help pages, they are a true nuisance. Another point is that on Linux, those users that have installed the webfonts package, are stuck with an old version Georgia that lacks modern Unicode support. In that regard, if you don't see any disadvantage to using Times, why stick with an inferior font? Edokter (talk) — 11:37, 12 March 2014 (UTC)
  • I didn't say I wanted to stick or not. On the examples so far I don't care. But I don't need to explain the visibility of this template in text whose very purpose is to demonstrate what text should look like. It's almost a certainty that of the literally hundreds or thousands of places where it's used, a few will somehow get messed up by this change, and some zealot will come down on you like a ton of bricks. I'm not saying don't do it, but think hard about how you go about it -- for example, advertise this discussion at Talk:MOS. Also, while we're discussing changes it would be nice to roll in the changes to the shading/outlining/whatever mentioned in the section just preceding this one.

    Having said all that, I'm now looking over this Talk and the very first section is a long, long discussion from years ago about -- ta da! -- whether to use Times or Georgia. I think you better look that over carefully, and maybe ping those involved there. EEng (talk) 16:38, 12 March 2014 (UTC)

I support Edokter's change to Times/Times New Roman because the digits are more uniform than Georgia (i.e., no descenders). I don't think the font size in the .times-serif class is quite right, however, as it appears noticeably larger than the surrounding text.
  • abcABC123def abcABC123def (current {{xt}} format with Georgia)
  • abcABC123def abcABC123def (Edokter's proposed format using times-serif class)
  • abcABC123def abcABC123def (my proposed format using Times New Roman at 110%)
What do you both think of my proposal? sroc 💬 12:24, 12 March 2014 (UTC)
The third option does not match the x-height for lower case (added in examples). The x-height is the determining factor with regards to perceived font sizes. I've come to 118% because that exactly matches the x-height of Times to that of most common sans-serif font in use, while maintaining scalability. Edokter (talk) — 12:55, 12 March 2014 (UTC)
I see what you're saying, but even when I increase the zoom, I have a very hard time seeing a difference in x-height between the default font (Arial?) and my proposal (Times New Roman at 110%), and the total height for uppercase and numerals appears to be evenly matched as well. Conversely, I can see a very obvious difference in the height of uppercase letters and numerals when comparing default font to your example (times-serif). Perhaps a compromise somewhere in between would work.
Incidentally, it was difficult to understand why my example appeared smaller than yours because you are using a class name rather than showing explicit font formatting and it was not clear that you were adjusting the font size until you stated it in your last comment. I prefer to use explicit formatting in examples to illustrate formatting in case templates/stylesheets get updated over time and retrospectively change the formatting used in past comments. sroc 💬 13:42, 12 March 2014 (UTC)
A3b A3b A3b A3b A3b A3b A3b A3b A3b A3b A3b
ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc
Plain TNR 110% TNR 111% TNR 112% TNR 113% TNR 114% TNR 115% TNR 116% TNR 117% TNR 118% Georgia

sroc 💬 14:00, 12 March 2014 (UTC)

See the above table with guidelines for comparison. sroc 💬 14:14, 12 March 2014 (UTC)

Considering that most examples are lower-case sentences, x-height is the determining factor. The 118% has been in used for over three years for inline math, and it took me a lot of testing (with numbers and text) to come to this value; it is the closest that makes the serif text blend in seemless to sans-serif text at any zoom level. The total font height does not show a discrepancy until the text is zoomed very large, ie. over 150%. Edokter (talk) — 14:03, 12 March 2014 (UTC)
Sorry, I appreciate the extensive testing that you have undertaken, but the examples at 118% just look huge compared to the surrounding text to the point that it really stands out. Up to about 113% looks OK, but over 115% looks noticeably larger. sroc 💬 14:19, 12 March 2014 (UTC)
Perhaps it's the character width that is making the examples in Times New Roman look disproportionately large compared with Arial? sroc 💬 14:24, 12 March 2014 (UTC)
I don't find it disproportional. Going below 115% does make it narrower, but for a serif font that also makes it less legible. My Times is no wider then Georgia now, and yours is narrower then the base font (Arial). Edokter (talk) — 14:46, 12 March 2014 (UTC)

At some point, we may have to agree to disagree, but in the meantime, here's an example lifted from MOS:NUM#Unit names using Times New Roman at 115%:

  • Measurements in metric units consisting of values other than ±1 should use the plural form of the unit name; otherwise the singular form is used. Thus: negative one degree Celsius, 10-3 watts and 0.25 metres, not 10-3 watt, 0.25 metre or 0.25 of a metre. In the case of imperial or US customary units with values in vulgar fractions less than 1, the singular form is used. Thus: 516 inch, not 516 inches or 516 of an inch.

It does have the unfortunate effect of adding to the line-spacing, especially with superscripts and fractions. sroc 💬 15:23, 12 March 2014 (UTC)

That is inherent to using sub- and superscript. All fonts suffer this. Edokter (talk) — 16:41, 12 March 2014 (UTC)
Well, yes, of course, sorry, I should have acknowledged this in my reply. What I meant was the increasing the font size will increase the line spacing, but it is most noticeable when super- and sub-scripts are added. sroc 💬 22:44, 12 March 2014 (UTC)
Space is pretty tight; the default body line-height is 1.5em, which is problematic. The Typography Beta changes that to 1.6em, which solves that problem. I maintain that 118% is the best option for most situation; it is the same increase that the font-size-adjust (for Arial: 0.58 > Times New Roman: 0.46) would result in, had that property not been abandoned in CSS 2.1 (and subsequently reintroduced in CSS 3, but only supported in Firefox for now). So can we please implement this? Edokter (talk) — 23:05, 12 March 2014 (UTC)
Maybe it's just a case of I just don't like it and I can adjust the appearance in my CSS anyway, so I'm not going to fuss if I'm alone on the exact size. Good work on pushing for the change. I suspect these are generally unpopular/unnoticed topics – until they are implemented! sroc 💬 00:01, 17 March 2014 (UTC)

Have you guys taken my advice to review this discussion? EEng (talk) 02:04, 17 March 2014 (UTC)

@EEng: Check the link. sroc 💬 02:21, 17 March 2014 (UTC)
I guess you had something else on your mind.
Oh, I guess you meant #Typefaces and consistent appearance above.
If you check my original link you'll see that, as your image suggests, I indeed had T on my mind. EEng (talk) 02:34, 17 March 2014 (UTC)
The earlier discussion EEng linked to got me thinking. Mzajac wrote:

If we must dictate our favourite font, then please don't start the list with Times New Roman. Better to put Times first. It has about identical metrics but looks much better on the Mac; it isn't found on most Winboxes, so it will fall back to TNR on those machines.
— User:Mzajac 2008-12-28 23:14 Z

I note that Edokter said in the initial post of this discussion that the change is modelled on switching to "Times", but the font list actually gives "Times New Roman" priority. Here's "Times" for a comparison:
A3b A3b A3b A3b A3b A3b A3b A3b A3b A3b A3b
ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc ABC123abc
Plain Times 110% Times 111% Times 112% Times 113% Times 114% Times 115% Times 116% Times 117% Times 118% Georgia
And here's an example in running text.
"Times" at 118% looks OK to me, so maybe putting this before "Times New Roman" would appease us both (and Mzajac, too). sroc 💬 02:47, 17 March 2014 (UTC)
That was over five years ago. The problem with putting "Times" first is that it may map to a bitmap font on some systems. Can you update this screenshot with Times on Mac? From what I can tell, difference is negligable. Edokter (talk) — 10:04, 17 March 2014 (UTC)
Bitmap font? Wasn’t that last a danger about fifteen years ago? On what platform is this happening? Michael Z. 2014-03-18 13:59 z
Nope they are still there (for backward compatibility) in Linux, Mac and Windows. Normally, they should be mapped to their modern equivalents, but that is not always the case. But Microsoft, has to this day, not mapped "Courier" to "Courier New". As a result, Internet Explorer uses the bitmap font in certail conditions. Other browsers may work aroud this, ie. by blocking bitmap fonts. Edokter (talk) — 22:29, 18 March 2014 (UTC)
Ask and ye shall receive: File:Sample of fonts (Arial, Times, Georgia) compared for use as example text.png. Sorry, the x-height gridline is slightly off. sroc 💬 10:48, 17 March 2014 (UTC)
Thanks. To be honest, I can't see any difference at all with regards to render quality (asuming you did not resize the images). I have to go with what's best for most. Luckily, the biggest benefit for this change is that the font-family will no longer be inline, so custom CSS is so much easier to implement. Edokter (talk) — 11:00, 17 March 2014 (UTC)
I haven't resized the images. I did place the gridlines manually, so sorry if there are any discrepancies. Just be wary about describing your proposal as adopting "Times" when you actually mean "Times New Roman". sroc 💬 11:06, 17 March 2014 (UTC)
They're different names for basically the same font (think 'Helvetica Neue'). 'Times' generally denote the entire Times family. Edokter (talk) — 11:24, 17 March 2014 (UTC)

This seems misguided.

  1. I don’t see a problem with the provided examples that justifies changing the font stack.
  2. In specific examples that require lining figures or tabular figures, instead of oldstyle figures (can someone provide one?), use a template to apply an appropriate font to the figures.

Times has a smaller x-height and is therefore less readable than Georgia. Michael Z. 2014-03-18 13:59 z

One should not need to use templates to correct typographic errors if they can be avoided, especially inside other templates. That alone should be justification enough. Lining figures should be the default, especially in example templates. Also the x-height has been corrected, as explaine multiple times above. Did you read any of it? Edokter (talk) — 15:57, 18 March 2014 (UTC)