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)
 * Can you please make it clear in something like a site notice (displayed to those that have the feature enabled) that you are making this change (the page width restriction)? I was just very confused by the page width suddenly shrinking so much. I've disabled this feature in my settings - I hope it is removed as it is absolutely terrible on widescreen monitors! Thanks. Mike Peel (talk) 20:04, 9 January 2014 (UTC)
 * Mike Peel, There won't be a site notice as this is a beta feature, however it is on our roadmap to have echo notifications when there are major changes to Beta Features for users who have the featured enabled. We just haven't gotten to creating that notification type yet.
 * Jaredzimmerman (WMF) (talk) 23:23, 9 January 2014 (UTC)
 * Thanks for the reply. Echo notifications would work well - I'd encourage you to consider prioritising getting those working before you make more big changes like this one. Thanks. Mike Peel (talk) 06:20, 10 January 2014 (UTC)
 * Mike Peel, when a column is too wide (say, more than 60 or 70 characters per line), it is harder to read. The only time I have a window open to full screen is to view a video or slide show. Still, I think the user should have a handy way to override the maximum width setting.
 * --71.178.95.236 23:02, 12 January 2014 (UTC)

ToC change and the new image frame
I like the ToC change and the new image frame. Although I'd also suggest experimenting with a very light faded frame when hovering the thumbnail. TheDJ (talk) 20:55, 9 January 2014 (UTC)
 * Thanks TheDJ, what do you feel would be the benefit of having a frame on images on hover? We don't want to step on the multimedia team's toes too much, as they might be planning some interactive elements for images on pages as well.
 * Jaredzimmerman (WMF) (talk) 23:27, 9 January 2014 (UTC)

The Egyptian pyramids of the Giza Necropolis, as seen from the air The Egyptian pyramids of the Giza Necropolis, as seen from the air
 * A frame creates gives affirmative feedback that the caption and the image belong together. Actually, you are creating a frame even in this design. It's just made using a lot of whitespace towards it surroundings. The reason this needs to be 'a lot' of whitespace is because whitespace is a lot harder to notice, so in order to create a 'grouping' of image and caption within the surrounding text, you will need at least more that 2 times the amount of whitespace that is between the two elements that you want to group. The frame I am proposing wouldn't have to be much. I'm thinking something like this example, with shadow and a significant fading. An alternative is to simply use a background color perhaps TheDJ (talk) 00:40, 10 January 2014 (UTC)
 * You're right TheDJ, there are lots of ways to create cohesion between the image text and the image, or separate the image caption from the article body text. and this is certainly one of the ways, in this version of the Text Refresh we went with a rather large margin for the images, this was partly due to the fact that even modern browsers still can't create a nice text rag automatically. and the rough rags look bad when the margin is too small. I don't know if a large hover effect is the right way to go, since there was such an outcry from people on the rather subtle hover effects for the edit links on visual editor from last year. I think the Multimedia team will want to investigate things like mouseovers and hovers where appropriate, but your point is taken that we can push further to more clearly associate the caption text with images and further distinguish it from article body text. Jaredzimmerman (WMF) (talk) 00:50, 10 January 2014 (UTC)
 * Yeah, my point was, please experiment with this, I think we can do more in this area. Personally I don't like the whitespace style, but perhaps with some experimentation, you can find something that is even better. TheDJ (talk) 07:59, 10 January 2014 (UTC)

Refreshing indeed
I find this update globally refreshing for a non typo/non tech expert. I like the experiment with the thumb images. It help reducing visual clutter (boxes, boxes, boxes,...) Keep on trying.

Working on high res screens makes the 715px width limit a little bit awkward. Is there any possibility to somehow link page width or font size to screen resolution? Is the number of characters per line important for improved readability or is the absolute width?

As others suggested, I would experiment with using the empty space for infoboxes, media or even ToC. I would also pay extra attention to formatting reference lists as they may become endless with a 715px page width (see Obama's page for ex) Afernand74 (talk) 11:03, 11 January 2014 (UTC)
 * Afernand74, thanks for your comments, to answer your question, yes, studies we've looked at identify 45 to 115 CPL (characters per line) to be ideal for reading long form content. The current measure of 715px gets you ~113 CPL depending on many factors, such as makeup of the line, language, etc. but gets quite close the the upper limits of what we researched was an ideal measure length. While we could link it to screen size we'd lose the benefits of staying within that 45-115 ideal CPL band.


 * As far as other reasons beyond readability that we went with the narrower measure, you basically read or mind, this is a Beta Feature and therefore not finished, final, or polished, we plan to experiment with moving the infobox out of the main body of text as well as plan on experimenting with other types of content that could exist to the right of the main article body, some examples we've thought of (as have you apparently) are TOC, related Commons content, Wikivoyage, Wiktionary, Wikinews, and other sister project content. Nearby (geographically) related articles, and other types of related articles or content.


 * This step was to lay the groundwork for people to start thinking about how we could simultaneously make the article content easy to read, as well as free up space for other types of content to help people explore, learn more, and discover content that already exists within the project but might not be as visible as we'd like it to be.


 * Its also easy to begin to imagine what other things could exist to the right of an article, things like Flow talk page, Content translation workflows, Draft guides for new editors, as well as others we haven't even thought of yet.
 * Jaredzimmerman (WMF) (talk) 00:27, 12 January 2014 (UTC)


 * I agree that for running text, the 715px limit is probably a good idea, and agree with putting infoboxes+images outside the main text. However, please be very careful if you consider putting other types of content there, as it may be distracting. The things you mention (talk, translation, draft) sound good, but perhaps should be collapsed by default. Otherwise I'm afraid we'll get information overload. Skalman (talk) 09:47, 12 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)
 * "the problem with that is that different languages use different base em sizes to properly scale their type." Could you say a bit more about what you mean by this? Do different language Wikipedias specify different font sizes in their style sheets? 86.149.168.38 00:40, 10 January 2014 (UTC)
 * Yes, thats exactly it, languages that use non latin scripts such as Japanese frequently change the font size to look appropriate for their character sets
 * Jaredzimmerman (WMF) (talk) 19:48, 10 January 2014 (UTC)


 * I would change two things about content width limiting. 1. I would make it slightly wider. 800px is perfect for me. 2. I would maybe center the content of the page. That would make it look better on wide screen displays. Other than that, I enjoy the update. Especially the fonts. Dr. Fatman (talk) 22:23, 11 January 2014 (UTC)


 * The width limiting, as it's currently implemented, seems like a step backwards. The article body is tight against the left hand side, and the right hand side is just a vast expanse of blank space. This is very unbalanced. For an example of how to do width limiting well, take a look at the recent New York Time redesign. While the text is still biased towards the left hand side, there's enough white space there to give a sense of openness. They also allow images to extend into the whitespace on the right hand side. See, for example or . 96.250.56.207 00:55, 16 January 2014 (UTC) (en:User:pburka)


 * There were already so many comments against fixed width in the being-designed Flow interface. Now you intend to also limit the width of the main space!? What is this? Width should not be imposed.
 * Fixed width may be rather comfortable for reading long texts, but I don't think that this matches the most frequent activity of our readers. Seriously, do most people usually read encyclopaedia articles or dictionary entries from start to end? Text reading is often done in a non-linear way, like in small chunks split from each others by various other actions such as reading refs/notes (possibly looking at a linked external web page), navigating thanks to the table of contents, navigating via the browser Search/Find functionality to quickly identify parts of text relevant to the current interest focus, having a quick look (e.g. just the intro) at a linked page, fixing a typo or any other kind of edit (it's a wiki, after all), etc.
 * Fixed width means seeing much less info on the screen at once and therefore having to scroll much more. In non-linear "reading", fixed with is no help, only an annoyance. At the very least, this should be an option. Not just a preference for registered users but really an option available to anyone (like switching to the mobile version is available to anyone as well). Klipe (talk) 13:25, 16 January 2014 (UTC)

Line spacing
I think that line spacing is too large. We could keep it the same as before. With this, every superfluous empty lines appear extremely large (Maybe beneficial for hilighting wrong typography?). --Gumok (talk) 19:17, 9 January 2014 (UTC)

