Talk:Typography refresh/Archive 3

Latest release

Hi everyone,

We've just updated the beta feature with bug fixes and a new font stack, the details of which are reflected on the main document here. (Not everything is rolled out across wikis, but it is present here on mediawiki.org, and will be everywhere by the end of next week.).

Other than the bug fixes and new font stack, I want to bring up the idea of releasing a permanent version of this beta feature that does not including elements such as:

1. The Table of Contents redesign
2. The new, minimalist thumbnail style
3. The new blockquote style
4. Removal of custom icons for external links, based on file type (e.g. a music symbol for .ogg files)

These changes are valuable in that they help remove visual cruft and increase focus on the text of pages. I personally like several of them. However, they also require a lot more testing and the previous discussions brought up numerous issues that remain unresolved. I think the conservative approach here is to submit them for review separately, if at all, and take in to account more edge cases (like wikis that heavily use templates for blockquotes, or the fact that wikitext markup for thumbs and frames would be made redundant by removing all frame styles from thumbs). Thoughts?

Also, many thanks to Vibhabamba, Quiddity, and others who wrote the bulk of the new FAQ and summary of changes. I highly encourage everyone to read it. Steven Walling (WMF) • talk 17:17, 14 March 2014 (UTC)

Update: no one seems to be much in strong favor of keeping the four things mentioned above, and further down in comments people have continued to bring up issues with some of them. Thus, we're going to remove them. Steven Walling (WMF) • talk 21:06, 21 March 2014 (UTC)

Only system font

Resolved

"Helvetica is the only default system font that properly renders glyphs in non-latin scripts", seriously? Either "default" or "system font" here must have some very specific definition that I'm unaware of, could you clarify? --Nemo 17:46, 14 March 2014 (UTC)

Is "browser default sans-serif" precise enough for your taste? Steven Walling (WMF) • talk 17:49, 14 March 2014 (UTC)

Oh, this is unexpected. How do the browsers' defaults matter? How many browsers set their own defaults (overriding the OS)? --Nemo 18:02, 14 March 2014 (UTC)

The browser default sans matters because that's what we set in Vector core currently, without the new stack in place. Steven Walling (WMF) • talk 18:11, 14 March 2014 (UTC)

Ok, so that's Typography_refresh/Font_choice#Current_situation. Are you saying you tried to pick a font among those? Helvetica is the current default only in iOS and MacOS, according to that list. All the others except Roboto (i.e. Arial, DejaVu Sans, Liberation Sans) are definitely ok in non-latin scripts. --Nemo 18:27, 14 March 2014 (UTC)

The section is getting a bit better. I still don't understand «the fonts that most browsers use in this condition do not account for proper rendering of glyphs, pairs, and diacritical marks at small sizes»: even according to the table in the subpage, scores of Arial, DejaVu Sans, Liberation Sans are very similar (8 vs. 10) and some upstream bugs have been fixed in a matter of days after being reported. --Nemo 19:03, 14 March 2014 (UTC)

The reasoning for Helvetica Neue

Resolved

Body copy (the main text of pages) has been set to "Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif". Could you please explain the reasoning for selecting Helvetica Neue and prioritize it over Helvetica?

According to the body font evaluation at Typography refresh/Font choice, plain Helvetica got a better general score. While Helvetica Neue seems to be 2 points more more "appropriate" (10 to 8 in terms of "readability, neutrality, and "authority"", relatively subjective factors), in technical terms (a factor that can be measured more objectively) Helvetica wins Helvetica Neue 10-1.

Helvetica is also as "appropriate" as Arial, and both look very similar. For all these reasons, wouldn't Helvetica serve better to the goals of this Typography refresh? (readability, consistency, availability, accessibility)--Qgil (talk) 19:23, 14 March 2014 (UTC)

Yeah this needs to be clarified. Steven Walling (WMF) • talk 20:56, 14 March 2014 (UTC)

I added some explanation with advice from Vibha. Steven Walling (WMF) • talk 03:27, 18 March 2014 (UTC)

Thoughts

Georgia on Linux

The FAQ states: Linux systems (perhaps ironically) do not recognize Linux Libertine nor Georgia.

According to this font survey, Georgia is installed on 70% of all Linux systems, so that statement is uneducated. Most Linux users have it installed throught the TTF-Fonts-Core package. However, it contains rather outdated fonts from when they were still freely available (until 2002), so they may lack essential Unicode support. It means that 70% may potentially see mis-rendered text in headers should they occur.

With that in mind, perhaps Georgia should be removed from the stack. — Edokter (talk) — 23:59, 14 March 2014 (UTC)

Having tested extensively on Ubuntu and Debian, I don't trust the accuracy of that source. Also, en:Core fonts for the Web:

However, these proprietary fonts (or some of them) are not distributed with some modern operating systems by default (e.g. in Android, Ubuntu, FreeBSD, OpenSolaris or some Symbian versions)[11][12][13][14][15][16][17][18][19] and they are substituted by other fonts (e.g. by free software fonts, such as Liberation fonts, Ghostscript fonts,[20] Droid fonts, DejaVu fonts and others).

So yes, users may easily install font packages that include Georgia, but we can't rely on the most popular Linux-based desktop operating systems having it installed by default. (The exception is Mint, which I haven't tested on.) Even if it was the case, we need to specify Georgia in the stack for OSX users at at least, who would otherwise get Times (which is undesirable). Steven Walling (WMF) • talk 22:37, 15 March 2014 (UTC)

