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)

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)

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)

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)

Mixing serif and sans serif faces

 * 1) 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.
 * 2) 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
 * 3) 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.
 * 4) 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)

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)

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)

licence bug
The mediaviews says "cc-by-sa _3_.0", also if another version is used. --Sebaso (talk) 20:03, 16 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).