Still nothing
I enabled it again, and disabled again after 30 seconds. Nimbus Sans looks awfully on my computer: the letters are blurry and crammed next to each other. Non-bold DejaVu Serif in headers looks awkwardly slim, I am tempted to say that the headers are even less readable than previously. There is a large blank space to the right of page content, and I am in no mood for fighting with style sheets to get rid of it. If I wanted webpages to take only half of my screen width, I would shrink the browser window to half of my screen width. I do not. Respect it.

This is just change for the sake of change. Keφr 16:54, 10 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 agree stronly with this, the user should be in control, we already know which font works best for our eyes, e.g. I want to read Wikipedia and all my webpages in serif fonts without even a single sans-serif anywhere and I had to uninstall typography refresh after I found out it doesn't adhere to my browser's default fonts (which are all serif). In fact I'm considering uninstalling all sans-serif fonts from my computer to force websites suffering from stylesheet fascism to load serif fonts. For centuries readers were forced to read books without control over how the text was shown and we had to bow to the typographer's preferences; why shouldn't we let webpage readers control how text is displayed on their own screens? Webpages aren't books to specify what fonts should be used to read them, the user should have control! Cogiati (talk) 14:38, 14 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)
 * As a user I already know which font I prefer for text (serifs) and I've set it in my browser as the default font, why should the webpage designer force me to use another font? What's wrong with allowing me to read with the font *I* have specified in my browser? Forcing a particular font upon the users is stylesheet nazism, the stylesheet designer isn't supposed to act against my preferences and my own needs. Cogiati (talk) 14:42, 14 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.
 * But *I*, the user, already have the fonts (serifs) I prefer to read webpages in, I already know what's good for me and what is readable to my eyes. The stylesheet designer shouldn't force a particular font upon me, she or he doesn't know what's good for me, I'm the only one who should have control over how webpages are rendered on my own screen, and I do so by adjusting my browser font settings. If typography refresh is fascist and doesn't allow me to have self-determination on my own screen, then it acts against my best interests by forcing me to read with a font I dislike. Cogiati (talk) 14:46, 14 January 2014 (UTC)
 * @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)
 * What's wrong with not specifying any font at all and allowing me, the user, to choose my browser default font? I already know the best font for me (serif). The stylesheet designer should respect my browser settings! Cogiati (talk) 14:49, 14 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:
 * Main Page — https://en.wikipedia.org/wiki/Main_Page
 * Rationale: The design of this page is not set up for the narrow measure and become hard to read depending on where images fall


 * Administrators' noticeboard - https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard
 * The table of contents overlaps the Centralized discussion box

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)
 * Rationale: even in non-visual editor workflows, its easier to understand my edits if the layout of the page resembles what it will look like in read mode.

Visual issues that may be caused by narrower measure
on https://en.wikipedia.org/wiki/United_States_Senate the template halfway down the page has weird overflow issues now https://www.dropbox.com/s/l97fccee3czxg9k/Screenshot%202014-01-09%2011.44.50.png (Mac/Chrome 32.0.1700.68 beta) Jaredzimmerman (WMF) (talk) 19:48, 9 January 2014 (UTC)
 * Caused by nowraplinks selflink class combination on the "United States Senate" header + increased font size.


 * For some reason this selector does not seem to take effect if I load with debug=true (which does give me a shitton of MF related error btw). TheDJ (talk) 20:46, 9 January 2014 (UTC)

Looking forward to a mature version of the Typography Refresh
I was specifically looking for a way to not have paragraphs span across the entire width of my widescreen (16:9) monitor. I was very happy to see that the typography refresh creates easy to read columns. This is a good idea. I'm sure it's why newspapers do it on their web editions. I would like to see the column itself centered. As of now it's too far to the left when the browser is maximized, and monitors are only getting wider. 66.65.172.106 16:13, 12 January 2014 (UTC)

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)
 * This is a good idea, and we've heard it brought up before. Moving elements like images, infoboxes, etc. in to that right-hand space is not out of the question, though it's fairly complex to do well when so many of these are dependent on templates. Steven Walling (WMF) &bull;  talk   18:47, 9 January 2014 (UTC)
 * And the ToC of course. plus JS toggle might help. But to begin with, I'd go just slightly wider than this. With the font-size increase and info boxes taking up a third of the remaining space, this is just a bit too narrow for my taste atm (and I'm on a 13" laptop). TheDJ (talk) 20:27, 9 January 2014 (UTC)
 * You might already know about it, but Magnus Manske has a demo proposal of what this might look like, which I think looks good. I don't know how usable it is as currently written, though. Imo the current beta max-width look has two problems by comparison: 1) asymmetrical, with whitespace on the right but not left (and the header extends above the whitespace, making it look extra-gaping), and 2) everything pushed into a narrow column including all the flow-around boxes gives a cluttered feeling (at least to me). --Delirium (talk) 20:30, 9 January 2014 (UTC)
 * I really like many aspects of Magnus' demo. 2 problems that jump out: it doesn't work at all on small screens or in small windows (try reducing the window size - below 1024px width it starts to look bad), and it completely removes the option of using thumbnails larger than 220px (eg larger lead images, or wide panorama shots). Those aspects would need to be thought about in any design that utilized forcibly split-columns. –Quiddity (talk) 22:40, 9 January 2014 (UTC)
 * The demo is interesting, but I don't actually think it is a very pleasant layout, Having the images small and completely pulled out of the text looks very dated to me. It can be quite nice to have images break up the text, the article in the demo is not just a huge wall of grey text, I don't think that is good from a UX or visual design point of view. But it does start to get at the point of what we were experimenting with. When you have a narrower measure for your text with the larger text size it is (arguably) easier for people to read. What it also gives you is room to highlight relevant non-text content, Images, galleries, content from sister projects like wiktionary and wikisource. You could also imagine a situation where you had a two column layout with the article on one side a second functional column such as Flow for discussing the article or Translate UI for translating the article side-by-side. Try not to imagine the narrow measure as an end of itself, but as a means to an end.
 * Jaredzimmerman (WMF) (talk) 23:45, 9 January 2014 (UTC)

The 715px max width may be good for small monitors, but on most modern monitors that's just too narrow (expecially in the era of 1920x1080 and larger) interfaces. Hasteur (talk) 20:02, 9 January 2014 (UTC)

On my wide monitor, the narrow max width looks awful, and pretty much renders the typography refresh unusable for me. Please roll back that part of the update, or at least provide some css so that I can disable it myself. Thanks. —DoRD (talk) 20:45, 9 January 2014 (UTC)
 * Indeed. I find this to be ludicrously narrow, disrupting the display of tables and crushing text around infoboxes and images. I've been enjoying the typography refresh so far but this has driven me to deactivate the beta for myself. I see I am not alone in this. - Dravecky (talk) 20:59, 9 January 2014 (UTC)