They were never installed by default, but they were always available in their respective repositories. Why should you distrust this survey? The 70% figure is quite consistent throughout the web. — Edokter (talk) — 19:29, 17 March 2014 (UTC)

Linux Libertine

I don't like Linux Libertine. The x-height is far too low, which makes headers appear disproportionally small. In blockquotes, this is even more noticable. The difference between LL and Georgia also does not help consistency; Georgia appears almost 50% larger then LL.

Well since few users have it installed by default, I think the concerns are not something to worry about. You basically have to opt-in to using LL at this point in time. Steven Walling (WMF) • talk 22:38, 15 March 2014 (UTC)

It is a concern none the less... for those that have it installed (like me). Waiving the concerns due to low install base is once again ignoring the core goals of this beta, in this case consistency. It is a good font, but simply not suitable for headers. The x-height of H2 headers is almost no larger then the body font. — Edokter (talk) — 01:58, 16 March 2014 (UTC)

Serif

I do like the current body font very much. Why do we not expand on this font-family by using the same fonts for serif:

• Tinos, "Liberation Serif", "Times New Roman", Times, serif;

This ensures the same availability as the body font stack, ans they are part of the same font families.

Monospace

One thing I have missed is monospace. I think I'm not wrong if I say that most of us are quite bored with Courier New. So, we can expand even further:

• Cousine, "Liberation Mono", "DejaVu Sans Mono", Consolas, monospace;

— Edokter (talk) — 13:40, 15 March 2014 (UTC)

The truth is there is so little monospace styling on Wikimedia sites (and most wikis in general) that I'm not sure it's really a high priority. Steven Walling (WMF) • talk 03:29, 18 March 2014 (UTC)

Any text inside ‎<code>...‎</code> and ‎<pre>...‎</pre>, and any page with JavaScript. CSS or module code... There is a lot of monospace. — Edokter (talk) — 23:35, 18 March 2014 (UTC)

Also add <source> tags and possibly text in the WikiEditor's window itself. Monospace is used a lot in articles about computer science (to give snippets of code) and on help and project pages to explain Wikitext/Templates/etc. --Patrick87 (talk) 00:18, 19 March 2014 (UTC)

Certainly, but what is the rationale for trying to dictate specific font choices here? All Macs, Windows systems and *n*x boxes all already have one or more monospaced fonts installed by default, one of which will be used for this purpose, but they are not the same from system to system; there is no one single font that will typically be found on all of them, though Courier New is probably the most common. Like most Mac people, I use Monaco. I'm also a font horse, so I have most of the other fonts mentioned, and might have one or another of them installed at any given time, for one project or another; I wouldn't appreciate Wikipedia and especially it's editing fields suddenly changing appearance based on which extremely optional random fonts I'm running with any given time. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:42, 26 March 2014 (UTC)

What would be the rationale behind trying to dictate specific font choices for serif headings and sans-serif body text? All Macs, Windows systems and *n*x all already have one or more serif and sans-serif fonts installed by default.
Seriously, setting specific fonts is the whole point of typography refresh! If we "dictate" specific fonts at one point, we should "dictate" the same fonts throughout font styles. This way we can at least try to make sure to get a consistent look by using the same font family everywhere. I would totally prefer to not use a different font family for every font style (which Typography refresh currently achieves on my system: Georgia for headings, Libeeration Sans for body text, Courier New for monospaced text). Don't you think it would be nicer to have all font styles looking consistent? --Patrick87 (talk) 00:25, 27 March 2014 (UTC)

Line height bug?

It seems the font-size (0.875em) for #bodyContent is overruled by the default Vector declaration (0.8em). (I don't mind this bit, with the current stack, it is quite legible.) Also 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)

Forget the font-size; my own CSS was in the way. Line-height remains a problem though. — Edokter (talk) — 14:41, 16 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 #bodyContent, not div#content. — Edokter (talk) — 20:15, 3 April 2014 (UTC)

Giant quotation marks around blockquote

Resolved

