Talk:Typography refresh

New font stack breakdown

I have proposed a new font stack (for Latin languages only) on wikitech-l, and after some feedback I was asked to test it here on mediawiki.org. So here it is:

font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica, sans-serif;

Breakdown

Nimbus Sans L

For Linux. This is the defacto Helvetica font on Linux systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').

Helvetica Neue

For Mac. Like Nimbus, this should not match fonts on Windows (or Linux for that matter), as those copies for Windows have different font family names (such as 'HelveticaNeueLT Com 55 Roman').

Arial

For Windows. Positioned after Nimbus Sans and Helvetica Neue, so Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.

Helvetica

Generic Helvetica fallback for any system not matching any of the previous fonts.

I am quit confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though). — Edokter (talk) — 12:36, 12 April 2014 (UTC)

Discussion

The test stack does result in Arial for me (XP SP3, Chrome 33). I have Nimbus Sans L, Helvetica, but not Helvetica Neue installed. So providing someone can confirm Helvetica Neue on Windows doesn't break it, at least that would give legible fonts again (although I still question the wisdom of forcing stacks like this with the potential for problems for others we have seen - e.g. Linux, above. "sans-serif" is surely adequate, standard, and sensible). The rest is then a matter of my preferences - I still dislike the size and serif headers, but the body type is not broken and badly rendered any more, so my major concern for logged out or non technical users is addressed by that, thanks (assuming it's implemented). Begoon • talk 16:28, 13 April 2014 (UTC)

Helvetica Neue rendering on Windows

I have Helvetica Neue on Windows, attached a screenshot of what it looks like for me (I rather like it). --Skizzerz 04:25, 24 April 2014 (UTC)

That doesn't seem like Helvetica Neue; it is supposed to have decent kerning, and I don't see that here. -- [[User:Edokter]] {{talk}} 09:26, 5 May 2015 (UTC)

As a Mac user, I have to say thanks for putting a Helvetica option ahead of Arial. Is the number of Windows users with the substandard Helvetica greater than the number of Mac users with Helvetica but not H. Neue? Was that considered? Helvetica looks much better on Macs than Arial does. ⇔ ChristTrekker 16:41, 19 November 2014 (UTC)

Helvetica is pretty rare in Windows; the ammount of systems have a subpar version (which "Helvetica" points to) is negligable, and those who do have a good quality version usually have it under a different font family name. That is why having it before Arial is pretty safe. -- [[User:Edokter]] {{talk}} 09:26, 5 May 2015 (UTC)

Header fontstack

See also: Header test

As an experiment, the test wiki has a new font stack for the serif headers:

font-family: "Nimbus Roman No9 L", "Times New Roman", Times, serif;

Reason: the 'Linux Libertine'/'Georgia' stack is too inconsistent. Stylistically worlds apart and their sizing is also very different. Georgia's use of en:text figures is also an eyesore to many. Perhaps ironically, the middle ground in both style and size between these two fonts is provided by Times (New Roman). Where serifs are concerned, Times is as neutral as Helvetica is for sans-serif. It is also the most ubiquitous serif amongst platforms, which helps consistency. Thoughts? — Edokter (talk) — 14:03, Today (UTC+2)

(Edit:) Another reason Georgia is not fit for a global font stack is that it only supports Latin/European scripts. Like the body font, perhaps the default should be 'serif' and Georgia should be reserved for Latin stacks only. — Edokter (talk) — 09:02, 24 April 2014 (UTC)

Times New Roman is ugly. While it is legible, esthetically it just does not look good. Since we don't really need to aim for maximum legibility for headers (they are rendered large enough to be easily readable even on the smallest screens) but actually want to give Wikipedia some characteristic look by the use of serif headers, I'd abstain from using Times. --Patrick87 (talk) 16:42, 14 April 2014 (UTC)

That is a matter of opinion; I like Times' neutrality. Do you have a suggestion for a serif that you do like? — Edokter (talk) — 16:49, 14 April 2014 (UTC)