Not actually sure what this is supposed to 'fix'. If people find their screens too wide to read, they will make their browser window narrower. This isn't exactly typography-related either; it is a layout change. In web design, some thing are best left to the browser. — Edokter  ( talk ) — 21:26, 9 January 2014 (UTC)
 * Agreed. I've had to disable this feature now as, frankly, having very narrow page displays is just annoying. Internet pages used to be this width, but then we all got wider, higher res screens and moved on. As Edokter says, I too don't understand what this is supposed to fix and as a result it just looks like a backwards step. Danno uk (talk) 22:52, 9 January 2014 (UTC)


 * As someone who isn't a fan, I can explain the logic behind all the studies that prove a narrower column-width (and larger font-sizes) lead to increased content understanding & retainment - It's a matter of eye-movement, whereby if the eyes have dozens of centimetres to travel to find the beginning of the next-line (or have to squint to read tiny type), that is a tiny increased cognitive load. It's partially why ye olde gigantic printed dictionaries and encyclopedias use multi-column layouts, and ditto for many current magazines and newspapers. The width of an average book page (paper/trade/hard) is: cost-effective to print/transport, and easy to hold/carry/store, but also easy to read with minimal effort (particularly by demographics without perfect vision or peak language fluency).
 * That said, I think there's a difference between reading a page in-depth, and scanning/skimming a page looking for content. I'd suggest (with no scientific evidence) that a very-wide page is preferred by many editors because we spend so much time scanning back-and-forth and up-and-down (articles/documentation) looking for sentences to re-write, and paragraphs to shuffle amongst sections, and images to align with content chunks, as well as glancing rapidly through gigantic talkpages looking for keywords or keylinks or usernames that warrant closer attention (eg, "oh look, someone mentioned category:X which interests me, I guess I'll read this thread...").
 * Overall, I think this is a highly-subjective point, i.e. there are legitimate rationales in each direction (both towards clarity/sparseness, and towards density/compactness). I usually prefer great-density (I want as much detail on-screen as possible. I purposefully use small fonts, on a largish monitor. If there's wasted space, I'll tile the windows so that they overlap. I often tile windows if I'm going back and forth between 2 programs/pages a lot. Etc.); but occasionally I'll use a bookmarklet to minimize everything and zoom the font in, so that I can lean back and read a site slowly and carefully. Relatedly: There's a very interesting script linked in this design mailing list post (scroll down to the screenshots, or go straight to the script/css to be pasted into your vector.js/.css), which I've installed on Enwiki, and I like having as an option, but not as my own default. I can certainly understand how some people would prefer to have it (or something like it) as their default though.
 * HTH. –Quiddity (talk) 22:49, 9 January 2014 (UTC)
 * No, this is clearly a bug. The intent, to ensure the width of the text is reasonably short and thereby improve readability, is fine. But limiting the length of the bodyContent div to a fixed pixel width is the wrong way to achieve that aim, for at least two reasons. First, this div contains things other than paragraphs of text (it includes diffs, for instance, which appear in two columns, and it includes floated content like images and sidebars, thereby reducing the actual text to less than the desired width); second, specifying the width in pixels takes no account of users different font sizes, screen or window sizes, etc.86.149.168.38 23:28, 9 January 2014 (UTC)
 * But it's the user who should be in control and decide how wide the text should be by adjusting the browser window, the stylesheet designer shouldn't force a specific pixel width upon us! Cogiati (talk) 14:19, 14 January 2014 (UTC)

I mostly like it. As Quiddity pointed, it makes reading long articles much more pleasant. On my wide screens (1680x1050 and 1920x1080), lines were too long to be read comfortably and even long paragraphs did not span more than a few lines. But to make this update complete and really operational, non-text items should be removed from the article body and flushed to the right column ; except for tables and maybe wide pictures if they stay clear of text on both sides. Kept inline, these items just get in the way of reading. This layout would miss a way to link article text to pictures, maybe some kind of new illustration reference (like source references but pointing to illustrations on the side) could be introduced. One last point : on wide screens again, it is disturbing that the main column sticks to the left panel ; it would probably look more natural (or less disturbing) if it was centered, with white space on both sides. --EdouardHue (talk) 23:37, 9 January 2014 (UTC)


 * I was disappointed with this addition and had to disable the feature as a result. I wish it was an optional setting as I liked other aspects of what this feature provided. --Varnent (talk)(COI) 05:49, 10 January 2014 (UTC)


 * I'm afraid to say that I've disabled the feature as well. The large amount of white space created on large monitors does not go well with the user menu in the top right, which starts to look very lonely. As for the bunched-up content, enwiki's Main Page is one of the victims - Mark Schierbecker's screenshot illustrates this well. — Mr. Stradivarius  ♪ talk ♪ 06:10, 10 January 2014 (UTC)

I've disabled this feature. It looks *absolutely godawful* on modern widescreen monitors, wasting a high percentage of screen space. If the goal is to reduce paragraph width, the solution needs to be introducing multi-column layouts, not artificially forcing everyone's viewing back to the SVGA era Too bad. 174.236.69.160 08:14, 10 January 2014 (UTC)

I'm truly shocked somebody considered even trying the fixed page size. What is this? Back to the 90's of the Internet? I always admired Wikipedia for using responsive design much earlier than other mainstream websites, and I think it is absolutely not an option to introduce fixed-width pages in 2014. —Volgar (talk) 09:39, 10 January 2014 (UTC)


 * Agreed. I also had to disable this feature as well (after I had found out that this was actually not a bug – I thought something with my vector.css was broken). While in Wikipedia articles I could imagine that some people would find it helpful to have not too long rows (but these people can just adjust their browser window as mentioned above), in longer discussions, on pages with large tables, on image description pages etc. this is just VERY bothering. And yes, why would you dictate people with wide screens that they have to use a fixed width and have half of their screen left blank? Please undo. Yellowcard (talk) 10:38, 10 January 2014 (UTC)


 * I actually like it, as you can browse in a full screen window and still have reasonable short lines, but the I have to agree with 86.149.168.38 that the current solution isn't optimal. I tried


 * instead, which looks good (though I didn't test it on many pages). --Schnark (talk) 10:41, 10 January 2014 (UTC)
 * Why the heck would I want Wikipedia to not make use of my whole screen? I hate the idea and have gone ahead and inserted the code posted in a lower conversation into my vector.css page to remove the width limit. I really like the other features that were added at the same time (change in typography in article text, removal of borders around pictures) but it seems pointless not making full use of the whole screen - especially since Wikipedia automatically adjusts to the width of your browser/screen anyway. Jr8825 (talk) 11:17, 10 January 2014 (UTC)
 * And a few afterthoughts: If the purpose is to make it easier to read, why not develop a reading button (along the top pane along with 'view history' and 'edit' etc.) which turns the page into columns or moves pictures to the side? That way people can choose to use it, it is easily to enable and it doesn't force itself upon anyone. I don't like the idea of just reducing everything into one single column, if people are moving towards fixed-width columns couldn't a feature be developed that fits two or three columns into the page depending on the screen resolution/width? Therefore it's still smart and fills up the screen but it also make it easier to read. Jr8825 (talk) 11:25, 10 January 2014 (UTC)

You state accessibility as one of your goals and you stress that visual impairments must not get in the way of access. I'm afraid that a fixed maximal width that is measured in pixels works against this goal. Some visual impaired people (like me) work with big screens and huge fonts, i.e. they scale everything up. This works very nicely as long as I do not run into fixed pixel measurements. There is also another point. In the time of CRTs the pixel densities of the monitors didn't vary much but today we have to work with an extreme range of pixel densities of which many would not work well with a fixed pixel width optimized for some commonplace monitor configuration. In summary, if you want to set any width limit at all, do it in ems, not in pixels. If this is found necessary, reasonable values should be at least 60 or 70 ems. But I think that this should be better kept easily configurable because it depends on so many factors (reading distance, for example) which cannot be generalized. --AFBorchert (talk) 12:46, 10 January 2014 (UTC)

715px is too narrow. I think 900px would be OK.--Portal3046 (talk) 05:18, 11 January 2014 (UTC)

I disabled the feature because I like to use the full width of my screen. It's a pity since I liked the other improvements especially the increased difference between the section and sub-section headings. Would it be possible for each reader to decide in its preferences the width he likes ? With, of course, an option for "full screen width" ? Thank you.--AnTeaX (talk) 11:09, 11 January 2014 (UTC)


 * I disabled the feature because of the very narrow width, too. This is no improvement. --Cepheiden (talk) 20:58, 12 January 2014 (UTC)

I am chiming in to object to this as well. I don't think it looks good in articles, but it's especially bad outside of the mainspace. Crimping to that width makes the entire Portal namespace look just awful. Most portals use a two column format (like the main page does). When I review portals for Featured Portal status, I look to make sure that the portal looks good in what I consider "low-width" resolutions, like 1024× [whatever], 1280× [whatever] , and 1366× [whatever] , because I know that not everyone has a 1600px wide screen like I do, and it's important for it to look good on smaller screens. To go any smaller than 1024 though (especially when taking into account the vector bar) makes portals look cramped and lowers the utility of the namespace. Sven Manguard (talk) 22:58, 12 January 2014 (UTC)


 * I have also disabled this. I have a wide screen display (1366X768), and having half of my screen blank, and everything else shoved to the left side of the display is both ugly and inconvenient. I understand the desire to make the extension usable on as many systems as possible, but setting a fixed resolution at circa 1995 levels is a bit ridiculous. My en.wp userpage is designed to look good on most modern displays (the userboxes are fixed width, while the collapsible frames for the various sections are set at a variable width). It looks nice (with no overlap) with any horozontal resolution of 1280 pixels or greater. It looks terrible with a max width of 715 px. I won't even go into the frustration of dealing with long article talk pages, which now become a scroll-fest of epic proportions when looking at a threaded discussion with multiple active sections actively being edited.
 * What are the current stats for user screen resolution among our readers? Is there a substantial proportion of editors using resolutions so low that a 715px width is essentially a full-screen display? Horologium (talk) 03:48, 13 January 2014 (UTC)

narrow columns are good for reading... but what kind of reading?
Maybe one reason why so many of us find the narrow width completely unusable is that we don't read Wikipedia pages in the same way that we read the types of writing that benefit from narrow columns. I almost never treat a Wikipedia page as something to be read from beginning to end. For Wikipedia articles, I first look at the overall structure of it, and then (without thinking about it too much overtly) starting zooming in on the places I think have the information I'm looking for. Likewise, talk pages and other Wikipedia pages aren't the kind of texts that are meant to be read linearly. I really like narrow columns for blogs, newspaper articles, and other web prose where there's a linear text (usually unstructured or lightly structured, in terms of headings and subdivision) that I'm reading from the beginning onward. But I don't think that's a good fit for wikis; it may make it easier to read and comprehend from beginning to end, but at the expense of being able to navigate the page and grok its structure. The latter matters a lot more for wikis than other types of reading.--Ragesoss (talk) 18:39, 13 January 2014 (UTC)


 * It is the user who should decide how wide a webpage should be, not the stylesheet designer! I can control the text by adjusting my browser window... Also note that I often use Wikipedia in extremely high zoom levels (300-500%) because I often use it as a foreign language learning tool and it's useful to let people far away from the screen to be able to read it so I zoom highly, but this doesn't work well with the left sidebar and the max width forced upon the user by the stylesheet designer. Why not let the user be in control? Cogiati (talk) 14:16, 14 January 2014 (UTC)


 * Just adding another voice to the chorus who don't like the width limit. I can make my browser window as wide as I prefer—when pages insist they don't want to use that space, it is annoying. The Wikipedia main page, which is already divided into columns, looks particularly poor with this setting. I've turned the beta off for now while this is in effect. If it is put in for real, please make it something we can turn on or off. —Salton Finneger (talk) 16:31, 14 January 2014 (UTC)


 * +1 to Ragesoss' explanation. That's exactly what I was trying to get at, just above. –Quiddity (talk) 20:13, 14 January 2014 (UTC)

Analysis/screenshots
I just learned of the typography refresh beta when it was mentioned on a talk page at the English Wikipedia. Upon enabling it, I assumed that something was broken on my end. I was very surprised to learn that the fixed width is intentional. As others have noted, such an approach seems downright antiquated. It's been noted that "one of the main points of this beta feature is consistency", with an em-based approach rejected because "different languages use different base em sizes to properly scale their type". But what about consistency across different displays? A fixed width causes a particular wiki's white space to vary wildly (depending on resolution, window size and text size). Some have suggested increasing the width by 50x, 100px or 200px. This might help under some configurations, but it would barely make a dent under others. As an example, let's look at the English Wikipedia's Wikipedia article at various resolutions (with a full-screen window and the default text size). 1024x0768px: Typography refresh beta disabled | Typography refresh beta enabled 1280x1024px: Typography refresh beta disabled | Typography refresh beta enabled 1600x1200px: Typography refresh beta disabled | Typography refresh beta enabled 1920x1080px: Typography refresh beta disabled | Typography refresh beta enabled 2560x1440px: Typography refresh beta disabled | Typography refresh beta enabled 3840x2160px: Typography refresh beta disabled | Typography refresh beta enabled Surely, the results seen at higher resolutions don't reflect the intent behind the change. I don't understand why this method is even under consideration. —David Levy 07:25, 15 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)
 * Yes, that's correct. We have tried to account for this by increasing the line height of titles (i.e. h1 elements) so that there is enough space to provide some balance. If anyone would like to suggest a common serif to emphasize other than Georgia, suggestions are welcome. Overall, we're aiming for a serif that conveys a serious, encyclopedic feel. Steven Walling (WMF) &bull; talk   18:45, 9 January 2014 (UTC)
 * Does Georgia (or a similar font) have the ability to specify a "lining numerals" variant? The traditional typographic practice with old-stye numerals wasn't to use them throughout, but to use both types depending on context. Old-style numerals would be used in body text, and then lining/title numerals would be used in headings and titles. --Delirium (talk) 22:09, 9 January 2014 (UTC)

Something like this will force lining numerals in modern browsers where appropriate (although the user may need to have a recent version of Georgia installed too): Is this something that could be incorporated into the refresh? the wub "?!"  00:09, 10 January 2014 (UTC)
 * Sounds pretty reasonable. I'll make sure we run it up to the designers in our next meeting about this. Steven Walling (WMF) &bull; talk   00:17, 10 January 2014 (UTC)
 * For those not familiar with the rationale behind "old-style figures" they are created to bend in better with written text. the wub, this would be one totally valid way to fix the bottoms of letters being clipped off, adjusting the line height would be another way, when we meet next time to iterate on the Typography refresh, I think this is a good idea and we'll definitely evaluate it against some other options
 * Jaredzimmerman (WMF) (talk) 00:58, 10 January 2014 (UTC)

This is my only problem with using Georgia (or any typeface that uses old-style numerals [OSN]) in headers (or in articles either). OSN's are a nice typographic feature for signs, posters, or simulating something that might have been written in the 1700s or 1800s. It's just distracting and difficult to read in most modern uses, especially in an encyclopedia. We want to make things easier to read, so why make the numerals more difficult to read? If you pick a typeface that avoids OSN (and any CSS "hacks" necessary to "fix" the line spacing as shown in the examples above), then you will have something that will work in ALL browsers, not just the "modern" ones. I also think that doing so is more in line with the goals of this refresh. And if the font on the mobile edition doesn't match, then just change the font there. That will improve the mobile version, too. &mdash; Will  scrlt ( Talk | w:en | com | b:en | meta )  17:50, 12 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)
 * There's a user preference for link underlining... we should probably simply respect that? --MZMcBride (talk) 23:05, 9 January 2014 (UTC)
 * Just because something is not widely used doesn’t mean it is cleaner. For example the letters ‘g’ and ‘q’ look exactly the same in an underlined link (Bugzilla etiquette). So it increases readability to use the border-Version. But I agree with MZMcBride, the user preference should be respected. —MRosetree (talk) 07:45, 10 January 2014 (UTC)
 * Strongly disagree. I could not support any change that blatantly screws up proper typography standards in the way that was suggested. The bottom border is a block-level style. Underlining is an inline style. If you had something two lines long that was underlined using border, it would underline the bottom of the two lines, but the top would not be. Even if you "hack" the CSS so that it is set to in-line, the semantics would be all screwed up. You use underlining to underline, not a border. Borders sit outside of the text (which is why you like it, since the underlines drop below the descenders), but that's not the way that underlining works. Underlines are supposed to appear under the baseline of the text, which means that they likely will cross the descenders. That's what is supposed to happen. If a typeface doesn't allow enough room between the baseline and the descender such that it becomes unreadable, then just pick a different, better designed typeface. &mdash; Will  scrlt ( Talk | w:en | com | b:en | meta )  17:56, 12 January 2014 (UTC)
 * Ok, I didn’t knew that. This is a point I can agree with. &mdash;MRosetree (talk) 07:27, 13 January 2014 (UTC)

blockquote
On enwiki, blockquotes are showing in italics, and much larger than the font-size: 85% set in Common.css. Here it is not italic. "Lorem ipsum dolor" --Gadget850 (talk) 20:42, 9 January 2014 (UTC)
 * Italicised blockquotes were killed already, the change will be visible on en.wp too soonish (with wmf10 at the latest, see MediaWiki 1.23/Roadmap). Matma Rex (talk) 21:07, 9 January 2014 (UTC)
 * I support this change. Excessive italics should be avoided. But I have an other problem: In my Windows 7/Opera 12/GDI setup the contents of the blockquote look like they are bold. The blockquote isn't only bigger and uses an other font, it looks like it's double the weight as the rest of the text. The debugger shows that the calculated font weight is the same in both cases (400) but the font family and size is different (16.9px instead of the normal 14.08px). Dimming the currently used  slightly down to   fixes the problem (reduces the calculated size to 16.47px). I did not tested it with other browsers and configurations but I'm pretty sure that 0.03 will not make a difference in most other cases. --TMg 19:27, 10 January 2014 (UTC)

In enwiki (vector skin) using Safari on Mac (most recent versions, default everything), blockquotes just started appearing at 17pt in italics, compared to 14pt body text. It is way too big, folks. Zero0000 (talk) 06:56, 11 January 2014 (UTC)
 * The italics issue has been fixed but not yet deployed. The size has not yet been fixed. We can always override it on enwiki through Common.css. --Gadget850 (talk) 11:59, 11 January 2014 (UTC)

Max width / Narrow pages opt out option
As with all experiments, there is always something that might be seen as a little controversial / whacky to some users. It seems this time round the max-width is upsetting users.

If any one wants to disable the max width part of this experiment on this opt in feature, feel free to add in your Vector.css e.g. User:Jdlrobson/vector.css the following css to disable it. Please do not apply this rule somewhere stupid like MediaWiki:Common.css where you will effect all users and not allow constructive discussions around this part of the experiment to take place. Jdlrobson (talk) 21:05, 9 January 2014 (UTC)


 * You mean "affect" and using the word "stupid" in this context is probably a poor idea. --MZMcBride (talk) 23:03, 9 January 2014 (UTC)
 * I can't agree more with MZMcBride.--William915 (talk) 09:36, 10 January 2014 (UTC)

Pages gone narrow when logged in.
Is checking this option supposed to be making all Wikipedia articels narrow (except when previewed from edit source)? I've unchecked it for now, and the pages are fine again, but how will I know when the bug is fixed? This is true for both IE9 and Firefox. It was also okay when not logged in, but...

Graham.Fountain.
 * Disabled it for now too. It looks similar to the Flow discussion style, which does not work for article space at all. - Hahnchen (talk) 21:22, 9 January 2014 (UTC)
 * The general refresh seemed promising, but I disabled it now as it seems this was "by design". Too bad, it sounded like a good initiative. Disabled, let me know when you're back to normal width and I'll happily try again. Effeietsanders (talk) 21:01, 10 January 2014 (UTC)

Narrow pages: centering content
I've seen the new display of pages as narrow, which is a great thing I waited for a long time: on wide screens, it was difficult to follow lines in an article. But I would have a suggestion: display the page content at center of the screen. Indeed, on my screen, the page content only covers one half on the screen, on the left, which makes it very uncomfortable and very bad looking, with the whole right half of the screen made white.

Another way would be to display the content using two columns.

Epok (talk) 21:27, 9 January 2014 (UTC)
 * I agree in principle with a fixed column width. However, I use a 2560x1600 monitor and while I know that is rather uncommon, it looks horribly off-centred and unbalanced. Even on my laptop which is 1366px wide, the column width looks much too narrow to me. Centring the column would certainly minimise the issue. I'd like to see it a bit wider still though, to better fit the vast majority of displays (according to this, 90% of displays are at least 1280px wide, and 99% of displays are at least 1024px wide, and those stats are a year out of date). I'm not suggesting we set the column width to 1280px or 1024px necessarily, but something not far off would be a better compromise between compatibility and viewability. Diliff (talk) 23:24, 9 January 2014 (UTC)
 * You could try adding

to your personal css. That should center the main body content.--Salix alba (talk) 00:18, 10 January 2014 (UTC)
 * Das geht garnicht. und tschüss.--Mauerquadrant (talk) 05:46, 10 January 2014 (UTC)
 * Tested here, don't work. Maybe I'm putting it in the wrong place? Note: I'm using style vector. Epok (talk) 08:41, 10 January 2014 (UTC)
 * Try


 * In your vector.css. This has a simpler selector. Its working for me in en.wikipedia using chrome. You may need to refresh you browser to get it to work.--Salix alba (talk) 09:09, 10 January 2014 (UTC)
 * Yep, this version worked! Thx, much better. Epok (talk) 09:21, 10 January 2014 (UTC)
 * I'm not that keen on editing my own CSS - I've already disabled the typography refresh on my account as I didn't like what it did to the pages. If we're all editing our own CSS to get it looking the way we like it, how is that helping move the typography refresh forward? I assume that overrides the settings that the beta? Surely it's better for us to test what is implemented for everyone participating in the beta and provide feedback on that? Diliff (talk) 09:47, 10 January 2014 (UTC)

Infoboxes and tables not considered
Sorry, but the current limitation is way to narrow. And why pixels? Why 715px? It simply feels wrong if half of the screen space is wasted. Currently it's like the Vector design is broken somehow. The rest of the design does not reflect the change. Most important problem: Currently this results in lines of only 50 to 60 characters if there is an infobox template, an image, climatic diagram or something like that on the right. People are using this space a lot when designing articles. There should be enough room for at least 80 to 100 characters even with an infobox template on the right. A typical infobox is 250px to 300px. PS: I forgot all non-article pages like the main pages and portals. They are all using columns. Mostly two columns, sometimes three columns. With the proposed change all these pages are excessive scrolling stripes of sometimes only 20 characters per line. Even the most narrow newspaper style does have longer lines. An other example are gallery pages. Now it's impossible to use images larger than the proposed 715px without breaking the design.
 * 1) Please expand the max-width to something like 1000px.
 * 2) Please provide a solution to turn the limitation off for big tables.