The use of decorative large quotation marks for block quotes in Wikipedia is contrary to the Manual of Style (Wikipedia:Manual of Style#Block quotations), which reserves them for pull quotes only. A sensible rule, to avoid clutter on the page. – Tim riley (talk) 11:25, 15 March 2014 (UTC)

They're going to be removing the blockquote changes, per Steven's note at #Latest release. Hopefully a.s.a.p. to reduce this confusion ;) –Quiddity (talk) 20:33, 15 March 2014 (UTC)

I am very happy with the new Style. Especially math formulas within text look a lot better. However Quotations need to be improved. For example the one in w:de:Viskosität#Definition der Viskosität für newtonsche Flüssigkeiten. Most disturbing are the huge black quotation marks, which happen to be placed underneath (or even on top of?) a transparent image on the right, far away from the text. If necessary I can provide a screenshot.--Debenben (talk) 17:22, 21 March 2014 (UTC)

The blockquote styling is being removed, along with a few other elements, per Steven's comments up at #Latest release. (Some of them might be re-suggested as part of a different Beta Feature, in future months.) I believe those elements will be removed on next Thursday (possibly just on mediawiki.org for the first week, then everywhere else the week after). HTH. –Quiddity (talk) 17:54, 21 March 2014 (UTC)

Yes, the quotation marks in particular are annoying. Thanks for the report Debenben. Steven Walling (WMF) • talk 20:18, 21 March 2014 (UTC)

Thank you both. In case of a future redesign, I'd like to point out, that in German, quotation marks should be like „…“ and not “…”, see for example [1]. Maybe it just appears in the English style because of my browser settings, but it should be possible to always use the format that fits the wikipedia edition. If they stay big, I would prefer them not to be black, but gray or something less obtrusive.--Debenben (talk) 20:54, 21 March 2014 (UTC)

+1! Would have suggested exactly the same if it hadn't already been suggested. --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:04, 22 March 2014 (UTC)

Indeed. Those huge quotation marks are ridiculous, and don't make sense for lots of languages, not just German. Among other problems. They definitely should not "be re-suggested as part of a different Beta Feature, in future months". — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:35, 26 March 2014 (UTC)

No worries, quotation marks are translated at traslatewiki.net (just like the other messages) and I'm sure MediaWiki core devs will veto any change wishing to hardcode specific marks. --Nemo 12:04, 27 March 2014 (UTC)

Blockquotes

Screenshot of the bug

Looking at w:South American dreadnought race with the typography beta, the new quotemarks around blockquotes don't work very well with an image alongside them. In addition, the English Wikipedia's policies only allow for quotemarks when it is a pull quote (see eg w:Template:Cquote). Ed ^{[talk] [en:majestic titan]} 18:17, 30 March 2014 (UTC)

The blockquote changes will not be included in the typography refresh at this time. --Entlinkt (talk) 15:34, 31 March 2014 (UTC)

Thanks! Ed ^{[talk] [en:majestic titan]} 20:17, 1 April 2014 (UTC)

Mixing serif and sans serif faces

1. Using a serif face for block quotes is bad practice from the accessibility point of view. Screen text should all be in sans serif faces: see advice here and here
2. From the purely aesthetic angle, mixing serif and sans serif faces within the text looks messy and amateurish, though this is a matter of taste, I admit.
3. Having headers in a serif face is fine, and looks rather good, in fact. – Tim riley (talk) 11:25, 15 March 2014 (UTC)

They're going to be removing the blockquote changes, per Steven's note at #Latest release. Hopefully a.s.a.p. to reduce this confusion ;) –Quiddity (talk) 20:33, 15 March 2014 (UTC)

I actually think that it has been noted before in the discussion surrounding the typography refresh that some people would actually like to see the use of serif fonts for headings and sans-serif fonts for body text reversed, and I agree with this discussion. Serif fonts look — well, they look confusing, not to mention weird. — RandomDSdevel (talk) 20:51, 23 March 2014 (UTC)

I for one strenuously object to the use of serif headings, or any other serif font stuff, other than when it's being done deliberately at the content level (e.g. with inline style in the wikicode as. in w:en:Template:Xt). People who like serif fonts for Web reading can have their own stylesheets use them. Mingling serif and sans-serif looks awful, like someone in Public Relations 101 trying to design an ad. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:29, 26 March 2014 (UTC)

That's another reason why I hate the new serif headings!!! — RandomDSdevel (talk) 20:45, 27 March 2014 (UTC)

I'd like to add another voice saying how awful and amateurish it looks to mix serif and sans serif. It's a jarring contrast and it seriously needs to be reconsidered. Texugo (talk) 11:31, 2 April 2014 (UTC)

+1 Don't mix it! I agree. It looks dilettantish and amateurish. -- DerFussi (talk) 06:57, 3 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)

Matthiasb 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. Steven Walling (WMF) • 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.

• 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".

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

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 #Mixing serif and sans serif faces discussion above. It definitely needs to be reconsidered and, I'd say, changed back to all sans serif — 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)

Italic issues in Korean

Since most of the Korean fonts looks creepy in italic, there is a concensus to use it sparingly in kowiki, AFAIK. I have added an override to the local css.[2] Anyway, where can I keep track on such changes? (i.e. within the repository?) --PuzzletChung (talk) 12:02, 15 March 2014 (UTC)

@PuzzletChung: We have not changed the use of italics to increase them anywhere. If italics have been introduced anywhere new it shouldn't be a result of this beta feature. Steven Walling (WMF) • talk 20:55, 21 March 2014 (UTC)

@Steven (WMF): This is to do with these lines of code. That part is changing the Enwiki custom code in the "Hatnotes and disambiguation notices" section of en:MediaWiki:Common.css (which is presumably the only place it will get merged to). –Quiddity (talk) 23:16, 21 March 2014 (UTC)

responsive typography

Hi, thanks for yout hard work. I like the new version much better. But it has the same struggles like before: the font is to small on current displays and devices. I would like to point out to this topic again. Maybe we could invite the people form iA to share their thoughts on our challenges? (See http://ia.net/blog/responsive-typography-the-basics/ - they are also quite famous for making on of the best writing apps.) --Sebaso (talk) 09:06, 16 March 2014 (UTC)

@Sebaso: There were 2 previous responsive ideas that have been pointed to, http://simplefocus.com/flowtype/ and http://webdesign.maratz.com/lab/responsivetypography/realtime/ - the 2nd one is (imo) a purely experimental toy and would drive me crazy, but the first one has possibilities if adapted to lower the maximum, and provide user-controls rather than basing it on window-size.

However, as Vibhabamba wrote [now in /archive 2], "Once we have a persistent header we plan to add font controls so a user can start with a default optimum but adjust the font size based on their screen size. Vibhabamba (talk) 23:03, 5 February 2014 (UTC)" - which I think is the best solution. Perhaps a mix between the flowtype idea, and the typesize adjuster that sites like NYTimes (screenshot) use. That would allow the default to be the standard that suits the majority, and allow users who want something large (or smaller) to decide for themselves. [I gather we have a lot of users who browse the web with everything zoomed in (or using a screenmagnifier), but they each want different percentages of text enlargement.] HTH. –Quiddity (talk) 18:41, 16 March 2014 (UTC)

Thx! But even non-responsive its to small. :( --Sebaso (talk) 20:29, 16 March 2014 (UTC)

Could you make it so that paragraph widths would be editable as well? Everyone seems to be hating on the 700px (I think that's how wide it is) limit. — RandomDSdevel (talk) 20:47, 27 March 2014 (UTC)

licence bug

The mediaviews says "cc-by-sa _3_.0", also if another version is used. --Sebaso (talk) 20:03, 16 March 2014 (UTC)

This is not related to this feature. Steven Walling (WMF) • talk 20:54, 21 March 2014 (UTC)

Liberation Sans on Windows

As I have Liberation Sans installed on Windows (e.g. to create SVGs for Commons) this font is now used for body text with the new font stack. While the font might be designed well in principle it turns out to be plainly inferior technically when compared to Arial, notably

• Hinting is inferior which makes many glyphs look bad, especially for bold text and numbers.
• Letter-spacing is too small when rendered at small sizes which makes navigational elements at the top/left of the page less legible (might also be dependent on hinting)
• x-height is lower (e.g. 7px compared to 8px with Arial at the default font size of 14px I'm seeing) which makes the font look smaller overall. Actually I like the lower x-height but it appears as being about the same size as Arial without typography refresh (e.g. 12.8px font size). Therefore this lowers the gain achieved by increasing the font size which should be considered (but probably is OK).

Especially the hinting needs to be fixed in my opinion if Liberation Sans should be selected to be part of the default font stack. I hope this can be achieved as you write "Liberation Sans has a respectable amount of ubiquity and it is produced by Red Hat who can help us with addressing rendering issues." on the front page. --Patrick87 (talk) 22:14, 18 March 2014 (UTC)

On the other hand, it's looking very good indeed on my Linux desktop. -- The Anome (talk) 11:30, 21 March 2014 (UTC)

I'm not saying that it shouldn't be used at all. But currently it's just not fit for Windows in my opinion and I assume there was no workable solution to deliver different OSs with different font stacks. Since degrading readability for some Windows users only to get on other systems what is wanted is not a workable option, the best possibility would probably be to fix the hinting. Many other applications would profit from that, too, so it would be a worthwhile investment. --Patrick87 (talk) 16:04, 21 March 2014 (UTC)

I can agree that Liberation Sans for English-speaking users may not be ideal on Windows. However, the case where a Windows user would have it installed is very rare, isn't it? The vast majority of Windows users will get Arial still, so in this case I'd recommend you use your personal CSS to use that too if you want. Steven Walling (WMF) • talk 20:54, 21 March 2014 (UTC)

The Liberation font family is distributed as part of LibreOffice. Therefore I don't think the case is as rare as one might assume.
Apart from that I actually like the look of Liberation Sans. I never really found Arial to be a nice font but it is at least a very clear font. Liberation would be nice and clear if it wasn't for it's technical limitations. That's why I personally would love to use it if the hinting was OK. --Patrick87 (talk) 21:30, 21 March 2014 (UTC)

Just making sure... you do have the 2.0 version installed? That release has some significant improvement in hinting. I do agree there are some minor hinting glitches in the bold variant. As far as rarity goes... Arial also has a wide install base on Linux desktops, which I have no idea how it renders. It simply means we have to make a choice in which font to pick first. There will always be fonts that are 'out of place' on one system or the other. — Edokter (talk) — 21:52, 21 March 2014 (UTC)

Yes, I've got version 2.00.1 (that's also the version that comes bundled with LibreOffice). I accept that not every font renders well an all systems – but if we promote a free font (or even a non-free font) by including it in a fixed font stack we should make sure that at least it doesn't decrease legibility on some systems. --Patrick87 (talk) 22:32, 21 March 2014 (UTC)

That would mean we can't provide a font-stack at all. There will always be systems that has fonts not indiginous (I have XP with all free fonts installed). So, I (also) don't get Arial. Liberation/Arimo is a good alternative, and of al the free fonts is one of the best rendering fonts. But each font, free or non-free, has issues and will always have issues. — Edokter (talk) — 12:01, 22 March 2014 (UTC)

Screenshot

Resolved

Can someone please provide an updated comparison screenshot showing how an article currently looks and how it will look if this proposed change is implemented? --MZMcBride (talk) 00:07, 22 March 2014 (UTC)

On what browser + OS? I have made File:New typography Vector OSX.svg for OS X 10.9 on Chrome. Normally I use a VM to test Ubuntu and Windows, but I don't trust the font hinting enough to take a screenshot from them that is high quality. Steven Walling (WMF) • talk 00:51, 22 March 2014 (UTC)

Browser + OS doesn't matter to me. Other than being a strange file format for a screenshot, File:New typography Vector OSX.svg is great. Thanks! I've inserted it into the subject-space page. --MZMcBride (talk) 03:14, 22 March 2014 (UTC)

Small gap in main page boxes on de.WP

With the typography refresh enabled on de.WP (I'm only there, so don't know about other languages), on the main page all the boxes have a small gap between the blue "header box" (like "Artikel des Tages", for example, featured article of the day) and the frame of the "content box" that show the introduction of the featured article. Is this intended, a bug in the beta feature or a bug in the local CSS for these boxes? --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:00, 22 March 2014 (UTC)

Just did inspect the page with Firefox and found the bad guy, but not sure who is responsible for this and if it's intended (the gap looks wrong): --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:26, 22 March 2014 (UTC)

div#content h2 {
    font-size: 1.5em;
    line-height: 22pt;
    margin-top: 16pt;
    font-family: "Linux Libertine",Georgia,Times,serif;
    padding: 0px;
    margin-bottom: 4pt; <!-- this is the bad guy! -->
}

.Ah, accoording to the fonts it is the beta typography. Then I think the boxes on the german main page must be fixed (own class insead of using just a h2 header, for example) --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:28, 22 March 2014 (UTC)

This has been fixed locally (it was a CSS selector specifity issue). --Entlinkt (talk) 21:03, 27 March 2014 (UTC)

FAQ feedback

Thanks for the announcement on the Commons Village pump. The improved horizontal <pre>-scrolling could be also interesting for Monobook. The section on "opt out" could give an (or link to an) example, and while at it also explain how users with other skins could "opt in" to test this—as far as that's possible with a few CSS-lines, e.g., serif headers. –Be..anyone (talk) 01:23, 23 March 2014 (UTC)

Printing -- eco fonts?

Hi. I recently heard about Ecofont. Does anyone think a free version of something like this should be used when printing articles? I don't think so, but just putting this idea out there. πr² (t • c) 18:44, 26 March 2014 (UTC)

There was a lot of talk around Garamond lately in the USA, but it seems those calculations were debunked as completely wrong. Is there serious research on this or other such fonts? [3] [4] --Nemo 11:52, 3 April 2014 (UTC)

Thumbnail style

Resolved

I miss the slight background color change behind and border around image thumbnails and their captions; they served to help visually group the caption with the image. I can see doing away with one of these features but not both. I don't miss the goofy "enlarge" icon. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:53, 26 March 2014 (UTC)

That element is not going to be part of the actual release (See #Latest release above for details).

However, there's a discussion at en:Wikipedia:VPT#New image thumb design about thumbnail styles, that you all might be interested in joining. –Quiddity (talk) 19:33, 27 March 2014 (UTC)

Yes. If you test here, you'll notice the beta feature has been removed and the default change is live. It does not include thumbnail or blockquote styles. Steven Walling (WMF) • talk 20:53, 27 March 2014 (UTC)

Slight increase in default text size

I like the change (see #Screenshot, above, to have a look at the difference). It's not a huge increase in the main text size, but just enough to compensate for monitors being huge these days. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:58, 26 March 2014 (UTC)

If we get more feedback around this issue - we are open to increasing the type size for body copy and leading. 192.195.83.38 22:55, 28 March 2014 (UTC)

Funny, I haven't noticed any change in the screen-size of my 10" netbook for quite some time. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:40, 1 April 2014 (UTC)

Spacing around section headings bad

Tracked in Phabricator
Task T65312

It seems to me there's a problem with the spacing around section headings. There is too much space before them and too little space directly after them. It would look much better if it were "more in the middle". I'm running Linux with a recent Firefox. Jason Quinn (talk) 00:50, 27 March 2014 (UTC)

Confirmed (for level 2 headers): they look as if they had a double empty line before. --Nemo 12:08, 27 March 2014 (UTC)

Spacing increase around headers is an intentional part of the update. See "New spacing and sizing for headings, body copy, and leading" in the summary of changes. A primary goal of the update was to design for the state of our most popular content, which often tends to be very long articles with many sections. Spacing between sections plus serif for major headings increases ability to read/scan by providing a clearer visual break between sections, rather than one continuous block of text. Steven Walling (WMF) • talk 18:58, 27 March 2014 (UTC)

Hi, User:Steven (WMF). Increased spacing may be a part of the design goals but this thread is about the positioning of the heading within that spacing. It's too far away from the last section and too close to the text of the new section. Jason Quinn (talk) 16:13, 28 March 2014 (UTC)

Thumb images overlapping level 2 headers

Please see File:Thumb image overlap issue.png. Sven Manguard (talk) 18:39, 2 April 2014 (UTC)

Sven Manguard, I was unable to reproduce this issue, can you tell us more about your OS/Browser setup as well as if you have any custom CSS that might be affecting it?Jaredzimmerman (WMF) (talk) 22:00, 2 April 2014 (UTC)

Is this with the beta feature turned on, or with the version that is released as default? I think this should be resolved with the version that will be the new default, since we didn't update the thumbnail style. Steven Walling (WMF) • talk 22:09, 2 April 2014 (UTC)

Better idea

Make the typography change go live on April 1, and make it consist of changing all font faces to Comic Sans. Dtobias (talk) 01:50, 27 March 2014 (UTC)

Very good idea. We'll implement this immediately. ;) Steven Walling (WMF) • talk 18:55, 27 March 2014 (UTC)

You're joking, right? I'm not quite as enamored with Comic Sans as Dtobias is and don't like it when I see it on computer screens. The font is more suited for humorous print-outs and comment signatures, IMHO. — RandomDSdevel (talk) 20:57, 27 March 2014 (UTC)

Yes, very much joking. We're not going to do that. Dtobias was suggesting it as a practical joke because he likely agrees with everything you just said, as do I. :) Steven Walling (WMF) • talk 23:57, 27 March 2014 (UTC)

Someone did, in case you missed it: http://home.web.cern.ch/about/updates/2014/04/cern-switch-comic-sans --Nemo 11:53, 3 April 2014 (UTC)

CSS script

Section 2.12 states that CSS script can be added to "opt out" of these changes. Could a technical bod post the script needed, as I'm quite happy with the existing font. Optimist on the run (talk) 12:27, 27 March 2014 (UTC)

I would need to find out the exact code changes that will be rolled out. I can't seem to find it in Gerrit. Found it. There will undoubtably be someone that will concoct a "Classic Vector" gadget. — Edokter (talk) — 14:27, 27 March 2014 (UTC)

Arial

See also Thread:Talk:Wikimedia Foundation Design/Typography/Arial?

This was brought up in one of the archived threads, but I don't think it was ever explicitly addressed: I think Arial should be removed from the font stack. On systems that have Arial but none of the fonts with higher priority (i.e. Windows), Arial is the default for sans-serif in most common browsers, so falling back to sans-serif would render the text in Arial anyway. As it stands, the only effect of specifying Arial in the font stack is overriding the preference of the minority of users who have explicitly set a different default sans-serif font. I don't think this is desirable. (Sorry for raising this so late--I was only reminded about it on seeing the deployment announcement.) wctaiwan (talk) 16:08, 27 March 2014 (UTC)

Consistency is one of the goals that this font stack is aiming for. If Arial were removed, then whatever the browser default is would be used, and that is, as you point out, not always Arial. Arial is there because we want it to be Arial. In fact, most website that use a sans-serif fontstack fall back to Arial. Most browsers do have an option to override the website's fontstack though, so you can still set your own font. — Edokter (talk) — 16:20, 27 March 2014 (UTC)

Absolute consistency should never be a goal in design, and I doubt it would be here, either, if we got a word from the designers. The basis of responsive design is to make a design that adapts to different devices so that the users get what is the best experience for them, regardless of how it may differ - this may mean different layouts for different screen sizes, higher contrast for mobile devices, using or overriding native keyboard interfaces depending on effectiveness for the task at hand, adding available character sets, and, yes, setting the best fonts for the platform. In light of this, given that Arial is already the default and it would only be overridden on the user end with good reason, including it in the font stack is likely nothing more than an oversight. -— Isarra ༆ 16:37, 27 March 2014 (UTC)

Although I'm not on the design team, I believe Edokter's statement is closer to their take on things. The designers were looking for fonts that matched a particular style (basically Helvetica) and Arial was the best match for that on Windows. It also benefits from supporting a broad range of glyphs and having support for a lot of the more technical features in Unicode. See Typography refresh/Font choice for more information. Although the designers want to ensure a consistent experience for readers, it is still possible for users to override these fonts in their local CSS (or via the Universal Language Selector). Kaldari (talk) 17:32, 27 March 2014 (UTC)

I'm quite willing to test interesting fonts, but when I configure Palatino Linotype as serif, Tahoma as sans and default, and Source Code Pro as mono-spaced it means that I don't like Arial or New Courier. –Be..anyone (talk) 21:10, 29 March 2014 (UTC)

Be..anyone, then it's desired for you not to like MediaWiki sites, and consistently so. :) --Nemo 18:11, 31 March 2014 (UTC)

Gray text is a strain to the eye

Even if it has been pointed out multiple times already I think with the impending deployment on all Wikis I have to stress it again: The dark gray text color is strain to the eye! I immediately notice my eyes being tired by the unnecessarily reduced contrast. Here's an example so everybody can judge him/herself:

Pure black text (color:#000):
Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Dark gray text (color:#252525):
Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

The dark gray example will be the future default with typography refresh and I think it will be an unnecessary strain to the eyes of most users. And to prevent the default counter argument: Users with known problems regarding black on white text (like users with dyslexia) probably have set their display to reduced contrast already by default, so there's absolutely no reason to reduce it even further for them. --Patrick87 (talk) 23:28, 27 March 2014 (UTC)

The proposed text color is #252525 against #FFFFFF provides adequate contrast.

It has a contrast ratio of 15.33, and is WCAG AAA compliant which is the most stringent accessibility standard.

Use this tool to check the contrast - http://snook.ca/technical/colour_contrast/colour.html

Other reasons for reducing contrast:

1. Computer screens are a projection and thus have much higher black/white contrast than the typical reflective printed page.
2. Resolving complete black against a bright backlit display creates stress and vibration for the eye.
3. A dark grey provides adequate contrast but also works better across platforms due to the wide variety of anti-aliasing algorithms.

Hope this helps, Thanks Vibhabamba (talk) 21:41, 2 April 2014 (UTC)

Not really... The accessibility standards you quote say what contrast text should have at least to be readable. I didn't find the section where it said the contrast isn't allowed to be higher... For the other points (I numbered them for convenience):

1. Computer screens also have much less resolution than printed text in most cases. Additionally most ergonomic workplaces are set-up to have the monitor in at least 50 cm distance from the reader – more than when reading printed text increasing the need for good contrast. Also font enhancement techniques like anti-aliasing and sub-pixel rendering tend to smooth font edges (e.g. making them grayish / colorized) effectively reducing perceived contrast even further. Even another issue: In contrast to a sheet of paper contrast doesn't increase on a brightly lit (e.g. by the sun) computer display but it decreases. All in all the theoretical contrast calculated from the plain color values is worth close to nothing in practice.
2. I never felt any stress for the eye because of too much contrast – only the other way round. I don't even now what "vibration for the eye" should mean.
   The only real issue I can think of is that a user has set his display so bright that it blinds him. But this is a fundamental problem that should be solved by correctly adjusting the display on the user side and nothing we should prevent by artificially reducing contrast. (Remember: If contrast is too high, one can turn it down; if contrast is too low one is stranded).
3. For this point I want sources! Otherwise I don't believe you how grayish text should improve anti-aliasing algorithms (that already suffer from the reduced contrast caused by the gray edges those algorithms produce).

For me personally I solved this issue by changing my user CSS. However I think this is a fundamental annoyance that we (Wikipedia/Wikimedia Community) should abstain! Other users might not know how to get rid of those text degradations (or even can't change them like unregistered users) and we shouldn't force such design stupidities (probably invented by designers with 4K IPS Displays and 200 % font size set) on them. --Patrick87 (talk) 22:40, 2 April 2014 (UTC)

Serious Guys, this is a very bad decission. I tryed the new grey-setting on existing pages (using local CSS), and it was a HUGE pain in readability. I'm already past 50, and I feel that my eyes are no longer the same way as they have been 30 years ago. This change may be fun for younger, but seriously not for me - and it's no reassurance that anyone else also gets older :) The other issues are more of a design decision (Using serifed fonts looks like going back to middle ages in my opinion), but greying out content is realy decreasing usability for a lot of people. Raffzahn (talk) 00:04, 3 April 2014 (UTC)

"l" vs "I"

Hi, folks! I wanted to add that the new typography should consider the "l" vs "I" issue. If a typefont doesn't distinguish between those two letters, then it shouldn't be used. --NaBUru38 (talk) 18:28, 28 March 2014 (UTC)

That practically rules out 99% of all sans serif fonts. I don't think that is really a practical option. — Edokter (talk) — 19:15, 28 March 2014 (UTC)

Perhaps it wasn't such a good idea to switch to sans-serif for body copy, then? —SamB (talk) 20:18, 29 March 2014 (UTC)

That's not a switch. We've always (in monobook and vector at least) specified "sans-serif" for the body typeface. –Quiddity (talk) 21:00, 29 March 2014 (UTC)

Well, not quite - originally, before vector and monobook existed, the font for stuff (what's body copy? the content area? why 'copy'?) was indeed sans-serif. I believe Quiddity is correct though that sans-serif has always been used in monobook and vector. There is also a very slight difference between I and l in the usual sans-serif font that everything has used until now, but it's so slight that people who don't sit abnormally close to the screen (i.e. most people who aren't me) probably don't see it. Cathfolant (talk) 20:46, 31 March 2014 (UTC)

@Cathfolant: Re: "Copy", see en:Copy (written) and en:Copy editing. ;)

Re: "[...] in the usual sans-serif font that everything has used until now [...]" - there was no "usual" font, because everyone had whatever their Browser/OS combination specified as the default for "sans-serif", which is part of what this refresh is intended to fix. –Quiddity (talk) 22:10, 2 April 2014 (UTC)

NaBUru38, you're right, this is one font issue that Unicode calls inadequate rendering support. Typography refresh/Font choice doesn't yet explain any of the criteria used in the one evaluation which is still in the text of the page; it should be clarified whether this issue was taken into account for the technical evaluation. For what Edokter said, however, I can't imagine it would be given many points.

On the other hand, our friends of SIL are working on very high quality fonts which see broad usage/support in some GNU/Linux distributions, the most famous being Gentium. Gentium sans-serif was not made available yet, so they instead suggest Andika for sans-serif use. Andika seems to be an actually readable font, e.g. it distinguishes I and l, but I've not studied it thoroughly. I've added them to the page because we'll need an evaluation at some point, after the criteria have been clarified. I expect Gentium and Andika to get the maximum technical score but we can't just guess. If you have other free fonts to suggest please do so, it's important for us to get a sense of what's available in the font scene. --Nemo 06:15, 1 April 2014 (UTC) P.s.: I see NotoSans is also good in that regard, while Arimo isn't.

I liked this new look but the Il-issue is an absolute no-go. As a work-around I suggest to add

#bodyContent { font-family:"Tahoma", sans-serif; !important; }

to your vector.css. Tahoma does it and probably some other fonts, depending on the availability on your computer. --9xl (talk) 09:34, 2 April 2014 (UTC)

Table of contents redesign needs work

Resolved

Overall, I like the direction that this is going in, very much! But I think the new table of contents is not good. It needs to stand out more. Right now, it looks like a block-quote, and something subservient to the rest of the text, rather than the master navigation control that it really is. Klortho (talk) 17:10, 29 March 2014 (UTC)

The TOC redesign will not be included in the typography refresh at this time (in fact, it is not included on this very page, which already has the typography refresh). --Entlinkt (talk) 15:34, 31 March 2014 (UTC)

Footnote reference spacing

Resolved

Hi, either on my notebook or large computeur screen, footnote references are touching the upper line, making them difficult to see. --Salix (talk) 19:52, 30 March 2014 (UTC)

Salix, is this on fr.wikipedia.org? I can't seem to recreate this issue I know that nl.wikipedia.org had an issue that was caused by a custom site-wide css override, we're working with the site admins to fix it, do you have skin speciffic css overrides? or can you post a screenshot of the issue so that we can understand what the issue is, thanks! Jaredzimmerman (WMF) (talk) 21:41, 2 April 2014 (UTC)

Hi Jaredzimmerman (WMF). I'm using vector + Typography refresh, no other special skin. You can see an exemple here : fr:Fichier:2014-04-03 114620.jpg, but it's available for any page. --Salix (talk) 09:59, 3 April 2014 (UTC)

Salix, Thanks for that, It looks like the same issue as nl.wiki we'll investigate if there is something in the site css overrides that is causing this, as was the case on the other wiki, and work with admins to fix it if that is the case.Jaredzimmerman (WMF) (talk) 20:15, 3 April 2014 (UTC)

I think this part of the site common.css is to blame

.reference, .exposant { vertical-align: text-top; position: relative; font-size: .8em; top: -5px; } .reference-text sup { vertical-align: text-top; position: relative; font-size: 0.75em; top: -0.1em; } .reference { padding-left: 1px; }

Thanks Jaredzimmerman (WMF), now it's correct :-) --Salix (talk) 21:44, 3 April 2014 (UTC)

Salix, always happy to help. Jaredzimmerman (WMF) (talk) 23:09, 3 April 2014 (UTC)

Download new font

Resolved

Does anybody know, where I can get the new font as a download? Regards, --Brackenheim (talk) 23:04, 31 March 2014 (UTC)

Which one? Steven Walling (WMF) • talk 23:30, 31 March 2014 (UTC)

The font, which is used for the texts of the articles. --Brackenheim (talk) 09:28, 1 April 2014 (UTC)

I think you misunderstood something here: Typography refresh introduces a so called "font stack". This is a list of fonts, that get checked by your browser one by one. The first font you have already installed in you system will be used. E.g. on Windows without any additional fonts installed this will still be Arial as before the typography refresh. --Patrick87 (talk) 09:48, 1 April 2014 (UTC)

Ah, ok ;-) Thank you. --Brackenheim (talk) 13:46, 1 April 2014 (UTC)

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) • 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) • 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 bugzilla: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. Quiddity 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 #Wikipedia or MediaWiki?: 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...

A consistent visual experience across desktop and mobile devices.

— Typography refresh

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)

Missing info - which browsers were tested?

{{Resolved}}

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)

N Not done

Please don't mark as resolved if you haven't done anything. Read the request again: "only seems to list the operating systems, and does not specify which browsers were tested." -- Jokes_Free4Me (talk) 14:49, 7 April 2014 (UTC)

Fat Fs, Ts and Is

Tracked in Phabricator
Task T65591

The new default font on Wikidata has odd-looking Fs.

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 Feuerrabe on English Wikipedia. Helder.wiki 14:29, 4 April 2014 (UTC)

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

Vibhabamba, 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: Arimo (?), "Nimbus Sans L", "Helvetica Neue", Helvetica, Arial, sans-serif;." — 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 Sinuhe20 and mentioned on enwiki's Village Pump. Helder.wiki 17:17, 5 April 2014 (UTC)

Hey Andy (aka Pigsonthewing) 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) • talk 23:48, 5 April 2014 (UTC)

