Talk:Typography refresh

Wikipedia or MediaWiki?
I am getting conflicting information whether this update is Wikipedia only or MediaWiki thing. Some examples below.

Wikipedia: "'Type is a core visual element of Wikipedia's language'" "'we want the font choice to reflect us and our content'"

MediaWiki: "'which is a good thing for both Wikimedia and third party users of Vector/MobileFrontEnd'" "'it's something we should do before we move to merge anything from the typography refresh in to Vector proper'"

Please clarify which point of view has been used as basis of the changes. If it is Wikipedia, please clarify what thought has been given the suitability of the choices for 3rd party users of MediaWiki. For example, do you want every site to look like Wikipedia? --Nikerabbit (talk) 08:29, 18 February 2014 (UTC)
 * I too would like to see an answer to this. Legoktm (talk) 07:01, 10 March 2014 (UTC)
 * Dearchive unanswered question also asked several times on mailing lists and made even more pressing by the newer text "Wikimedia's default typography", "Wikimedia content must be highly accessible" but "all projects (as part of the Vector skin)" etc. --Nemo 17:39, 14 March 2014 (UTC)
 * It's a partially unresolved question, but is probably best answered by the first question in the FAQ. When it comes time to remove this from Extension:VectorBeta the most logical destination is Vector skin in MediaWiki core. Whether other MediaWiki users want to retain the change is up to them of course. Steven Walling (WMF) &bull; talk   17:52, 14 March 2014 (UTC)
 * No, I don't find any answer in the first FAQ question. "Of course"? How? --Nemo 18:00, 14 March 2014 (UTC)
 * "Who will see this change?" "All users of Wikimedia sites who use the default Vector skin, including readers and editors. Users who use their preferences or another method to use an alternative skin, like Monobook or Cologne Blue, will see no changes." Steven Walling (WMF) &bull; talk   18:10, 14 March 2014 (UTC)
 * Why are you copying it here? If you're implying that this change will not be made in core or the Vector extension, it would be useful to say so explicitly. --Nemo 18:23, 14 March 2014 (UTC)


 * We're still lacking an answer here. The current TL;DR is: we made it for Wikipedia only, but forced every MediaWiki user as well, hoping they wouldn't mind.
 * Source: on wikitech-l however Steven said «This was designed primarily with Wikimedia readers in mind, but this is extremely minimal stylistically». So it seems we're never going to know and the text of Typography refresh will keep being contradictory, omissive and non-explanatory; authors of this thing are very defensive. --Nemo 07:09, 1 April 2014 (UTC) P.s.: Filed 63351 to keep track of the release notes part.

Some (probably unwanted) feedback
So...as you may know I've thrown together some code to override this, and I say 'thrown together' because I'm still pretty close to a beginner at css and I was mostly just trying to get typography refresh out of the way. was kind enough to suggest ways I could improve it, and I've broken it into a fonts and colours section and a font size section but I didn't succeed in fixing the other things, probably because I did it wrong - 0.8em made things too small...and anyway, apologies for not making it exactly how it should be. But I think it would be much better if there were a preference one could turn on or off; just telling people they can customise their css won't work for those of us who don't want to bother learning how, and some may not even want to bother copying my code, especially considering that the elements I set probably aren't what they should be and it's not a complete fix anyway - there's a bit much padding under the headings, for example, and who knows what it looks like in other browsers.

I also feel like at least the grey text bit is a change to benefit those with vision problems at the expense of those without, though I doubt it's intentional. I don't notice the difference between the grey and the black and don't find either a strain, but someone irl has told me that he finds grey text on a white background to strain his eyes, and he doesn't have the sort of vision problems you're trying to address. He says it would be better to darken the background rather than lighten the text. The comment above about how dyslexics etc probably have their contrast turned down also seems valid and I'd appreciate if it were taken into consideration.

Finally, like someone else on this page I would like to know if this will be in core MediaWiki or if it's just for Wikipedia or the Wikimedia wikis. The link Quiddity posted on my talk looks to me like you're changing core mediawiki, and this worries me because this seems to be a change for specifically wikipedia and other mediawiki wikis may not want it, and will have to do some kind of awkward patch business. Another thought I had was that perhaps this could be made into a separate opt-in skin, rather than a change to vector - forcing it on everyone who chooses to use vector doesn't seem fair; I realise it may be hard to create a skin that works for everyone, but you may want to weigh the benefits of one against the other, and please at least make it possible to opt out via a simple checkbox in Special:Preferences.

Thanks for reading, apologies if it's tl;dr or not what you wanted to hear. Cathfolant (talk) 03:15, 1 April 2014 (UTC)


 * On your question, see : we never managed to get a reply, though at least half a dozen persons asked on mailing lists. It seems the change was thought with Wikipedia only in mind, but applied to MediaWiki core by default. That's hard to believe, but I guess the only defense mechanism for users and non-Wikipedia wikis is to use monobook instead of Vector (a strategy broadly adopted since 2010 by the majority of power users and more). --Nemo 07:01, 1 April 2014 (UTC)


 * A fairly clear answer (basically your second sentence) was given on wikitech-l. For what it's worth, I largely agree that this (applying it to core) was the right thing to do--the requirements for the changes aren't specific to Wikimedia sites--for example, increasing the body font size should make all wikis using Vector more readable in general. I don't like some aspects of the changes, but restricting the changes to Wikimedia wikis as a way to "limit damage" is not the right way to go. wctaiwan (talk) 13:05, 1 April 2014 (UTC)


 * Not really: the text doesn't explain how the decisions taken are consequences of those supposed requirements. For instance, point one is "legible and beautiful", but we were not provided any criteria for "beautiful" by designers (devs summarised their thought with "how similar to Helvetic Neue the font is"); yet, despite being Wikipedia-specific, it seems to have overridden any other consideration. Point two is "consistent visual experience across desktop and mobile devices", but MobileFrontend is only developed for Wikimedia wikis (Wikimedia-specific overrides, rarely compatible with stable release, almost unused by third party wikis). Not to mention the needs of non-Latin scripts languages, which have never been considered here, but can be important for sysadmins whose main focus happened to be on wikis in such languages. --Nemo 22:14, 6 April 2014 (UTC)

Let's get something straight...

Seriously?!? So then we should expect the standard interface to change to the one shown on the right, pretty soon now, shouldn't we? -- Jokes_Free4Me (talk) 02:28, 7 April 2014 (UTC)

Redundant bug fixes?
Changes were made in Special:Code/MediaWiki/108215, Special:Code/MediaWiki/99389, Special:Code/MediaWiki/104160, Special:Code/MediaWiki/105517 and Special:Code/MediaWiki/105521 for fixing bugs 29405, 30809 and 32826. The fix for  seems to be overridden in the beta feature (although in a good way). The  specified in the beta feature appears to be more than the   specified in the original bugfix.

Not sure if the original bug fix was for vector or all skins, but it should be evaluated whether it is needed anymore.

NOTE: I've only tested this for hindi (hi) at मुखपृष्ठ.--Siddhartha Ghai (talk) 10:00, 1 April 2014 (UTC)

Headlines on pt.wikipedia Main Page
This new typography funks up the section headlines on pt.wikipedia. . Some of them get moved completely outside of the line they are supposed to be. GoEThe (talk) 11:31, 1 April 2014 (UTC)


 * Yes, this is because the new h2 style is designed for regular content pages (including Talk, Help, etc.) so there is a bit more space above it (margin-top: 1em;). Places where there are additional local styles around an h2 might need fixing in Common.css. You can see that they already fixed this in German Wikipedia's Common.css by referring specifically to the Main Page h2's and removing the serifs and fixing the spacing. It looks like putting in styles that refer to div#artigos-destacadosHead h2 will fix this. Steven Walling (WMF) &bull; talk   21:57, 2 April 2014 (UTC)

