Talk:Typography refresh

Latest release

Hi everyone,

We've just updated the beta feature with bug fixes and a new font stack, the details of which are reflected on the main document here. (Not everything is rolled out across wikis, but it is present here on mediawiki.org, and will be everywhere by the end of next week.).

Other than the bug fixes and new font stack, I want to bring up the idea of releasing a permanent version of this beta feature that does not including elements such as:

1. The Table of Contents redesign
2. The new, minimalist thumbnail style
3. The new blockquote style
4. Removal of custom icons for external links, based on file type (e.g. a music symbol for .ogg files)

These changes are valuable in that they help remove visual cruft and increase focus on the text of pages. I personally like several of them. However, they also require a lot more testing and the previous discussions brought up numerous issues that remain unresolved. I think the conservative approach here is to submit them for review separately, if at all, and take in to account more edge cases (like wikis that heavily use templates for blockquotes, or the fact that wikitext markup for thumbs and frames would be made redundant by removing all frame styles from thumbs). Thoughts?

Also, many thanks to Vibhabamba, Quiddity, and others who wrote the bulk of the new FAQ and summary of changes. I highly encourage everyone to read it. Steven Walling (WMF) • talk 17:17, 14 March 2014 (UTC)

Update: no one seems to be much in strong favor of keeping the four things mentioned above, and further down in comments people have continued to bring up issues with some of them. Thus, we're going to remove them. Steven Walling (WMF) • talk 21:06, 21 March 2014 (UTC)

Wikipedia or MediaWiki?

I am getting conflicting information whether this update is Wikipedia only or MediaWiki thing. Some examples below.

Wikipedia:

"Type is a core visual element of Wikipedia's language"

"we want the font choice to reflect us and our content"

MediaWiki:

"which is a good thing for both Wikimedia and third party users of Vector/MobileFrontEnd"

"it's something we should do before we move to merge anything from the typography refresh in to Vector proper"

Please clarify which point of view has been used as basis of the changes. If it is Wikipedia, please clarify what thought has been given the suitability of the choices for 3rd party users of MediaWiki. For example, do you want every site to look like Wikipedia? --Nikerabbit (talk) 08:29, 18 February 2014 (UTC)

I too would like to see an answer to this. Legoktm (talk) 07:01, 10 March 2014 (UTC)

Dearchive unanswered question also asked several times on mailing lists and made even more pressing by the newer text "Wikimedia's default typography", "Wikimedia content must be highly accessible" but "all projects (as part of the Vector skin)" etc. --Nemo 17:39, 14 March 2014 (UTC)

It's a partially unresolved question, but is probably best answered by the first question in the FAQ. When it comes time to remove this from Extension:VectorBeta the most logical destination is Vector skin in MediaWiki core. Whether other MediaWiki users want to retain the change is up to them of course. Steven Walling (WMF) • talk 17:52, 14 March 2014 (UTC)

No, I don't find any answer in the first FAQ question. "Of course"? How? --Nemo 18:00, 14 March 2014 (UTC)

"Who will see this change?" "All users of Wikimedia sites who use the default Vector skin, including readers and editors. Users who use their preferences or another method to use an alternative skin, like Monobook or Cologne Blue, will see no changes." Steven Walling (WMF) • talk 18:10, 14 March 2014 (UTC)

Why are you copying it here? If you're implying that this change will not be made in core or the Vector extension, it would be useful to say so explicitly. --Nemo 18:23, 14 March 2014 (UTC)

We're still lacking an answer here. The current TL;DR is: we made it for Wikipedia only, but forced every MediaWiki user as well, hoping they wouldn't mind.

Source: on wikitech-l however Steven said «This was designed primarily with Wikimedia readers in mind, but this is extremely minimal stylistically». So it seems we're never going to know and the text of Typography refresh will keep being contradictory, omissive and non-explanatory; authors of this thing are very defensive. --Nemo 07:09, 1 April 2014 (UTC)

Only system font

Resolved

"Helvetica is the only default system font that properly renders glyphs in non-latin scripts", seriously? Either "default" or "system font" here must have some very specific definition that I'm unaware of, could you clarify? --Nemo 17:46, 14 March 2014 (UTC)

Is "browser default sans-serif" precise enough for your taste? Steven Walling (WMF) • talk 17:49, 14 March 2014 (UTC)

Oh, this is unexpected. How do the browsers' defaults matter? How many browsers set their own defaults (overriding the OS)? --Nemo 18:02, 14 March 2014 (UTC)

The browser default sans matters because that's what we set in Vector core currently, without the new stack in place. Steven Walling (WMF) • talk 18:11, 14 March 2014 (UTC)

