Template talk:Xt/Archive 1

This is an archive of past discussions about Template:Xt. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Fleshing out details

Exploring size

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

This section is 54.1%R-0%G-6.3%B
Maroon is R=50%-G=0%-B=0% (headbomb finds this too dark)
{{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%.

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
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
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
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
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
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
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
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
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
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
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
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
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 because I didn’t want to take the time to figure out how to make face="times new roman" to work with 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”.

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
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
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
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
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
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
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
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
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
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
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
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
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 seem to have been misunderstood. 107 or 108% is about the maximum I can tolerate; 100% would be 5 cats and 32 dogs, which seems about right; it's the same as the rest of the [black] text to me. Septentrionalis PMAnderson 23:09, 18 December 2008 (UTC)

Does the lower set look any different from the top set PMA? Greg L (talk) 23:45, 18 December 2008 (UTC)
- Yes. The top set is much stringier. Are other IE computers getting the same> Septentrionalis PMAnderson 01:47, 19 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  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: , 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)

P.S. PMA: Is there a size difference in the second set, above? Is 108% still the absolute max? Greg L (talk) 03:23, 19 December 2008 (UTC)
- The lower set increases in size with the parameter. 109% looks to be the same in both, but looks better in the lower, explicitly TNR, set. Septentrionalis PMAnderson 03:55, 19 December 2008 (UTC)

Feedback please. Things to discuss:

108% ?
45.1% green? Good? Bad? Shoot Greg L?
Woodstone’s fuchsia-like color? Good? Bad? Put a stick between Tony’s clenched teeth so he doesn’t swallow his tongue?
54.1%R-0%G-6.3%B? This is what the above two charts (and the below screen capture) are in.
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 : 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: : 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: : 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))

With TNR, there appears to be a box from 104% to 109% inclusive; works for mee, but so does the box around 100%. Septentrionalis PMAnderson 21:26, 19 December 2008 (UTC)

That means your preference (104–109%) and mine (107–114%), overlap at 107–109%. Thus, it seems 108% is looking to be ready to soon be anointed with holy oil. Greg L (talk) 22:01, 19 December 2008 (UTC)
- But we should check with a large range of editors before using the template. The fact that we've got three different responses on size-clumping imply there are more out there yet to be found. Septentrionalis PMAnderson 22:14, 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)

IE on Windows. I see a sharp distinction at 103/104% and 109/110% so it's clear there are some more variables. Septentrionalis PMAnderson 22:50, 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 14⁄13, which is 107.7%. Scaling more, to 15⁄13 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 e = mc²

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 mc² 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 = or hex = , 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 , 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 like. —Michael 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 5 cats and 32 dogs or five cats and thirty-two dogs, not five cats and 32 dogs.. 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  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 and , 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  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. and 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 . -- 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  by the renderer. Now  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.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 23: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 ... 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

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please add:

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

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

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

Use of color

Moved from Template talk:Tx/see also

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  ).

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;