Talk:Typography refresh

What browser (etc.) are you using?
Might I suggest that comments include mention of the browser the posting editor is using? (If others agree perhaps this should mentioned in an editnotice.) EEng (talk) 13:26, 29 November 2013 (UTC)

What do you like about Typography Update

 * Hello, I like the way section titles show a clearer hierarchy. Regards, --Daehan (talk) 10:14, 22 November 2013 (UTC)


 * Nothing, thus far. I dislike reading serif fonts on the computer, and much prefer Arial. It's not graceful or fancy looking, but it's brutally effective. I also find that when you have fonts that aren't very tall, they don't stand out as much, which kind of defeats the purpose of section headers. Finally, I dislike the change to the size of the "Username Talk Preferences Beta Watchlist Contributions Log out" bar up top. It's too small now, and even with glasses corrected normal vision, it's just at the level where if it gets any smaller it will be difficult to read. Sven Manguard (talk) 03:59, 23 November 2013 (UTC)
 * Nothing, the text is too small and I dislike the smaller links at the top. I disabled the setting after a few minutes. Frmorrison (talk) 19:14, 26 November 2013 (UTC)
 * Nothing. Not seeing any improvements, but the different font/sizes throw me off. Disabled very quickly. What was the point of this again? Seems pointless. --Piotrus (talk) 05:16, 29 November 2013 (UTC)

Small fonts even smaller?
I know it's not fair to start a discussion without having seen what you did. Sorry. But your note about reducing the font size for navigational elements confuses me. I know that many users think the font used in articles (0.8em, resulting in 12.8px) is to small. There are constantly discussions about using  or   in templates and articles. Most users (at least in the German Wikipedia) agree stuff like this makes the text very hard to read and should be avoided. In addition the current font size for all navigational elements is already smaller than the main font (0.75em, resulting in 12px). Therefor my suggestion is: Don't make any fonts smaller. Make the main font a little bit bigger instead. --TMg 13:13, 6 November 2013 (UTC)


 * Readers don’t read the navigation links very much – they mainly scan or skim over them, when they look at them at all. They become familiar and don’t contain any new words. So they have very different readability requirements than running text an encyclopedia article that may present new concepts, technical language, unusual technical characters, or foreign-language text. I would say that nav links can safely be smaller than the body text. Determining a specific acceptable size would depend on designer’s judgment, and testing in different browsers and platforms, with different readers. —Michael Z. 2013-11-07 18:09 z 
 * Reducing the font size also reduces the clickable region. Links like "Watchlist", "Talk" or short usernames like mine are already very small, hard to hit with the mouse and almost impossible to hit on a touch screen. Some of the more important links were made a lot smaller recently when [ "My talk" was truncated to "Talk"] along with other truncations. Please don't make these navigational links – thousands of users click them like a million times each day – even less clickable. --TMg 10:44, 8 November 2013 (UTC)
 * Good point. This could be compensated by padding the a elements instead of using line-height, padding, and margins on the list items, essentially making the nav items fat buttons. —Michael Z. 2013-11-08 23:29 z 
 * Yes, padding would help a lot. Currently there is zero padding in most places except for the tab bar ("Page", "Discussion" and so on) a the top. --TMg 10:46, 12 November 2013 (UTC)
 * This is basically a revert back to the mono book styling for the links. It might be wise to look into the original argumentation for this change in Vector. (if that has ever been captured anywhere). TheDJ (talk) 17:32, 26 November 2013 (UTC)

Georgia, OK. But Helvetica !?
''"While Georgia and Helvetica are fonts optimized for the web, we can see that body gracefully degrades to Arial because it is freely available on nearly every computer and operating system while being a screen-friendly typeface." '' Helvetica, and most of its clones like Arial or Nimbus Sans L, are not optimized for screen reading nor for the Web. Its original intent was signage which is the complete opposite of tiny sizes on screen. Its closed counters make it harder to recognize or distinguish some letters. There are much better options out there, Liberation Sans or Arimo (Croscore fonts) are already a bit better, but I’d recommend Source Sans Pro or Noto fonts (a variation of Droid Sans) both with more open and legible designs, fully optimized for screen reading and larger coverage. All these are available as web fonts, can be hosted on Wikimedia servers or are available on Google Fonts. Helvetica and its clones should only be fallbacks not first choice. Full disclosure: I work in the digital type design industry, and am a co-lead on the DejaVu Fonts project, DejaVu Sans LGC would be a possible option however it is not yet fully optimized for screen as some characters are still unhinted, DejaVu Sans is available on most Linux systems.