PPS: Regarding the infobox templates. When looking at an article like de:Flugplatz Buochs with a single infobox template in the top right as the only non-text element, it feels like the infobox must be outside of the text. I created a mockup to show what I mean. Being able to put infoboxes and images there would solve many current problems. I'm sure many user would love and use this. It doesn't solve the problem with big tables, though. I think the best way to solve this is to turn the limitation of for specific elements like big tables. Something like  for big tables,   for images and   for infobox templates as shown in the image. --TMg 16:39, 10 January 2014 (UTC)


 * We are considering this. One of the main motivations for making the space on the right was to explore putting infoboxes and other media here. It feels like this may warrant a separate beta experiment though in my opinion :) Jdlrobson (talk) 23:56, 10 January 2014 (UTC)
 * I don't think this can be separated. "Waste space first, make use of it later" is not going to work. See all the complaints here. If you want to separate this you need to remove the width restriction from the current feature set.
 * I'm using the limited width layout for some days now to see what happens and if it becomes familiar after a while. Here are my findings:
 * Even if I'm starting to get familiar with the layout I still have mixed feelings. I still find it to narrow. The benefit of the short lines is outweigh by the increased need to scroll. With the current width I find the disadvantage of the additional scrolling much more distracting than the disadvantage of long lines. Every time you have to scroll you have the same problem as with long lines: it's hard to find the right line again. Please find a better balance. 100 to 120 characters per line are no problem nowadays. People are used to this.
 * .js and .css subpages (in the MediaWiki: and User: namespaces) must always use the full width.
 * Diffs should never be limited in width but currently are.
 * Take care of the mixed "diff at the top, preview at the bottom" settings with both action=view and action=submit.
 * Currently the preview isn't limited in width but must be similar to the final article.
 * Take care of the live preview settings.
 * --TMg 14:21, 13 January 2014 (UTC)

