Talk:Typography refresh

Update to Typography refresh
Hi everyone,

This an update regarding the "Typography refresh" Beta feature, which is live on all wikis that have Beta Features available. The following changes will be live soon, if you don't see them already.

The first version of the typography update certainly wasn't perfect, but the UX design team wanted to get it out there and see what people thought about some of the ideas included. Well, we've recevied a ton of feedback on the Talk page.

Changes made based on your feedback
Almost all of the feedback was constructive, and some showed a really keen understanding of the issues with typography on Wikipedia. Thank you to everyone who stopped by and left a message. Based on the feedback we got, we made the following changes:


 * 1) Reverted the size of the personal toolbar menu and lefthand sidebar back its previous size (.8em)
 * 2) Reverted the black/grey links in the sidebar and personal toolbar back to blue
 * 3) Reverted the width of the left-hand back to its previous width, to avoid line breaks in those links
 * 4) Increased the body content size to 1.1em. While we did not originally increase the body content size, we saw that many people brought up this idea, and we think it's a good strategy for improving readability. This also allows us to emphasize the main content more without decreasing the size of toolbar or sidebar links, etc.
 * 5) Increased the size of page titles and their line height
 * 6) Tweaked the whitespace between section/subsection headings and around blockquotes. We hope this version provides better balance.
 * 7) Reprioritized the font family CSS for headings, placing the free and open source variant "DejaVu Serif" first

Additional ideas we're trying out in this release

 * 1) Placing a maximum width on page contents of 715px. It is widely accepted that text columns with a line length which spans the entire width of a (desktop or laptop) screen are not ideal for reading/scanning.,, , The max width will not apply to Special pages (like Prefences) or to actions on an article, like viewing history.
 * 2) Removing the border around thumbs, increasing the whitespace around them, and changing the text styling on thumbcaptions. Vector and Monobook styles are both overly reliant on border styles to demarcate page elements. Numerous borders, especially with right angles, increases cognitive load when scanning a page.
 * 3) Changing disambiguation and row links to have the same type as thumb captions.

Other things we have retained in the beta. For example, serif headings were a source of complaints, but were retained since one of the goals is consistency with the mobile skin for Wikimedia projects.

On behalf of the design team, Steven Walling (WMF) &bull; talk   23:17, 7 January 2014 (UTC)


 * Regarding maximum width: for reading text, I don't mind having a narrower column, but Wiktionary has very little body text, and on svwiktionary we put quite some content (images, links, inflections) floating on the right. Are we expected to disable the maximum width for pages in the main namespace? Skalman (talk) 12:01, 8 January 2014 (UTC)


 * FWIW, I've already disabled maximum width for the main namespace at svwiktionary. Skalman (talk) 12:44, 8 January 2014 (UTC)
 * I'm a little confused. You are penalising ALL svwiktionary users with a slightly larger CSS page load for an opt in feature that is currently only enabled by 4 users (according to the preferences page) which by the way doesn't even work... why? This is senseless.... I understand there may be problems with the feature but it would be more useful to surface those issues and discuss them than hide them. Please consider using User:Skalman.css/Vector.css instead. Jdlrobson (talk) 06:47, 9 January 2014 (UTC)


 * One of the four was complaining about it, so I thought I might as well fix it by adding 46 bytes of extra uncompressed, minified CSS. Further, I am assuming that Typography refresh will actually be enabled by default in the "near" future, and thus making the transition smoother by starting now. If we're caring this much about 46 bytes there are plenty of other improvements that should go first. Skalman (talk) 10:13, 9 January 2014 (UTC)