Missing info - which browsers were tested?
The FAQ entry "Did we test this on a variety of browsers and operating systems?" only seems to list the operating systems, and does not specify which browsers were tested. 86.160.127.102 21:10, 1 April 2014 (UTC)


 * Browser Testing information updated in the FAQ - Please see https://www.mediawiki.org/wiki/Typography_refresh#Did_we_test_this_on_a_variety_of_browsers_and_operating_systems.3F
 * Thanks Vibhabamba (talk) 21:50, 2 April 2014 (UTC)

Fat Fs, Ts and Is


As can be seen from my screen-shot, it appears on my system (Win XP, Chrome) that all the Fs are emboldened. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:37, 1 April 2014 (UTC)


 * Do you have Liberation Sans installed? It does not render too well without ClearType enabled. Try enabling that and see if that improves the issue. — Edokter  ( talk ) — 00:36, 2 April 2014 (UTC)
 * Same problem here (Windows 7, Chrome 33.0.1750.154 m).
 * Users without administrative rights cannot change the ClearType configuration, so that is not an option. Helder.wiki 18:04, 3 April 2014 (UTC)
 * Then the only option remaining is to reset the font to Arial in you vector.css. — Edokter  ( talk ) — 18:59, 3 April 2014 (UTC)
 * See the screenshot provided by on English Wikipedia. Helder.wiki 14:29, 4 April 2014 (UTC)
 * Edokter  Thank you for reporting this. Can you help us with the OS/ Browser details. And can you tell us if Cleartype is turned on in your system Open Source fonts don't work well without clear type being turned on. Vibhabamba (talk) 00:12, 5 April 2014 (UTC)
 * , the biggest problem is by far (old) Liberation Sans installed on Windows, usually by way of OpenOffice. Steven already enquired on enwiki about removing Liberation Sans from the stack, which I think is a viable option. I replied: "You would need a replacement for those without Arimo on Linux systems (if you want to keep Arimo at all). Helvetica should map to Nimbus Sans L, but it wouldn't hurt to include it explicitely (it has near 100% penetration on Linux), so it would become: ." —  Edokter  ( talk ) — 00:31, 5 April 2014 (UTC)


 * Hi, I just went through the same problem, bug details here: 63512. There's a test page to see if the fix works for you here: Save_the_princess. - Martín
 * See also Image:Newfont thebigf.JPG uploaded by and mentioned on enwiki's Village Pump. Helder.wiki 17:17, 5 April 2014 (UTC)

Hey Andy (aka ) and everyone. We've identified which fonts for body text were causing this problem for users without ClearType/font smoothing turned on. We've tested and added a local fix on English Wikipedia for now, and on Monday when software deployments can resume we're going to add this fix to the new default everywhere. Steven Walling (WMF) &bull; talk   23:48, 5 April 2014 (UTC)

Error Visual / Visual error
Español: he observado, al probar la nueva versión de la piel Vector, un error en un artículo de Wikipedia en español. Al usar la plantilla "cita" con una imagen cerca, la plantilla con la cita invade la imagen; esto antes no pasaba.

English: I have observed, to test the new version of the Vector skin, an error in a article of Spanish Wikipedia. By using the "quote" template with an image around the template with Quote invades the image, this did not happen before.

- El Ayudante (talk) 23:01, 1 April 2014 (UTC)


 * This feature has already been removed. — Edokter  ( talk ) — 00:30, 2 April 2014 (UTC)

The use of BCE & CE for dating vs, BC & AD...
Why do you use BCE (Before Common Era) instead of BC (Before Christ) and CE (Common Era) vs. AD (Anno Domini)?
 * This doesn't have anything to do with the typography refresh but if you would like to read more about why this is the case Jimmy Wales has a great answer on Quora about this subject Jaredzimmerman (WMF) (talk) 21:49, 2 April 2014 (UTC)

Significant size increase for body copy
The body copy has been increased to 0.875em (from 0.8em). This results in about 15% less text displaying in a window (as width and height increase, so less text displays on a line, and fewer lines display). What can we put in our vector.css to revert just this part of the change? thanks. Nurg (talk) 09:05, 2 April 2014 (UTC)
 * Nurg, this was to address an accessibility issue that many have brought up with the current type size being too small, you can read more in the FAQ about our rationale for the increase as an accessibility improvement. Jaredzimmerman (WMF) (talk) 21:57, 2 April 2014 (UTC)
 * Thanks for the rationale, though it isn't what I asked for. I would like to know what I can put in my personal vector.css to revert just this part of the change. Thanks. Nurg (talk) 23:32, 2 April 2014 (UTC)
 * Sorry Nurg, I misunderstood, that was what you were asking for, there is a css override ( …also in the FAQ), a less permanent thing to do would be to use your browser's text zoom feature as well. Jaredzimmerman (WMF) (talk) 02:52, 3 April 2014 (UTC)
 * Neither of those answers are what I asked for either. A correct answer appears to be:

font-size: 0.8em !important; }
 * 1) bodyContent {
 * Nurg (talk) 22:48, 3 April 2014 (UTC)

Font size difference in diff pages
It seems that the font for the changed text in diff pages is different than that for the unchanged text. In this diff, for example, the equal signs in the old text that were removed (i.e the highlighted ones), appear smaller than the unhighlighted ones.--Siddhartha Ghai (talk) 13:40, 2 April 2014 (UTC)
 * Without further screenshots in other language projects, It doesn't seem like this is being specifically impacted by the typography update. Vibhabamba (talk) 22:07, 2 April 2014 (UTC)


 * Tested the issue on the English wikipedia with and without the typography refresh beta feature. Results (below) seem to suggest that the problem is with the update. The concerned diff is this.--Siddhartha Ghai (talk) 07:23, 3 April 2014 (UTC)


 * Testing on Commons reveals that the issue is present with the update too. See this diff on commons.
 * PS: The screenshots above were taken on Windows 7 X64 with Google Chrome Version 33.0.1750.154 m.--Siddhartha Ghai (talk) 07:29, 3 April 2014 (UTC)


 * I can confirm I see the difference, but it is not caused by different font sizes. It just so happens that at that particular font size (in Arial), the "=" character renders seemingly different in bold then in normal weight. [//commons.wikimedia.org/w/index.php?title=User:Siddhartha_Ghai/sandbox&diff=120589758&oldid=120589742 Look here] to see the effect, and also see that other text is not affected. — Edokter  ( talk ) — 11:42, 3 April 2014 (UTC)


 * The problem is also present with dashes [//commons.wikimedia.org/w/index.php?title=User:Siddhartha_Ghai/sandbox&diff=120666445&oldid=120666422 see diff]--Siddhartha Ghai (talk) 15:48, 4 April 2014 (UTC)

H4 vs H5 (and potentially H3)
Maybe I'm nuts, but shouldn't there be some difference between H4 and H5? (And more than just a stroke-width difference between H3 and the others?) LtPowers (talk) 14:18, 3 April 2014 (UTC)
 * They decided to make them equal size to running text to make H2 and H3 more distinguishable, as H4-H6 are rarely, if ever, used. — Edokter  ( talk ) — 15:19, 3 April 2014 (UTC)
 * Excuse me just a minute while I check your statement against enwiktionary-20140311-pages-meta-current.xml dump. 3970659 pages processed, 1126424 L4 to L6 found. They may be uncommon, but not rare. (Also, on en.WT L4 and L5 are semantically significant.) - Amgine (talk) 20:18, 3 April 2014 (UTC)
 * 'Never' would be one thing, but 'rarely' is another thing entirely. Given that H4 and H5 are sometimes used, how are they to be distinguished visually?  LtPowers (talk) 23:44, 3 April 2014 (UTC)
 * Proposal: Why not use the italic to differentiate? H4 could have the same size as H3 but in bold-italic and not in bold. H5 would stay in the actual size, H6 would be the same size as H5 but bold-italic. An example were the difference could be needed is for example the German article about Wikipedia --217.226.201.21 14:57, 5 April 2014 (UTC)

en.WT issues
The typography refresh has been unpopular on en.wiktionary, initially assumed to be a joke. It is also associated with some breakage. - Amgine (talk) 18:58, 3 April 2014 (UTC)
 * Unpopular on en.wikivoyage too. Texugo (talk) 19:04, 3 April 2014 (UTC)
 * Looks like it isn't going down brilliantly on en.wikipedia. Can we change back to the old and see if there's consensus for a change? Thanks, Matty.007 (talk) 19:45, 3 April 2014 (UTC)
 * That's debatable, Texugo. You don't speak for all of us.  LtPowers (talk) 23:45, 3 April 2014 (UTC)
 * I believe it's a fair to say "unpopular" in a situation that consists only of a majority of negative opinions, plus a few neutral wait-and-see ones. You certainly couldn't argue that it's "popular". Texugo (talk) 11:22, 4 April 2014 (UTC)
 * Let's face it, it's a bloody mess. A mish-mash of type faces, unwanted resizing of text.  It's ugly, it's confusing to look at, and the resizing means that there's less text on the page, so you have to waste time and effort paging down.  Whoever thought it up should be taken out and shot!  Skinsmoke (talk) 23:49, 4 April 2014 (UTC)

Why is Arimo highest priority?
Arimo is set as the highest priority font, even though it scored fifth place. Why is this? Personally, I think it looks odd, especially bolded like it is in basically every article. 216.52.207.75 19:52, 3 April 2014 (UTC)

Bold Arimo on both Firefox and Chrome for Windows is quite awful at the default body size. The bolded "e" is particularly uneven. --96.49.52.143 22:07, 3 April 2014 (UTC)


 * Yes, it's well known that forcing specific fonts has terrible results on Windows: see Talk:Typography refresh/Archive 2 (January). Three months later it seems the powers that be acknowledged it, too, in their way: . --Nemo 16:16, 6 April 2014 (UTC)

How to revert to old typography?
The new typography hurts my eyes and makes the articles hard to read.

How do I switch it back to how it was?

Please note that I am not a power user, just a heavy browser of interesting pages.

Thanks. —The preceding unsigned comment was added by 74.201.1.5 (talk • contribs) 20:36, 3 April 2014‎ (UTC)


 * I'm in the same boat with the above. I already posted a similar comment on the blog announcing the change, but I'll repeat myself here. The font change has made Wikipedia unreadable to me. The font is very narrow and it takes extreme zooming before it becomes comfortable to read. I had never experienced any kind of trouble with the old font. Now trying to read a Wiki article for a minute is impossible without practically having double vision afterwards. That is how bad it is. Here is what it looks like on my screen now (Win7, 1366x768, Firefox 12): http://oi60.tinypic.com/34j85qf.jpg —The preceding unsigned comment was added by 88.114.248.71 (talk • contribs) 21:20, 3 April 2014‎ (UTC)

Same here..... Wiki, if it works well, you must not change it. —The preceding unsigned comment was added by FoureychEightess (talk • contribs) 21:55, 3 April 2014‎ (UTC)

Me too! I want the old typography back! --Andreas Schwarzkopf (talk) 18:07, 5 April 2014 (UTC)

New font is too big
Words and lines are too much spaced out, and make text hard to follow and read. Please change it back, at least to 0.85em.
 * Font size and leading changes are explained in the FAQJaredzimmerman (WMF) (talk) 23:21, 3 April 2014 (UTC)
 * Jesus Christ! How can you mark this as "resolved". We claim it is too-big-to-read now. I already reversed those changes with Cathfolant code, because I had to move back with my chair from the screen! These are (one of) the worst changes I have ever witnessed in my 10-year history at wiki. Arvedui89 (talk) 06:48, 4 April 2014 (UTC)
 * I have to agree with Arvedui89 regarding the font size. It's too big. It's all well and good that it's explained in the FAQ but that doesn't address the fact that people don't like it. Your response to this reminds me of the crApple response when iPods were first released. "Hello Apple, my iPod battery is dead." "Easily fixed. Buy a new iPod". --AussieLegend (talk) 08:13, 4 April 2014 (UTC)
 * May I register my dissent? ;) In my opinion, the font is still too small. I believe the default for body text should be 1em, which is the default that the user sets in his browser (or has that changed?). Every user has a different situation, so you need to give up control about exact sizes. Use the default, and let the user decide what that is. --87.157.78.253 22:25, 4 April 2014 (UTC)
 * I also agree with Arvedui89 that the bigger bread text font in the recent typography disaster makes articles harder to read —WinTakeAll (talk) 04:31, 5 April 2014 (UTC)
 * Marking this as 'resolved' is some kind of joke. In this situation I don't see another choice than voting. Piotr Jurkiewicz (talk) 09:37, 6 April 2014 (UTC)
 * Absolutely agree. Resolving an issue assumes some kind of change in response to feedback. This was not the case here. -- Jokes Free4Me (talk) 17:01, 6 April 2014 (UTC)
 * You already can control the font size of your own. Just use Ctrl Plus oder Ctrl Minus to set the font of the actual domain bigger or smaller (key shortcuts for Firefox, other browsers may have different shortcuts). Your browser remembers your preference. I’d always enlarged Wikipedia’s font pressing Ctrl Plus three times. Now I can go one step back. --217.226.201.21 13:37, 5 April 2014 (UTC)
 * You already can control the font size of your own. Just use Ctrl Plus oder Ctrl Minus to set the font of the actual domain bigger or smaller (key shortcuts for Firefox, other browsers may have different shortcuts). Your browser remembers your preference. I’d always enlarged Wikipedia’s font pressing Ctrl Plus three times. Now I can go one step back. --217.226.201.21 13:37, 5 April 2014 (UTC)

Deformation in esWiki
Hi. ¿Is this normal? In 100% zoom, I see each letter lower than the same text in other zoom rate, making the bold letters going deformated. ¿Does it just happen to me? I use Chrome. Greetings. Albertojuanse (talk) 21:12, 3 April 2014 (UTC)

Font
Change the bad font back to the old good font please. The new is hard to read.

I want to use my PC's serif or sans-serif font. —The preceding unsigned comment was added by FoureychEightess (talk • contribs)  21:52, 3 April 2014‎ (UTC)

I don't like at all that police
At least you should have given the users the possibility to keep the old police or to use the new one. I would like to have the exact code of the old police to put in in my vector.css. Could somebody help me. --Berdea (talk) 22:57, 3 April 2014 (UTC)
 * See User:Cathfolant/typographyrefreshoverride.css. By the way, what do you mean by "police"? I'm sure you don't mean the actual police. πr2 (t • c) 23:15, 3 April 2014 (UTC)
 * Policy, I reckon. Lagrange613 06:14, 4 April 2014 (UTC)
 * No it's just because Berdea is a french contributor and in french font is said police ;) Euterpia (talk) 09:22, 4 April 2014 (UTC)
 * Thank you Cathfolant, PiRSquared17 & co. It works (like before) ! Lysosome (talk) 10:33, 4 April 2014 (UTC)

Body font is too squished
I don't know if I just have to have a different font installed, but I feel that the new body font looks really squished and it's just too small for my taste. Everything just looks really narrow and it's a bit harder to read. --98.113.144.121 23:22, 3 April 2014 (UTC)
 * I agree. It's *way* too narrow.  Makes it harder to read.


 * That's right. It is absurdly narrow. It is impossible to read a full article now. I struggle to read even one paragraph, and even then I have to squint. Whoever forced through this "improvement" should be fired immediately.


 * I'm pretty sure this "narrow" look is not intended. I believe it is caused by having only the narrow version of one of the higher priority fonts installed on your machine.  So, for example, you have Ariel installed (which would look fine), but Helvetica is set by MediaWiki as a higher priority font.  Normally Helvetica would look even better than Ariel - but what if the only member of the Helvetica family you have installed is Helvetica Narrow?  That would look pretty dreadful, but may still end up being chosen by your browser because it is reading the rules as saying "any kind of Helvetica is better than Ariel."  I don't know how to fix this, but I believe it is a genuine bug, rather than a matter of user opinion. 2.29.0.99 01:42, 5 April 2014 (UTC)


 * Nope. Font fallback does not actually work that way. Helvetica Narrow is considered a separate family from Helvetica, in the way that the OSes group fonts, at least on Windows and Mac. (If it were an Adobe app something like this could actually happen.) &lt;signature-anon&gt; 03:27, 5 &lt;april&gt; 2014 (UTC)

opinions from pl-wikt

 * ''See also pl.wiki

Translated feedback from the Polish Wiktionary's Village Pump (BTW Polish Wiktionary has reverted the changes, so that the problems are not observable there now):

Typographic nightmare! Some amateur serif font in the header with a chaotic kerning and spacing. Especially the bold font in the text is badly displayed on the monitor: And this widened font, which is not more legible, but it causes expansion of the inflection tables in the text. Fatal amateurism. I understand that the Wiki is a community project, but it would better consult such changes with someone who has a little sense of aesthetics and typography?
 * e, s and a lost themselves in the horizontal elements
 * Vertical element f is displayed thinner than the other ones,
 * The colon and parenthesis look as if they were larger than the rest of the text,
 * All Polish diacritical marks look like the amateur character modification in the early 90s when the Polish computer science was in its youth,
 * Poor kerning, which almost glued some characters, such as •••,
 * Capital letters B, F and J look like from a different font,
 * Kerning in text is disastrous, because it gives the impression as if letters were thicker sometimes and thinner in other places.

Another examples of amateurism of the selected font : 83.5.201.92 (dyskusja) 21:33, 1 kwi 2014 (CEST)
 * W) ← parenthesis is placed lower then letters
 * zn ← the letter "z" is narrower than the "n" and the put together they look like from completely different fonts

Please communicate to them, that the change is awful and please restore the former style. Marek Mazurkiewicz (dyskusja) 1:02, 4 April 2014 (UTC)
 * Thank you for acting as ambassadors on behalf of your community. πr2 (t</b> • c</b>) 01:39, 4 April 2014 (UTC)


 * You are right in many points. I noticed the bold e and a looks bad in Chrome. If I change the size to 1em, it looks better. So it's a case of bad hinting / kerning, IMHO. Same with "zn", if you zoom or set size to 1em it looks better. Agree on parentheses, too. I do like the quirky "J" in Arimo/Liberation Sans. --87.157.78.253 22:46, 4 April 2014 (UTC)

Article heading is complete mess now
Problems (http://i.imgur.com/tMZIO2I.png - screenshot with my annotations):

1. marging-bottom on #firstHeading. Why it has been introduced? It results in spacing between article header and "From Wikipedia, the free encyclopedia" (#siteSub), what looks inelegant and buggy.

2. Spacings between #contentSub and .dablnks should be equal. Now it is inconsistent.

3. And the most important thing: "&amp;nbsp;&amp;nbsp;(Redirected from ...)" - #contentSub content is aligned with blank spaces (!)

I suspect that someone done it in order to align #contentSub (margin-left: 1em) with .dablinks (padding-left: 1.6em). So he just put two spaces in front of it, instead doing css tuning.

I propose the following changes:

1. Set margin-bottom on #firstHeading to 0.

div#content #firstHeading { margin-bottom: 0; }

2a. Change spacings between #contentSub and .dablnks to be consistent (0.5em).

2b. Set margin-left on #contentSub to 1.6em (the same as .dablinks padding-left).

margin: 0.5em 0 0.5em 1.6em; }
 * 1) contentSub, #contentSub2 {