Actually I'm fine with Georgia. It looks "smoother" compared to Times New Roman. Actually Times is too narrow for my taste which doesn't look too well in headers. What you describe as "neutrality" seems rather sterile to me. Times might be a fine font for body text (as it doesn't draw any attention) but I assume that's the exact opposite of what we want to achieve with headers.
As for a free font I don't have a good option at hand right now. Linux Libertine is quite close to Times I'm afraid, but at least it's the font used in our Wikipedia Logo. Therefore I think it's a fine choice at least in that respect and I wouldn't replace it with Nimbus Roman No9 L. --Patrick87 (talk) 23:48, 15 April 2014 (UTC)

You are right that Times New Roman is a very ubiquitous font. It's the default serif font for Internet Explorer and widely used in the world of academia and law. For some reason it has not been optimized for screen in all its weights. The Bold weight is a fat or heavy and is altogether a different style than the regular weight, The italic weight is also too wide which would create an issue to a lot of articles that are set in nouns for Wikipedia Article Pages. The capitals are too heavy and wide, Specifically, the kerning on screens is weak without antialiasing, which i'm not sure we can count on. Some lower case characters when set in non standard sizes lowercase 'e' is cramped and strangely offsets to the left. In general its a default font, but there is little evidence that its been optimized for screens. Also for windows users who don't have georgia, TNR will be the fallback font. Vibhabamba (talk) 20:12, 16 April 2014 (UTC)

All Windows/Mac users have Georgia, and many Linux users have too. The main problem I have with Georgia is its use of text figures. I can disable that for Win/Mac, but not for Linux because they are stuck with an pre-OpenType version of Georgia. I still don't know what Linux Libertine is doing there; it has a very low install base, and is the stylistic counterweight of Georgia. — Edokter (talk) — 20:27, 16 April 2014 (UTC)

Sorry, but how many headers actually contain numbers? It's very rare and even if a header happens to contain a number the use of text figures is not an issue at all. It's only that people are not even used to serif headers yet, therefore blaming the seemingly evident "flaw" of "misaligned" numbers is one way to express this. I bet if you give Georgia two weeks, nobody will actually notice the text figures anymore. Does anybody have a real issue with them? I doubt it... --Patrick87 (talk) 20:42, 16 April 2014 (UTC)

More then you think, predominantly in article titles. And yes, they are a real problem in some scripts, mainly CJK. Text figures are OK for body text but are not suitable for headers. — Edokter (talk) — 01:27, 17 April 2014 (UTC)

Georgia is a lovely screen font, and has a wide distribution. Sadly, the text figures rule it out from being used as title font. I'm not enthusiastic about Times New Roman, but it may well be the only viable serif alternative. If the size is large enough it's OK, even without smoothing.

OTOH, why not take "serif" for titles? It will be Times in 90% of cases, but I can change my default serif to "Cambria" or whatever. Power to the user.

OTthirdH, I played around and found "Trebuchet" an interesting contrast to Arial. So, if it doesn't have to be a serif, this would work IMHO. --87.157.67.76 22:29, 20 April 2014 (UTC)

The edited in reason to abandon Georgia (no support for non-Latin characters) is the first argument I'd accept (the rest seemed more or less like personal preferences to me). However I think we should consider increasing the size of <h1>,<h2> headers then. I just tested on Windows with "Times New Roman" and they look tiny. E.g. the size of serif <h2> headers is not much larger than the bolded sans-serif <h3> headers. Because of the bolding (and the narrow font face of Times New Roman) <h3> headers look even more prominent than the <h2> headers do! --Patrick87 (talk) 09:28, 24 April 2014 (UTC)

As far as looks go, Georgia does look better, despite its shortcomings. It is still not suitable as global font stack, so it should be reserved for Latin/Cyrillic only, with Times/serif as a global fallback. — Edokter (talk) — 20:42, 27 April 2014 (UTC)

Palatino

font-family: 'URW Palladio L', 'Palatino Linotype', Palatino, serif;

As the only other alternative to the Times stack, I can offer Palatino, which also has a good cross-platform record, wide script support and excelent legibility. — Edokter (talk) — 15:37, 27 April 2014 (UTC)

For some reason 'URW Palladio L' turns out to be rendered as "URW Palladio L Bold" on my System (Windows 7, Firefox 28) since it's the only font face I have installed of this family. I have no idea where it comes from though, but it might be a problem if more people have only the bold variant installed. --Patrick87 (talk) 15:56, 27 April 2014 (UTC)

That is correct behaviour. But I am suprised you only have the bold font. They are usually installed with all variants together. It possibly comes from Libre/OpenOffice (but not sure). 'URW Palladio L' should not match on Windows, where its font family name is 'URWPalladioL', so OpenOffice may also set a font substitute. — Edokter (talk) — 19:48, 27 April 2014 (UTC)

Firefox with DirectWrite enabled (standard behavior on Vista and newer) not only recognizes the PS font name like GDI does but also the "family name" and "name for humans" (that's how fontforge calles these names, I don't know the proper term). So "URWPalladioL" and "URW Palladio L" are equivalent on a DirectWrite enabled Firefox. It's the same with Nimbus Sans. Maybe we should place "Palatino Linotype" first in the font stack to avoid problems on Windows. --Schulu (talk) 21:12, 29 April 2014 (UTC)

Yuck! I'm still on XP, which does not match the 'friendly' name with the fonts' PostScript name (which is also the font family name). Is this Firefox specific, or a DirectWrite 'feature'? It basically sends my font stacks down the drain. — Edokter (talk) — 23:16, 29 April 2014 (UTC)

@Schulu: (and others); are you absolutely sure that you have no font substitute set in your registry? I cannot imagine something recognizing the 'human' name since the font only contains the PostScript name. Even DirectWrite cannot guess its full name. So I am inclined to blame this on a hidden substitution. Can anyone with Windows 7 and URW fonts test this? — Edokter (talk) — 10:25, 8 June 2014 (UTC)

Here is a small test; only Linux users should see the respective fonts:

• Is this Nimbus Sans?
• Is this Nimbus Roman?
• Is this Palladio?

Windows users should see something completely different. — Edokter (talk) — 18:43, 8 June 2014 (UTC)

Last one is "URW Palladio L Bold" for me on Windows 7 (don't know where it comes from right now, though). --Patrick87 (talk) 20:07, 8 June 2014 (UTC)

Can you check in your registry if there is an entry for "URW Palladio L" under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes? — Edokter (talk) — 10:06, 10 June 2014 (UTC)

I deleted the bold font variant of "URW Palladio L" (it really was the only font from this family that was installed) some time ago and it did not reappear. So let's hope it really was an individual case on my system (I still have no idea were it could have come from...) but since nobody else reported similar issues there's a good chance this will not cause widespread problems. --Patrick87 (talk) 11:18, 26 October 2014 (UTC)

I think it is safe to assume the above is a personal issue. So any thoughts on the design side of Palatino for the headers? -- [[User:Edokter]] {{talk}} 07:25, 26 October 2014 (UTC)

I concur with you (see comment above). From the design side, Palatino is definitely not as nice as Georgia on my Windows machine, but it's much better than Times. If we really have to drop Georgia because of technical issues, Palatino would probably be OK. --Patrick87 (talk) 11:18, 26 October 2014 (UTC)

Problem with accented characters

Using Firefox 25.01 on OS 10.6.8, accented characters show up as bold and their kerning is off, both in headers and in ordinary text. Using Safari 5.1.10, only the kerning problem is visible if you look closely. See en:Japanese ironclad Fusō for an example. I do have MS Office 2008 installed. The problem goes away if I use OS 10.9.2 with all the latest versions of Firefox and Safari.--Sturmvogel 66 (talk) 19:22, 13 April 2014 (UTC)

It would help if you could upload a screenshot so we can see the problem. — Edokter (talk) — 20:42, 13 April 2014 (UTC)

Upload it to Commons?--173.8.239.114 21:50, 13 April 2014 (UTC)

You can upload it here as well. It is not of much use on Commons. — Edokter (talk) — 21:53, 13 April 2014 (UTC)

Didn't much think so. I'm not running MediaWiki on my Mac, so how do I enable uploads since I don't have php?--Sturmvogel 66 (talk) 00:42, 14 April 2014 (UTC)

You don't have to run PHP or MediaWiki; just ckick "Upload file" (under "Tools") in the menu on the left. — Edokter (talk) — 16:53, 14 April 2014 (UTC)

Doesn't show up as an option in my sidebar.--173.8.239.114 22:23, 14 April 2014 (UTC)

Ah OK, I guess you need to be registered (also on Commons for that matter). — Edokter (talk) — 22:51, 14 April 2014 (UTC)

I am logged in here and on Commons. Is that what you mean?--Sturmvogel 66 (talk) 02:33, 15 April 2014 (UTC)

Yes. — Edokter (talk) — 10:42, 15 April 2014 (UTC)

@Sturmvogel 66: Hi, I'd recommend uploading your screenshot to a temporary location for now (I tend to use http://imgur.com/ which doesn't require registering or anything), or waiting for 14 more hours, because to upload files here or at Commons, your account needs to be "Autoconfirmed", which takes 4 days at those 2 wikis. Hope that helps. –Quiddity (talk) 05:08, 17 April 2014 (UTC)

Other nitpicks

1. While the font color has been changed to #252525, the headers remain black. At least for the (bold) H3 and down, this sticks out too much. Should the headers follow the body text?
2. The H3 size is slightly too small; it renders 16px, only marginally larger then H4 (100% / 14px). This makes pages like ResourceLoader/Default modules hard to decypher. Suggest changing font-size to 1.2em (renders at 17px).
3. The 1.6em lineheight for body text only affects ‎<p> sections; lists, often used for indenting in discussions, still render at 1.5em lineheight, which is inconsistent. Should ‎<dt>/‎<dd>/‎<ol>/‎<ul> follow ‎<p> in line-height?

— Edokter (talk) — 10:45, 14 April 2014 (UTC)

The headers are darker so they stand out, this is intended based on reading behaviors. Readers skim article and section headers act as entry points in an otherwise dense wall of text. All colors have been contrast evaluated and conform to W3C AAA Guidelines. Thanks Vibhabamba (talk) 23:23, 15 April 2014 (UTC)

1. Change it all back to black, then it's consistent. Actually one of the WMF devs even claimed one of the "features" of the gray body text would be to "make the headers stand out more". I dislike grayish text altogether – there's nothing gained by it's use. The only thing we loose is contrast for no reason.

   Please be aware that we have many audiences that engage in long form reading and are not aware of how to adjust screen brightness. Typically an older demographic. We have feedback from readers which establishes that black on white vibrates for readers on bright screens when engaged in continuous reading. Also we are not 'loosing' contrast with changing from all black to #252525. #252525 provides sufficient contrast by the most stringent accessibility standards. See http://snook.ca/technical/colour_contrast/colour.html. Vibhabamba (talk) 23:28, 15 April 2014 (UTC)

   "Suffucient" and "not loosing" are two different things. We loose contrast, that's pure math. If it might or might not be sufficient is a subjective measure heavily dependent on vision of the individual and the available hardware. I asked before where the feedback is that claims pure black on white would cause issues (without an answer) and I asked before where in those standards it is stated that more contrast wasn't allowed (without answer). I'd appreciate some evidence on how grayish text should increases legibility (if available), otherwise I'm tempted to call this decision a designer's whim, poorly supported by the fact that contrast is at least not too low. --Patrick87 (talk) 00:04, 16 April 2014 (UTC)

   Split the difference between sufficient contrast and not (or, rather, only imperceptibly) losing contrast. I can tell you for a fact, because my eyes hurt looking at this after only 15 minutes, that #252525 isn't quite enough contrast, no matter what this organization or that standard says. I agree that #000000 is actually too contrasty and does produce a jiggling illusion after too long reading it. But #252525 is just too greyed-out and fuzzy.

   • #000000: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
   • #131313: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
   • #202020: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
   • #252525: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
   • #444444: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

   Something around #131313 works much better to me, but even #202020 is an improvement. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 05:22, 19 May 2014 (UTC)

2. Agree.
3. Agree. Actually I think it is time for a major UI refactoring (not to make everything look different but to make everything look consistent). Every feature that is added by the WMF (e.g. Flow, VisualEditor, Hovercards, MediaViewer, etc.) adds a new set of it's own styles instead of reusing CSS that is already available resulting in an overall inconsistent look. I don't even start talking about the unnecessary complexity, aggravated maintenance or performance. --Patrick87 (talk) 16:51, 14 April 2014 (UTC)

Patrick87, Flow and Visual Editor have both been able to significantly simplify their code post typography refresh in order to have greater consistency as users navigate from page to page and mode to mode, wikipedia/mediawiki are so vast and complex that if you look you will surely find pages that are inconsistent, but we plan to, and are actively removing page and feature specific overrides in order to get greater consistency across the projects. If there are pages, or features where you see a lot of overrides being used I'd appreciate the help logging bugs we can clean up the code in those cases. Thanks! Jaredzimmerman (WMF) (talk) 23:47, 15 April 2014 (UTC)

That is good news. I appreciate that this is actually worked on.
However I'm afraid that Flow (whatever amount of code simplification was possible so far) is a paragon of inconsistency. It looks nothing like the rest of Wikipedia but rather like an independently developed extensions that is forced into the existing layout at most half-heartedly. I'll have an eye on it though and report if I find any obviously unwanted inconsistencies. --Patrick87 (talk) 00:15, 16 April 2014 (UTC)

@Patrick87: There's an ongoing massive reworking of the front-end, one of the items in which is "be in line with typography refresh". So, ignore the current front-end design inconsistencies for a few more weeks, please. :) Quiddity (WMF) (talk) 04:54, 17 April 2014 (UTC)

For [1]: I second "change it all to black". Using dark grey text can be an option to reduce contrast, in the appropriate circumstances, and I sometimes use it in images, and used to use 90% black text occasionally on physically printed pages when I was an "ink on paper" printer. However, in that case, we had control of the final output (a printing press) and product (a printed piece of paper).
It's not appropriate here, because in this case we do not have control of the many and varied output devices (monitor types/mobile devices et al.), and so should leave the adjustment of such devices to the user, without reducing their options or range. The user can reduce contrast to taste - he cannot add back what has been removed. The fact that a guideline can be found which says this doesn't reduce contrast "too much", does not alter the reality that it does reduce it, and thus the end user's options. We shouldn't do that.

I tend to agree with Patrick, here, that this looks a lot like a "designer's whim", rather than anything else. Also, I have no idea what "vibrate" is supposed to mean in this context.

For [2] and [3]: Edokter's suggestions seem sound and sensible, promote consistency, and should be implemented. Consistency is a good thing. Begoon • talk 11:02, 16 April 2014 (UTC)

Yep, I certainly get the feeling that (per the FAQ) designer's whim and anecdote drive this typography refresh. When will we learn to use proper controlled tests? Rich Farmbrough 16:58, 17 April 2014 (UTC).

Re "The user can reduce contrast to taste - he cannot add back what has been removed", but he usually can. Most monitors have contrast settings - it used to be a simple dial or pair of buttons, now it's generally hidden in the settings menus, but it's common if not almost universal. Or he can adjust the gamma settings. Or brightness settings. Or adjust the ambient lighting.

Chances are he's already done so as many web sites have other than black on white contrast. Not only is non-black text common, with grey being the most common colour, but non-white backgrounds are too. I just had a look at my four favourite news sites (CNN, WP, BBC, Guardian.co.uk) and all use grey text, sometimes combined with black headings. And those are among the most conservative and soberly formatted websites. It wouldn't be hard to find some with more extreme variations.

So FWIW I support it; it seems a decision in line with good and common practices on the web.--JohnBlackburne (talk) 21:57, 22 April 2014 (UTC)

No John, the user really can't do what I said. If, for instance, for reductio ad absurdum, the site reduced the contrast to "dark grey on dark grey", there is nothing he can do with his monitor controls or Ikea lamps to make it legible. It is lost.
Back in the real world, you can "simulate" increased contrast over the original, but it ain't real. The visible image contrast adjustment range available will always thus be less than it was previously. It can't be otherwise. Consider, for this thought example, the poor man with the knackered old screen who already has his contrast knob forced "all the way up" to get what he wants. You reduce the contrast at source. What does he do with his knob now?
For context we're talking monitor controls here - obviously you can do what you like with custom CSS etc - the ASCII characters are there - but that's not this discussion. Nobody is denying that tech savvy users can have purple text on an orange background if they like, by editing stylesheets etc. The discussion concerns users who can't, won't, or should not have to do that. A knob on a screen will not replace reduced contrast range for them. It just can't. You have, in effect, limited the abilities of that knob.

Now your argument that other websites have done it, that you like it, that other users like it, that it has caused no problems there, is valid, but separate. OTHERSTUFFEXISTS can be perfectly valid here, when expressed as well as you did. But that is not the same argument. I say, as a global, textual website, we shouldn't remove contrast options. You think it's ok. They're both fine views, but they're not both about monitor contrast adjustment. That's where we failed to mesh. This site has reduced that available range for non technical users, by default, including non-logged in users/new readers, and I disagree with that choice. That's all. Begoon • talk 13:41, 23 April 2014 (UTC)

Italic article titles

First of all, my apologies if this is in the wrong place or has been discussed ad nauseum, I contribute to the English Wikipedia and have looked all over for somewhere to post this.

For articles that have italic titles I noticed that the lower-case v looks a lot like a u. When I compared this to non-italicized titles I noticed that they are virtually 2 different fonts! The lower-case i, for example, looks like a nice, readable serif font, but when it's italicized it looks like script. Surely the italics should look like a slanted version of the standard font. Is this intentional? nagualdesign (talk) 00:21, 23 April 2014 (UTC)

That is how Italic type are supposed to look like. Compare with Oblique type, usually used by sans serif fonts. — Edokter (talk) — 01:41, 23 April 2014 (UTC)

Thanks for providing a distinction. Still looks funky to me, mind. Regards, nagualdesign (talk) 03:21, 23 April 2014 (UTC)

Why, why, why (encore)

There was no clear answer to my questions that are moved to Archive 4.

I did read the FAQ, but it does not explain several things that are the most disturbing:

• Why are H1 and H2 serif, and H3, H4, H5 sans serif on laptop/desktop (looks ugly), and why is H1 - H5 always serif on android smartphones (looks much better)?
• Why does "18 Lettertype veranderd" have to look like "18 Lettertype veranderd"? The big difference between high letters and low letters makes it difficult to read. It could be OK if it appeared just once on a page like H1, but with H2 also in this type face the readibility becomes a problem.
• Why does "5 DSM" have to look like ^"5 ^DSM"? I found out how this is called, and reading the article on Wikipedia about it, I learned that it is described in terms of "old style", "antique figures", "medieval". All words that say "not of modern times". So why is this type face selected?

--FredTC (talk) 07:58, 17 May 2014 (UTC)

You know what it's called, so I don't need to explain that. As to why; Georgia was chosen for its general legibility and availability. It happens to contain text figures which not everyone appriciates (I happen to be ne of them). On wikimedia.org (here), these text figures should be disabled. However, not every platforn (ie. Linux) supports disabling this font feature. If your home wiki would like to disabled text figures for headers, I can provide the CSS. — Edokter (talk) — 12:46, 17 May 2014 (UTC)

These are all pretty serious problems. I've used user-level CSS to "fix" them for my own eyeballs, but they need to be dealt with more broadly. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 15:44, 18 May 2014 (UTC)

Is there a way that the user can customize the fonts used?

I find the title of DSM-5 awful and confusing to those not in the know. (For some reason it looks ok here, but not on the article on Wikipedia, where the "5" looks like a subscript, e.g. DSM-₅.) Thanks, Parabolooidal (talk) 18:13, 17 May 2014 (UTC)

Sorry! I see there is an override at User:Cathfolant/typographyrefreshoverride.css. Parabolooidal (talk) 18:21, 17 May 2014 (UTC)

No serif fonts on my wiki?

I updated two of my wikis to 1.23, and while I can see the serif font declarations in the .less files, both wikis show sans-serif fonts for the big captions when using Vector. As far as I'm aware, there should be no custom styles that should cause this. Isn't MW 1.23 supposed to have serif headers?

I have also encountered the same situation on my update to 1.23. I found that by by replacing line 13 of the skins/vector/variables.less

@content-heading-font-family: sans-serif;

with

@content-heading-font-family: "Linux Libertine", Georgia, Times, serif;

as per mediawiki-core/skins/vector/variables.less did the trick.

Badges do not appear completely on fiwiki after the typography refresh

Badges do not appear completely on fiwiki after the typography refresh. Example: w:fi:Linus Torvalds. A good article badge in the upper right corner doesn't appear completely from the bottom. We think that it's because of the typography refresh. How we could solve the problem? What I've looked at the other wikis, there's no such a problem. --Stryn (talk) 18:29, 8 September 2014 (UTC)

Nothing anymore, I just fixed those templates showing the badges. Needed to add some more pixels to div. --Stryn (talk) 22:07, 13 September 2014 (UTC)

Vector header font and sizes

I've uploaded a patch for review that makes all the headers (h1-h6) use the same fonts (the serif font stack defined in variables.less) and changes their relative sizes so that each level is slightly smaller than the next higher level. This addresses bugzilla:70004 and bugzilla:69998.

You can see a live example here (compare with the same page on enwp). Thoughts? -— Isarra ༆ 19:34, 23 September 2014 (UTC)

Actually I like the bold sans-serif font for <h3> and downwards. It just looks right where the serif font would look out of place. I agree that it might be a problem that <h4> to <h6> are styled identically now, but on the other hand it's probably something fundamentally wrong when an article needs such deep nesting anyway. --Patrick87 (talk) 20:16, 23 September 2014 (UTC)

Does the serif look out of place for the h3 in the example? And if so, why doesn't it look out of place for the h2? I agree about most projects not needing the h4-6, but some projects have very different use cases than wikimedia projects, and this affects those as well as these. (Actually those are really the only reason I care about this in the first place, but hey.) -— Isarra ༆ 21:00, 23 September 2014 (UTC)

I assume the main reason serif looks strange for headings >= h3 is because they don't stand out enough. While h1/h2 have the underline h3-h6 are just slightly larger than content text, which seems not to be enough for eyes/brain (at least for mine) to quickly identify them as headings. I'm afraid this problem can't be easily solved without making the headings ridiculously large or giving them all underlines (which is just as impractical). Combining the serif font with bold font weight looks bad, too. I'm afraid the status-quo (although clearly not optimal) is the best solution I can think of right now.
To solve the issues with identical font sizes of h4-h6 one could think about fine tuning the font-sizes of each level (e.g. 100%/110%/120%/130% for h6/h5/h4/h3, which should give sufficient distinguishability). To prevent h3 from getting too large and thereby similar prominent than h2 one could even evaluate the possibility to start with 90% at h6 which is still OK with bold font. --Patrick87 (talk) 22:54, 23 September 2014 (UTC)

But if it doesn't stand out, how can it look strange? What if it's just that you're used to the bold sans-serif? Either way, though, the status quo of a mix, as it is now, is particularly problematic for making work because it's mixing and matching fonts that are completely different sizes from each other (beyond one being bold and the other not being bold), because different computers have different sans serifs (they tend to come in two sizes) as well as different serifs (I've seen four different ones already). This adds up to 8 possible different size combinations, so making the headers work with each other, and with the content text, quickly becomes more complicated. When 150% h2 is still smaller even than bold 117% h3 due to the different fonts, that's a bit difficult to work around. (And that is literally what I'm seeing sometimes.)

In conclusion it's a mess and I'm tired of trying to clean up after these people. Thank you, though. -— Isarra ༆ 01:40, 24 September 2014 (UTC)

Also, buggrit, I just figured out what you meant with the smaller headings not standing out enough - some of the serif fonts that can wind up showing really aren't very bold, and indeed do wind up the same darkness as the sans-serif even at larger sizes. Others, like linux libertine (what I usually see) actually is a lot bolder, go figure. bugzilla:69998 has a bunch of screenshots attached where you can see what the different serifs look like in the h1s and h2s. It's interesting. -— Isarra ༆ 06:35, 24 September 2014 (UTC)

What were the Heading font sizes before the refresh?

I read the summary of changes, but is there a place I can find all the details of what was changed? Specifically, font sizes for the headings and the associated line heights?

There is a gadget on enwiki (here) that resets everything to their pre-refresh settings. You can pretty much distill everything from that. -- [[User:Edokter]] {{talk}} 11:33, 8 November 2014 (UTC)

why restricted to common fonts?

Why restrict consideration for the font stack only to those that are commonly installed? Maybe "Marapfhont" is the gold standard for good design, but is expensive (or whatever), only 10% of visitors have it. (That's a joke, BTW. Marapfhont is Free, and definitely not a wonderful design for body copy.) I say, "So what?" If we can give those 10% a better experience, at the cost of only a few dozen bytes additional CSS to download, why not do it? That's the whole point of CSS font stacks—shoot for the moon, but offer fallbacks. ⇔ ChristTrekker 16:35, 19 November 2014 (UTC)

I think the main consideration is that we want to offer a consistent look to all our readers. This also aids editors to see how their articles will look when using the preview function. -- [[User:Edokter]] {{talk}} 09:33, 20 November 2014 (UTC)

monospace

This was briefly addressed in /Archive 3, but why isn't monospace styling getting a font stack? Code samples and such are a large chunk of many articles related to programming. (Actually, I can't think of many instances to use a monospace other than that. Infrequent, but heavily concentrated, usage.) Unfortunately, the Courier family is about the only one that's going to be commonly present across major platforms, and I don't think it (particularly C. New, ugh) is a good option for this use anyway. Is it necessary—in this case—to maintain consistency across platform, or is it sufficient just be a good choice (i.e. work well for the intended purpose, complement other fonts used on the page)? Because if so, there are many articles listing "good programmer fonts". Or, should we just not give any font suggestions other than "monospace" and let the user set their browser preferences to deal with it—if he cares to? ⇔ ChristTrekker 17:04, 19 November 2014 (UTC)

Polish Wiktionary

I don't know if this topic has been already raised yet or not, but since Typography refresh Polish Wiktionary still has smaller font-size and sans-serif font in headings. Whether it is due to the setting css Polish version, or errors in the software globally? Sincerely, Kszapsza (talk) 19:37, 22 February 2015 (UTC)

It's a result of the internal discussion in the Polish Wiktionary project (wikt:pl:Wikisłownik:Bar#Czcionki). 88.156.130.192 19:58, 22 February 2015 (UTC)

123 Font size and position for pagename and headings (Page 12391 97B)

After updating our wiki to MW-1.24.2 I get a lot of comments from our users about the font size and positioning of the characters in page names and heading1. On our wiki it is very common to use numbers in page names or in headings (example in heading text). You can't argue about taste but it looks a bid odd when there are numbers used in page names and headings. Also when users enabled Auto-number headings in there preferences the headings start to look strange. Tested this in Chrome, Chromium & Firefox. Is this normal behavior in MW-1.24.2? --Felipe (talk) 13:31, 28 April 2015 (UTC)

This is how digits look in Georgia, the font which most computer will use for the H1 and H2 headers. They are called text figures. There is a way to force the headers to use lining figures instead, by placing the following in your site's MediaWiki:Vector.css:

.mw-body #firstHeading,
.mw-body h1,
.mw-body h2 {
    -moz-font-feature-settings: "lnum";
    -webkit-font-feature-settings: "lnum";
    font-feature-settings: "lnum";
}

-- [[User:Edokter]] {{talk}} 13:39, 29 April 2015 (UTC)

OK thanks. To me it seems that text figures make sense when writing something on paper or printing newspapers or magazines where there are "no lines" but MediaWiki page names and headings 1 & 2 have lines below them and then it starts to look strange, especially the numbers 3, 4 and 5. In my opinion they should not "drop" below the imaginary line. It becomes "worse" when you also have headings 3 on a page because they look "normal" again. I tried explaining this to our users but 99% of them are either technicians or engineers and that basically means that they don't understand or want to understand :). Thanks again and regards. --Felipe (talk) 16:18, 29 April 2015 (UTC)

Small comment, the above CSS did not work for me. In .../skins/vector/variables.less the fonts are set with @content-heading-font-family: "Linux Libertine", Georgia, Times, serif; adding the below CSS will "disable" the Georgia font. You can do this in Mediawiki:Vector.css or user specific with User:Username/vector.css.

/* CSS placed here will affect users of the Vector skin */
 
/* Base fonts */
.mw-body #firstHeading,
.mw-body h1,
.mw-body h2 {
    font-family: "Linux Libertine", Times, serif;
}

--Felipe (talk) 08:36, 30 April 2015 (UTC)

Do you happen to have Linux? The core-fonts package includes a very old version of Georgia that does not support lining figures. Or you have a browser that does not support font-feature-settings. -- [[User:Edokter]] {{talk}} 09:03, 30 April 2015 (UTC)

Our server is running Windows Server 2008 and the clients are Windows 7. I "always" test in up to date browsers (except for IE). At home I use Ubuntu Desktop 14.04 LTS but the behavior is exactly the same. --Felipe (talk) 09:24, 30 April 2015 (UTC)

I don't why it doesn't work then; I have it in my vector.css, and I even had it in Common.css here without issue. -- [[User:Edokter]] {{talk}} 15:48, 30 April 2015 (UTC)

This doesn't work on windows 7 on any browser. --121.214.13.217 11:18, 30 April 2015 (UTC)

Adding Linux Libertine G for the headings

Is it possible of adding Linux Libertine G for the headings? Several LibreOffice users can get this font directly because LO has bundled this font. --Great Brightstar (talk) 04:16, 3 March 2016 (UTC)

@Edokter: What do you think of? --Great Brightstar (talk) 06:59, 6 March 2016 (UTC)

Are we talking Linux, or Windows as well? The first should have a mapping, the latter may have a too marginal install base. -- [[User:Edokter]] {{talk}} 22:31, 19 March 2016 (UTC)

I think LibreOffice bundles this font for all three major desktop platforms, and has a fairly large userbase, over and above Linux. From the w:LibreOffice article: "The project claims 120 million unique downloading addresses from May 2011 to May 2015, excluding Linux distributions, with 55 million of those being from May 2014 to May 2015." If we add in the roughly 1.5% of desktop users worldwide who use Linux, that's quite a lot of users. It's also a really nice font, both visually and typographically, and matches Wikipedia's in-house branding, as it is used in the logo. -- The Anome (talk) 06:58, 23 May 2016 (UTC)

body text

Different people have different preferences over what font to use to read an article and I have to say it's pretty a bad idea to specify a font for main text, just use sans-serif and let readers choose their owns via browser setting