Georgia is optimized for screen reading (specifically with Windows 95 rendering) and is downloadable in MS Core fonts for the Web. If another option or a better fallback than 'serif' are needed, there are a few web fonts that could do and actually have a better coverage than Georgia. --Moyogo (talk) 09:35, 8 November 2013 (UTC)
 * Arial is heavily optimized for the screen. It contains a lot of hinting information most other fonts are missing. Hinting is crucial on Windows (not so much on Apple products). Same applies to Georgia – that's why I think it's a good choice. More important: People are used to Arial and Helvetica. This alone makes the fonts very readable. It doesn't really matter if the shapes are perfect. People recognize them instantly because they have seen them a million times before. --TMg 10:44, 8 November 2013 (UTC)


 * That recognition or familiarity of a screen font improve its readability sounds dubious. Any evidence? Even were it so, WikiMedia could start with a very readable typeface, rather relying on familiarity to bring a mediocre one up to middling. —Michael Z. 2013-11-09 00:26 z 


 * Yes Arial is hinted but it wasn’t originally designed to be used at small size, it is therefore not optimized for Web use as a body text font. The fonts I mentioned as better choices by their designs are hinted and work well on Windows. Yes, Georgia is a good choice, Helvetica is not, they are diametrically opposed. Georgia has wide x-height, open counters while Helvetica has short x-height and closed counters. In fact Helvetica would be better at larger sizes and Georgia is great at small sizes, see . For info on better legibility of open designs compared to closed designs see . I guess you don’t care about legibility, but neither about language support or character coverage and care more about not changing the font you’re used to, ignoring what people are telling you. --Moyogo (talk) 21:53, 8 November 2013 (UTC)


 * @MediaWiki design team: So many free-as-in-freedom typefaces designed for reading on-screen (Open Sans, Merriweather, Ubuntu, DejaVu, Liberation, etc.), and you go and choose Helvetica. If you only increased the ridiculously tiny bodytext size… Fitoschido (talk) 08:56, 10 November 2013 (UTC)
 * I can not support using any other body font than the default "sans-serif" simply because of the familiarity argument explained above. It outweighs every other argument. If you are in web typography, you know what I'm talking about. There is enough evidence out there. As said above I highly support increasing the body text size. I really wonder why this was not considered instead of making everything but the body text smaller. WMF, please explain (in the section above) why you prefer this solution over each other. --TMg 11:11, 12 November 2013 (UTC)
 * TMg so for you familiarity is more important than legibility, intended use of typeface, or character support? Does this means that Helvetica/Arial will be the Wikipedia fonts forever? How could we convince you that improvements outweighs familiarity? What’s the point of this Typography update then? Wouldn't any kind of change break familiarity? Isn’t breaking familiarity for improvements the whole point? --Moyogo (talk) 21:54, 14 November 2013 (UTC)
 * We are obviously not talking about the same thing. It's all about legibility. There is nothing more legible than a familiar font at a decent size. You may not like Arial. This doesn't make it illegible. Do you have a problem to read this right now? No? Then please explain what the problem is. The proposed font stack mainly uses fonts that are default anyway. What's the point? When became "sans-serif" a problem? At the current small font size where the letters are made of not more than 10 to 20 pixels it is way, way more important to have perfect hinting than anything else. It may become less important when all screens are 200 ppi. But today they aren't. --TMg 10:18, 15 November 2013 (UTC)
 * We are recommending sans-serif fonts. Where did you get that we have a problem with sans-serif? I already explained why Helvetica/Arial are less legible, and that other fonts are very well hinted and more legible. But for you familiarity trumps everything else, legibility [], intended use, character and language support. When I ask what the point of this "Typography update" I mean, why is this called an update if we're just keeping the same font? Don't ask people what they think if you've already made up you mind and won't change it when given arguments. --Moyogo (talk) 16:56, 15 November 2013 (UTC)
 * I find the choices problematic. print typography has almost universally used serif for text and sans-serif for headings. Serifs are I think used for text used, because the additional visual features of a letter  increase readability.  My understanding of the difference for the web is because of the limitations of digital pixels, the finer features don't come over well, especially on the formerly conventional low resolution monitors, and the   readability advantage therefore disappears or even becomes confusingly blurred. But increasingly monitors especially for handheld devices are of much higher resolution; I know I increasingly prefer serif fonts with better monitors.  I think this is a field where individuals & their needs  will differ--I use not only different default point sizes but different default fonts on my different computers, and even at different times of the day. Of course the CSS can be changed on an individual basis, but perhaps there should be a facility so this can be a easy prebuilt feature to enable quick and easy choices (I'm thinking of the analogy  of a car radio's easy choice of a variety of preset display colors--I use blue at night and amber in daylight)DGG (talk) 03:28, 19 November 2013 (UTC)

--Cappuccetta Rosa (talk) 01:28, 22 November 2013 (UTC) I think it would be better Tahoma or Calibri, are very readable. Ariel is used everywhere and it seems too boring ..... :-)


 * I don't understand why people think it is necessary to change the fonts. I think they are fine the way they are.  I definitely support using sans-serif for both text and headings.  I think serif fonts look old-fashioned and are just a bit harder to read than sans-serif fonts.  As it is, I have to increase the size of the text to be able to read articles.  Just a thought -- to allow more space for the article itself and perhaps allow all the fonts to be a bit larger, couldn't the WP information at the left be hidden, with a button one could click in order to view it? CorinneSD (talk) 23:32, 22 November 2013 (UTC)
 * I agree with the above comment. I am in favor of continuing to use a sans-serif for both text and headings, and think that sans-serif fonts are more straining to read on a computer. Sven Manguard (talk) 20:37, 24 November 2013 (UTC)