3. Now, when #contentSub margin-left and with .dablinks padding-left are the same, remove blank spaces (&amp;nbsp;&amp;nbsp;) from #contentSub content.

In my opinion after these changes it looks much more elegant and consistent: http://i.imgur.com/LHrLbHg.png

--Piotr Jurkiewicz (talk) 00:14, 4 April 2014 (UTC)

New typography hasn't been tested in non-antialiased mode
Check out this screenshot: http://i.imgur.com/AJuubVC.png This is how the new typography renders by default on my system, where "Font smoothing" is disabled (since I prefer crisp text to blurry text). This screenshot is in Firefox, but it looks virtually the same in Chrome. Seems like the same problem font as used by Google+, where this annoying font is one of the things that puts me off.

Typography should work well everywhere, and if your preferred font doesn't work on machines where antialiasing or ClearType has been disabled, then you should detect that and fall back to a font that works.

Also: serif in headlines is unconventional, therefore looks unprofessional. —The preceding unsigned comment was added by Chaosdruid (talk • contribs) 00:57, 4 April 2014‎ (UTC)


 * Agree, it's bad without Cleartype. But have you got the newest version of Arimo or Liberation Sans? (See this thread) I found that my older Lib Sans looked like your screenshot when I turned Cleartype off. The latest version is better, but still not like MS Core fonts. About Serif headlines ... I beg to differ. It is not unprofessional. It is less conventional than the other way round, yes. But there are stylish magazines that use a sans for the body and serifs for headlines. If you have enough of a size difference to the body text, in my opinion, it looks very elegant. --87.157.78.253 22:09, 4 April 2014 (UTC)
 * Does it matter whether he's got the latest version or not? Should he have to change his version just because some smartarse at Wikipedia decided to fuck up the look of the thing?  Skinsmoke (talk) 23:54, 4 April 2014 (UTC)
 * That's all so true. I can't now visit without eyesink any Wikimedia project where I haven't turned IT out; I don't know how to turn atialiasing on, neither I want to on some older machines where I have no extra flops; and, finally, I don't like or at least am not used to this tiny square font. Why not to rely on default user's fonts? For rare glyphs, placing somewhere on a page a button "apply Unicode font to the content" is better than mutilating millions of other pages. Ignatus (talk) 18:04, 5 April 2014 (UTC)

Voting for implementing new typography
Hi

Were is the page to vote on using the beta typo across all wikis?

Where is the page asking us if we want it made permanent?

Are there any Rfcs ongoing about whether or not we wanted this forced on us?

Who took the decision to implement? (If not the editors, then why were we not consulted?) Chaosdruid (talk) 00:57, 4 April 2014 (UTC)


 * Up, there should be a voting for it. --Piotr Jurkiewicz (talk) 01:15, 4 April 2014 (UTC)
 * I would definitely vote for NO... Arvedui89 (talk) 06:50, 4 April 2014 (UTC)
 * Absolutely agree. Apparently there was discussion over the past months, when this was a beta feature. I don't use beta features and when I edit Wikipedia, I am more concerned with actual content. However, I think such a fundamental change should have been much more publicized before going live. Wikipedia has a notification system for registered users, registered users have e-mail addresses that could have been used for a newsletter asking for input, there could have been a banner and so on. Had I been aware of this change beforehand, I would have given my opinion sooner. I did it now (here and on the poll) but I have the inkling it's not gonna change much now that the new style has gone live. --Destruktor5000 (talk) 14:37, 4 April 2014 (UTC)

This is what it looks like for me
http://imgur.com/zjjDnRs