Limitation of page content width needs some more thought
While I like the idea of a limited content width (actually I never maximize my browser window horizontally for this very reason) I think a potential implementation on Wikipedia would need much more work than is done in this iteration of typography refresh. Some issues that directly come to my mind: --Patrick87 (talk) 00:59, 8 January 2014 (UTC)
 * While the page content's width is limited all other UI elements use all available horizontal space (e.g. navigational links at the top). This doesn't look right and makes the actual content look needlessly squeezed to the left.
 * Pages with navigational templates or floating images as well as informational templates often look squished.
 * File description pages also look wrong with the image not being influenced by the width restriction and often being much wider than the rest of the page content.
 * Jaredzimmerman (WMF) (talk) 07:58, 9 January 2014 (UTC)
 * Patrick87, can you update with some specific links so we can make sure we're all on the same…page, as to which pages we're talking about. I've also added a section below for cataloging special pages with issues due to the fixed measure.


 * I agree with Patrick and would add that category pages should not have the maximum width either, since they are displayed in columns.
 * Why is the max width specified in pixels, not ems? Ems would seem to make more sense to me for this kind of thing. This, that and the other (talk) 10:40, 8 January 2014 (UTC)


 * Jaredzimmerman (WMF) (talk) 07:51, 9 January 2014 (UTC)
 * I played around with using ems for the width, the problem with that is that different languages use different base em sizes to properly scale their type. So, if we base the width on ems (about 53em) the page width could change a lot per language, and since one of the main points of this beta feature is consistency both with mobile and across projects, that wouldn't work out so well.


 * Thanks guys this is really useful feedback. Jdlrobson (talk) 06:48, 9 January 2014 (UTC)

Default system fonts should be given preference over free fonts (especially on Windows)
I'm running Windows 7 and use Firefox. By chance (mainly to create SVGs for Commons) I have the fonts "Liberation Sans" and "DejaVu Serif" installed on my system. After the update to typography refresh those free fonts are used throughout the page instead of the default system fonts normally expected on Windows ("Arial" and "Georgia"). This results not only in an inconsistent look compared to other pages but more importantly to badly readable text due to bad font rendering which is caused because of insufficient hinting of those free fonts (basically the same problem that came up with the Autonym font). The code should be changed to always prefer default system fonts! --Patrick87 (talk) 00:35, 8 January 2014 (UTC)


 * I have to agree in principle, but I also understand this is next to impossible; each OS has its own system fonts and CSS cannot determin what OS is being used. I do not share Patrick's concern about Liberation Sans (or DejaVu Serif); they render quite well on my Windows PC (perhaps you should update the fonts?) One question though... If Liberation Sans is used for the body, why not use Liberation Serif for the headers? As they are basically part of the same font family, it would make more sense to combine them. On second thought, Liberation Serif is too narrow. — Edokter  ( talk ) — 14:03, 8 January 2014 (UTC)
 * I note that the font stack for the headers appears to be DejaVu Serif, then a non-free font, then the system default. While for the body it appears to be Nimbus Sans L, Liberation Sans, then some non-free fonts, then the system default. I applaud the use of free fonts over non-free fonts in this iteration. But agree with Edokter: DejaVu Sans, Nimbus Roman No9 L, and Liberation Serif exist, so why not include them too? I have no opinion on the ordering of the free fonts as long as they remain before the non-free fonts. Anomie (talk) 14:51, 8 January 2014 (UTC)
 * What the heck are you talking about? DejaVu Serif is a free font to use, reuse, and modify. Just see http://dejavu-fonts.org, including the licensing information there. Steven Walling (WMF) &bull; talk   19:15, 8 January 2014 (UTC)
 * I mis-read it too. He ment "DejaVu Serif, [then] a non-free font [Georgia], then the system default." — Edokter  ( talk ) — 21:29, 8 January 2014 (UTC)
 * Sorry, clarified. Anomie (talk) 14:32, 9 January 2014 (UTC)
 * @Edokter: Those fonts render OK, but they are considerably less readable than Arial. Therefore this change would actually be detrimental to the most important goal of typography refresh which it is actually supposed to improve: Readability.
 * @All: I assumed it would be hard to prefer system fonts while still using a customized font stack. But if no proper solution can be found we should accept that we have to stick with the specification of generic font families - normally the way to go if you don't want to force specific fonts to achieve a particular design (which will by definition never look well on all systems) but aim for maximum compatibility. In this case if default system fonts are used optimum rendering is guaranteed and a high level of readability can be assumed. At the same time people with different likings are free to change the fonts used in their browser's preferences, therefore being served with their favorites instead of a predefined list of favorites of the MediaWiki devs. --Patrick87 (talk) 21:39, 8 January 2014 (UTC)
 * The new body stack starts with Nimbus Sans L, which has issues in bold text. I would much prefer Liberation Sans as the initial font. Also, not too sure about the font-size increase to 0.875em; it is really big, no matter what font. — Edokter  ( talk ) — 14:43, 8 January 2014 (UTC)