Ok, so that's Typography_refresh/Font_choice#Current_situation. Are you saying you tried to pick a font among those? Helvetica is the current default only in iOS and MacOS, according to that list. All the others except Roboto (i.e. Arial, DejaVu Sans, Liberation Sans) are definitely ok in non-latin scripts. --Nemo 18:27, 14 March 2014 (UTC)

The section is getting a bit better. I still don't understand «the fonts that most browsers use in this condition do not account for proper rendering of glyphs, pairs, and diacritical marks at small sizes»: even according to the table in the subpage, scores of Arial, DejaVu Sans, Liberation Sans are very similar (8 vs. 10) and some upstream bugs have been fixed in a matter of days after being reported. --Nemo 19:03, 14 March 2014 (UTC)

The reasoning for Helvetica Neue

Resolved

Body copy (the main text of pages) has been set to "Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif". Could you please explain the reasoning for selecting Helvetica Neue and prioritize it over Helvetica?

According to the body font evaluation at Typography refresh/Font choice, plain Helvetica got a better general score. While Helvetica Neue seems to be 2 points more more "appropriate" (10 to 8 in terms of "readability, neutrality, and "authority"", relatively subjective factors), in technical terms (a factor that can be measured more objectively) Helvetica wins Helvetica Neue 10-1.

Helvetica is also as "appropriate" as Arial, and both look very similar. For all these reasons, wouldn't Helvetica serve better to the goals of this Typography refresh? (readability, consistency, availability, accessibility)--Qgil (talk) 19:23, 14 March 2014 (UTC)

Yeah this needs to be clarified. Steven Walling (WMF) • talk 20:56, 14 March 2014 (UTC)

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

Thoughts

Georgia on Linux

The FAQ states: Linux systems (perhaps ironically) do not recognize Linux Libertine nor Georgia.

According to this font survey, Georgia is installed on 70% of all Linux systems, so that statement is uneducated. Most Linux users have it installed throught the TTF-Fonts-Core package. However, it contains rather outdated fonts from when they were still freely available (until 2002), so they may lack essential Unicode support. It means that 70% may potentially see mis-rendered text in headers should they occur.

With that in mind, perhaps Georgia should be removed from the stack. — Edokter (talk) — 23:59, 14 March 2014 (UTC)

Having tested extensively on Ubuntu and Debian, I don't trust the accuracy of that source. Also, en:Core fonts for the Web:

However, these proprietary fonts (or some of them) are not distributed with some modern operating systems by default (e.g. in Android, Ubuntu, FreeBSD, OpenSolaris or some Symbian versions)[11][12][13][14][15][16][17][18][19] and they are substituted by other fonts (e.g. by free software fonts, such as Liberation fonts, Ghostscript fonts,[20] Droid fonts, DejaVu fonts and others).

So yes, users may easily install font packages that include Georgia, but we can't rely on the most popular Linux-based desktop operating systems having it installed by default. (The exception is Mint, which I haven't tested on.) Even if it was the case, we need to specify Georgia in the stack for OSX users at at least, who would otherwise get Times (which is undesirable). Steven Walling (WMF) • talk 22:37, 15 March 2014 (UTC)

They were never installed by default, but they were always available in their respective repositories. Why should you distrust this survey? The 70% figure is quite consistent throughout the web. — Edokter (talk) — 19:29, 17 March 2014 (UTC)

Linux Libertine

I don't like Linux Libertine. The x-height is far too low, which makes headers appear disproportionally small. In blockquotes, this is even more noticable. The difference between LL and Georgia also does not help consistency; Georgia appears almost 50% larger then LL.

Well since few users have it installed by default, I think the concerns are not something to worry about. You basically have to opt-in to using LL at this point in time. Steven Walling (WMF) • talk 22:38, 15 March 2014 (UTC)

It is a concern none the less... for those that have it installed (like me). Waiving the concerns due to low install base is once again ignoring the core goals of this beta, in this case consistency. It is a good font, but simply not suitable for headers. The x-height of H2 headers is almost no larger then the body font. — Edokter (talk) — 01:58, 16 March 2014 (UTC)

Serif

I do like the current body font very much. Why do we not expand on this font-family by using the same fonts for serif:

• Tinos, "Liberation Serif", "Times New Roman", Times, serif;

This ensures the same availability as the body font stack, ans they are part of the same font families.

Monospace

One thing I have missed is monospace. I think I'm not wrong if I say that most of us are quite bored with Courier New. So, we can expand even further:

• Cousine, "Liberation Mono", "DejaVu Sans Mono", Consolas, monospace;

— Edokter (talk) — 13:40, 15 March 2014 (UTC)

The truth is there is so little monospace styling on Wikimedia sites (and most wikis in general) that I'm not sure it's really a high priority. Steven Walling (WMF) • talk 03:29, 18 March 2014 (UTC)