Margins when mixing paragraphs and lists
I know I'm nitpicking. That's the point of my posts. ;-) Please don't get me wrong. I like almost all the changes (bigger font size, more line height, more margins). However, here is one of my nitpicking issues: First paragraph introduces list: Second paragraph introduces list: With the typography refresh enabled it's like the margins are switched. The margin at the bottom of a list (between a list and a paragraph) is smaller than the margin at the top of a list (between a paragraph and a list). It should be the other way around.
 * First list
 * Second list

For comparison: With the typography refresh disabled these margins are equal. I never liked that for the same reason as above. In my opinion the bottom margin of a list should be slightly bigger than the top. I'm not sure if this is a good idea in all possible cases where lists are used. I know it will be good in most cases since almost every list does have an introduction and only very few do have footnotes. If you are not sure please make the margins equal again. --TMg 18:41, 10 January 2014 (UTC)

Enlarge image icon
Why was the "enlarge image" icon removed? I'm afraid this will cause existing pages to contain copyright infringements. Yea, I know this sounds strange. Let me explain. Sometimes images are used like they are simple imagemaps, using the relatively new  parameter as shown in the example on the top left. With the magnify clip this wasn't a problem. The file description page could still be reached. When removing the icon all pages with such images will have an ugly licensing problem: you can't reach the file description page any more.

