Talk:Typography refresh

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, , and others who wrote the bulk of the new FAQ and summary of changes. I highly encourage everyone to read it. Steven Walling (WMF) &bull; 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) &bull; talk   21:06, 21 March 2014 (UTC)

Please return to previos typography, the new one is non-redable --Vegen451 (talk) 07:31, 4 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) &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.

Only system font
"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) &bull; 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) &bull; talk   18:11, 14 March 2014 (UTC)


 * Ok, so that's Typography_refresh/Font_choice. 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
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) &bull; talk   20:56, 14 March 2014 (UTC)


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

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) &bull; 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) &bull; 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: 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: — 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) &bull; talk   03:29, 18 March 2014 (UTC)


 * Any text inside  and , 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  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)

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

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, not  . —  Edokter  ( talk ) — 20:15, 3 April 2014 (UTC)

Giant quotation marks around blockquote
The use of decorative large quotation marks for block quotes in Wikipedia is contrary to the Manual of Style (Manual of Style), 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 . 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 Viskosität. 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 . (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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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 . 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". — <font face="Trebuchet MS">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
Looking at 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 . 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&thinsp;—&thinsp;well, they look confusing, not to mention weird.  —&thinsp;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. — <font face="Trebuchet MS">SMcCandlish  Talk⇒ ɖ⊝כ⊙þ Contrib.  23:29, 26 March 2014 (UTC)


 * That's another reason why I hate the new serif headings!!! —&thinsp;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)


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

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)

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.[] Anyway, where can I keep track on such changes? (i.e. within the repository?) --PuzzletChung (talk) 12:02, 15 March 2014 (UTC)


 * 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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   20:55, 21 March 2014 (UTC)
 * 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)
 * 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.  —&thinsp;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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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 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)
 * 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).

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)
 * 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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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.
 * 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
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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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)


 * .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 -scrolling could be also interesting for. 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&mdash;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. <b style="color:#f90;font-family:Arial">πr2</b> (<b style="color:#0f3;font-family:Arial">t</b> • <b style="color:#03f;font-family:Arial">c</b>) 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?  --Nemo 11:52, 3 April 2014 (UTC)

Thumbnail style
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. — <font face="Trebuchet MS">SMcCandlish Talk⇒ ɖ⊝כ⊙þ Contrib.  23:53, 26 March 2014 (UTC)
 * That element is not going to be part of the actual release (See above for details).
 * However, there's a discussion at en:Wikipedia:VPT 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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   20:53, 27 March 2014 (UTC)

Slight increase in default text size
I like the change (see, 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. — <font face="Trebuchet MS">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
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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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. ;) <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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.  —&thinsp;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. :) <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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
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:

<span style="color:#000!important">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.

<span style="color:#252525!important">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:
 * Computer screens are a projection and thus have much higher black/white contrast than the typical reflective printed page.
 * Resolving complete black against a bright backlit display creates stress and vibration for the eye.
 * 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)

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).
 * 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):
 * 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.
 * 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.
 * 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? &mdash;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)
 * 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
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
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
Does anybody know, where I can get the new font as a download? Regards, --Brackenheim (talk) 23:04, 31 March 2014 (UTC)
 * Which one? <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; 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)

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)

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 (<tt>margin-top: 1em;</tt>). 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 <tt>div#artigos-destacadosHead h2</tt> will fix this. <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   21:57, 2 April 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)

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)

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)

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)

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)

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)

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.


 * 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

Same here..... Wiki, if it works well, you must not change it.

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)

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.

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. <b style="color:#f90;font-family:Arial">πr2</b> (<b style="color:#0f3;font-family:Arial">t</b> • <b style="color:#03f;font-family:Arial">c</b>) 23:15, 3 April 2014 (UTC)
 * Policy, I reckon. Lagrange613 06:14, 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.

opinions from pl-wikt
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. <b style="color:#f90;font-family:Arial">πr2</b> (<b style="color:#0f3;font-family:Arial">t</b> • <b style="color:#03f;font-family:Arial">c</b>) 01:39, 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-antialised 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.

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)

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)

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)