That's plainly different from the example images. It also makes my eyes hurt after reading a couple paragraphs. 108.70.132.28 01:37, 4 April 2014 (UTC)
 * What browser/OS are you using? (See also the section below, if you'd like to investigate further.) Thanks for including a screenshot. :) –Quiddity (talk) 21:23, 4 April 2014 (UTC)

Typeface
A number of people asked that any sans face used should distinguish between l and I (be legible). Ubuntu and MS Trebuchet do this, is there any reason they can't be used? Rich Farmbrough 02:23, 4 April 2014 (UTC).

OpenType
Hi everybody. I have trouble visualizing the Linux Libertine font in Mac OS. It happens with font with OTF extension, the TTF works well. Maybe the OTF is not recognized because it is called Linux Libertine O. Can this be fixed? --Gusama Romero (talk) 03:00, 4 &lt;april&gt; 2014 (UTC)

Can some more free fonts in Korean also can selective?
Hello. I'm editor on Korean WP, and I saw your notice on our villiage pump.

As for Korean. There is good fonts for korean, which is distributed by Free copyright licences. For example, Nanum fonts(Nanum means 'share' in Korean), which is distributed by Open Font Licence 1.1. And these fonts shows better legibility than normal fonts like Gulim and Dotum. And Un fonts also serves in Open licences, but I think these fonts do not have good legibilities.

If this refresh project supports multiple selection of fonts, How's about Include Nanum fonts and some more open fonts in Wikimedia projects when using Korean? - Galadrien (talk) 12:42, 1 April 2014 (UTC)


 * Hi . I think it would be fine to write in Korean Wikipedia Common.css to refer to a different open source font. But as the FAQ notes, we're not actually having users download new fonts, we're only telling their browsers which fonts to use, if they already have it. So unless most readers or editors on Korean Wikipedia would already have the font on their system, there may not be much point in changing it. As a side note, I am also curious: do you think the serif font for page titles and section headers is okay in Korean? I know non-Latin scripts may look different with serifs. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   22:07, 2 April 2014 (UTC)

Um.. It maybe good, but At this point, em-size of English font and Korean font is different- so you have to think how to make balance for English and numeral decender and Korean baseline.

And, especially, printed materials in South Korea(And CJK printing culture also) do not uses serif fonts for main subject- they usually use san-serif as subject, then use serif for main contents. So you can make think about make changes for CJK languages. - Galadrien (talk) 02:52, 4 &lt;april&gt; 2014 (UTC)

I uploaded the sample of 'problems' in my wiki. Please check the circles especially. - Galadrien (talk) 03:05, 4 &lt;april&gt; 2014 (UTC)

위키백과:사랑방 (기술)/2014년 4월#문서 제목 서체에 대해 also talking about this problems. - Galadrien (talk) 03:16, 4 &lt;april&gt; 2014 (UTC)

Height/width issue & Russian wiki issues (ST vs CTT, СГT, 1234567890)
There is something very bad with new font: it changes height/width ratio of chracters (or text block?) from one size to another. My calculations show 13 % ratio differences for my usual height in Chrome (10, I assume) and two zoom-clicks higher (12, I assume). Subjectively, usual font look much wider than before, 11 is ok, but 12 is narrow.

Also there are worse problems for cyrillic fonts. In 10 bold italic (sometimes italic only), character "и" is rendered one or two pixels shorter than others (may be local browser/OS problem), check: абвпипабв, абвпипабв; and this new font is generally bad for cyrrilic; and tables (and all beautiful templates since they depend on tables) is sometimes have no enough space for one line text representaion (was fine before changes). *panic mode on* IT'S ALL RUINED!!!!!!!!*panic mode off* --Igel B TyMaHe (talk) 08:57, 4 April 2014 (UTC)




 * That's Georgia; it has "old-style" numerals. That's just how the font looks. — Edokter  ( talk ) — 12:44, 4 April 2014 (UTC)

Inconsistent font heights with Georgia for CJK
Can Georgia be dropped for CJK? In CJK typography, each character in a line is expected to be bounded by a virtual square. Latin numerals are widely used in CJK documents (it's even a norm in Japanese Wikipedia), and Georgia's presentation of Latin numerals with inconsistent height breaks this rule and gives unorthodox appearance there. Linux Libertine seems to be acceptable in this regard, but most Windows users see it fallbacked to Georgia. I'm aware that each wiki can override it, but I thought this issue has some universality. Speaking personally, using serif (or Ming/Mincho) for headings in Japanese seems ok to me. See also. whym (talk) 00:59, 5 April 2014 (UTC)
 * See - the differing heights for numbers are a feature of the Georgia typeface, and hence look equally odd in all languages/combinations! –Quiddity (talk) 03:51, 5 &lt;april&gt; 2014 (UTC)
 * Thanks for the link. It seems that at least capital Latin letters are comparable to CJK text in regard to the expectation of consistent height. whym (talk) 04:42, 5 April 2014 (UTC)
 * There is a way to force Georgia to use lining ('normal') numbers by using the following CSS:


 * Works on the newest browsers, so it's not perfect. If you do not want old-style numbers, you may simply have to change the font in Common.css. — Edokter  ( talk ) — 11:08, 5 April 2014 (UTC)

Article title and sections
Please look at 987654321 (I know it's red, just click). Numbers are unaligned, some up and some down. It's impossible to read them. Please use another font. --NaBUru38 (talk) 10:31, 4 April 2014 (UTC)
 * Not just unaligned, the 1 and 2 are distinctly different sized from the others. Horrible font form a readability standpoint. A comparison (Win7, FF28): http://imgur.com/Aglp3sk --167.236.64.4 11:39, 4 April 2014 (UTC)

1234567890

 * ''See also

different heights of numbers--Sasha Krotov (talk) 20:36, 4 April 2014 (UTC)
 * Compare to File:NewTypDesignForRussianWikipedia.jpg --Vegen451 (talk) 10:21, 4 April 2014 (UTC)

This is a feature of the en:Georgia (typeface), and I agree it's quite odd. It looks particularly strange for years in article titles, eg en:1984–85 NHL season, or mathematics related topics, eg en:142857 (number). –Quiddity (talk) 21:20, 4 April 2014 (UTC)


 * These are so-called en:Text figures. Georgia is designed as a book type, and these numerals make sense there. It's true that people aren't used to these on the web or in headlines. --87.157.78.253 21:59, 4 April 2014 (UTC)


 * And that's only one of the reasons Georgia was such a terrible choice of H1 H2 font in the recent typography disaster —WinTakeAll (talk) 03:44, 5 &lt;april&gt; 2014 (UTC)


 * Old-style numbers is good for book cover, allowable for plain text but look weird in headers. It's must be changed.--Tucvbif (talk) 12:09, 6 April 2014 (UTC)

Hebrew fonts
Many editors in the Hebrew Wikipedia don't seem to be happy of the change and have opted for reverting it.

Someone wrote a gadget that sets fonts back to sans-serif and reverts the change of font sizes. It is not the default, but seems to be welcomed (discussion in hewiki - Hebrew).

I'm not an expert of typography, but right now the serif fonts used don't look good in Hebrew: Georgia does not seem to have a Hebrew script, and the Hebrew scripts of both Linux Libertine (on my Linux system) and Times New Roman (on Windows systems) don't look good enough. I'm playing now with David (availble on most Hebrew Windows systems. On Linux: available from the Culmus fonts, IIRC). But naturally it does not have the coverage of Linux Libertine and Times New Roman. Tzafrir (talk) 16:15, 4 April 2014 (UTC)
 * the new design doesn't work for Hebrew. i don't think u can treat such different set of signs (languages) the same. if u check the new Hebrew sets of titles u'll see it. level 3 title is not only ugly (and clearly doesn't merge with the shape and flow of the other titles) but is much more dominant and outstanding then the higher ones - so no aesthetics and bad representation of hierarchy = bad GUI. it seems each language should have its own design or localisation. at least change Hebrew level 3 font design. tnx Dalilonim (talk) 19:56, 4 April 2014 (UTC)
 * Tzafrir & Dalilonim, going to the page that you linked to and not seeing any readability or rendering issues. Can you post a screen shot of the issue since we can't reproduce it? Thanks!Jaredzimmerman (WMF) (talk) 23:50, 4 April 2014 (UTC)
 * I'll note that I'm personally mostly happy with the change, with the sole exception of the title font. Hanay complained about the same issue below. I use a Linux system and therefore cannot produce a screenshot of Times New Roman on Windows. My system is Debian Wheezy (7.0) running IceWeasel 24. In hewiki I set the title font to David (provided on my system by the Culmus package, but is also a high quality Hebrew font on Windows system. It also happens to be the font used for the logo of the hewiki) and I'm happy with it. Here is the default and with David font. Tzafrir (talk) 12:50, 5 April 2014 (UTC)
 * i uploaded several screenshots to show differences between the verses (not the best quality but hopefully good enough). one is the new and the other is with the gadget (if the gadget undo all changes we can see that as the old version). the files:
 * i think they cover the main issues. font design, size and proportion change in zooming, titles.. Dalilonim (talk) 13:39, 5 April 2014 (UTC)
 * Note that Dalilonim's first pair is regarding the daily quote from the main page. That quote (and some other templates) use the CSS style hebrewQuote (IIRC), which sets the font to David. This is not related to the recent changes. The gadget she refers to seems to explicitly set the font to sans, overriding the usage of David in those templates (or maybe I miss something and the recent changes did change this font to some people?) Tzafrir (talk) 17:21, 5 April 2014 (UTC)
 * i dono how it affected each user, but i see many differences. as i experience it, its not unified enough, titles font changes and breaks the general pleasantness, clarity of text has been lost (as with the quotes and in general - i think this aspect is really important cause we donot serve only 12:12 sight people. as 'boring' as the previous font might look, it is more clear and readable), with the change of zoom there's a total lost of proportion. and in 'normal' zoom the content text is too large and catches too much space. maybe there r more things that need improvement.
 * a general question, isn't that something hebrew wiki needs to solve? after all we r the hebrew readers/writers. there r general changes that can be made in the design, but in some areas its the specific language signs that need to be considered. hebrew and english font might bare the same name (type), and share some decorative qualities but beside that they r totaly different and have plenty of qualities they'll never share... Dalilonim (talk) 22:18, 5 April 2014 (UTC)

The new font in Hebrew: Times New Roman
The community in Hebrew wiki is very un happy with the new font Times New Roman. It looks not good in Hebrew. I would like to know who choose this font? Did an Hebrew reader was a part of the team who made the decision? and what is need to be done to go back to the old font?

In Hebrew wiki we already have a gadget that take us  back to the old design. Thanks Hanay (talk) 04:37, 5 April 2014 (UTC)
 * As a Hebrew-wikipedian I agree with Hanay. The Times New Roman font doesn't look nice in Hebrew. The new design also caused several other problems, as some wikipedians have reported in our village pump. We will really appreciate if if the new changes will be cancelled. Mr._W
 * there's already a paragraph above referring to hebrew font problems - Talk:Typography refresh . i think we should stick to one trade. Dalilonim (talk) 23:33, 5 April 2014 (UTC)

About troubles include IE's rendering error in Japanese Wikipedia
Hello. This new font setting bring bad situation in Japanese Wikipedia. (Discussion )
 * 1) Old versioned Internet Explorer (IE8, IE9, IE10) render wrong.  (mixed serif and san-serif at random, mixed Japanese letters and Korean letters at random)  (Screenshot : )
 * 2) We normally use Asian serif fonts (Mincho) for main contents and san-serif (Gothic) for title letters, or often use the same font for both. Because new typography is reversed, readability for people in some Asian country is lost.
 * 3) Old style numerals of Georgia font damages Japanese readability. Because the baseline of all Japanese letters are straight, Almost Japanese unfamiliar with Georgia font, therefore regard texts include Japanese original letters and Georgia's numericals as incorrect text lendering. (screenshot : )
 * 4) Not only Wikipedia, but also other Wiki sites, have these same problems. And perhaps many Asian countries, too (in these countries, 2byte letter fonts, such as Chinese Kanji, Korean Kanji and Hangul, Japanese Kanji and Kana and so on, are used with 1byte letter fonts). We are going to introduce new local css in Japanese Wikipedia, but this way for only each community isn't a efficient solution against these problems.