Oh, and while you are at it, please make the design of the ever misplaced "i" icon of the imagemap extension fit (example at the bottom right). --TMg 19:04, 10 January 2014 (UTC)
 * The ImageMap extension allows you to control the placement of the blue icon. — Edokter  ( talk ) — 20:24, 10 January 2014 (UTC)
 * I'm not talking about the position but about the design of the "i". It always looked weird compared to the Magnify-clip (sans arrow).svg icon. --TMg 13:19, 13 January 2014 (UTC)
 * Best place to discuss that would be at Extension talk:ImageMap. — Edokter  ( talk ) — 22:37, 13 January 2014 (UTC)
 * If one of the icons is discussed here why not discuss the other? Users tend to use imagemaps next to thumbnails in articles. They don't draw a line between the two. Same here. --TMg 20:58, 17 January 2014 (UTC)

Why can't you center the page?
Instead of pulling the whole page left.
 * Because we've got plans for the right side… but we might want to adjust the margins a bit next iteration.
 * Jaredzimmerman (WMF) (talk) 04:36, 13 January 2014 (UTC)

Left Aligning
Left aligning the whole page doesnt really look well, especially for users who have really adjusted themselves to center aligned page. When all of a sudden, I viewed the new Typography refresh beta update, it gave me really a complex look, and I didnt wait any longer to revert the update. I hope Wikipedia will reconsider this update. Anandtr2006 (talk) 14:24, 11 January 2014 (UTC)

Thumbs border removing?
«''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.''» — That is a really bad idea. All the pages that have extensive picture usage have now transformed into hardly readable mixture of main text and captions. Check, as an example ru:Письма_махатм_А._П._Синнетту. You can see also that the font in the captions is the same in size now as in the main text, that brings even more confusion. --Melirius (talk) 13:41, 12 January 2014 (UTC)
 * Aha, the last point (about caption font) is connected to the magnification of the font in FF by Ctrl+, and it is not existing in the default size, where the difference is clearly visible. But this is still an issue to be solved: after the first magnification the difference is substantially decreased and after the second perceived difference disappears. --Melirius (talk) 13:48, 12 January 2014 (UTC)

I suggest also to make an option that allows one to show borders or switch them off for a thumb. --Melirius (talk) 13:50, 12 January 2014 (UTC)

A bit wider?
It's really good to see this project responding to feedback from users; it's really improved over the last few months. I still get the feeling that the current chosen page width is a bit too narrow, particularly on pages such as the enwiki Main Page: have you experimented with making it perhaps 50 or 100px wider? I also wonder whether you have experimented with A/B or multivariate testing on this? -- Giadiniera (talk)

Solve the width problem by making it user-configurable
Perhaps we could allow configuration of the narrowing or widening of the default screen width become a user-configurable option. Something like we have now under Preferences > Appearance > Files > Thumbnail Size. The options could read: Tiny (320px), Narrow (620px), Default (715px), Wide (960px), Full-screen. The numbers are just examples; feel free to substitute other values that make sense.
 * The "Tiny" option matches the width of many mobile devices. In fact, this could basically just trigger the standard mobile interface so that we don't have to reinvent the wheel.
 * The "Narrow" option would be the minimum width we can see being the narrowest usable screen size. 620px fits in a standard 640x480 monitor resolution (allowing 20px for browser borders and scroll bars). Nobody uses 640x480 anymore you say? Not true! Many people with limited vision use very low resolutions to "scale up" the size of everything on their screen automatically (higher resolutions make text and other things appear bigger, thus easier for people with vision problems to read more easily). Yes, there may be some issues with divs, TOCs, tables, etc., but we are trying to do our best here, and it establishes a goal to design for.
 * The "Default" value is the 715px that is currently being bandied around in this proposal. Whatever "default" size is picked would go here, and it would be selected by default for all new users and for users with no accounts.
 * The "Wide" would be a comfy size for people with wider screens. It probably also should center the main body text on the screen and do any other changes that people are suggesting (like moving thumbnails outside the body text flow). It would be for those people with plenty of screen real estate. Don't like it? Just change back to default.
 * The "Full-screen" option would basically leave everything the way it is now. The text sprawls all the way across the screen. For folks with unusual screen dimensions, this might be a better option than any fixed size. Also, for people who like to have the text flow all the way across the screen, this would satisfy them.

To test this, the functionality could be implemented as a Gadget initially. Eventually, if successful, it would be rolled out into the interface. It should become part of Preferences > Appearance, under the Skin section. If a skin supports these default widths, then the preferences options would appear. If not, they would be dimmed out (disabled). This could be determined easily by adding a setting inside the skin's file. If the option is supported (i.e., the skin is updated to support these features), a directive (like "narrow-width:620px" or "full-screen:yes") could be added to the template, and preferences would only have to check that file to see if a width is supported and how many pixels it is (715px might be the default for Vector, 720px for Modern, and 721px for some other skin).

This level of configuration would be a big benefit for both end-users and for skin designers. It also would provide flexibility down the road as screen dimensions change, and also help designers trying to design new skins for people with disabilities or for new technologies that have a totally different output geometry. It also would satisfy people who like the text wide and sprawling, and those would think that narrow and compact is more readable. Personally, I think it depends on the device you are using to output (huge difference between how any site looks on my netbook screen vs. my HDTV). No designer can properly design a site to look good under all conditions, especially since it's a subjective decision anyway. Leaving the user in control is the best way to "fix" this problem. But, giving them a reasonable default is very important, too.

What do you think? &mdash; Will  scrlt ( Talk | w:en | com | b:en | meta )  18:23, 12 January 2014 (UTC)


 * I would suggest that an on/off switch also be included on the individual pages, so that the user wouldn't need to go back and change their default settings for each situation. The page would always open with the user's or wiki's default width, but the switch would release the width restriction to expand the contents to the full window width. This would be useful for making as much of the article, image gallery, or commons category as possible visible within the window. I see it working somewhat like the wrap/nowrap selection on some text-editors, with perhaps even a keyboard equivalent like ctrl-w to toggle back and forth.Nonenmac (talk) 20:29, 12 January 2014 (UTC)

DejaVu Serif Bold looks awkward in headings
Look at Main Page, the headings like "From today's featured article" look awkwardly ugly. The letters look like being smashed down and stretched horizontally. While I understand that this is a typeface peculiarity, I really don't think this should be used on Wikipedia and sister projects, especially as it is so noticeable on the Main Page. Timothy Gu (talk) 19:32, 12 January 2014 (UTC)

Max-width and large fonts
I have a wide monitor but I routinely tell my web browser to increase the font size for all web sites to avoid eye strain.

Needless to say, a "maximum width" that is based on displayed-pixels rather than "what would have been displayed, if it were displayed at 100%" pixels means I have a lot fewer words-per-line than is sensible, given the large amount of "unused" screen real estate.

My recommendation: Ditch the mandatory maximum-width-in-pixels, but enable it as a Preferences: item with a default of "no maximum."

70.251.134.187 21:29, 12 January 2014 (UTC)

All pages width shrunk
Some days ago the width of all Wikipedia pages went narrower than previously, I don't know why. I switched off "Typography refresh" because of this. --Misibacsi (talk) 21:42, 12 January 2014 (UTC)
 * "It's not a bug, it's a feature" - and one that many are finding faults with. See  above for opt-out instructions.  Davidwr (talk) 02:44, 13 January 2014 (UTC)

Mixing serif and sans serif
I think that using serif section headings and sans serif body text is silly looking. If the goal is to improve readability, I don't think that serif versus sans serif makes much of a difference at that size. If the goal is to look more classy or more professional, I think it backfired. Sorry, Sven Manguard (talk) 00:23, 13 January 2014 (UTC)