Error Visual / Visual error

Resolved

Old versión, good.

New versión, poor visualization (Quote and image)

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

Resolved

Why do you use BCE (Before Common Era) instead of BC (Before Christ) and CE (Common Era) vs. AD (Anno Domini)? — Preceding unsigned comment added by 50.27.49.138 (talk • contribs) 03:04, 2 April 2014‎

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

Resolved

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:

#bodyContent {
	font-size: 0.8em !important;
}

Nurg (talk) 22:48, 3 April 2014 (UTC)

Font size difference in diff pages

Resolved

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)

@Vibhabamba: 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)

• 
  Diff without Typography refresh
• 
  Diff with Typography refresh

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. 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 see diff--Siddhartha Ghai (talk) 15:48, 4 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#Default system fonts should be given preference over free fonts (especially on Windows) (January). Three months later it seems the powers that be acknowledged it, too, in their way: [5]. --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.

N Not done

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)

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. πr² (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)

Ah, faux amis! Merci beaucoup, Euterpia. Lagrange613 15:35, 7 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.) <signature-anon> 03:27, 5 <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)

Since yesterday, Microsoft stopped support for Windows XP. So there is no operating system left on the market that hasn't enabled font smoothing by default. If you change your OS defaults you're on your own. And in newer Windows iterations you have to do a lot of work to disable font smoothing system-wide. Also you can still add a custom css in your preferences to change the fonts. Schulu (talk)

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 #How to determine which Font are being used in your Browser? 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).

Hi Rich, designers have been asking to provide suggestions of fonts. You can add them to Typography_refresh/Font_choice for a future round of evaluation. --Nemo 13:39, 9 April 2014 (UTC)