Especially, wrong serif rendering on IE is very serious. Please rollback to previous font-family setting (all elements "san-serif"), as soon as possible.

However, some of us have a high opinion of new typograpy except but a few problems relating to "font-family" setting. And We hope for the best solution to achieve the requirements, high readability, consistency, availability and accessibility for all people.

We are collecting more opinions and reports include petition signatures from Jpapanese Wikipedia editors about this matter. Thank you. --ディー・エム (talk) 05:57, 6 April 2014 (UTC)

French portal list
Hi, better to look at this French page than a long explanation : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_122301.jpg. --Salix (talk) 10:31, 4 April 2014 (UTC)


 * An admin needs to add  to all H2 headers on that page. —  Edokter  ( talk ) — 12:44, 4 April 2014 (UTC)


 * I [//fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Titre_section&diff=prev&oldid=102625124 fixed] the local template. Not sure why there is a bug for this. — Edokter  ( talk ) — 13:35, 4 April 2014 (UTC)
 * Thanks Edokter. Now it looks ok for me. --Salix (talk) 17:06, 4 April 2014 (UTC)
 * Oops Edokter, some users are still complaining, it's no fixed on wordwrap for small screens : . Any idea ? --Salix (talk) 18:59, 4 April 2014 (UTC)
 * , Not much I can do about that... Make the font smaller, or make it sans-serif again (as it was designed for that). Tell me if you want that. — Edokter  ( talk ) — 19:38, 4 April 2014 (UTC)
 * Because of 8 inches screen users complaining, could you please come back to the previous font for this kind of title ? --Salix (talk) 20:54, 4 April 2014 (UTC)
 * The headers now use sans-serif again. I hope that fixes it. — Edokter  ( talk ) — 21:10, 4 April 2014 (UTC)
 * Thanks. I'm waiting for a feed back from my small screen users, but it's getting late in France... --Salix (talk) 21:26, 4 April 2014 (UTC)
 * According to them, it seems to be better, but again a little bit too large compared to the original state. --Salix (talk) 22:43, 4 April 2014 (UTC)
 * (←) That is because the overall font size is bigger now. Other templates may have the same problem. I'll let the local template experts handle this further. — Edokter  ( talk ) — 23:50, 4 April 2014 (UTC)

Formal Beta status (or a dashboard)
This feature was released to all wikis. It means it was turned on. But I don't find it useful to remove it from beta tab then, as it has nice big fat buttons where people can provide feedback, as many of them would like to do after you turn it on. Gryllida 11:34, 4 April 2014 (UTC)

Recently beta
If you don't consider it beta, please add a list of 'recently beta' features to the beta tab, with a note that they were deployed. Gryllida 11:34, 4 April 2014 (UTC)

Show Deploy time/plan in the beta tab
For each of the beta features, please also show the deploy plan for current wiki, if it exists. Gryllida 11:34, 4 April 2014 (UTC)


 * Mistakenly posted to the general Beta Features talk page

Please read this note and participate, by filing bugs in bugzilla and setting them a reasonable priority. Thanks. Gryllida 11:36, 4 April 2014 (UTC)

Middle dot with Liberation Sans
The middle dot disapears with Liberation Sans in italics. This affects specially in Catalan language as it is used in the group "l·l" (italics l·l). For example, at Interpunct I see "e.g. cel la" instead of "e.g. cel·la". --Vriullop (talk) 14:29, 4 April 2014 (UTC)
 * Reported in bugzilla.redhat. --Vriullop (talk) 16:36, 4 April 2014 (UTC)

How to determine which Font are being used in your Browser?

 * In Google Chrome, install WhatFont chrome extension to easily determine what font is being used on your computer when browsing each website. • Sbmeirow  •  Talk  •  16:36, 4 April 2014 (UTC)
 * See Typography refresh/Font choice/Test for instructions on how to use the (Chrome/Firefox) default webdev "Inspector" tool. –Quiddity (talk) 19:23, 4 April 2014 (UTC)
 * And what about IE, Opera, Safari, and other minor browsers?! -- Jokes_Free4Me (talk) 01:01, 7 April 2014 (UTC)

Where to download Fonts?

 * Download Linux Libertine fonts. • Sbmeirow  •  Talk  •  16:36, 4 April 2014 (UTC)
 * Download Liberation fonts. — Edokter  ( talk ) — 19:48, 4 April 2014 (UTC)
 * Download Arimo fonts --217.226.201.21 13:47, 5 April 2014 (UTC)

Another technical approach
It is clear there are some unwanted side effects. This is a result of trying to target all platforms in a single font stack. I really wish there was some mechanism where we could provide each platform (OS) with their own fontstack, so we could avoid fonts ending up being displayed on a system those fonts were never intended for. Does LESS, ULS, ResourceLoader or any ohter component have any such mechanism? — Edokter  ( talk ) — 19:43, 4 April 2014 (UTC)


 * That would be very cool. But if it's not possible or feasible, I would vote for a return of boring Arial to the body text. There are too many problems that can't be swept under the rug (especially the bad looks without anti-aliasing and bad (Polish) diacritics). I would put the text at 1em, and have a line-height of 1.5em. I believe we can't have a font that fails without anti-aliasing. Right now, I believe there are still too many people who don't use anti-aliasing, for any reason. I checked a number of fonts, and it's no surprise that only MS own core fonts still look good if cleartype is turned off... So if it needs to be something else than Arial, Trebuchet and Georgia are also well distributed on Macs. Georgia looks good in long texts, even at small sizes! For Linux, we could keep Arimo / Liberation Sans and Libertine / Lib Serif / Tinos in the stack. --87.157.78.253 23:05, 4 April 2014 (UTC)

Just another idea: Can CSS be loaded after a cookie has been checked? If that's possible, we could have a style-switching button or menu. It would set a cookie so that the choice gets remembered. --87.157.69.73 20:40, 6 April 2014 (UTC)

non-readable
Please return to previos typography, the new one is non-redable --Vegen451 (talk) 07:31, 4 April 2014 (UTC)
 * Please explain the readability issues you face? Inlcluding your OS and Browser would help us address your issues. Thanks Vibhabamba (talk) 23:37, 4 April 2014 (UTC)

Line height bug?
Line-height seems to be a mess, starting with 1.6em for div#content, then 1.5em for #bodyContent and ending in 'inherit' for 'div@content p'. Has this been thought through? — Edokter  ( talk ) — 14:01, 15 March 2014 (UTC)
 * There is a bug out for this and we are looking into it. Ideally the line height is a bit more open. A core setting over-rides the line height change right now. Vibhabamba (talk) 19:11, 28 March 2014 (UTC)
 * I see the problem now; the 1.6em lineheight shoud be set for, not  . —  Edokter  ( talk ) — 20:15, 3 April 2014 (UTC)
 * Thank you for taking the time to scrub this. Can you include screenshots of what you are seeing. Vibhabamba (talk) 23:43, 4 April 2014 (UTC)
 * It wouldn't show much. Suffice to say, basic body line-height is still 1.5em and not the intended 1.6em. — Edokter  ( talk ) — 23:53, 4 April 2014 (UTC)
 * ( talk ) We can file a bug for this. Vibhabamba (talk) 00:48, 5 April 2014 (UTC)
 * I thought you said there was already a bug for this. Do you have a bug# ? — Edokter  ( talk ) — 00:52, 5 April 2014 (UTC)

My eyes are bleeding
Seriously, this new font is terrible. I can barely get through one sentence of an article without my eyes getting confused. The old font was just fine the way it was, but this new one is simply painful, nigh unreadable. Is there any way for me to revert to the old Wikipedia font? --Samuel Peoples (talk) 00:28, 5 April 2014 (UTC)

Please explain the readability issues you face? Including your OS and Browser would help us address your issues. Thanks Vibhabamba (talk) 00:43, 5 April 2014 (UTC)


 * Actually, as of an hour ago, the font seems to have changed again on Wikipedia. It's still different from the old font, but it's now larger than it was an hour or so ago, and seems more readable. --Samuel Peoples (talk) 02:27, 5 &lt;april&gt; 2014 (UTC)


 * I just noticed this and I want to restore the new type. However it is not appearing in my beta preferences.  This MediaWiki page is displaying with the new type and I would like to make Wikipedia pages do the same as I love the changes. - User:Shiftchange


 * As it is now, the normal text is all in bold in various browsers on Windows 7 and 8 and in any Wikipedia by country I checked.
 * Wiki20140405 ie.png Wiki20140405 gc.png Wiki20140405 ff.png
 * I do not understand how such a major change could be made without regard for how it will look on different browsers and operating systems. It basically messed up every country's Wikipedia on the planet. Cush (talk) 19:46, 5 April 2014 (UTC)

How do we know how many people opt out?
There is some considerable feedback from the community. I personally don't like this change at all, but let's be constructive: how do we know how many people opted out of this change? Couldn't this be made a "Beta feature" on by default (if you insist), but it is possible to turn if off and quantify (say, among most recently active contibutors)? « Saper // talk » 16:12, 5 April 2014 (UTC)
 * We can measure gadget use at en:Wikipedia:Database reports/User preferences, but it is not update very often. — Edokter  ( talk ) — 17:38, 5 April 2014 (UTC)
 * Thanks. This works only for those using the gadget (now available on enwiki and others), but not if anybody applied manual workaround as presented on top of this page. « Saper // talk »  21:53, 5 April 2014 (UTC)
 * We do have live gadget data, see ~liangent/gadget_usage/enwiki_p/. For a complete measure one should "grep" the dumps for css user pages and to count how many new monobook users we got... We can't know how many tell browsers to ignore site-specific font settings though. --Nemo 22:21, 6 April 2014 (UTC)

Dyslexie & wrong use of serif/sansserif
Two comments: Just my 2 cents. Tjako (talk) 21:23, 5 April 2014 (UTC)
 * 1) Updating fonts could be a great opportunity to choose for use of special dyslexie fonts, which are more easily readable for all people. These fonts are designed for ease of use and look great in print as well as on screen.
 * 2) A mix of serif (in headings) and sans serif (in body and smaller headings) is bad typography, as most experts on layout and typography will tell you.
 * I can only agree that the mix of serif/sanserif fonts is a bad idea and probably the most important reason for people to opt out from this otherwise quite sane change (say I who use Monobook most of the time). /Esquilo (talk) 16:20, 6 April 2014 (UTC)