Any text inside ‎<code>...‎</code> and ‎<pre>...‎</pre>, and any page with JavaScript. CSS or module code... There is a lot of monospace. — Edokter (talk) — 23:35, 18 March 2014 (UTC)

Also add <source> tags and possibly text in the WikiEditor's window itself. Monospace is used a lot in articles about computer science (to give snippets of code) and on help and project pages to explain Wikitext/Templates/etc. --Patrick87 (talk) 00:18, 19 March 2014 (UTC)

Certainly, but what is the rationale for trying to dictate specific font choices here? All Macs, Windows systems and *n*x boxes all already have one or more monospaced fonts installed by default, one of which will be used for this purpose, but they are not the same from system to system; there is no one single font that will typically be found on all of them, though Courier New is probably the most common. Like most Mac people, I use Monaco. I'm also a font horse, so I have most of the other fonts mentioned, and might have one or another of them installed at any given time, for one project or another; I wouldn't appreciate Wikipedia and especially it's editing fields suddenly changing appearance based on which extremely optional random fonts I'm running with any given time. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:42, 26 March 2014 (UTC)

What would be the rationale behind trying to dictate specific font choices for serif headings and sans-serif body text? All Macs, Windows systems and *n*x all already have one or more serif and sans-serif fonts installed by default.
Seriously, setting specific fonts is the whole point of typography refresh! If we "dictate" specific fonts at one point, we should "dictate" the same fonts throughout font styles. This way we can at least try to make sure to get a consistent look by using the same font family everywhere. I would totally prefer to not use a different font family for every font style (which Typography refresh currently achieves on my system: Georgia for headings, Libeeration Sans for body text, Courier New for monospaced text). Don't you think it would be nicer to have all font styles looking consistent? --Patrick87 (talk) 00:25, 27 March 2014 (UTC)

Line height bug?

It seems the font-size (0.875em) for #bodyContent is overruled by the default Vector declaration (0.8em). (I don't mind this bit, with the current stack, it is quite legible.) Also line-height seems to be a mess, starting with 1.6em for div#content, then 1.5em for #bodyContent and ending in 'inherit' for 'div@content p'. Has this been thought through? — Edokter (talk) — 14:01, 15 March 2014 (UTC)

Forget the font-size; my own CSS was in the way. Line-height remains a problem though. — Edokter (talk) — 14:41, 16 March 2014 (UTC)

There is a bug out for this and we are looking into it. Ideally the line height is a bit more open. A core setting over-rides the line height change right now. Vibhabamba (talk) 19:11, 28 March 2014 (UTC)

Giant quotation marks around blockquote

Resolved