Black text on white, why not black text on light grey?
Pure black text on pure white is hard on the eyes in some contexts. A very light grey would be preferable, but it must not be too light either otherwise low contrast will prevent legibility. --Moyogo (talk) 10:58, 9 November 2013 (UTC)
 * Indeed… Not only the text should not be pure black, also the page’s background should not be pure white. Designers, search for this, any Smashing Magazine article will tell you. —Fitoschido (talk) 09:07, 10 November 2013 (UTC)


 * You can't use "light gray" backgrounds for a simple reason: Cheap and badly calibrated monitors. It will look ugly on many devices, like the battery is going to die or worse. Sometimes it will even look greenish. But you can use dark gray text on white. #111111 on white (example) is a good idea if the font has a reasonably size (which is currently not the case, see above). Just don't make it as worse as in the current Microsoft Office 2013. They are using #5E5E5E on white (example) in some places. This makes the interface look "smooth" – when looking at it from a designers perspective – but actually reading it hurts my eyes. --TMg 11:28, 12 November 2013 (UTC)
 * PS: [//en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures The Beta wiki] currently uses #252525 on white (example) for the text and #555555 on white (example) for some navigational elements. On top of that the level 2 headlines look like they are smaller because Georgia is a lighter font. There is also a major problem with the navigation on the left (see the screenshot on the right). I can't help but I find the sum of these changes disturbing. Please increase all font sizes (starting with the main text) and please, please do not remove all color from all navigational elements. --TMg 12:48, 12 November 2013 (UTC)
 * As someone getting rapidly older, I suggest that doing anything but pure black on pure white is a mistake--to the extent either text or background is colored or even tinted it decrease accessibility especially for older people. Anyone who likes it otherwise can get the same effect by decreasing monitor contrast and brightness. I am not colour-blind, but colour always decrease readability for me except in very large font sizes--when you use colour, there are intrinsically fewer receptors in the human eye. DGG (talk) 03:28, 19 November 2013 (UTC)


 * Running text should be have a high contrast, and the common colour-blind combinations should be avoided in conveying information. That is essential readability.


 * But accessibility doesn’t mean tailoring the site for a specific reader’s needs. Particular readers may require black-on-white, white-on-black, 36px text, or something else, and all websites aren’t about to accommodate this. If your needs are unusual, find the accessibility controls on your computer or device. They let you increase text size, change contrast, eliminate colour, invert the display, or read text aloud.


 * Accessibility means making the site work well with these accessibility controls. —Michael Z. 2013-11-19 17:43 z 
 * I am quite aware of these controls. Setting them to B/W removes colour in everything not just text. You may call it readability not accessibility, but it's the same thing to most people if we're talking bout vision within the normal range of variation that needs careful design, not special individualized modifications. You've decreased readability. Why should an encyclopedia want to do that?  DGG (talk) 01:37, 26 November 2013 (UTC)


 * Regarding the sidebar links: the space is too small, and even a single word has been split on sv-wiktionary: Deltagarportal+en. Skalman (talk) 06:49, 22 November 2013 (UTC)


 * Links should be somehow differentiated from the rest, also in the navigations zones (maybe another mean than colours could do it, but I don't have a better idea for now). Navigation links spread over 2 lines doesn't help either.  And really I don't see the purpose of smaller fonts. Klipe (talk) 18:21, 25 November 2013 (UTC)

Alternate proposal regarding text sizing and color
Hey all. For those not familiar with it, we have a public design mailing list, which you're welcome to join. On there, I made a proposal which so far has had support from several people.

Basically, I am in agreement with the goal to focus on page content as the first priority, but I also agree with the objections to the smaller text size and the color changes for the sidebar and personal toolbar. My proposal is that we give more focus to content by making the main content text have a larger size of 1.1em, and leave the rest of the UI (toolbars, sidebar, footer, etc.) at .8em. I think others here have said they would prefer to see us increasing base font sizes rather than making anything smaller.

In my mailing list post I attached links to screenshots of how this looks on OSX in Chrome and Firefox, and an approximation is visible via my personal CSS. Different browsers react slightly differently to this: FF looks only barely larger, while on Chrome the difference is notable. In general, I think this will improve both accessibility and still support the main goals of the typography refresh, which are to improve the visual hierarchy in a page and align with the very nice typography on mobile (m.wikipedia.org). Steven Walling (WMF) &bull; talk   00:57, 15 November 2013 (UTC)


 * I would be happy if the body text size were the browser default of 16px instead of the current 13px.


 * The browser difference might be because FF uses fractional pixels but Webkit rounds to whole pixels in sizing text. It shouldn’t be hard to make it identical in both, or at least rounded to the nearest pixel. —Michael Z. 2013-11-15 02:10 z 

Black links are a bad idea
In the updated style many links (those in the navigation bars to the left and on the top as well as the vector tabs) are colored in black or dark gray. This is a very bad decision in my opinion, since links should always have a uniform color across a site, which is different from the text color. Blue (as it was before) is probably the best option, since people are used to it. I advise to undo the changes to coloring of navigational links. --Patrick87 (talk) 12:28, 20 November 2013 (UTC)


 * Why? These are obviously horizontal and vertical lists of navigation links. Who thinks otherwise? According to whom must all links be uniform? —Michael Z. 2013-11-21 00:45 z 
 * "According to whom must all links be uniform?" I believe the answer is one of the goals of this update: Consistency. ChrisJBenson 22:40, 30 November 2013 (UTC)
 * These are obviously horizontal and vertical lists of navigation links as soon as you're used to Wikipedia and have first analyzed the page content. For a user visiting Wikipedia rarely or even for the first time, those are lists of black text, which are not identifiable as links prior to hovering. Unnecessary steps and unnecessary obscurity for no gain at all (or what are black link actually meant to improve?)...
 * See also the section directly below, where the black links are also thematized (overlooked that when posting because the section was missing a heading). --Patrick87 (talk) 09:50, 21 November 2013 (UTC)


 * They are clearly sidebar nav menus, if you’ve used the web for an hour. Anyone who is actually seeing a web browser for the first time in their life can determine that this is a nav menu by the way it looks, by its text, and by its behaviour on mouseover in about three seconds.


 * But ten seconds later, you no longer need to be signalled that they are a nav menu. Since a significant proportion of humanity has now seen these menus five thousand times, an advantage of the black link text is that it visually de-emphasizes distracting, non-content parts of the many pages that they will be reading. —Michael Z. 2013-11-21 17:21 z 
 * Sorry, but how are blue navigational links distracting? Distracting is the fact, that content text as well as navigational elements share the same font, similar size, comparable style and identical color - making them indistinguishable when having only a short glimpse at the page. The gain is still zero in my opinion while clarity suffers from the changes. --Patrick87 (talk) 22:20, 21 November 2013 (UTC)


 * Visual emphasis. Blue links are coloured blue to differentiate and draw attention to themselves by their hue, chroma, and lightness, in contrast to surrounding text. But the sidebar navigation does not benefit from this. Its nature is already evident from its elements’ size, position, and arrangement. In a visual design, any unnecessary emphasis is a distraction, and detracts from the design’s objectives.


 * It’s like ushers in the aisle continually whispering “hey, I’m an usher,” for the benefit of moviegoers. —Michael Z. 2013-11-23 20:50 z 


 * I personally don't care what color you make them, they are obviously links. My opposition to this is when I took a look, the links in the pt- toolbar were a light gray and the contrast ratio to the background was very low.  On top of that, bold seems to be stripped from the ones inserted by JavaScript and the font size seems to be smaller than normal.  This renders them very difficult for me to see on my laptop and I would expect near impossible to see in desktop mode on my mobile.  Due to this lack of accessibility (the very thing this claims it is suppose to improve), I've disabled this beta feature for me for now.  Technical 13 (talk) 12:32, 22 November 2013 (UTC)


 * I agree. Besides, black links on grey background just look bad. Dr. Fatman (talk) 14:18, 22 November 2013 (UTC)

The uniform black links are bad. Before I could tell if a discussion page existed (blue link) or not (red link). Now both are just black. There needs to be a distinction between "target page exists" and "target page does not exist". Now I have to click on the link to see if a discussion page exists. If a discussion link was red I did not click it becaue I already knew I won't find answers there. Now I have to try and see a create new page formular. I don't care what color you give the links (they can be black), but please make a distinction at least between "existant" and "non-existant". --2003:63:2F00:D800:98DD:D5CA:240B:868A 13:53, 22 November 2013 (UTC)
 * I agree with the IP, as well as with Patrick87. I also don't see a purpose to this change, from a design point of view. We shouldn't be breaking from a strongly held internet tradition without a good reason, as it does cause confusion. Sven Manguard (talk) 04:04, 23 November 2013 (UTC)
 * I came here myself with the same complaint 2003: just raised. I can't tell whether an article's talk page exists at a glance anymore. The blue/red needs to be restored for these, if nowhere else. Jackmcbarn (talk) 20:08, 24 November 2013 (UTC)
 * +1 for this. I see that non-existent talk pages still come up as red links, but having links to existing talk pages coloured black was confusing for me. I instinctively thought of black as "existence status unknown" rather than "exists". — Mr. Stradivarius  ♪ talk ♪ 02:56, 30 November 2013 (UTC)

Split the page-content changes out from the navigation-UI changes
I like, and want to keep testing, the changes to the article/project/talk/content pages. I dislike the color and size changes to the navbar (details elsewhere on this page). Perhaps we could split this Beta Feature into two parts? –Quiddity (talk) 00:17, 22 November 2013 (UTC)

Puny light fonts do not improve readability
I don't care so much about whether the fonts are serif, sans-serif, small x-height, large x-height, whatever. But if you are going to use Helvetica and Arial, the size needs to be bigger than it is, and the text should also be black to make it clearer. Typographic improvements are good, but they are not improvements if the changes make the text less readable. I was happy to see "Typography Update," but when I tried it out, I found that the fonts were smaller and gray &mdash; not even black. This looks okay from a distance, but reading it seriously hurts my eyes when reading. And really, screen resolutions have increased over the years, yet we're still using puny font sizes? The trend over the last decade has been toward larger fonts for more readable typography, and more generous leading. Why is Wikimedia stuck in the bad old days, and (perhaps) making them even worse? Not only that, but the navigation links are even tinier. Casual readers may not use them very much, but the people who edit the wiki (and spend the most time there) use them all the time. There are steps that could be taken to improve the readability. One is to first make the navigation links a similar size to the body text. Another is to make all standard text black. The next is to make the standard small text size a bit larger (e.g. fonts at 14px for body text, 12px for navigation). Tengu800 (talk) 03:50, 24 November 2013 (UTC)


 * Totally agree. I found the typography update style to be grayish and very difficult to read. Actually the discussion above prompted me to switch my default "sans-serif" font in Firefox to Liberation Sans, which I find to be even a slight improvement over the previous default (Dejavu Sans). --Nanite (talk) 11:08, 29 November 2013 (UTC)

Serif titles are bad design
No, seriously. Titles are even often sans serif in print. You should not be mixing serif titles with sans serif main fonts. It just looks wrong, as wrong as Cologne Blue or Modern.

And, yes, we are supposed to be all about being free. Using non-free fonts is a bad idea. The whole point of custom fonts is that you include them in the webpage itself. You can only do that with free fonts. Trlkly (talk) 04:26, 30 November 2013 (UTC)

Line breaks and missing colors on navigational links
I consider the line break issue (see the screenshot in the section above) a bug/regression as well as the missing colors on all navigational links. Readers are already complaining about the Wikipedia pages looking gray and dead. This makes it worse. --TMg 12:59, 12 November 2013 (UTC)
 * I agree that the main-navigation-sidebar linebreaks are a serious problem. All wikis will have carefully tailored the wording in their interfaces to minimize linewrap problems. (I don't understand why the smaller text is resulting in more linebreaks?) –Quiddity (talk) 21:26, 12 November 2013 (UTC)


 * I also agree that removing the color from the links in the main-navigation-sidebar and the personal toolbar, is problematic and probably needs more discussion (or at the very least a mention and some references in the Typography Update page). Links should always be easily discernible, and blue for links, and purple for visited links, (or red in the case of non-existent content, per mediawiki standard), are the universal browser standard, as endorsed by the Nielsen. We already collapse some of the subsections (on most/all wikis?), which imho is sufficient. –Quiddity (talk) 21:26, 12 November 2013 (UTC)


 * Jakob Nielsen’s own website uses black, non-underlined links for the main navigation menu across the top, and the Popular Topics menu at the bottom, so we can see that his 9-year-old recommendations are not holy scripture. —Michael Z. 2013-11-21 17:42 z 
 * You noticed, that all the links in the left sidebar on the mentioned page are blue, with black headings, did you? --Patrick87 (talk) 22:17, 21 November 2013 (UTC)


 * You didn’t notice we were talking about “all links,” did you? —Michael Z. 2013-11-22 20:15 z 


 * Same problem on Portuguese Wikipedia. It is important no notice that the words in other languages may be longer than their English translations. Helder 14:08, 22 November 2013 (UTC)


 * On Dutch Wiki ALL menu links are just plain black text, so we can't see it's linking to something, only by navigating over those items. Further: the left menu widt is too small, so certain links are broken up over several lines... which gives a linguistic false abbreviation on those items. Pls fix: 1. link color (BLUE!!!!) 2. left column width. Regards, Tjako (talk) 00:44, 23 November 2013 (UTC)


 * FWIW I'm not convinced the links in the left nav and the personal bar are the right colour, but I certainly disagree that they need to be blue - especially when it comes to navigation menus. Go to Amazon, facebook, bbc news, google, twitter, youtube.. all of thee sites have menus which do not have blue links. The most important thing with links is that they stand out from the rest of the content and you can distinguish them from other things. I agree that the line breaks need to be fixed but I'm not convinced that the link colours are as problematic as being made out. This is a interesting guide on styling links Jdlrobson (talk) 01:28, 23 November 2013 (UTC)


 * Same here on the Wiktionnaire (fr.wiktionary). Vive la Rosière (talk) 18:29, 24 November 2013 (UTC)

Page heading descenders are truncated
In Safari/iOS 5, the descenders on the H1 page heading are clipped by the underline. This hinders readability. —Michael Z. 2013-11-20 03:42 z 


 * The H1 has a relative  (=26px), but an absolute   (=29px). On my machine, the underline bites into the text descenders already.


 * If I increase my font-size by almost any method, the text will be truncated. Mixing relative and absolute sizes is bad for accessibility. Also, there doesn’t seem any point in setting . —Michael Z. 2013-11-22 20:10 z 
 * I am experiencing the same issue in Firefox. In Chrome, the descenders are not cut off, but they touch the horizontal line. Simply eliminating line-height and letting the browser figure it out solves the problem. MrX (talk) 00:27, 24 November 2013 (UTC)


 * Descenders (g, q, etc.) in article titles are shaved at the bottom, cut in half, or cut off almost completely by the horizontal rule just below. How much this happens depends on the browser, zoom level, and (in IE11) text size setting. EEng (talk) 13:26, 29 November 2013 (UTC)

Line breaking
Typography refresh unnecessarily break sidebar texts at Wikimedia Commons (problem screenshot, without TR). This problem also visible at ml.wikipedia, and also wikipedia icon is slightly not visible there (problem screenshot). Interface Language: Malayalam, OS:Linux Mint 13 (Ubuntu 12.04), Browser: Firefox 24--Praveenp (talk) 04:52, 23 November 2013 (UTC)
 * Same here: https://dl.dropboxusercontent.com/u/22742936/wikibeta.PNG (dewiki; Firefox 24.0, Win 7). Note that "Drucken/exporti" is cut off alltogether. Pajz (talk) 13:39, 23 November 2013 (UTC)

Logo gets clipped
&#35;p-logo a has a width of 10em but the background image is 135px x 135px. This results in the logo getting clipped. Specifying a background size would possibly help with this. —The preceding unsigned comment was added by Jdlrobson (talk • contribs) 21:38, 19 November 2013‎
 * Also, different problems at various sizes:
 * If the window is more than ~985px then it looks like this (http://i.imgur.com/UaXmuF5.png), otherwise it looks like this (http://i.imgur.com/QQwnCbF.png). –Quiddity (talk) 00:01, 22 November 2013 (UTC)
 * Both issues mentioned above affect the English Wikibooks logo as well. Coupled to the linebreak issues discussed above, it does suggest the sidebar should be made a little wider. --Duplode (talk) 01:44, 22 November 2013 (UTC)
 * Same here on the Wiktionnaire (fr.wiktionary). Vive la Rosière (talk) 18:29, 24 November 2013 (UTC)
 * Same on my iPad: http://www.flickr.com/photos/101369746@N07/11114658825/lightbox/ Numbermaniac (talk) 10:36, 29 November 2013 (UTC)

Conflicts between CSS properties
Hi,

If you navigate on arnaquâtes, you can see that the display is different with and without this beta feature. With the beta feature, the padding CSS property for the h3 elements overwrites the padding-left property inherited of the "site" module (wikt:fr:Mediawiki:Common.css, by the .titredef class), as a result the text is on the image. Is "Typography update" should be corrected or attribution styles on fr.wikt? Automatik (talk) 23:47, 21 November 2013 (UTC)
 * Annoying and disturbing problem. Vive la Rosière (talk) 18:23, 24 November 2013 (UTC)

Subheadings
On sv-wikt we make frequent use of an H2-heading immediately followed by an H3-heading, so we've made the space between the two smaller than default.

The typography update causes that space to re-appear, since it adds a large margin-top (on e.g. H3), rather than keeping the margin-bottom (on e.g. H2).

If possible, maybe something like this should be done (if it's okay with performance):

Skalman (talk) 06:32, 22 November 2013 (UTC)

Padding of h1-headings too small
The padding of h1-headings (article titles) is too small. Therefore letters are colliding with the underlining. You can alreday see what I mean on the top this page. The letters "y,p,g" are all touching the line. --Patrick87 (talk) 18:43, 24 November 2013 (UTC)

Русская версия
Принципиально пишу на русском, т. к. проблем в английской версии 100 % нет. Ширина сайдбара стала уже, а значит те бедняки, которые не имеют у себя никаких Helvetica, то они получают Arial шрифт, который решительно шире, следовательно, мы получаем замечетльные переносы типа «Спецстраниц\nы», «Загрузить\nфайл», которых ранее не было. Сам логотип слева и справа ограничен и обрезаются буквы «В» и «Я», а также слоган. Заголовки 3 уровня теперь имеют непозволительно большой отступ от основного текста или заголовка, что указан до него. --Higimo (talk) 07:47, 22 November 2013 (UTC)
 * Эти ошибки я тоже вижу и они неприятны. На 1920X1080 можно найти место для нескольких букв.--Attendant (talk) 21:57, 27 November 2013 (UTC)

Order: beta feature bug?
It looks like the Typography css stylesheet is loaded after the sites own stylesheets when we use the beta. So any custom changes that were made for the sites would be overwritten by the Typography update if they change the same properties. If that is the case, then this is a bug of the beta feature and not of the Typography update style. Darkdadaah (talk) 10:01, 25 November 2013 (UTC)

Purge links on a page are inactive
I have a purge link in userboxes on my user pages in English Wikipedia and Simple English Wikipedia, and those links do not work under the Typography Update. StevenJ81 (talk) 03:46, 27 November 2013 (UTC)

Complex diacritics poorly printed
Hello, as you can see on the picture on the right, the complexe diacritics are poorly printed when Typography Update is enabled. Pamputt (talk) 06:21, 27 November 2013 (UTC)
 * There are fonts with similar high quality for screen that have much better character coverage, as I have mentioned before. An advantage of using open source fonts is that the community can change them to what it needs. --Moyogo (talk) 09:28, 27 November 2013 (UTC)

Typography refresh dramatically increase Wikibase items label font
There looks like to be an issue between Wikibase and Typographic refresh beta option: Wikibase item label, in view and edit mode, looks very big when the option is activated.

Section titles on Main Page
At, some section heading have "jumped" out of their place (Firefox 25.0.1, Mac OSX 10.6.8). 130.225.98.240 11:21, 22 November 2013 (UTC)
 * Same problem with w:fr:Portail:Accueil Safari 7.0, Chrome 31.0 on OS X 10.9 Drongou (talk) 22:02, 25 November 2013 (UTC)

Chinese web
In Chinese web, sans-serif more readable. No serif--Shizhao (talk) 03:45, 8 November 2013 (UTC)

Where I can test it?
In which Wikimedia project is it possible to test this feature? --Daniele Pugliesi (talk) 07:47, 9 November 2013 (UTC)
 * Right now you can definitely test it [//en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures on the Beta Labs replica of English Wikipedia, at en.wikipedia.beta.wmflabs.org]. Steven Walling (WMF) &bull; talk   23:13, 9 November 2013 (UTC)


 * That site looks pretty broken. The CSS is not working at all, the site says I must log in to use Preferences, but does not accept my login. —Michael Z. 2013-11-19 01:06 z 

About Beta Features still says “This feature is now scheduled for release by November 14.” But it hasn’t been released as of Nov 14.

What is the current schedule? —Michael Z. 2013-11-14 16:23 z 

I'd also love to test it. Today is not the day? The Beta Labs link above sends me to a page with unstyled text. Also, I'm looking at the thumbnails on the beta-features opt-in page and the graphic (though faint) suggests a searchbox at the top of the screen instead of the current at the side. Is this coming?

Personally I think of all the editor engagement projects, redesign/update should be high on the list. Giving users the ability to author rich/beautiful content is a motivating force. At the moment, Wikipedia, as usefull as it it, is a just a little antiquated visually and it is a put off as a potential editor. I prefer reading it from the snippets that appear at the side of my Google searches. MarkJurgens

What is this called?
Which is the correct name, Typography Refresh or Typography Update? —Michael Z. 2013-11-14 16:25 z 
 * Agreed. To clarify: In Special:Preferences it says "Typography refresh", but everywhere else (?) it is called "Typography Update". –Quiddity (talk) 00:14, 22 November 2013 (UTC)

Browser default font-size
To make the body text the browser default font-size, put the following in your vector.css. This is changed slightly from before the refresh.

—Michael Z. 2013-11-21 03:05 z 
 * Is there a setting that works with and without the refresh, so I do not have to go back and forth from different parts of the project? DGG (talk) 01:38, 26 November 2013 (UTC)

Include screenshots
Please include screenshots at Typography Update. --MZMcBride (talk) 00:21, 22 November 2013 (UTC)
 * Done Jdlrobson (talk) 01:28, 23 November 2013 (UTC)

Where are the changes documented?
I'd like to know what exactly has been changed. Is there a CSS file, or a gerrit link, or anything? I'd love to understand the changes more, and to help diagnose and fix bugs, and make my own experimental iterations (eg. removing the sidebar/UI changes, but keeping the page-content changes), but I need something to start off with. –Quiddity (talk) 00:44, 22 November 2013 (UTC)
 * +1. And screenshots (before/after) would help a lot. Perhaps something interns for Google Code-In could help with? --Elitre (WMF) (talk) 16:48, 22 November 2013 (UTC)
 * Elitre, Quiddity The CSS is right here: https://git.wikimedia.org/tree/mediawiki%2Fcore.git/HEAD/skins%2Fvector%2Fbeta TheDJ (talk) 17:40, 26 November 2013 (UTC)
 * Much thanks, TheDJ. I've added a link to that (and a link to Requests for comment/LESS for anyone confused by the file extensions), on the project page. –Quiddity (talk) 18:35, 26 November 2013 (UTC)

Increase font size
After activating the article font actually got smaller than the default font. Is it a bug or something? Specs: Linux Mint 15, Firefox 25.0.1, default zoom, cache cleaned. TheVulcan (talk) 01:51, 22 November 2013 (UTC)
 * Agreed. The personal toolbar has "font-size: 11px;" on Google Chrome 27. Helder 11:25, 22 November 2013 (UTC)

Quotes Font Size
The most urgent element that needs to be fixed in my opinion is the completely unproportional size of quotes in the general text. Not only is the font itself unnecessarily large, it also includes a gigantic margin that interferes with the text's natural flow. --InbalabnI (talk) 15:12, 22 November 2013 (UTC)


 * You mean quotes, i.e. quoted text, or quotation marks? Can you link to an example? —Michael Z. 2013-11-22 19:34 z 
 * Ditto what Michael asks. I've tried looking through all the Enwiki quote-templates but I can't see any unproportional changes. Perhaps your home wiki's (Hebrew) templates are using custom-style-code that conflicts with the Typography Update? Examples almost always help! :) –Quiddity (talk) 19:46, 23 November 2013 (UTC)

Comments
I enabled the typography refresh on enwiki, but have disabled it again, as I find it makes the UI less usable. While I can see the intent of the refresh, there are two major problems with it from my point of view: -- The Anome (talk) 12:06, 25 November 2013 (UTC)
 * small fonts just got smaller, and are now too small to comforably read, given that the new choice of default font is not hinted/anti-aliased well on my default platform, Debian Linux 6.0: the new default font should either be chosen from the set of fonts with better anti-aliasing support across all platforms, or the current new font should have better hinting
 * menu navigation links are no longer blue -- this is an important hint that something is clickable, and such a common idiom of web design that removing it is perplexing even for experienced users, and likely to make the learning curve steeper for new users


 * Of the top 10 Alexa sites that I could access, 5 have menu navigation links in black or grey (Google, Facebook, YouTube, Yahoo, Gmail), 2 have blue links (Baidu, Wikipedia for now), 4 have mixed links with blue prominent (QQ, LinkedIn, Amazon, Taobao), and one has blue links, but customized by users on many pages (Twitter). It looks like blue links is a fairly common idiom, but not considered mandatory by website creators or universally expected by website visitors.


 * Is there any evidence that making nav-bar links black or grey perplexes anyone at all? —Michael Z. 2013-11-25 17:24 z 


 * It's not a matter of being perplexed; it's a matter of readability. The current Vector skin has mostly blue text in the left sidebar and mostly black text for the article.  This contrast makes it easier for your eye to read paragraphs, because it's less likely that your eye will jump back too far at the end of a line.  The proposed new skin does away with that, making the article less readable.


 * Unlike Google, Facebook, YouTube, etc., Wikipedia is primarily a platform for users to read vast quantities of text. The user's focus should always be drawn towards the article; everything else should look like background.  Because of this, I think Wikipedia's design should not derive from those websites' designs.  We ought to use black links or not solely depending on whether or not they improve Wikipedia's core focus of delivering articles to users.  My judgment is that they do not.  Ozob (talk) 03:14, 26 November 2013 (UTC)


 * I'd also put it the other way round: rather than justifying the default web-1.0 convention of blue links, those proposing changing it should be able to justify exactly how non-blue menu links would be an improvement on the status quo. If you want graphic-design-led change, you should do a root-and-branch redesign and propose radical change. If you want to do incremental change, you need to be far more cautious, lest you end up with something that is a mish-mash: neither bold and fresh, nor traditional and comfortable. If something's a material improvement with a rationale for changing it, and ideally also evidence from A/B or multivariate testing that it's more effective and better liked by users, it's definitely fine to do so: change for change's sake, particularly if the only justification for doing it is that other, commercial, sites do it, generally isn't such a good idea in my opinion. -- The Anome (talk) 10:54, 27 November 2013 (UTC)

ÄÖÜÉÈÊÂ... accents and dots over capital letters in first and second level headings are not displayed
As you can see on https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=124826866 with Typography Update enabled there are the dots and accents over the capital letters in the headings missing. --Pyfisch (talk) 16:15, 25 November 2013 (UTC)


 * They all appear correctly, in both the headings and the page index, on Safari 6.1/Mac, Firefox 25.0.1/Mac, and Chrome 31.0.1650.57/Mac, and on Safari/iOS 5.


 * What browser/version/OS are you using? Do you have Georgia or DejaVu Serif fonts installed? If not, what is your browser’s default serif font? —Michael Z. 2013-11-25 17:33 z 


 * Ditto what Michael said/asked. (Here's a screenshot from Firefox in Ubuntu http://i.imgur.com/WGggvHP.png (and a Tools->web-developer->inspector screenshot http://i.imgur.com/Z4AIKyp.png)). –Quiddity (talk) 17:58, 25 November 2013 (UTC)

It looks like a font size problem to me. If I set the default size to 14 I can see the dots, but everything is too small. Regards --Pyfisch (talk) 15:34, 26 November 2013 (UTC)
 * OS: Ubuntu 13.10
 * Browser: 25.0.1
 * Default font: serif; size 22
 * DejaVu Serif is installed
 * Screenshot: http://i.imgur.com/W8hlv5j.png

Improvements for audio usage of the page ?
Slightly off topic, but still about accessibility. It seems that it would be really useful to have a mean to go quickly to the start of the main article when listening to a page (with screen readers) instead of having to go through so many navigational elements first. Something like having a very first navigational element allowing to jump directly to the title of the main content. Klipe (talk) 18:23, 25 November 2013 (UTC)
 * Pages are already laid out like this. The =H1= of the page title is the first content in the html body. The navigation (left-sidebar, and personal-toolbar) are at the very end, after all the page content (which means notifications are harder to access, but that's 47993). Hope that helps. –Quiddity (talk) 00:03, 26 November 2013 (UTC)
 * @Quiddity What you write here sounds good to me. Is this rather recent?  In a small informal report on the topic on the WP:fr "bistro" page of 25 July 2013 [//fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/25_juillet_2013#Synth.C3.A8se_vocale], I read (rough translation) "When one arrives on the page, the synthetic voice first reads the address of the page, then everything that appears on the page in the order in which it is written: link create an account link log on link article link talk link read link edit link history link search...".  Because of the example given, I understand "the order in which it is written" as the order in which it appears on the page, at least for what concerns the navigation elements at the top of the page.  Could it be that this behaviour actually depends on the reader and some would read in the HTML code order while others would read in the display order (after having taken positioning via CSS and JS into account)?  Strange. Klipe (talk) 17:13, 26 November 2013 (UTC)
 * Klipe, I'm not sure what software was used there, but it's definitely not what the most used screen readers (JAWS, VoiceOver and NVDA) would do. They follow what is called the document order, where title and content come before navigational UI components of the website. Actually, it's one of the few areas in terms of accessibility, where we really do stuff correctly.
 * Now it might be that some screen readers have a mode, where you can switch between 'visual order' and 'document order' of reading the document, but that would be a different story. We ALSO have 'jumplinks' in the top of the page, just under the H1, that are only 'visible' to users with screen readers, that can quickly take them to search and the navigation sections of pages. This has been in place for a long time already (Vector and monobook, the skins that have been the default for the past 9 years or so feature this). But this is getting off scope of this page a bit. If these things interest you, I suggest discussing them on the wikitech-l mailinglist, check out the links here and/or contacting people in w:Wikipedia:WikiProject Accessibility. There aren't many people working on things like this, but there is slow progress on various accessibility issues. TheDJ (talk) 17:56, 26 November 2013 (UTC)
 * TheDJ, thanks for your answer. It may have been specific to that user's config.  I'll discuss this elsewhere if/when I ever get to know more. Klipe (talk) 09:19, 28 November 2013 (UTC)

I can't see any apreciable difference
I can't see any apreciable difference, only better aligments in the text. What are exactly the changes? I use in my browser the Ubuntu font, so probably is that? --Jakeukalane (talk) 17:59, 27 November 2013 (UTC)