"BUY NOW BUY NOW" hints a ploy. Seriously, the dyslexie font wants  money  and the font is hard to read, worse than Arimo.

Arial and verdana are  free  and much much better to read.

Freedom and freeness.
 * It's already possible to use a free/open font called "OpenDyslexic" on Wikipedia. Go to a Wikipedia article (e.g. Elephant), go to the left side and scroll down to the languages list. Right next to the top of the "languages" there is a gear icon. If you select the gear icon, there will be two tabs at the top of a window that pops up. Select "Fonts", and then select "Download fonts when needed". This will create a drop-down menu for fonts. There should be at least two options: System font and OpenDyslexic. Then click the "apply" button. πr2</b> (t</b> • c</b>) 23:53, 6 April 2014 (UTC)

Why not use browser defaults?
Would Wikipedia be any worse if the font was "serif" or "sans_serif"? It would lead to some variation depending on the browser defaults. But I assume most browsers use a font that is well readable as default. Could there be problems with non-latin scripts? A browser in China or Korea would have a sensible default font for their language -- or am I mistaken? So we would not have to worry about those things at all. The CSS would only need to define sensible sizes and spacings. These should also be no problem if the units are "em". A line-height of 1.5 or 1.6em would always look good. A margin of 2em would always be well visible.

Is there a list of factory defaults for sans_serif and serif in different browsers? On Win7 most browsers seems to have Arial/Times New Roman. Which is OK, readability-wise and also when it comes to Unicode coverage. And if a user hates these two, it's easy to change for everyone. Sounds like a win-win to me! Btw, if you want to try fonts quickly without starting the web-inspector tools, the "Soma FontFriend" bookmarklet is helpful. http://somadesign.ca/projects/fontfriend/ --87.157.69.73 21:13, 6 April 2014 (UTC)


 * Yes, we have a list. Before this change, Vector fonts were like this: Typography refresh/Font choice. Conclusion of public beta testing has always been that just "sans-serif" (i.e. browser defaults) should be used, see Typography_refresh/Font_choice/Test. --Nemo 22:17, 6 April 2014 (UTC)