The use of decorative large quotation marks for block quotes in Wikipedia is contrary to the Manual of Style (Wikipedia:Manual of Style#Block quotations), which reserves them for pull quotes only. A sensible rule, to avoid clutter on the page. – Tim riley (talk) 11:25, 15 March 2014 (UTC)

They're going to be removing the blockquote changes, per Steven's note at #Latest release. Hopefully a.s.a.p. to reduce this confusion ;) –Quiddity (talk) 20:33, 15 March 2014 (UTC)

I am very happy with the new Style. Especially math formulas within text look a lot better. However Quotations need to be improved. For example the one in w:de:Viskosität#Definition der Viskosität für newtonsche Flüssigkeiten. Most disturbing are the huge black quotation marks, which happen to be placed underneath (or even on top of?) a transparent image on the right, far away from the text. If necessary I can provide a screenshot.--Debenben (talk) 17:22, 21 March 2014 (UTC)

The blockquote styling is being removed, along with a few other elements, per Steven's comments up at #Latest release. (Some of them might be re-suggested as part of a different Beta Feature, in future months.) I believe those elements will be removed on next Thursday (possibly just on mediawiki.org for the first week, then everywhere else the week after). HTH. –Quiddity (talk) 17:54, 21 March 2014 (UTC)

Yes, the quotation marks in particular are annoying. Thanks for the report Debenben. Steven Walling (WMF) • talk 20:18, 21 March 2014 (UTC)

Thank you both. In case of a future redesign, I'd like to point out, that in German, quotation marks should be like „…“ and not “…”, see for example [1]. Maybe it just appears in the English style because of my browser settings, but it should be possible to always use the format that fits the wikipedia edition. If they stay big, I would prefer them not to be black, but gray or something less obtrusive.--Debenben (talk) 20:54, 21 March 2014 (UTC)

+1! Would have suggested exactly the same if it hadn't already been suggested. --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:04, 22 March 2014 (UTC)

Indeed. Those huge quotation marks are ridiculous, and don't make sense for lots of languages, not just German. Among other problems. They definitely should not "be re-suggested as part of a different Beta Feature, in future months". — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:35, 26 March 2014 (UTC)

No worries, quotation marks are translated at traslatewiki.net (just like the other messages) and I'm sure MediaWiki core devs will veto any change wishing to hardcode specific marks. --Nemo 12:04, 27 March 2014 (UTC)

Blockquotes

Screenshot of the bug

Looking at w:South American dreadnought race with the typography beta, the new quotemarks around blockquotes don't work very well with an image alongside them. In addition, the English Wikipedia's policies only allow for quotemarks when it is a pull quote (see eg w:Template:Cquote). Ed ^{[talk] [en:majestic titan]} 18:17, 30 March 2014 (UTC)

The blockquote changes will not be included in the typography refresh at this time. --Entlinkt (talk) 15:34, 31 March 2014 (UTC)

Mixing serif and sans serif faces

1. Using a serif face for block quotes is bad practice from the accessibility point of view. Screen text should all be in sans serif faces: see advice here and here
2. From the purely aesthetic angle, mixing serif and sans serif faces within the text looks messy and amateurish, though this is a matter of taste, I admit.
3. Having headers in a serif face is fine, and looks rather good, in fact. – Tim riley (talk) 11:25, 15 March 2014 (UTC)

They're going to be removing the blockquote changes, per Steven's note at #Latest release. Hopefully a.s.a.p. to reduce this confusion ;) –Quiddity (talk) 20:33, 15 March 2014 (UTC)

I actually think that it has been noted before in the discussion surrounding the typography refresh that some people would actually like to see the use of serif fonts for headings and sans-serif fonts for body text reversed, and I agree with this discussion. Serif fonts look — well, they look confusing, not to mention weird. — RandomDSdevel (talk) 20:51, 23 March 2014 (UTC)

I for one strenuously object to the use of serif headings, or any other serif font stuff, other than when it's being done deliberately at the content level (e.g. with inline style in the wikicode as. in w:en:Template:Xt). People who like serif fonts for Web reading can have their own stylesheets use them. Mingling serif and sans-serif looks awful, like someone in Public Relations 101 trying to design an ad. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:29, 26 March 2014 (UTC)

That's another reason why I hate the new serif headings!!! — RandomDSdevel (talk) 20:45, 27 March 2014 (UTC)

Italic issues in Korean

Since most of the Korean fonts looks creepy in italic, there is a concensus to use it sparingly in kowiki, AFAIK. I have added an override to the local css.[2] Anyway, where can I keep track on such changes? (i.e. within the repository?) --PuzzletChung (talk) 12:02, 15 March 2014 (UTC)

@PuzzletChung: We have not changed the use of italics to increase them anywhere. If italics have been introduced anywhere new it shouldn't be a result of this beta feature. Steven Walling (WMF) • talk 20:55, 21 March 2014 (UTC)

@Steven (WMF): This is to do with these lines of code. That part is changing the Enwiki custom code in the "Hatnotes and disambiguation notices" section of en:MediaWiki:Common.css (which is presumably the only place it will get merged to). –Quiddity (talk) 23:16, 21 March 2014 (UTC)

responsive typography

Hi, thanks for yout hard work. I like the new version much better. But it has the same struggles like before: the font is to small on current displays and devices. I would like to point out to this topic again. Maybe we could invite the people form iA to share their thoughts on our challenges? (See http://ia.net/blog/responsive-typography-the-basics/ - they are also quite famous for making on of the best writing apps.) --Sebaso (talk) 09:06, 16 March 2014 (UTC)

@Sebaso: There were 2 previous responsive ideas that have been pointed to, http://simplefocus.com/flowtype/ and http://webdesign.maratz.com/lab/responsivetypography/realtime/ - the 2nd one is (imo) a purely experimental toy and would drive me crazy, but the first one has possibilities if adapted to lower the maximum, and provide user-controls rather than basing it on window-size.

However, as Vibhabamba wrote [now in /archive 2], "Once we have a persistent header we plan to add font controls so a user can start with a default optimum but adjust the font size based on their screen size. Vibhabamba (talk) 23:03, 5 February 2014 (UTC)" - which I think is the best solution. Perhaps a mix between the flowtype idea, and the typesize adjuster that sites like NYTimes (screenshot) use. That would allow the default to be the standard that suits the majority, and allow users who want something large (or smaller) to decide for themselves. [I gather we have a lot of users who browse the web with everything zoomed in (or using a screenmagnifier), but they each want different percentages of text enlargement.] HTH. –Quiddity (talk) 18:41, 16 March 2014 (UTC)

Thx! But even non-responsive its to small. :( --Sebaso (talk) 20:29, 16 March 2014 (UTC)

Could you make it so that paragraph widths would be editable as well? Everyone seems to be hating on the 700px (I think that's how wide it is) limit. — RandomDSdevel (talk) 20:47, 27 March 2014 (UTC)

licence bug

The mediaviews says "cc-by-sa _3_.0", also if another version is used. --Sebaso (talk) 20:03, 16 March 2014 (UTC)

This is not related to this feature. Steven Walling (WMF) • talk 20:54, 21 March 2014 (UTC)

Liberation Sans on Windows

As I have Liberation Sans installed on Windows (e.g. to create SVGs for Commons) this font is now used for body text with the new font stack. While the font might be designed well in principle it turns out to be plainly inferior technically when compared to Arial, notably

• Hinting is inferior which makes many glyphs look bad, especially for bold text and numbers.
• Letter-spacing is too small when rendered at small sizes which makes navigational elements at the top/left of the page less legible (might also be dependent on hinting)
• x-height is lower (e.g. 7px compared to 8px with Arial at the default font size of 14px I'm seeing) which makes the font look smaller overall. Actually I like the lower x-height but it appears as being about the same size as Arial without typography refresh (e.g. 12.8px font size). Therefore this lowers the gain achieved by increasing the font size which should be considered (but probably is OK).

Especially the hinting needs to be fixed in my opinion if Liberation Sans should be selected to be part of the default font stack. I hope this can be achieved as you write "Liberation Sans has a respectable amount of ubiquity and it is produced by Red Hat who can help us with addressing rendering issues." on the front page. --Patrick87 (talk) 22:14, 18 March 2014 (UTC)

On the other hand, it's looking very good indeed on my Linux desktop. -- The Anome (talk) 11:30, 21 March 2014 (UTC)

I'm not saying that it shouldn't be used at all. But currently it's just not fit for Windows in my opinion and I assume there was no workable solution to deliver different OSs with different font stacks. Since degrading readability for some Windows users only to get on other systems what is wanted is not a workable option, the best possibility would probably be to fix the hinting. Many other applications would profit from that, too, so it would be a worthwhile investment. --Patrick87 (talk) 16:04, 21 March 2014 (UTC)

I can agree that Liberation Sans for English-speaking users may not be ideal on Windows. However, the case where a Windows user would have it installed is very rare, isn't it? The vast majority of Windows users will get Arial still, so in this case I'd recommend you use your personal CSS to use that too if you want. Steven Walling (WMF) • talk 20:54, 21 March 2014 (UTC)

The Liberation font family is distributed as part of LibreOffice. Therefore I don't think the case is as rare as one might assume.
Apart from that I actually like the look of Liberation Sans. I never really found Arial to be a nice font but it is at least a very clear font. Liberation would be nice and clear if it wasn't for it's technical limitations. That's why I personally would love to use it if the hinting was OK. --Patrick87 (talk) 21:30, 21 March 2014 (UTC)

Just making sure... you do have the 2.0 version installed? That release has some significant improvement in hinting. I do agree there are some minor hinting glitches in the bold variant. As far as rarity goes... Arial also has a wide install base on Linux desktops, which I have no idea how it renders. It simply means we have to make a choice in which font to pick first. There will always be fonts that are 'out of place' on one system or the other. — Edokter (talk) — 21:52, 21 March 2014 (UTC)

Yes, I've got version 2.00.1 (that's also the version that comes bundled with LibreOffice). I accept that not every font renders well an all systems – but if we promote a free font (or even a non-free font) by including it in a fixed font stack we should make sure that at least it doesn't decrease legibility on some systems. --Patrick87 (talk) 22:32, 21 March 2014 (UTC)

That would mean we can't provide a font-stack at all. There will always be systems that has fonts not indiginous (I have XP with all free fonts installed). So, I (also) don't get Arial. Liberation/Arimo is a good alternative, and of al the free fonts is one of the best rendering fonts. But each font, free or non-free, has issues and will always have issues. — Edokter (talk) — 12:01, 22 March 2014 (UTC)

Screenshot

Resolved

Can someone please provide an updated comparison screenshot showing how an article currently looks and how it will look if this proposed change is implemented? --MZMcBride (talk) 00:07, 22 March 2014 (UTC)

On what browser + OS? I have made File:New typography Vector OSX.svg for OS X 10.9 on Chrome. Normally I use a VM to test Ubuntu and Windows, but I don't trust the font hinting enough to take a screenshot from them that is high quality. Steven Walling (WMF) • talk 00:51, 22 March 2014 (UTC)

Browser + OS doesn't matter to me. Other than being a strange file format for a screenshot, File:New typography Vector OSX.svg is great. Thanks! I've inserted it into the subject-space page. --MZMcBride (talk) 03:14, 22 March 2014 (UTC)

Small gap in main page boxes on de.WP

With the typography refresh enabled on de.WP (I'm only there, so don't know about other languages), on the main page all the boxes have a small gap between the blue "header box" (like "Artikel des Tages", for example, featured article of the day) and the frame of the "content box" that show the introduction of the featured article. Is this intended, a bug in the beta feature or a bug in the local CSS for these boxes? --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:00, 22 March 2014 (UTC)

Just did inspect the page with Firefox and found the bad guy, but not sure who is responsible for this and if it's intended (the gap looks wrong): --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:26, 22 March 2014 (UTC)

div#content h2 {
    font-size: 1.5em;
    line-height: 22pt;
    margin-top: 16pt;
    font-family: "Linux Libertine",Georgia,Times,serif;
    padding: 0px;
    margin-bottom: 4pt; <!-- this is the bad guy! -->
}

.Ah, accoording to the fonts it is the beta typography. Then I think the boxes on the german main page must be fixed (own class insead of using just a h2 header, for example) --2003:63:2F67:9600:20BD:C68C:D4AA:EEDA 11:28, 22 March 2014 (UTC)

This has been fixed locally (it was a CSS selector specifity issue). --Entlinkt (talk) 21:03, 27 March 2014 (UTC)

FAQ feedback

Thanks for the announcement on the Commons Village pump. The improved horizontal <pre>-scrolling could be also interesting for Monobook. The section on "opt out" could give an (or link to an) example, and while at it also explain how users with other skins could "opt in" to test this—as far as that's possible with a few CSS-lines, e.g., serif headers. –Be..anyone (talk) 01:23, 23 March 2014 (UTC)

Printing -- eco fonts?

Hi. I recently heard about Ecofont. Does anyone think a free version of something like this should be used when printing articles? I don't think so, but just putting this idea out there. πr² (t • c) 18:44, 26 March 2014 (UTC)

Thumbnail style

Resolved

I miss the slight background color change behind and border around image thumbnails and their captions; they served to help visually group the caption with the image. I can see doing away with one of these features but not both. I don't miss the goofy "enlarge" icon. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:53, 26 March 2014 (UTC)

That element is not going to be part of the actual release (See #Latest release above for details).

However, there's a discussion at en:Wikipedia:VPT#New image thumb design about thumbnail styles, that you all might be interested in joining. –Quiddity (talk) 19:33, 27 March 2014 (UTC)

Yes. If you test here, you'll notice the beta feature has been removed and the default change is live. It does not include thumbnail or blockquote styles. Steven Walling (WMF) • talk 20:53, 27 March 2014 (UTC)

Slight increase in default text size

I like the change (see #Screenshot, above, to have a look at the difference). It's not a huge increase in the main text size, but just enough to compensate for monitors being huge these days. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 23:58, 26 March 2014 (UTC)

If we get more feedback around this issue - we are open to increasing the type size for body copy and leading. 192.195.83.38 22:55, 28 March 2014 (UTC)

Spacing around section headings bad

Tracked in Phabricator
Task T65312

It seems to me there's a problem with the spacing around section headings. There is too much space before them and too little space directly after them. It would look much better if it were "more in the middle". I'm running Linux with a recent Firefox. Jason Quinn (talk) 00:50, 27 March 2014 (UTC)

Confirmed (for level 2 headers): they look as if they had a double empty line before. --Nemo 12:08, 27 March 2014 (UTC)

Spacing increase around headers is an intentional part of the update. See "New spacing and sizing for headings, body copy, and leading" in the summary of changes. A primary goal of the update was to design for the state of our most popular content, which often tends to be very long articles with many sections. Spacing between sections plus serif for major headings increases ability to read/scan by providing a clearer visual break between sections, rather than one continuous block of text. Steven Walling (WMF) • talk 18:58, 27 March 2014 (UTC)

Hi, User:Steven (WMF). Increased spacing may be a part of the design goals but this thread is about the positioning of the heading within that spacing. It's too far away from the last section and too close to the text of the new section. Jason Quinn (talk) 16:13, 28 March 2014 (UTC)

Better idea

Make the typography change go live on April 1, and make it consist of changing all font faces to Comic Sans. Dtobias (talk) 01:50, 27 March 2014 (UTC)

Very good idea. We'll implement this immediately. ;) Steven Walling (WMF) • talk 18:55, 27 March 2014 (UTC)

You're joking, right? I'm not quite as enamored with Comic Sans as Dtobias is and don't like it when I see it on computer screens. The font is more suited for humorous print-outs and comment signatures, IMHO. — RandomDSdevel (talk) 20:57, 27 March 2014 (UTC)

Yes, very much joking. We're not going to do that. Dtobias was suggesting it as a practical joke because he likely agrees with everything you just said, as do I. :) Steven Walling (WMF) • talk 23:57, 27 March 2014 (UTC)

CSS script

Section 2.12 states that CSS script can be added to "opt out" of these changes. Could a technical bod post the script needed, as I'm quite happy with the existing font. Optimist on the run (talk) 12:27, 27 March 2014 (UTC)

I would need to find out the exact code changes that will be rolled out. I can't seem to find it in Gerrit. Found it. There will undoubtably be someone that will concoct a "Classic Vector" gadget. — Edokter (talk) — 14:27, 27 March 2014 (UTC)

Arial

This was brought up in one of the archived threads, but I don't think it was ever explicitly addressed: I think Arial should be removed from the font stack. On systems that have Arial but none of the fonts with higher priority (i.e. Windows), Arial is the default for sans-serif in most common browsers, so falling back to sans-serif would render the text in Arial anyway. As it stands, the only effect of specifying Arial in the font stack is overriding the preference of the minority of users who have explicitly set a different default sans-serif font. I don't think this is desirable. (Sorry for raising this so late--I was only reminded about it on seeing the deployment announcement.) wctaiwan (talk) 16:08, 27 March 2014 (UTC)

Consistency is one of the goals that this font stack is aiming for. If Arial were removed, then whatever the browser default is would be used, and that is, as you point out, not always Arial. Arial is there because we want it to be Arial. In fact, most website that use a sans-serif fontstack fall back to Arial. Most browsers do have an option to override the website's fontstack though, so you can still set your own font. — Edokter (talk) — 16:20, 27 March 2014 (UTC)

Absolute consistency should never be a goal in design, and I doubt it would be here, either, if we got a word from the designers. The basis of responsive design is to make a design that adapts to different devices so that the users get what is the best experience for them, regardless of how it may differ - this may mean different layouts for different screen sizes, higher contrast for mobile devices, using or overriding native keyboard interfaces depending on effectiveness for the task at hand, adding available character sets, and, yes, setting the best fonts for the platform. In light of this, given that Arial is already the default and it would only be overridden on the user end with good reason, including it in the font stack is likely nothing more than an oversight. -— Isarra ༆ 16:37, 27 March 2014 (UTC)

Although I'm not on the design team, I believe Edokter's statement is closer to their take on things. The designers were looking for fonts that matched a particular style (basically Helvetica) and Arial was the best match for that on Windows. It also benefits from supporting a broad range of glyphs and having support for a lot of the more technical features in Unicode. See Typography refresh/Font choice for more information. Although the designers want to ensure a consistent experience for readers, it is still possible for users to override these fonts in their local CSS (or via the Universal Language Selector). Kaldari (talk) 17:32, 27 March 2014 (UTC)

I'm quite willing to test interesting fonts, but when I configure Palatino Linotype as serif, Tahoma as sans and default, and Source Code Pro as mono-spaced it means that I don't like Arial or New Courier. –Be..anyone (talk) 21:10, 29 March 2014 (UTC)

Be..anyone, then it's desired for you not to like MediaWiki sites, and consistently so. :) --Nemo 18:11, 31 March 2014 (UTC)

Gray text is a strain to the eye

Even if it has been pointed out multiple times already I think with the impending deployment on all Wikis I have to stress it again: The dark gray text color is strain to the eye! I immediately notice my eyes being tired by the unnecessarily reduced contrast. Here's an example so everybody can judge him/herself:

Pure black text (color:#000):
Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Dark gray text (color:#252525):
Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

The dark gray example will be the future default with typography refresh and I think it will be an unnecessary strain to the eyes of most users. And to prevent the default counter argument: Users with known problems regarding black on white text (like users with dyslexia) probably have set their display to reduced contrast already by default, so there's absolutely no reason to reduce it even further for them. --Patrick87 (talk) 23:28, 27 March 2014 (UTC)

"l" vs "I"

Hi, folks! I wanted to add that the new typography should consider the "l" vs "I" issue. If a typefont doesn't distinguish between those two letters, then it shouldn't be used. --NaBUru38 (talk) 18:28, 28 March 2014 (UTC)

That practically rules out 99% of all sans serif fonts. I don't think that is really a practical option. — Edokter (talk) — 19:15, 28 March 2014 (UTC)

Perhaps it wasn't such a good idea to switch to sans-serif for body copy, then? —SamB (talk) 20:18, 29 March 2014 (UTC)

That's not a switch. We've always (in monobook and vector at least) specified "sans-serif" for the body typeface. –Quiddity (talk) 21:00, 29 March 2014 (UTC)

Well, not quite - originally, before vector and monobook existed, the font for stuff (what's body copy? the content area? why 'copy'?) was indeed sans-serif. I believe Quiddity is correct though that sans-serif has always been used in monobook and vector. There is also a very slight difference between I and l in the usual sans-serif font that everything has used until now, but it's so slight that people who don't sit abnormally close to the screen (i.e. most people who aren't me) probably don't see it. Cathfolant (talk) 20:46, 31 March 2014 (UTC)

NaBUru38, you're right, this is one font issue that Unicode calls inadequate rendering support. Typography refresh/Font choice doesn't yet explain any of the criteria used in the one evaluation which is still in the text of the page; it should be clarified whether this issue was taken into account for the technical evaluation. For what Edokter said, however, I can't imagine it would be given many points.

On the other hand, our friends of SIL are working on very high quality fonts which see broad usage/support in some GNU/Linux distributions, the most famous being Gentium. Gentium sans-serif was not made available yet, so they instead suggest Andika for sans-serif use. Andika seems to be an actually readable font, e.g. it distinguishes I and l, but I've not studied it thoroughly. I've added them to the page because we'll need an evaluation at some point, after the criteria have been clarified. I expect Gentium and Andika to get the maximum technical score but we can't just guess. If you have other free fonts to suggest please do so, it's important for us to get a sense of what's available in the font scene. --Nemo 06:15, 1 April 2014 (UTC)

Table of contents redesign needs work

Overall, I like the direction that this is going in, very much! But I think the new table of contents is not good. It needs to stand out more. Right now, it looks like a block-quote, and something subservient to the rest of the text, rather than the master navigation control that it really is. Klortho (talk) 17:10, 29 March 2014 (UTC)

The TOC redesign will not be included in the typography refresh at this time (in fact, it is not included on this very page, which already has the typography refresh). --Entlinkt (talk) 15:34, 31 March 2014 (UTC)

Footnote reference spacing

Hi, either on my notebook or large computeur screen, footnote references are touching the upper line, making them difficult to see. --Salix (talk) 19:52, 30 March 2014 (UTC)

Download new font

Does anybody know, where I can get the new font as a download? Regards, --Brackenheim (talk) 23:04, 31 March 2014 (UTC)

Which one? Steven Walling (WMF) • talk 23:30, 31 March 2014 (UTC)

Some (probably unwanted) feedback

So...as you may know I've thrown together some code to override this, and I say 'thrown together' because I'm still pretty close to a beginner at css and I was mostly just trying to get typography refresh out of the way. Quiddity was kind enough to suggest ways I could improve it, and I've broken it into a fonts and colours section and a font size section but I didn't succeed in fixing the other things, probably because I did it wrong - 0.8em made things too small...and anyway, apologies for not making it exactly how it should be. But I think it would be much better if there were a preference one could turn on or off; just telling people they can customise their css won't work for those of us who don't want to bother learning how, and some may not even want to bother copying my code, especially considering that the elements I set probably aren't what they should be and it's not a complete fix anyway - there's a bit much padding under the headings, for example, and who knows what it looks like in other browsers.

I also feel like at least the grey text bit is a change to benefit those with vision problems at the expense of those without, though I doubt it's intentional. I don't notice the difference between the grey and the black and don't find either a strain, but someone irl has told me that he finds grey text on a white background to strain his eyes, and he doesn't have the sort of vision problems you're trying to address. He says it would be better to darken the background rather than lighten the text. The comment above about how dyslexics etc probably have their contrast turned down also seems valid and I'd appreciate if it were taken into consideration.

Finally, like someone else on this page I would like to know if this will be in core MediaWiki or if it's just for Wikipedia or the Wikimedia wikis. The link Quiddity posted on my talk looks to me like you're changing core mediawiki, and this worries me because this seems to be a change for specifically wikipedia and other mediawiki wikis may not want it, and will have to do some kind of awkward patch business. Another thought I had was that perhaps this could be made into a separate opt-in skin, rather than a change to vector - forcing it on everyone who chooses to use vector doesn't seem fair; I realise it may be hard to create a skin that works for everyone, but you may want to weigh the benefits of one against the other, and please at least make it possible to opt out via a simple checkbox in Special:Preferences.

Thanks for reading, apologies if it's tl;dr or not what you wanted to hear. Cathfolant (talk) 03:15, 1 April 2014 (UTC)

On your question, see #Wikipedia or MediaWiki?: we never managed to get a reply, though at least half a dozen persons asked on mailing lists. It seems the change was thought with Wikipedia only in mind, but applied to MediaWiki core by default. That's hard to believe, but I guess the only defense mechanism for users and non-Wikipedia wikis is to use monobook instead of Vector (a strategy broadly adopted since 2010 by the majority of power users and more). --Nemo 07:01, 1 April 2014 (UTC)