Pages with issues due to narrower measure
Jaredzimmerman (WMF) (talk) 07:35, 9 January 2014 (UTC) There might be some page types that the narrower measure doesn't make sense as a hard limit, such as watchlist, or contributions, while we've tried to find and exclude as many of these from the typography changes as we could find, I'm sure we've missed some, if you come across pages where the measure is breaking things, list and link them here so we can take a look.

Pages where narrow measure possibly shouldn't be applied:

Pages where narrow measure isn't applied but possibly should:
 * Edit and edit preview state of pages which have narrow measure (like this talk page you're reading)

Update to typography refresh, or refresh to typography update
What is the correct name of this project? —Michael Z. 2014-01-08 04:23 z 
 * Jaredzimmerman (WMF) (talk) 07:37, 9 January 2014 (UTC)
 * "Typography refresh" is the name of the Beta Feature

Not sure which header to put this under
Can someone please make an updated version of File:Typography refresh beta feature 2013-11-22 13-35.png? --MZMcBride (talk) 05:00, 8 January 2014 (UTC)



max-width: 715px
Today I filed 59815 because I thought the new "max-width: 715px" is a bug but I learned it is feature... It makes Wikimedia Commons nearly unusable for me, half of my (wider) screen is white now, see screenshots included in the bug.

I will wait until thursday, when this release will be deployed to the German Wikipedia for further critics. But I am sure that I do not like narrow Wikipedia pages... Raymond (talk) 16:39, 8 January 2014 (UTC)


 * ACK. Elleff Groom (talk) 21:27, 8 January 2014 (UTC)


 * I've had to uninstall. While I agree that for continuous prose (like a wikipedia article body text) a limit on width may be desirable, there are too many pages on Wikipedia and Commons where this is unhelpful. I can choose to not maximize my browser window for when I want the prose to be narrower. Too much wrapping for complex pages like watchlists and diffs. Pages with the gallery packed feature (like Flickr) were reduced to just one or two images per row. -- Colin (talk) 22:03, 8 January 2014 (UTC)

Thanks for the feedback. Out of interest could we categorise this width limit as a problem on certain types of pages e.g. file pages / pages with gallerys etc? Also would it be less of a problem if the whitespace opened up by such a change was occupied by things like infoboxes / gallery images? It would be really interesting if you could point us to examples of pages you do not think the limit works on. Maybe it's a bad idea, maybe it's a good idea that needs some polish. I'm keen for us to distinguish between the two. Jdlrobson (talk) 06:41, 9 January 2014 (UTC)
 * I think it would be a good idea to restrict the max-widths to pages in the content namespace(s) (NS0 on most wikis). But maybe not on the Main Pages? Please note: Some wikis have their Main Page in another namespace (like dewiki in the WP namespace). Your idea to occupy the whitespace by infoboxes sound interesting. Raymond (talk) 09:23, 9 January 2014 (UTC)

A couple of suggestions: Only regular paragraphs should be corralled into the maximum width. Many page features can benefit greatly from the full width of the viewport: div boxes, like the one at the top of WP:ANI; galleries; panoramic images; all tables; possibly columnar reference lists (a la enwiki and frwiki); etc. And yes, I really like the idea of pushing infoboxes and floated images into the whitespace (if it is wide enough). These things may not be possible with CSS alone, but they are still ideas. This, that and the other (talk) 12:36, 9 January 2014 (UTC)

Numbers looks weird in article title
The "9" and "1" in the title at the top of the AT91SAM article looks weird. They are both shorter than then "AT" and "SAM". I'm using 64-bit Windows 7 IE11. 98.164.11.206 23:05, 8 January 2014 (UTC)
 * That's the nature of the Georgia font: it uses "old-style" digits. This is the way it is supposed to look. ABCabc 1234567890 versus Georgia: ABCabc 1234567890 This, that and the other (talk) 01:47, 9 January 2014 (UTC)

Underlining Links
I’d suggest that links should be underlined with  instead of   The text-decoration cuts through the letters with descenders (g, j, y), while the border leaves enough space for them. —MRosetree (talk) 11:41, 9 January 2014 (UTC)
 * Disagree,  is the de facto method of underlining links, and is present in every major browser's default stylesheet as well as in wide use across major websites. As such, I believe users come to expect that when a link is underlined, the underline is close to the bottom of the text and will cut through those letters you mention. Pushing the underline further down would look "weird" because it is simply not seen across the major websites. -- Skiz  zerz  16:35, 9 January 2014 (UTC)