April joke?
Please tell me, that changing the headlines to a serife font is an Aril's fool joke only! --Matthiasb (talk) 10:45, 1 April 2014 (UTC)


 * it is not. If you're curious about why this choice was made, there's a couple explanations at "Why are we using serif fonts for the headings?" on the main FAQ on Typography refresh. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   21:41, 2 April 2014 (UTC)


 * It does indeed look jokey. I can't believe this change has been pushed through. What a travesty. Texugo (talk) 11:36, 3 April 2014 (UTC)


 * It's a shame. ;-( --Stobaios (talk) 14:40, 4 April 2014 (UTC)

serif vs sans serif
I think, mixing the font families in this way was a very bad idea, and led to a mess in the typography. And so on... Well, the MediaWiki has changed just in the opposite direction: the h1 and h2 titles are serifs (normally: sans-serif), the text is sans-serif (normally: serif), the h3 and &lt;b> titles are sans-serif to mess with h1 and h2 titles (examples are common on wiktionaries: here). Moreover, the fonts chosen are not very popular ("Linux Libertine" as the first choice, when most readers use Windows?), so the unification is illusory. I suggest rethinking the change. At the moment, I switched it off on Polish Wiktionary. Best regards, Olaf 07:38, 2 April 2014 (UTC)
 * A quote from the Best Practices of Combining Typefaces article: "By far the most popular principle for creating typeface combinations is to pair a sans serif header typeface with a serif body typeface. This is a classic combination, and it’s almost impossible to get wrong."
 * A quote from a manual on creating manuals book: "When using two different fonts, use a sans serif font for the header and a serif font for the text".
 * A quote from another manual: "Sans-serif are the best used for headlines (...) serif fonts are the best used for longer paragraphes of text"
 * A quote from another book : "It is generally agreed, that serif styles are more appropriate for the body of the poem itself, while the sans-serif styles can be used, if you wish to do so, for titles".
 * Body copy is long and dense unlike titles. It causes issues for dyslexic users which interferes with our goal for accessibility. https://en.wikipedia.org/wiki/Dyslexia_interventions. Also Smashing Magazine does not take context like short vs long form content into account. They are also discussing very specific font combinations, rather than pro's and con's of serif's in general. Vibhabamba (talk) 22:30, 2 April 2014 (UTC)
 * +1 for the serif vs sans serif part. That's the complete opposite of what decades of professional typesetting has shown to be best practice. Even the guide you link in the FAQ to explain why you are using serif fonts for the headings says serif for the body, sans-serif for the headings. I would very much welcome changing the body font to serif for better readability and headings to sans-serif for the reasons you mention in the FAQ, but this is – in my opinion – not a good idea. --El Grafo (talk) 09:51, 2 April 2014 (UTC)
 * As stated above, using a serif font for body copy will hurt a class of our users. This can be alleviated to some extent with significantly increased Kerning + Leading and restricted measure. Howevere those changes are much larger and don't feel like strong or balanced decisions for a varied user base. Personally I would love that, But then you and I aren't the only people reading Wikipedia. Vibhabamba (talk) 22:33, 2 April 2014 (UTC)
 * As stated above as well. The mixed fonts look dilettantish and amateurish. -- DerFussi (talk) 06:59, 3 April 2014 (UTC)
 * See also the discussion above. It definitely needs to be reconsidered and, I'd say, changed back to all sans serif &mdash; serif fonts on webpages look amateurish in the first place, and the current configuration with serif headers and sans serif body looks absurdly so. Texugo (talk) 11:39, 2 April 2014 (UTC)
 * There are many links and references in en:Wikipedia talk:Wikipedia Signpost/2014-03-26/Op-ed (about halfway down), discussing the research and 'rules' regarding when to use, and when to mix, serif and sans-serif. That should answer most of the questions in this thread. HTH. –Quiddity (talk) 22:49, 2 April 2014 (UTC)
 * Thanks for the link, but an explanation does not help it look less crappy to a lot of us. I am not interested in having the change explained away; I'm interested in consolidating support for changing it back. Whatever advantage you think may be gained by further highlighting only the H1 and H2 headers with a jarringly more formal looking font is outweighed by the disadvantage of lending a mediocre, unprofessional, bloggish look to every page. The discussion you pointed to even evidences more people who agree with us. As Olaf pointed out, mixing serif and sans fonts is sometimes done, but this is doing it wrong - it's completely backwards and it flies in the face of all standard typesetting wisdom and aesthetic refinement in general. Texugo (talk) 11:25, 3 April 2014 (UTC)

Strange fonts
Why the headers are different with two equal marks and three? == produces serif font, === sans-serif. It looks strange. It may be no problem on Wikipedias, but Wiktionaries have many level three subtitles. The combination of serif header and sans-serif content is unusual, I can't find any other web page using it in this way. Most of them uses sans-serif fonts everywhere, because they are better for screens with small resolution. Some of them use serif fonts everywhere because they are considered more readable when the resolution is sufficient. Some follows the general typographic principle of sans-serif titles and serif content (it's not the best solution however, beacuse sometimes there are subheaders made by the bold tag, so you should have serif fonts everywhere or sans-serif everywhere for consistency). You have chosen the fourth way, the most unusual one, with serif titles, and sans-serif content. Why? What are the reasons? Was there any voting about the change? How can we rollback the changes? Flammadore (talk) 09:50, 2 April 2014 (UTC)
 * Hi, Flammadore the FAQ explains the rationale for serif vs san serif, and when we use one vs the other. You'll see that the page title and H1 use serif type to distinguish them from sub-headings. From looking at wikitionary this seems to make sense in that context as well. Jaredzimmerman (WMF) (talk) 22:14, 2 April 2014 (UTC)
 * I'm sorry, that explanation is bunk. Combining serif and sans-serif may not be "an unusual or original idea" but combining them in this particular way definitely is unusual and original, and not in any good way. Serif for headers on sans serif text is already backwards enough; having mixed fonts for headers is yet another layer of completely unnecessary strangeness. The explanation you point to does nothing to establish that there was, in the first place, any need for more "contrast and distinction". Who decided that it just wasn't enough to have headers already in different sizes, in bold, and with a separator line under them, that there was this burning need for even more contrast, a need so great that it was worth sacrificing our aesthetic harmony to get it? Your "solution" is far worse than any supposed problem you were trying to fix. It was never broken in the first place, and now the result is that headers now stand out too much, in an undesirable way, like sore thumbs. Texugo (talk) 13:07, 3 April 2014 (UTC)
 * You're completely right. Serif text + san-serif head/title is a bit strange but acceptable, but Title should be clear, sharp. Big, bolded serif text is anything but sharp. Arvedui89 (talk) 12:57, 4 April 2014 (UTC)
 * The fonts seeme to be bigger now. The fact affects existing articles and should be reconsidered. Some of the tabs on infoboxes don't fit the to infobox size any longer and look crappy now. I don't feel like looking through all our articles now. -- DerFussi (talk) 08:51, 4 April 2014 (UTC)