P.S. I'd much, much rather all sans serif than all serif. I don't see an issue with the font in use right now, to be honest. Sven Manguard (talk) 00:24, 13 January 2014 (UTC)
 * I'm very sorry but I have to disagree. The headings font is the most important change. One of several reasons: Level 3 to 5 headings were almost indistinguishable and level 6 headings looked exactly like bold paragraphs. --TMg 15:04, 13 January 2014 (UTC)


 * "Silly" is fairly subjective. If we were using Comic Sans, I'd agree. ;) However, studies tend to show that users do react differently to serif type versus sans, when it comes to perceptions of seriousness, reliability, etc. This experiment by Errol Morris on the nytimes.com website is an amusing example of the phenomenon. As far as using all serif... I don't think this is objectionable per se, but as far as I know part of the goal of mixing is to more clearly differentiate headings from body text. Mixing different typefaces for headers and body is an extremely common technique for doing this, so we're hardly unusual in that regard. Last but not least: a primary goal of this experiment is to bring more consistency between our mobile typography and desktop typography. With that in mind, I don't think the design team will be removing the serif headings. As always, very advanced editors like the three of us are welcome to alter our experience using personal CSS. :) Steven Walling (WMF) &bull; talk   22:00, 13 January 2014 (UTC)
 * I want to read Wikipedia and all sites in all-serif fonts as I don't like sans-serif and I find it difficult to read, so I've customized my browser to replace all sans-serif fonts with serif ones for all sites, and I read Wikipedia in serif since the site was founded. However, when I tried typography refresh I found out it doesn't change to serif text even though I've specified serif fonts in my browser, so I had to revert back to the old Wikipedia stylesheet. If typography refresh becomes the default and I can't change it, I'll have to find another way to substitute sans-serifs for serifs, but I believe it would be great if typography refresh could be made to adhere to the user's browser fonts settings. If that's not possible, then I think it would be good to make a fork of typography refresh with all-serif fonts. Cogiati (talk) 13:56, 14 January 2014 (UTC)

While "the profession" seems to generally agree that “to more clearly differentiate headings from body text”, the type used for headings can be different from that of body text, it also generally agrees that there are limits on how much should be changed, and by what means. (“Don't overdo.” Really, any applicable book on typography—as opposed to graphics design—will explain, e.g. Tschichold's and others'.) Among the means are spacing and other visual cues (like a separating horizontal line above or below the heading), and there are about three dimensions of type along which to achieve differentiation: Together with that makes five degrees of freedom, but there are only two differences to show: heading and level! I think it is safe to assume that changes along all dimensions will be overdoing things. The design uses type, size, boldness and, in addition, spacing and a horizontal separator. The phenomenon (too many changes in appearance) is known as one form of fontitis, and should be addressed. As a side note, another traditional way to reduce (apparent) clutter is to have baselines stay on a grid where possible, thus suggesting to place headings in a box whose height is a multiple of the baseline. (Yes, even on a computer screen without anything printed on the other side. Humans do recognize regular patterns.) GeorgBauhaus (talk) 17:31, 15 January 2014 (UTC)
 * type (counting Italics etc. as separate ones)
 * size
 * boldness
 * space          (around the heading)
 * ♦ “graphical” cues
 * The headings we are using in the MediaWiki projects don't use all these degrees of freedom. Especially level 4 and 5 headings look exactly like bold paragraphs (I really wish the refresh would fix that, see below). Other levels use slightly bigger sizes. That's all. That's like 1 and a half degree of freedom for the two dimensions. I don't think what the refresh does is overdoing. Especially since the discussed level 1 and 2 headings aren't bold. --TMg 20:53, 17 January 2014 (UTC)

Level 4 or 5 heading, bold or broken definition list?
Level 4 or 5 heading, bold or broken definition list? Why not go on and fix this confusion too? I don't think the definition list should be changed. But all headings should. --TMg 20:53, 17 January 2014 (UTC)
 * Level 4 or 5 heading, bold or broken definition list?

Malfunction
I point out the malfunctioning of the Typography refresh in the beta version. All pages of Wp are blank on the right side. Removing Aggiornamenti tipografici (Typography refresh), the pages return to normal, as before. Thank you. --Antonella (talk) 01:15, 13 January 2014 (UTC)
 * "It's not a bug, it's a feature" - and one that many are finding faults with. See  above for opt-out instructions.  Davidwr (talk) 02:43, 13 January 2014 (UTC)

Missing icons for collapsible side bar and drop-down in tab bar
When I enable VectorBeta, the triangle icons in the side bar and the tab bar are missing, the CSS says something like  for the   of , which seems not to be resolved correctly. The URL should include the server and full path,  works for me. --Schnark (talk) 08:28, 13 January 2014 (UTC)


 * Hmm. I can't replicate this problem on Chrome. What browser/OS are you using? Also: can you check if you've enabled any other Beta features recently? Thanks for reporting this, Steven Walling (WMF) &bull; talk   21:54, 13 January 2014 (UTC)


 * I use FF10 (you don't have to tell me it is old, tell it to my university). You can't reproduce as you probably use a browser which uses the embeded SVG. FF10 falls back to PNG (the -hack doesn't work, as FF10 still needs the   prefix), which uses the relative path I already copied above, and which seems to be resolved wrongly. Here is the uncompressed CSS for reference:


 * I highlighted the line which is meant as fallback for old browsers, but doesn't work as expected. --Schnark (talk) 08:17, 14 January 2014 (UTC)


 * Vector and VectorBeta seem to use the same LESS file, but the compiled CSS in Vector is an protocol-relative URL starting with //bits.wikimedia.org/, so you should either use protocol-relative URLs for your paths (like in core), or claim it is a bug in RessourceLoader, and open a ticket to transform all paths to a working form there. --Schnark (talk) 10:54, 15 January 2014 (UTC)

Liberation Sans too narrow when compared with other fonts
The current font-stack is. I don't have, so I can't say anything about it, but   is too narrow, especially when compared to. The screenshot uses the default fonts in the first window, for the second window I removed. Note how different they look. IMHO the second one is much more readable, so I think  shouldn't be used. --Schnark (talk) 08:32, 14 January 2014 (UTC)
 * that looks a bit to me like it is using "Liberation Sans Narrow" instead of Liberation Sans". Would you happen to know if you have both or one them installed ? TheDJ (talk) 13:56, 14 January 2014 (UTC)
 * Another reason to stick with system fonts as requested above by simply specifying a generic font family, which is the best we can do after all (at least for normal text; headings might be given a more specific font as far as I'm concerned). --Patrick87 (talk) 17:53, 14 January 2014 (UTC)
 * You are right, I have "Liberation Sans" in C:\Windows\Fonts, but it only contains "Liberation Sans Narrow" (to be exact:, where Schmal is German for Narrow). I don't think the system administrator of my university did anything special about this font, so this could affect many Windows 7 users. --Schnark (talk) 08:39, 15 January 2014 (UTC)

Can't replace sans-serif with serif
I wanted to use typography refresh but I found out it doesn't let me change to the serif fonts I prefer reading Wikipedia in, so I was forced to revert to the default stylesheet (which does change to serif fonts when I customize my browser to display serif fonts whenever a stylesheet specifies sans-serif). Many users (myself included) want to read Wikipedia and all sites with serif fonts rather than sans-serif, and those who do often change their browser font settings to make the browser display all text with serif fonts. If typography refresh were to become the default and I couldn't change it, I'd have to find another way to be able to read Wikipedia in serif fonts. It would be great if we could make a fork of typography refresh with all fonts being serif. Cogiati (talk) 13:42, 14 January 2014 (UTC)
 * Also, as a general philosophy, I think it is the user who should decide what font to read webpages in, so CSS stylesheets should be made in a way that allows the user to replace one general family font (e.g. sans-serif) with another (e.g. serif) and still work satisfactory. Web designers shouldn't assume that users see the webpages in the fonts they specified, as many users strongly prefer serifs over sans-serifs since sans-serif fonts are difficult to read. Cogiati (talk) 13:50, 14 January 2014 (UTC)

Text should be in the center
Article text should be in the center of the screen. Sometimes users like myself use Wikipedia with very big zoom levels (300-500%), e.g. when using Wikipedia as a foreign language teaching tool or when sharing a screen with another person who is far away from the screen. When using extreme zoom levels, the distance of the text from the left side becomes far too extensive. In fact I think it would be better to place all the links currently on the left as horizontal links above or below the article text. After all, after reading somewhat into the article, we don't see the links anymore and all we see is an empty gray sidebar on the left. The perfect style for Wikipedia would be to use the whole screen width for the article text, and have the various links etc above and below the article. This would give users more control over where to position the text (e.g. I currently use a non-maximized browser window to place Wikipedia's text on the center of the screen because of the left sidebar, but if there were no sidebars I could use my standard maximized browser window just fine). Cogiati (talk) 14:07, 14 January 2014 (UTC)

Remove blue icon from images
Placing a blue icon over images is a bad idea. As a photographer myself I hate websites that place anything over my photos :) (in fact that's why I stopped sharing my photography on Facebook a long time ago). As a user, when I see an image in an article I expect to see the whole image rather than have some of it hidden by the blue icon. Cogiati (talk) 14:10, 14 January 2014 (UTC)
 * There are some beautiful redesigns of the thumb template above, and all of them (as well of the original thumb look) are vastly preferable to having an icon over the image. Frankly, I would find that putting anything over the image changes the image, and saps it of part of its educational value. That being said, the blue icon does not appear to be part of the current version of typography refresh (as it is deployed to EnWiki). Sven Manguard (talk) 20:35, 14 January 2014 (UTC)
 * The blue icon is only displayed when is used, and is not related to the typograpfy refresh beta. —  Edokter  ( talk ) — 16:57, 15 January 2014 (UTC)

In summary...
I have been testing the typography refresh locally (not on enwiki), and I must say it is not going the right direction. Knowing full well that each has their own opinion, here are my findings. Perhaps the typography refresh should be restriced to the content, and not the rest of the UI. I feels like you are trying to redesign the Vector skin, which is just out of scope of this beta, instead of just improving readability. — Edokter  ( talk ) — 17:21, 15 January 2014 (UTC)
 * 1) The constant switching of preferred fonts in the fontstack always reveals some issue on one platform or the other. Now that Nimbus Sans L is the primary font listed, I am met with a less-then-optimal rendering. Liberation Sans fares better, but is slightly narrow, but otherewise looks nothing like Helvetica. The initial goal was to have a Helvetica-like font on all platforms. In that regard, Helvetica should have remained the primary font (not Neue, as that is rarely mapped to a suitable substitute).
 * 2) I like Georgia as a header font, but realize that Linux has outdated fonts lacking Unicode support. DejaVu serif is a good second but it is just not a very pretty font for headers. If serif is the goal, perhaps a more generic serif like Times should have been chosen.
 * 3) There are some experiments with layout that have gone totally bad. First the UI links were all black, which was fontunately reverted. Now it is the restriced horizontal space that is an issue. Doing so in a hard-code value in px is a big no-no in any web layout where the rest of the page behaves fluidly, so that should be reverted as well. This is the "typography" beta; so stick to typography.
 * 4) Likewise for image thumbs. This should not be touched, as it has nothing to do with typography. In fact, every change that interferes with core- or skin CSS other then fonts should be reverted.
 * 5) All beta-related CSS is loaded after site and user CSS, which causes a lot of site/user CSS to fail, especially where non-typography related CSS is used. Make sure the CSS is loaded (if possible) before site/user CSS.
 * Regarding the fonts, I for one think that if we're going to be specifying specific fonts at all then we should be preferring libre fonts over proprietary fonts like Georgia, Helvetica, or Times, just as we prefer free software solutions when available (see Guiding principles). Those could be fallbacks for people on systems without free fonts, but shouldn't be preferred in our design over free fonts. Anomie (talk) 14:16, 16 January 2014 (UTC)
 * To what end? This would neither aid in content distribution nor promote the adoption of libre fonts.  It would merely ensure the existence of visual differences (however minor) on systems that happen to contain said fonts — arguably a penalty.  —David Levy 17:36, 16 January 2014 (UTC)
 * We certainly shouldn't contribute to the encouragement of non-free fonts. Also, I'd consider it to be people without free fonts are the ones being "penalized" by visual differences. Anomie (talk) 14:24, 17 January 2014 (UTC)
 * Ugh... we have been over this already. The preference of free fonts serves no practical purpose whatsoever. Fonts are part of the client software; they are part of the OS. All the font stack does is say "use this font (when available)". We should not "prefer" fee fonts over proprietary fonts, just as we do not "prefer" the use of Firefox over Internet Explorer, or even Lunix over Windows. The average reader is completely oblivious to this font-ideology, but it will hurt them if they are forced to use fonts that risk being illegible on their native OS. — Edokter  ( talk ) — 13:31, 18 January 2014 (UTC)
 * We aren't encouraging the adoption of non-free fonts. These particular fonts' ubiquity is one of the reasons behind their selection.  Virtually no one will obtain them as a result of anything done within MediaWiki.  Likewise, if MediaWiki were to favor libre fonts, very few users would even realize this (let alone act on it).  However, a fair number would download the libre fonts at some point (for unrelated reasons) and suddenly find that their favorite wikis look different.  How would this benefit anyone?
 * My reply already is overlapping that of Edokter (who covered the ideological issue well), so I'll stop there. —David Levy 00:20, 19 January 2014 (UTC)

Bug with the 715px layout
A couple thoughts about the new max-width layout: Neil P. Quinn (talk) 07:53, 17 January 2014 (UTC)
 * There seems to be a bug with some sidebars like this one caused by the line.
 * I really, really like the idea of limiting the article itself to a more readable width and moving infoboxes and images into the right margin. I've even tweaked my user styles to try it out for myself. Kudos for thinking big!
 * However, like many people here, I thought the size change was a bug at first and only learned otherwise after coming to this page. Honestly, the change seems much more appropriate for a nightly than a beta release—personally, I'd want to present a complete experiment (i.e. at least take a stab at dealing with the most obvious downsides and at actually moving the infoboxes and images) rather than push out a partial, off-the-cuff experiment to thousands of users who will all assume it's a big mistake and get irrationally annoyed. And I'd definitely want to separate it out from the typography refresh so it can be considered (and disabled) separately. I think you're on the right track—but I'd say do it with a bit more deliberation.
 * Thanks for sharing your custom vector.It looks great indeed. On my 1920x1080 screen, I bumped the font size to 20px and width to 1000px and it is a great readability improvement imho.Far better than just zooming in as I usually do. I also like the idea that reflist remain multicolumns. I added the "@media screen (max-device-width : 1920px)" "(max-device-width : 1280px)" to adjust my font-size in function of the resolutions of the screen I usually use. --Afernand74 (talk) 11:02, 18 January 2014 (UTC)

Rethinking Narrow Pages from the Start
I see similar debates all over this page, but I think I can reframe the issue well.

There must, indeed, be a balance between line height and line width for easy reading. On the other hand, white space should not be wasted. White space may be very useful in design, but the current design is not useful whitespace, it is waste--it is half a blank screen. How can we reconcile our need to have a body of limited width with our other need to use screen real estate efficiently or at least pleasantly? The right half of the screen being white is simply not an option. In its place, what should we do? I'll offer a few ideas, and we can discuss under each, and add more. DanHakimi (talk) 03:11, 19 January 2014 (UTC)
 * Media and Quotes. Move media to the right side of the page. Allow people to add quotes about the topic and pullquotes from the article. These will fill the space, look nice, and be useful -- the media for whatever reason it is already there, and t he quotes and pullquotes to offer more information at-a-glance. The problem, of course, is that when there is no media and nobody has put quotes on the page, this solution does nothing. DanHakimi (talk) 03:11, 19 January 2014 (UTC)
 * Table of Contents. Have the right side of the page be a scrolling table of contents. This will fill the page, and allow people to jump around much more easily. It might not be as pretty as the above, but at least it will be more consistent. DanHakimi (talk) 03:11, 19 January 2014 (UTC)
 * Building on this, what if the header of the current highest section appeared on the right, above or in the table of contents, and we used one of those javascript scrolling libraries to animate it to change when you reached the next section? That would look good, and be useful for sections that are more than one scroll-height long. DanHakimi (talk) 03:11, 19 January 2014 (UTC)


 * Two-pane system. This one would take time to make, and might be tricky... Is there some sort of system where we could have two Wikipedia pages next to one another, active at once, for comparison? I'm not particularly fond of this sort of setup, for a number of reasons, but figured I'd offer the idea. DanHakimi (talk) 03:11, 19 January 2014 (UTC)